I've spent a few days looking at the game program code (disassembly from IDA Pro) and MAME driver for this game. The MAME driver (C program) is useful in that it provides rough documentation for the hardware used within the machine.
The hope was to be able to take the arcade Rom, put a bit of an emulation wrapper around it and have it run on the computer - both on standard hardware and VBXE.
But... some problems. Looks like there's practically no way the game would work on a standard machine without extensive reworking, and it's likely the reworking would make it too slow anyway.
A few things about the arcade game:
- it uses 256x231 resolution. The horizontal res is somewhat incompatible with Antic modes, it's 4-colour for most of the screen, 8-colour for the bottom 32 pixels. The solution I had in mind was use Antic E with scrolling and pan the view when the cursor gets near the edges of the screen.
With VBXE it wouldn't be so much a problem, it can do 256 pixels in narrow mode although the aspect ratio of the game would be somewhat screwed up, it'd be near 1:1 where the arcade pixels are about 4:3.
- the video RAM uses a weird access/addressing scheme. At first glance it seems ridiculous but the way it works allows accessing pixels on byte boundaries rather than having to do shifts/masks etc. This allows the code to run faster when doing pixel access operations.
The system board uses 1-bit RAMs, so there is little/no wastage. The accesses are only redirected when a CPU instruction with lower 5 bits=00001 is active. Such instructions are the (ind,X) ones - this allows the system to use this addressing scheme for the video Ram with almost 60,000 unique addresses but still allow the system to have a "normal" type memory map where the normal RAM, 12K ROM and IO devices can reside and not resort to any bankswitching tricks.
- it uses a single Pokey at 1.25 MHz and 6502 at ~ 1 MHz. The lower Pokey speed would mean frequency translation or reworking parts of the code would be required (shouldn't be too much work). The lower 6502 speed means the computer has some nice spare cycles to do emulation layer stuff and hopefully still be able to maintain the same pace as the arcade.
- trackball. There are a couple of hardware registers that maintain 4-bit X/Y for the trackball, simulating this should be possible, this is where the extra spare cycles come in handy.
- Interrupts. The game appears to generate IRQs at VSync and periodically during the display (every 64th scanline) - I suspect the scanline IRQs are mainly for reading the trackball position.
I'm thinking this game could probably be made to run under VBXE without too much effort. There are about 30 (ind,X) graphics access instructions in the game although there might be normal access to the video RAM as well (quite possible things like the explosions are done by normal writes to the video RAM).