It’s still unfinished but I’ve cleaned up the code, prepared a bootable disk, and refreshed myself on the technical details. It was an interesting contrast to the Pac-Man project I’d worked on previously. As before, the challenge was to modify as little of the original ROM as possible, with a virgin copy of the ROM patched at runtime.

CPU

The Space Invaders arcade machine uses an Intel 8080 CPU running at just under 2MHz. The Z80 was released 2 years after the 8080 and was designed to be object-code compatible, so the Invaders code runs on SAM (almost) unmodified. The Z80 also added many new features, including: IX/IY index registers, alternate registers sets, multiple interrupt modes, CB/ED extended instruction sets, and the relative jump instructions JR [cc] and DJNZ.

The 8080 has a single interrupt mode equivalent to the Z80′s IM0, where an instruction is supplied on the bus at interrupt time. The Invaders hardware supplies both RST 08 and RST 10 instructions at a frequency of 60Hz, which drive the overall game logic, including the attract screen. SAM lacks the extra hardware, but they can both be simulated using IM2 and a line interrupt, without modifying the ROM.

I/O ports 1 to 6 are used for coin and button inputs, as well a hardware bit-shifter circuit. The shifter takes a 16-bit value (written to port 4 in low/high order), and a left-shift count (written to port 2). Reading from port 3 returns just the high byte of the result — more on this later.

As we’re running the ROM code natively, trapping the I/O requires patching the instructions that make the requests. The only I/O instructions supported by the 8080 are IN A,(n) and OUT (n),A, which include the port number as an immediate operand. This allows us to use a simple loop to find and patch instructions that access ports 1 to 6 (later checked manually to ensure no false-positive matches). Each occurrence is replaced by a RST 08 instruction, with the original operand modified to include a flag indicating whether the original instruction was IN or OUT. We could have used separate RST calls for each, but that requires duplicating the RST handler and modifying more of the original ROM.

Since we’re simulating the interrupt calls, we have control over how the original RST 08 and RST 10 handlers are invoked. The ROM code for both start with 4 register push instructions, which can be moved to our own interrupt handler, freeing the space for our I/O hook.

DISPLAY

Space Invaders uses a monochrome bitmapped display with a linear layout, similar to SAM’s mode 2. The display resolution is 224×256, but like most portrait arcade games the display hardware works in landscape mode. Fitting the 256×224 (rotated) area on SAM’s 256×192 screen means we lose 4 character columns from the width of the play area.

As with SAM’s mode 2 (and the Spectrum), drawing to a non-character aligned position requires bit shifting of data. Invaders uses this for more control over the vertical position of the invaders, as well as the smooth scrolling of player and invader bullets. The hardware shifting circuit makes easy work of this, which is a good thing considering the slow CPU speed! That said, the invader pack does only move one invader at a time, keeping the per-frame drawing to a minimum.

The Invaders display is stored at &2400-3fff, which isn’t compatible with the 16K boundary requirement for SAM’s mode 2. That means redirecting ALL display writes to a suitable upper memory location; something difficult to do from a centralised point in the code. About the only option is to identify ROM routines accessing the display and provide alternative implementations.

Copying the first 6K of Invaders display to a SAM mode 2 screen in upper memory confirmed the game was running, but revealed another issue — the bit order within display bytes was reversed compared to SAM, requiring each byte be flipped before writing. The byte rotation could be avoided by rotating the display in the opposite direction, but that would leave scanline rows in reverse order, requiring a much larger display mapping table to correct.

To map the display accesses to a SAM-compatible location we offset the high byte of the address. Subtracting an additional 2 from this value also pulls the display up (well, left!) by two columns, centralising the game area on the SAM display. This clips a character from each side of the title area, and half an invader at the left and right edges, but it’s only a small difference. The movement range for the player turret is more limited so it’s unaffected.

The game now looked great, but play-testing revealed some issues. When the invader pack reaches the edge of the display it’s supposed to lower and turn back, but that wasn’t happening. Also, player bullets were passing through the invaders without hitting them. It turned out that collision detection was done by checking the display contents, but it was still reading from the original display location. Hooking an extra couple of routines to look at the new display area soon fixed that.

A final change was to add a splash of colour to match the original machine. As the video hardware didn’t support colour, cellophane strips were added to areas of the monitor: green for lives, bases and player turret, red for the flying saucer at the top. An equivalent effect can be achieved in the SAM version using blocks of mode 2 attributes, which are unaffected by the display data writes.

Rotating the display to the normal SAM orientation remains a challenge. My original approach was to apply rotation and scaling to each display write, preserving the original layout. That meant scaling/masking/combining each byte, so the iconic graphics would suffer some scaling distortion. A better approach might be to relocate some areas of the display, as I did with the score and fruit areas in my Pac-Man emulator. It still requires rotation, but only within simple 8 pixel blocks. Writes from some hook reimplementations could also be optimised for full block writes.

SOUND

The sound effects in the original game are generated using analogue circuits rather than a sound chip, which makes them difficult to emulate in a traditional sense. Most Space Invaders emulators use sound samples taken from the original machine instead. I haven’t implemented the sound yet, but will attempt to create approximate effects with the SAM sound chip.

The source code and bootable disk image are now available on my website, but you’ll need to provide your own Space Invaders ROM image.

The Apple 1 is a surprisingly simple device, with 1MHz 6502 CPU, 4K RAM (expandable to 32K) and a tiny 256-byte monitor ROM. Slots on the main board allowed for add-on ROMs for BASIC, cassette functions, assembler, etc. The user manual includes comprehensive hardware details plus a fully commented disassembly of the monitor ROM.

There aren’t many original Apple 1 devices anymore, but there are a few modern replicas available. Most of them use the 65C02 CPU, so it’s probably just as well I added support for it recently! The original ROMs don’t use the extended instructions but a 3rd party assembler supports for them so it was worth having them covered.

Input and output is via a dumb terminal style interface, supporting only upper-case letters and a slightly cut-down symbol set. I/O speed is tied to the terminal display, giving a 60 characters/second maximum on the original. Both input and output have data and control ports, with the latter used to indicate whether the terminal is busy outputting a character or has a key available for input.

For the emulation, the limited terminal output speed means at most 1 character (plus cursor) needs to be drawn each interrupt. Until that is processed the terminal appears busy and the running program will wait before outputting more. SAM’s 50Hz interrupt frequency reduces the output speed slightly, but not by enough to worry about. Adding a line interrupt in the middle of the frame (312/2-68 = line 88) double this to 100Hz very easily, so Sym-1 and Sym-2 can be used to change the terminal speed.

When a character is written or a key is read, the terminal must update the control ports with the new status. This must happen as part of the read/write to prevent the running program doing anything further until it has been processed. The 6502 core was enhanced to trap memory writes for the Orao emulator, so the display could be updated immediately. The Apple 1 emulation also needs the same enhancement for memory reads, so it can update the input control port.

The output terminal is 40×24 characters, giving a maximum character set size of 6×8 pixels for a 256×192 mode 2 SAM screen mode. Mode 3 would have allowed up to 12×8 thin pixels, but there wasn’t really much benefit from the extra resolution, and the 24K display was 4 times slower to scroll. Perhaps the only drawback in using mode 2 is that Spectrum-style masking and rotating needed to draw each character.

Input is entirely character based, and doesn’t need support for multiple simultaneous key presses (just Shift for symbols). For that reason I decided to use SAM’s ROM keyboard scanner rather than rolling my own version. All I had to do was page the ROM in and ask for the next key, with the ROM debouncing the input and buffering fast typing. The returned key symbols are then converted to Apple 1 keys, converting lower-case to upper-case, and mapping a few special keys including Delete, Tab and Escape.

Normal monitor use is 100% speed, as most of the time is spent waiting for key presses. To test the underlying speed I ran an empty loop in BASIC: FOR X=1 TO 1000 : NEXT X which takes 1.2 seconds on the original device and 10 seconds in my emulator. The 10-15% running speed matches the results for the Orao emulator, and probably applies to anything else that uses my 6502 core.

The completed emulator (plus source code) is now available on my website.

Keyboard input was transplanted from the matrix scanning in the Galaksija emulator, though due to the weird memory mapping layout, the Orao table needs 3-byte (address+value) entries for each key. The bulk of the addresses were taken from the Windows Orao emulator source, though there were a few minor errors that I’ve corrected (one of them stopping Up working in Boulder Dash).

I considered updating the display during interrupt processing, but the large (256×256 = 8K) display size was too much to do every frame. Splitting the frame into 8 or 16 strips to have minor impact on the CPU emulation would have made it too obvious and laggy. It seemed better to update the display live by catching writes to the display memory. Unlike native running Z80-based emulators, we have full control of the 6502 CPU and can filter the writes as they happen.

One approach was to modify any instruction that could write to the display, but that would require a lot of duplicate code. Fortunately, each of the writes formed the target address in HL, where it remained until the point it jumped back to main_loop (next instruction fetch). I simply had to define a new looping point, and use that instead of main_loop for any display write candidates. Zero-page writes (&0000-&00ff) couldn’t affect the display (&6000-&7fff), so they were ignored.

Display writes were filtered using a simple:
LD A,H
CP &80
JR NC,screen_or_up
Using JR instead of JP meant the fall through case was only 5 tstates instead of 10 tstates. The total display write checking overhead was 4+7+5 = 16 tstates (plus contention) for normal RAM writes, which didn’t seem too bad. Further address filtering could also be done for sound writes at &8800, without further slowing of the normal RAM write path. No other addresses were of interest to us, so they were ignored.

At first glance the Orao display seems perfectly suited to SAM’s mode 2 layout, with both using linear addressing, 32 bytes per line, and 8 pixels per byte. The biggest difference is Orao’s 256 line vs SAM’s 192, where clipping or scaling of the display would be needed. Unfortunately, the bit order within each Orao display byte is also reversed compared to SAM, ruling out a simple memory copy to update the display.

Lookup tables to the rescue! Using a 256-byte table for the bit-reversing was a no-brainer, but the display mapping was more awkward. My first thought was to use a line mapping table, mapping from Orao line to SAM line, with &c0 entries for lines that weren’t visible. That still required too much arithmetic to look up an address, then add the line offset from the low 5 bits of the original address. Whatever I used would be done for every byte written to the display, so it had to be fast.

The 12K needed for the mode 2 display meant there wasn’t room in the normal 64K address space, so I was already paging to access it. That left over 16K of spare space in the 32K paging window. Rather than looking up display lines, I had enough space to map every byte on the Orao display to the final SAM address. This also gave the flexibility needed to pan any 192-line view of the original 256-line display, and even to scale the original display to fit, without any additional overhead.

As with the 6502 instruction handler addresses, the display table was ordered with address low bytes in the lower half and the address high bytes in the upper half. That allowed a SET/RES instruction to switch halves during the lookup, which is twice the speed of using add/sub on the high byte instead. Orao display bytes outside the visible area are mapped to SAM line 192, just beyond the visible display.

Everything seemed perfect at this point, until I realised I needed to preserve the 6502 PC value in DE. The core also crammed 6502 registers into almost every other Z80 register, leaving little room to juggle paging, the original address and a new address lookup. The only register-based option to preserve DE was to use IX, at a cost of 16 tstates each way. That was still 4 tstates faster that pushing DE around the block, once stack memory contention was included.

Here’s the final screen write code:

ld ixh,d
ld ixl,e
ld e,(hl)
ld d,rev_table/256
ld a,screen_page+rom0_off
out (lmpr),a
ld a,(de)
ld d,(hl)
res 5,h
ld e,(hl)
ld (de),a
ld a,low_page+rom0_off
out (lmpr),a
ld d,ixh
ld e,ixl

The 6502 core got a few additional upgrades along the way, with the first being a boost to 65C02 support. This added a new addressing mode, and a handful of new instructions (many sorely lacking from the base 6502). A side-effect of this was that undocumented instructions were guaranteed NOPs (1 to 3 bytes in length), so I didn’t have to worry about the hybrid undocumented instructions in the original chip.

Decimal mode was finally added too, in just 20 bytes of extra code. I simply needed to optionally execute a DAA after the adc/sbc calculations to make the necessary adjustment. The DAA was patched with a NOP when in normal binary calculation mode, for the non-BCD behaviour.

There were no interrupts to handle for the Orao, but I completed the implementations of BRK (call maskable interrupt handler) and RTI (return from interrupt), so they could be used if anything tried. As they’re untested, I set the emulator border colour to green to show it has been used. This actually happens when running Space Invaders, but due to a suspected corrupt image. The BRK instruction is &00, so it’s quite likely to get called if execution jumps to a random memory location.

As a result of the 65C02 change the emulator now runs Manic Miner correctly, a game which crashes under the Windows versions due to incorrect undocumented instruction handling. The decimal mode addition also fixes the score updating in Manic Miner and the timer count-down in Boulder Dash. Space Invaders will need redumping from the original tape for it to work correctly.

The final emulation speed is typically 10-15% that of the original machine speed, with slower speed during heavy display writes due to the screen write overhead described above. The mix of 6502 instructions also makes a difference, with heavy indexing requiring more calculations for the CPU emulation. It still runs surprisingly quickly considering everything it’s doing, and on a machine produced only a few years later.

The completed emulator is now available on my site, with the source code following soon.

Basic SAM support was trivial, requiring just an OUT to LMPR to page in the ROMs, and another OUT to VMPR to set video mode 1. The Spectrum key matrix is compatible so the keyboard worked, and SAM’s break button could even be used for hard break in Galaksija BASIC too. Proper SAM support required a number of changes…

The first was to use mode 2 instead of mode 1, mainly to avoid the mode 1 contention slowdown. This only gave roughtly a 10% speedup, which was rather disappointing. A chunk of the extra time was eaten away by needing ADD HL,DE to move between screen lines in the linear layout instead of INC H (for most) on the Spectrum. In the worst case of drawing all 512 characters it requires an extra 512*11*(12-8) = 45056 tstates! It is still faster overall, and worth the change from mode 1.

The Galaksija display is a text mode of 32×16 characters, with each character 8×13 pixels in size. Tomaz had already changed the font to be 8×12 to fit the Spectrum height, which was perfect for SAM use too. Having 2 characters span 3 vertical blocks made it easier to draw on the Spectrum version, but made no difference to mode 2 on the SAM – each character could be treated completely separately.

The biggest difference from the Spectrum version was to draw only changed characters between frames. This gave a huge speed boost in most cases, and even with the extra comparisons it was faster than the old version as long as no more than 80% of the screen was being updated. Further speedups were made by using a table for character address lookups, rather than tracking the address in a register (which required some arithmetic). A stack method to access the table allows a simple POP to fetch the next address, or discard it for skipped characters.

The speed gained meant that many games now ran too fast, or they ran with variable speed depending on how much of the display had changed. That required adding a throttling mechanism to limit the maximum speed, which was implemented by limiting number of unchanged characters that could be skipped during drawing. This technique worked well for the SAM version, but not so well for the Spectrum. In some cases adding small delays to the Spectrum drawing code increased the running speed! This is related to the long interrupt processing and the games own frame synchronisation, but I still don’t fully understand the details.

In a last minute change I replaced the SAM throttling code to use HPEN to track the number of frames that had elapsed during drawing. Rather than looping over all 512 characters as 2 blocks of 256, I split it into 4 blocks of 128. At the end of each block I read HPEN and compare with the previous value, and if it’s less than the current value I know it’s spilled over to a new frame. At the end, if 2+ frames have passed then I’m running too slow, otherwise there’s time to spare. In the latter case I poll HPEN to wait for the raster to reach a specific point, before leaving the interrupt handler and allowing the game to continue. The actual screen position was determined by trial and error, to ensure that most games ran at the correct speed.

Galaksija software was loaded from tape, and the Spectrum version used the ROM routines at &0556 to load blocks. The same technique could have been used for the SAM version, but since nobody uses tapes anymore it wouldn’t have been much use. Instead I chose to exit to SAM BASIC to handle the loading, which was easier than paging DOS and using hook codes to do it directly. Adding a simple menu and .GTP tape image parsing was just a few dozen lines of code too.

Full source code and build instructions are included with the disk image download, if you’re interested in knowing more.

The original installer was designed to have minimal dependencies, be simple to use, and avoid reboots where possible. I went for a single dialog design, with dynamic option choices that depended on whether the driver was already installed, and how the version number compared to that of the active installer.

Here’s what it looked like on first-time installation:

I wanted the new installer to be much more traditional wizard, with an uninstall entry in Add/Remove programs. I had already used NSIS for the SimCoupe installer, so I knew it would do the job without being too bloated.

The new installer also addresses the following areas:

1. Single installer for x86 and x64

   32-bit applications are prevented from writing to the Windows\system32 directory on 64-bit platforms, which now contains 64-bit system files. Such requests are redirected into Windows\SysWOW64 instead, which is the new location for 32-bit system files. FdInstall’s attempts to write fdrawcmd.sys into Windows\system32\drivers ended up in the wrong place, so a 64-bit installer was created as a work-around.

   Since then I’ve discovered the Wow64DisableWow64FsRedirection API function, which turns off the redirection, allowing 32-bit applications access to the 64-bit directories. The allows a single new 32-bit installer to cover both x86 and x64 platforms.

2. Vista x64 driver signing

   Starting with the 64-bit version of Vista, Microsoft requires kernel-mode drivers to be digitally signed. Unsigned drivers are simply not allowed to load on the system, even if you’re running with Administrator access rights on the current machine!

   Here’s what happens when an unsigned driver is installed:

   

   This insane decision is being pushed as a security measure, despite user-mode applications generally causing most of the problems on Windows machines. In fact, the best known kernel rootkit was a music protection system released by Sony, and driver signing certainly wouldn’t have helped block it! The signing requirement seems more likely to be a DRM measure to protection the digital media path from copying.

   The only free signing work-arounds are to have a debugger attached to the system, or to press F8 during each boot to disable Digital Signature Enforcement. Neither of these are particularly usable for a production driver, even a free one like mine! My only real option was to buy a digital certificate, costing from £140 (GlobalSign) to £275 (Verisign) per year.

3. Known publisher

   When launching downloaded applications from Internet Explorer, or any adminstrative application in Vista, Windows prompts for final confirmation from the user before launching it. The severity of the confirmation prompt depends on whether the application is digitally signed.

   Note the difference between the unsigned and signed applications below:

   

   Fortunately, the certificate needed for Vista x64 driver signing was also suitable for signing other modules, including the new installer.

4. Improved Vista support

   Microsoft recommends that all applications designed to run on Vista include a manifest resource entry describing their privilege requirements. This allows each program to indicate whether they should run with the standard users rights, or whether Windows should boost it to run with Administrative rights (prompting if necessary). FdInstall needs to install a kernel-mode driver, so Admin rights are required.

   It just happens that running the original installer under 32-bit Vista would correctly prompt for these rights, despite the lack of manifest entry. For compatibility reasons, applications with “install” or “setup” sub-strings in their filenames are assumed to be installers and are boosted automatically.

The actual driver installation involves copying the binary to system32\drivers, adding a new service, adding the driver as a lower filter for floppy-class devices, then restarting the devices to activate the driver without a reboot. Uninstallation requires most of these steps in reverse, but in a slightly different order!

Most of those aren’t standard NSIS facilities, so I created a small (5K) plug-in DLL to be called from the installer script. Most of the DLL code was the same as the original installer, so it was simply a copy-and-paste exercise. A slight complication was the device restarting, which couldn’t be done from a 32-bit application since it calls 64-bit class installer DLLs (failed with ERROR_IN_WOW64). That required an additional tiny (3K) x64 application to make the calls, using exactly the same code as the 32-bit version.

The install script is relatively simple compared to most other applications. The target directory is fixed at system32\drivers, the only installation option is the driver itself, and there is no need to install any icons.

Here are the 3 wizard steps (welcome, license, copy+finish):

The final installer size is 96K, a mere 25K larger than the total for the old installers – not bad considering how much better it looks!

The finished installer is now available from the fdrawcmd.sys page.