I asked Ian how he first got into coding his ASP (Amiga SPectrum emulator) for the Amiga:-
Having grown up during the era of the Spectrum, spending a lot of time coding them, playing games, etc. I was predisposed toward a natural interest in Speccy emulators later on. Eventually I became frustrated at how the available emulators always had one limitation or another. Let's combine the good points, I thought, and add something to that.
I initially envisaged an emulator that synchronised realtime to the Amiga video beam and would therefore, in theory, load hyperload games from tape, do border and attribute FX, and have stable sound... This contradicted wildly with my other premise, which was to make it fully multitasking and as system friendly as the situation allowed.
I'd been playing around coding in 68K Asm since about 1989, although I never spent long enough at one task to create anything close to release. I started considering systems for an emulator in about 1994 and tinkered and messed about, but it wasn't until about 1996 did I seriously consider programming one. At first I was reluctant - the Amiga market was shrinking fast, the other emulators available, although flawed, had many good points and surely, I thought, not many people would be interested in such a thing now? Well, time has shown that there are yet fans of Spectrums (and even Amigas!) and that, whether you consider ASp good or bad, it's feature set is comparable to those other systems. So I guess it was worth doing...
By dint of much patience - and possibly resulting in a mild psychosis ;-) - I created a massive spreadsheet containing every possible opcode combination the Z80 CPU could encounter (1792 rationally) with all timing information, access modes and, most importantly, pointers to subroutines in my code. That spreadhseet, having been modified and updated over time is now about 550Kb. It took a surprisingly little time to throw a rough shell around the emulation core to make a one-shot embedded-snapshot unsynchronised system. I then spent a lot of time trying to synchronise it to the Amiga video beam (AGA-only, PAL-only system this!) and had all sorts of trouble. Eventually a very rough-sounding, glitchy and buggy, but nonetheless synchronised emulation was available.
I don't recall exactly why now, but I gave up on the video-synched system. I replaced it with a per-frame system which DMA's a sound sample out, constructed from the previous frame's data. This worked tonnes better, but lost the border colour synch and, initially, the speed synch too. I refined the system a bit and gave it a rudimentary GUI (the first I'd ever coded) and thought it would be a laugh to release it.
Shortly after this, a contact I met on an IRC channel was good enough to spend a great deal of his time testing subsequent versions. I kept adding little bits and bobs and he would report how well they worked. In particular, I made literally dozens of very slightly different versions, each with greater or lesser changes to the emulation core in an effort to speed it up. I have an '060, on which the emulation has always run fine, he had an '030, which is much more sensitive to minor changes in code. He'd patiently do many speed tests and faithfully report the results. Over the next several versions, with his help, I managed to substantially increase the effective speed of the emulation core until it almost ran full speed on an '030. Since the first very basic incarnation of that early glitchy one-shot mess, the core has been virtually rewritten from scratch three times.
It's probably worth mentioning at this point that many people at the time asked why the system was not faster. My answer has always been "accuracy". Now, ok, in truth there is a substantially different approach to the core I could make which might improve performance by 15% or so on an '030, but it is a great deal of work and may not be worthwhile. Nonetheless, I have taken pains to make ASp very accurate in it's emulation and it is that "lack of shortcuts" which makes it slower than some other systems. In particular I'd point out to the technical minded that the H flag is valid at all times, and therefore the DAA instruction works as intended without limitations. The "unimplemented" flag bits are also calculated and correct (AFAIK) for each instruction. Code will run from the CPU stack, self-modifying code works, the stack can be in display RAM, ROM is write-protected, etc... And there have been literally dozens of revisions, months of coding, just to try out new and ever more devious means of shaving every last cycle off the execution time.
Of course, sooner or later the issue of 128K emulation arises. For those interested parties who do not already know, the 128K Spectrums were able to instantaneously switch "banks" of RAM and ROM into various address areas within the main memory map. To simulate this, it is necessary to either physically copy the chunks of data around, which is slow and prone to many other problems, or make some sort of page-indexed access system. I worked toward such a system, but it became clear that even an optimist was going to see an emulation which ran half the speed it did before. This left the third option, the use of the MMU. Coincidentally, at about this time Thomas Richter, programmer of many an Aminet utility, released a shared library intended to make MMU coding relatively simple. Encouraged by Simon Goodwin, emulation enthusiast and journalist, I made tentative steps towards this approach using Thor's library.
I was a little bit worried that not enough people would have an MMU, so I intended to make an MMU and non-MMU version. Since I haven't received any complaints to that effect yet, the other system is very much on the back burner! Anyway... Thomas was very helpful in response to my barrage of emails asking how various features were used. Once I figured it out, I was shocked that a mere couple of hours coding converted my 48K emulator into a 128K system. Yes, it had major problems, but hey, it worked. I was so pleased I put a "prerelease" on my site. All I've had since are emails complaining that "Where Time Stood Still" doesn't run fast enough! :-)
After that, of course, you get closer to the present. More speedups, more features, more bugfixes... I eventually gave in to pressure from gfx-card owners to make it RTG. (Many thanks to Stephen Brookes, author of FBlit, for enormous help here.) I fear the speed penalty for AGA is excessive, but I was quite pleased with the way it allowed me to do the "window" mode. (Let me take the opportunity to recommend Rick Pratt's BlazeWCP for optimum performance!) Since I do not have a gfx card myself, I was mildly surprised that the system (apparently) works ok under CGFX etc. The most requested features now are disk support and TZX support. Both are rather difficult. :( I don't spend much time on ASp anymore, what with the age of the Spectrum, the dubious existence of the Amiga, and pressures of life in general. I'm currently tidying up a few features, including rewriting the tooltypes and prefs systems. The next major feature might be a dynamic compilation "JIT" emulation core, partly for the speed bonus and partly because, after all, I'm coding ASp for the fun of it and I find such a feature interesting.
I'd just like to thank those people who have at some stage in the development of ASp supported my efforts by doing tests, offering suggestions, making bug reports, or simply mailing me to say they use it. It's old and corny, but true, that ASp simply would not have advanced as far as it has without their help.
ASp is available from my homepage, http://www.greew.freeserve.co.uk or World Of Spectrum, http://www.void.jump.org or Aminet in misc/emu.