Of Writing a CPU

I've always been fascinated by software emulators. The earliest example I've used that I can think of was a ZX Spectrum emulator on an Atari ST around 1987. I had a real Spectrum for some time at that point and had just bought a ST the year before, when I found this program on a BBS for download that was able to run all the Spectrum games on the ST. Needless to say, I was intrigued.

It was a pretty novel concept for me at that time, but emulators had already been around in University settings for a while. But on home computers this was a new thing, and the concept became hugely popular with the geek crowd of the day. By the late 80s, there were PC/DOS emulators on ST, Amiga and Mac, there was a full range of 8-bit emulations on everything 16-bit and there was even a Mac emulation on the ST.

The idea never really lost its importance or attraction, and nowadays we have programs like the excellent VMWare Fusion to run Windows on Macs and generally most modern operating systems are moving more and more into virtual machines for greater security and versatility.

So while I've been using emulators for more than 20 years now, I've always been intimidated by the idea of programming such a thing. But sooner or later I had to try.

A few weeks ago after seeing the progress that Tony Headford is making with Miggy - his Amiga emulator in Java, I thought that now is the time...

I've started work on a new ST emulator and I'm doing it from the ground up, with new 68K and hardware emulation code. I do lean for some of the concepts on exisiting code - starting with some of the CPU code from Miggy, but also checking out other open-source emulators for useful bits.

So I'm writing a CPU. Which is really quite exhilarating and quite possible one of the biggest programming challenges I've ever taken on. It feels like I'm working on the biggest Rubic's Cube ever!

Right now I have about 50% of the CPU working, and I'm making steady progress. I'm loading Atari TOS 1.04 into it for testing and just boot the virtual machine and see where it gets stuck, which is then the next thing to work on. This is a very appealing way to approach this problem, since the virtual CPU in debugging mode automatically coughs up my next task every evening as another opcode to implement, so there is never a question of prioritization.

I've also started to implement the virtual hardware for the ST, and that will be quite a tough nut to crack, since the interrupt behavior of some of the custom chips is pretty complex.

More details coming soon...