When developing for classic arcade hardware (Pac-Man in my case), the process of trying out your program code on the target hardware is tedious and long. To do so, you need to:
- Build the source files into binaries (z80asm)
- Convert the outputted files into ROM images (genroms)
- Move the ROM images over to a machine that can talk to a ROM burner (I develop on OS X, but the ROM burner is Windows only)
- Pull the EPROMs from the arcade board
- Drop the EPROMs into the eraser for 10-14 minutes
- Make sure the EPROMs are blank
- Burn each individual EPROM
- Insert them into the board
- Power up the board
It's only at this point, perhaps 15 minutes from step 1 that you know if your build worked. Granted you can have a second set of EPROMS that are ready, to minimize the wait. You can also do a lot of testing on an emulator before you get to this point.
The problem is that this is very time consuming, cumbersome, and puts a lot of stress on the EPROM chips themselves which may fail after many re-uses, or pins may break when removing/inserting them. There's also the possibility that these 25+ year old arcade boards may fail as well with this kind of use.
My solution to this problem is a board with USB capabilities that you plug into the arcade board (the "target"). You pull the Z80 CPU, plug in this board, then plug the Z80 CPU into this board.
This board has flash memory on it to hold at least one ROMset. It also has a chunk of RAM, into which a stored or live ROMset can be loaded into. It also has the capability of resetting the Z80 CPU, and can listen to commands from the Z80 CPU.
Software on the host computer can reload the flash with a new ROMset, or load the RAM directly with a new ROMset. It can also reset the CPU.
So the idea is this;
- The build tool ('Make') on the host computer will assemble the source code into a binary file
- Make will then generate the ROM image necessary via the 'genroms' tool.
- Make will then connect to this USB device
- It will then copy the ROMset image down into the device
- It then resets the target CPU
This all can happen directly from the build tool, almost instantaneously, without any external physical interaction by the engineer.
The current design I've been working on for this has a few components on the USB board.
- USB board is primarilly the Atmel AT90USBKEY
- pin headers added to the IO pins on the board
- Board 2: The target CPU piggyback board for the Z80
- Has a socket for the Z80
- Has a plug to plug into the host board
- Has headers to bring out the needed singalling lines (16 bit address, 8 bit data, plus a few aux IO: reset, ram read, ram write, Port IO access)
- NOTE- different versions of this board can be made for other target CPUs - 8086, 6502, etc, for working on other classic arcade architectures, or home computers.
Board 3: Logic interface board
- has headers that go to the target cpu board
- has headers that go to the AT90USBKEY board
- has 64k RAM sitting on the target CPU's data/address bus, read/write/csel going to the CPLD
- has CPLD with IO lines going to address and data busses and aux IO
- I2C connection to AT90 micro (for all interactions)
- has a few registers built in for target-micro communications - saving/loading high scores, selecting ROM banks and files via PORT IO
- is initialized with a memory map file that tell it which banks of 4k memory space are to be diverted to the RAM instead of mainboard.
The AT90 will initialize in one of two modes; USB-Control or Standalone.
In this mode, all interactions with the target CPU, RAM buffer, etc are handled by the USB host computer.
This is the primary mode for the development testing environment.
This is also the primary mode when the device is being programmed for standalone use.
The flash on the system is capable of storing multiple complete ROMsets. In standalone mode, a pre-determined initial ROMset is installed into the RAM buffer, and the target CPU reset immediately on startup.
The target CPU can then, via Port IO, tell the CPLD a different bank to switch to (as well as other commands). The AT90 will see these commands set in the CPLD's registers, and reload the appropriate ROMset image into the RAM buffer, and reset the Z80 CPU.
In this mode, the boardset is effectively a "multigame" system. The initial ROMset can be a menu system that lets the user select other ROMsets to load.
- The graphics chip (or other chips) will not be switched by the initial version of this system.
This project's source and documentation will be made available for free for non-commercial use.