tor, it my desire to swap out Comeback64 and use VICE
instead as the core OS.
- - - - - - - - - -
Q. How complicated is the software to get running, Do you just download it to an SD card and boot the card? When booted does it just look like a real
machine starting up?
A. Getting it working is very easy. When you purchase a Raspberry Pi, you can also get (or download) an SD card with a Raspbian (Linux) OS. You need only copy the kernel.img file from my distribution over the existing one. There is also a config.txt file that you will replace so that the machine defaults to 320x200 on the card. It will then boot up straight to a Commodore 64. I have only tested it on a composite video connection.
- - - - - - - - - -
Q. How long and how much time and effort was it to get the project to a state where it would boot and accept input from the user?
A. It took me about a month to get things in a semi-working state. I can tell you it was very cool the very first time it booted up and I could make out the Commodore 64 startup screen. Colour wasn't working correctly at the time,
there were no borders, and the picture was very...off. But I could make out
the screen. Very exciting! Keyboard input was another painful process because of the USB input. USB is notoriously complex, and so I used a library which is known to be minimal and have some issues. Rather than correctly handle input via the emulated CIA chip, I am currently just injecting the values directly into the keyboard buffer.
- - - - - - - - - -
Q. Why create this project, what was wrong with just running an emulator?
A. There are a few answers to this question:
1) An emulator reduces some of the parity between the hardware and the software. If you have used an emulator for game consoles like the N64 or Super Nintendo, you know that there is a different "feel" because your input controllers must be mapped properly. It isn't portable from one machine to another unless the second machine has the exact same hardware configuration.
2) The architecture of modern systems has become so big and difficult to understand that fewer people get involved with assembly language and systems programming. The 6502 (and 6510 variant) was an incredibly simple CPU to work with. Based on the software and hardware hacks being developed, there is still great interest in this chip. The only place people have to go to continue working with this chip is on older hardware. I want to change that. As fast as modern machines are, we can emulate older machines at the OS level, providing
a new generation an opportunity to work with the amazing hardware that we worked with. You won't find anyone teaching x86 assembly to high-school students because it's just too confusing. But they could teach simple 6502 assembly using off the shelf modern hardware.
3) Today's operating systems are not really meant for education. I learned programming on a VIC-20 because I didn't have a GUI with 100 things going on
at once, or massive libraries and APIs. All I had was a READY prompt. I was seven years old. How many seven year olds can program today's computers under modern operating systems? By developing an operating system out of an
emulator, the software lives on, as does the spirit of education.
4) When we think of the Commodore machines, we generally don't separate the hardware from the software. I think this is a mistake which has prevented us from carrying forward the elements which made working with these machines so great. The lifespan of the hardware is limited, but the software can live on.
- - - - - - - - - -
Q. You mention in the goals of the project that speed could be improved could for example the CMD SCPU be emulated by the software, also could the CMD range of storage devices be emulated?
A. The possibilities of this project go well beyond C64 emulation. Many folks have developed CBM hardware add-ons to provide access to SD cards, Ethernet, floppy and hard drives, etc. Inherently, this project provides that capability "out of the box" because the hardware is emulated and hooks can be created which capture requests to modern hardware. A simple demonstration of this
would be mapping some unused memory locations to the GPIO (General Purpose IO) pins on the Raspberry Pi. Then with simple POKE commands, we could talk to other hardware such as Arduinos....or even native Commodore hardware like a 1541. The Raspberry Pi has 512MB of RAM - quite a bit more than the 64k of the C64. Accessing the additional RAM could be as easy as POKEing to an in-memory "MMU", which swaps out portions of the emulated RAM, similar to the C128's
bank switching technique.
- - - - - - - - - -
Q. Speaking about The other goals the do sound quite advanced with things listed like USB connections and modern graphics mode, with these implementations will you break the commodore 64 backward compatibility for older software?
A. The goal is to retain compatibility to be sure. I believe there are ways to provide additional features without sacrificing most of that compatibility. Adding new video modes which rely on bank switched memory, in theory, should not affect compatibility. Talking to modern hardware via either unused locations or alternate memory banks should also maintain that compatibility. Also, In the past, it wasn't very feasible to update the kernal ROM because people were not generally comfortable opening their machines and replacing
a chip. But via software, we can actually improve on the ROM.
- - - - - - - - - -
Q. How would someone load applications into this environment, if current programming permits this and to what extent is the project complete?
A. Right now, there is no file system. The goal would be to include a FAT file system which would allow access to the SD card. Kernel traps would be enabled to catch BASIC commands which talk to the IEC serial bus. As you can see, this is one area where compatibility is a problem, unless you are connected to real Commodore hardware. The current state of the project is really a proof of concept to hopefully generate some interest in bringing back the 64 and 128 as operating systems.
- - - - - - - - - -
Q. What current problems are you experiencing with trying to improve the system?
A. Just about everything. Without a file system, it is difficult to test the system in any meaningful way. But before that, speed and timing needs work.
And before that, I think we need to switch to the VICE emulation core as it is a proven emulation which is actively maintained. Some of those guys have expressed support of this project and have been very helpful in providing some ideas. Imagine booting VICE up as an operating system on an old Celeron or
dual core x86. Who needs Windows when you can run GEOS at modern CPU speeds!
- - - - - - - - - -
Q. What help do you need and how can someone who feels they have the skills contact you?
A. My email is
scott.hutter@gmail.com and I welcome hearing from anyone who
has experience working with VICE ports, emulation in general, knowledge of the Raspberry Pi system, or general operating system development. It's quite an interesting skillset combination. And of course you would have to share in
the vision. I think there are many out there who miss "the good old days".... I'm saying: let's not toss out the baby with the bathwater - the 'good old days' need not go away just because Commodore is gone and the hardware has aged. Amiga continues to live on with 4.x of their operating system despite
the end of life of the hardware.
- - - - - - - - - -
Q. Do you plan other systems like the Pet, Vic, or...
A. Yes! VICE has combined all of these systems into a single project, and so I'm convinced that the same could be done with an emulated operating system. When your C128 dies, you don't need to scour eBay for one - you can pick up an Raspberry Pi, and run the 128 OS. If you want to play some C64 games, run the 64 OS. If you want to tinker with TED without fear of it burning up on you,
run the +4 OS. In fact, all of these systems could b
--- MBSE BBS v1.0.01 (GNU/Linux-i386)
* Origin: Dragon's Lair (39:901/280)