Classic Hardware ROM Device 25-Aug-2010 2:42 PM
Edit FancyEdit New New Blog Upload All Recent Home Logout

Table Of Contents
project diagram


1. Overview - The Problem

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:

  1. Build the source files into binaries (z80asm)
  2. Convert the outputted files into ROM images (genroms)
  3. 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)
  4. Pull the EPROMs from the arcade board
  5. Drop the EPROMs into the eraser for 10-14 minutes
  6. Make sure the EPROMs are blank
  7. Burn each individual EPROM
  8. Insert them into the board
  9. 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.


2. Solution / Theory

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;

This all can happen directly from the build tool, almost instantaneously, without any external physical interaction by the engineer.


3. Current Design

The current design I've been working on for this has a few components on the USB board.


4. Operational notes

The AT90 will initialize in one of two modes; USB-Control or Standalone.


4.1. USB Control

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.


4.2. Standalone

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.


5. Known Issues

  1. The graphics chip (or other chips) will not be switched by the initial version of this system.


6. License

This project's source and documentation will be made available for free for non-commercial use.


7. References