Hello, my name is Dave, and I'm an emulation addict.

Anonymous

Not necessarily in terms of using emulators, but certainly when it comes to writing them.

It all started in my first year at Uni, when I used the sampler on my ST to store Spectrum tapes on disk and play them back into the Spectrum. Yes, this did feel like jump-starting a Mini from a Ferrari, but I had rather a laugh with it. That led to me realising that if you could write code to do it you might actually be able to play the Speccy games on the ST.

And I wrote my first emulator. The ST was too far short of the grunt required to make it run, and I didn't have the tools either in my head or the computer to actually make it work at that point, but it kind of got me hooked on the idea.

Fast-forward some years and I found an open-source Atari ST emulator called STonX, running on Unix PC's, which was functional but terribly inaccurate in places. By that point the ST was something I knew inside-out and backwards, and I was sure that a quick application of my experience would make it work on DOS and be a lot better. And it did - I remember losing at least a couple of days' work in the office when I got Speedball working. Then I tried to 'improve' it even more by writing my own CPU core for the 68000 and failed. Again.

I didn't go near emulation for a long while after that, but I realised from my reading about other emulators that I'd developed most of the basic techniques involved. I kept collecting hardware documentation about the systems that interested me, and noting down interesting ideas I had, but I was never bothered enough to do anything about it.

So in 2005, I was taking another of the ten-hour plane flights that often impinge on my life, and on a sudden whim late the night before I thought that the ideal way to relieve the tedium would be to have a play with a Jaguar emulator and get it running Tempest 2000 - I was keen to have a go playing it with the spinner on my home-built arcade cab. There's an open-source 68000 emulator that could do the heavy lifting on that side, I had found a website with some fairly good hardware documentation, so not long after take-off I started bashing out some code.

I landed at SFO with two flat laptop batteries and part of the title screen. In the next few evenings I got a lot of the kinks worked out, and by the time I returned home I had a pretty tolerable Tempest 2000 emulator. Didn't run any other Jaguar games mind, but given the gulf in quality between T2K and most of the rest of the system's offerings, that wasn't the worst problem in the world. I fiddled a lot with it on and off over the next year or so until I'd got something that was very, very good at T2K. Still not that hot on the rest of the Jag stuff but I was quite happy with it. (You can find it here ).

As a bit of an aside whose relevance will become clear shortly, I was never a C++ programmer, but early in 2006 it became increasingly clear to me that I was going to need to sharpen my skills in this area substantially, and the Ladybird Book Of C++ I had (if you saw it - it's not that far from the truth!) was holding me back.I needed to do some proper coding and OO design in my spare time. First of all I did a quick translation of Lords Of Midnight (again! see Rodent issue 40 for my previous porting) but it wasn't really a chunky enough project to improve me further than Clueless to Beginner.

The solution, I decided, was The Multisystem. I'd realised when I was doing the Jaguar emulator that the Jaguar custom chips would have fitted neatly into a big hole in the ST's memory map and it set me to thinking about adding ST emulation alongside the Jaguar. The basic CPU is the same, all I'd need to do was write a couple of drivers for the ST custom chips...

Emulation is an oddly good fit for object-oriented programming: in general, the structure of the emulator pretty closely resembles a high-level view of the various chips on the board of the computer. So I reckoned that building Emulators out of CPUs and Devices sounded like a good way to stretch my C++ and OO muscles.

The first step was to get out the hammer and chisel and convert the Jaguar emulator to C++. This was an unpleasant step (sufficiently painful that the Jaguar emulator has never quite recovered, it remains the bastard stepchild with poor game support and an internal architecture that is a square peg in a round hole).

The next big step was the addition of Z80 support for a Spectrum emulator - about the third time I'd tried to write one over the years, the first time I'd stepped outside the comfort zone of the 68000, the first complex CPU core I'd had a go at since my STonX 68000 failures ten years previously. I got as far as writing the disassembler (a good chunk of it on a plane, again) and then left it alone for ages while I let my new-found C++ skills ferment.

Then I went back to it and had a complete Spectrum emulator running in a few days, and after a month, a rather good one too (it's the only part of the emulator that's got no known game bugs filed against it).

The result of all this is Emu - my Multisystem Emulator.

I suppose the big question would be - why?

I mean, the world doesn't need any more emulators for these systems. You can chuck a brick on the internet and hit at least twenty very complete Spectrum emulators. STeem is so accurate at the ST that everything else was seemingly rendered a bit pointless; the same goes for Gens on the Megadrive. And MESS is very similar in concept - an emulator that runs everything - to Emu. So what's the point?

For me, it's because it's a problem-solving exercise: just hard enough to be interesting, just easy enough to be fun. Sudoku for people who think in hexadecimal and mnemonics. The mindset is very similar: you KNOW there is a correct way to do this - because it worked on a real ST - so what's the reason it doesn't work?

I developed a lot of my early programming skills wandering through other people's code taking the protection off. That wasn't about copying games - it was all about the fun of it. If more than a couple of people ever had the stuff I unprotected I'd be quite astonished.

Emulation is the modern outlet.

And now I've also realised Emu could actually be useful.

In one way, emulation is going horribly wrong. Emulators are mostly designed by tech-heads like me, but we're notoriously shite at making these things easy to use. You can go look at the Gamebase 64 threads here or on YakYak to see that some very bright people have got to the smash-keyboard-with-monitor phase with 'em. Emulation is either a beautiful thing or a miserable experience. Sometimes both at the same time.

So I've decreed that Emu will be different. It will try never to ask the user a question, as they probably can't answer it. It will not have huge directory structures that need to be set up right - it will be one EXE and one readme file. Anything it can possibly work out itself it will. I realised that was a strength as soon as I added the ability to open any supported file on it. Spectrum tape? VCS ROM? ST Disk? Open the file, and Emu automatically reboots and starts it. Laaavely.

Sure, it needs to be accurate - otherwise people will just use something that works instead of something that usually works - so I've got a lot to do there. And it needs to be fast enough, although for the systems I'm emulating so far, that's not a problem. But most of all, it can be easy to use.

I'm a Man on a Mission.

But all that said, if the only person who ever uses it is me, to stop me spending hours with another Sudoku book and doing something more 'useful' instead - well, that'll still do.

March 2008

Comments