Feasible to capture data to/from a 1970s RAM chip?

Question

I have a 1978 Bally Playboy pinball machine. The processor is a 1Mhz 8-bit microprocessor Motorola 6800. I would like to build a way to extract/watch game state from outside of the machine. The best place in my mind to do this would be simply watch the game memory. The 6800 microprocessor communicates with a 6810 RAM module and a 5101 CMOS RAM module. I'm most interested in the data stored in the 6810 RAM. Effectively I'm looking to "packet capture" the memory, to be processed later to extract information about the game.

I see a few options and I'm not sure what is feasible with today's hobby-style boards like Arduino and Raspberry Pi. I do have a 8-channel Saleae Logic Analyzer I could use, but I don't think it's enough monitoring points to capture all the data I need.

1. Watch the I/O pins on the RAM chip(s). I could maybe even get away with just monitoring the inputs and keeping track of them in my own application's memory. Basically as addresses are updated/retrieved interpret the signals and store the data myself.
2. Emulate the RAM chip itself, re-implementing the functionality of the IC in code. Of course since I'm tracking the values FOR the microprocessor I have easy access to them.

Am I totally off base? Are these 40 year old microprocessors still too fast to be tracked with modern consumer hardware? Are there any relevant search terms I could use to research if someone else has attempted anything similar?

Answer 1

There is no need to emulate the RAM itself unless you want to be able to change the data in it.

To capture the write data you have to watch the /WR, CS, address and data lines. When the /WR and all CS inputs are active you read the address and data lines, then store the data in an array with the address value as the index. You will also need to synchronize your reads with the CPU. This can be done by waiting for the address lines to change or by monitoring φ1 or φ2.

Timing will be tight. At 1 MHz the 6800's bus cycle time is 1 us, but it can take up to 270 ns for the signals to stabilize, and if RAM access is gated with φ2 you may have less than 500 ns to respond. Worst case scenario is when the 6800 gets an interrupt and pushes 7 bytes in succession onto the stack, then your device will have to read and store each in byte in under 1 us.

An AVR based Arduino could probably do it, but the standard Arduino functions are far too slow so you will need to write some carefully crafted C or assembly code. Interrupts are too slow, so you will have to continuously poll an I/O port. AVR executes most instructions in 1 cycle, so a 16 MHz Arduino should be fast enough.

CPU load can be somewhat reduced by adding a bit of external logic. A few gates or a comparator IC (eg. 74HCT688) could be used to decode the control signals, then the AVR only has to test one pin. This also reduces the number of I/O pins required.

The Raspberry Pi has a much faster CPU, but if the OS is active it will suffer from 'random' interruptions, and it needs level shifters to work with a 5 V bus.

Answer 2

There are a good few FPGA and CPLD boards the market with DIL package pins and 5 V DIL pin capability. They are intended as modern replacements for old, unobtainable ICs. They plug into the board's IC socket with their FPGA carrying firmware to replace that IC's function.

There are many on the market and this site does not do specific product recommendations. Search the interweb for 'FPGA DIL 5V' or similar, they come up. They're reasonably cheap.

Their FPGA can easily meet, and vastly exceed, the timings of your board's 1 MHz bus signals. Many/most of these boards contain enough static RAM in their device to match the RAM chips you are looking at. You will need to be capable of designing the FPGA firmware, in VHDL, Verilog. If you don't/can't know these, you could even design it in schematic for such a small design.

You don't say if your RAM ICs are in IC sockets or not. If they are socketed, you can replace your IC with an FPGA/CPLD board. Otherwise, you can piggyback the chip using a DIP IC clip and and some neat wire links. That's something you can resolve.

Your firmware can them do the job of a simple logic analyser, capturing data into its own RAM when either emulating or piggybacking the board IC. It can pass this out through a spare FPGA board pin configured as a UART. It can't pass it out at the speed captured but it can give you useful history. You can view this through a terminal program on a PC.

This outlines the principles of what you can do with such a board. The exact functions to implement will depend on your capabilities and what you're trying to achieve.