How the CPU shares the machine

Who actually owns the memory

It is tempting to picture the CPU as the centre of the machine, issuing orders to peripherals. On this board that picture is close to backwards.

The beam does not wait. Every 167 nanoseconds another pixel has to be produced, which means tile numbers, attributes and pixel data must be read on a fixed and unforgiving schedule. The CPU's needs, by contrast, are entirely flexible: it does not matter whether an instruction executes now or in another 300 nanoseconds.

So the video hardware gets absolute priority and the CPU is fitted around it. This is not a detail - it shapes the whole board. As Jose Tejada notes in MAME's driver, the CPU's clock is gated by the bus arbitration logic and is halted until the video side has an opening. The Z80 is genuinely a 3MHz part, but it does not get three million useful cycles a second.

The uncomfortable truth about this architecture: the processor is a guest in its own machine. The video hardware must read memory on a fixed schedule because the beam will not wait, so the CPU is stopped whenever it would collide - and once a frame it is dispossessed entirely while the sprite board helps itself to the object list.

Three different ways of sharing

The machine solves the sharing problem three separate times, in three different ways, depending on what is being shared.

Time-slicing, for the video RAMs. The character memory alternates on H4 and the background memory does something similar on the C board. Both sides get a guaranteed regular window and neither ever asks permission. It costs a few multiplexers and it is invisible to the software.

Clock gating, for general contention. Where a collision is possible, the CPU's clock is simply stopped until the coast is clear. The Z80 does not know it happened; from its point of view a cycle merely took longer.

Bus mastering, for the sprite list. This is the dramatic one, and it needs its own section.

Giving the whole bus away, twice a frame

The sprite board needs all 384 bytes of the object list every frame, and the game code that writes it runs over here on the A board.

The obvious solution is to copy it across: give the B board its own memory and have the CPU write the list into it. That costs RAM chips on the B board and several hundred instructions of pure copying, sixty times a second, on a processor already short of cycles.

Capcom's solution is to move nothing. The sprite table stays in the A board's own work RAM at 7M, and the B board comes and reads it in place.

The Z80 was built for precisely this. Assert /BUSRQ and it finishes the current instruction, tri-states its address, data and control pins and answers with BUSAK: the bus is yours. The B board raises /ROB on the ribbon cable, which becomes the bus request, and the grant comes back buffered as /AKB. On the B board the handshake is run by a '74 at 6C, and 6A releases the request the moment all ninety-six objects have been read.

Then comes the part that explains half the chip count on sheet 1/8. With the CPU off the bus, somebody has to drive it - and every buffer on the A board is pointing the wrong way. So the B board asserts BLCNTEN, and that one line turns the board around: it flips the direction pins on the address buffers at 9K and 10K, flips the data buffer at 8L, and forces 6N to select the work RAM no matter what the address decoder thinks.

For a few microseconds a different circuit board is addressing this board's RAM directly. Then it lets go, and the CPU carries on with no idea anything happened. No duplicated memory, no copying, and the only cost is buffers that had to exist anyway to drive the cable.

The trigger, and the rest of sheet 2/8

The transfer is started by software. A write to C806 produces /OKOUT, which is what kicks off the handshake - so the game decides when its object list is complete and ready to be read.

That strobe comes from the write decoder at 7B on sheet 2/8, which turns CPU writes in the C800 range into eight individual strobes. There is a genuine fragility worth recording here: that decoder is not qualified by the write signal. Nothing in the hardware stops a stray read in that range from firing a strobe. It works because the program never does that - discipline in software standing in for a gate that was not fitted.

The rest of sheet 2/8 is the machine's contact with the outside world: five read ports at C000 to C004 for the coin slots, both joysticks and the two banks of DIP switches, and a control register at C804 held in a '174 at 7A. That register carries the coin counters, the sound CPU reset, and the screen flip bit that ripples out across all three boards. MAME's handler for the same address does exactly these things: bits 0 and 1 to the coin counters, bit 4 to the sound CPU's reset line, bit 7 to flip the screen.

What the interrupt PROM does, and what is still open

One more thing on sheet 1/8 belongs to this story, because it is how the CPU is told when to do its part of the frame.

There is no timer chip. Instead a 256-by-4 bipolar PROM at 6L is addressed directly by the vertical counter - V1 through V128, the whole scanline number - and its four outputs are registered through 7L, 6M and the vector latch at 11K. The interrupt schedule is not logic at all; it is a picture of the frame, 256 entries long, one per scanline.

The vector is elegant too. In Z80 mode 0 the CPU executes whatever byte it reads during the acknowledge cycle, and the single-byte RST instructions fit perfectly - so most of the vector byte is simply strapped to fixed levels with resistors and the PROM fills in what varies. A lookup table and some pull-ups doing a peripheral chip's entire job.

In the interests of not overstating things: exactly how many interrupts per frame this produces is not settled in this model. The PROM's four outputs have not yet been traced all the way to the Z80's /INT pin, and MAME gets a working game from a single vblank interrupt per frame, vector D7, which is RST 10. The PROM's addressing proves a per-scanline schedule exists; the exact schedule burned into it is still an open question here, and it will be answered by reading the PROM rather than by reasoning about it.

The drawings behind this story

Each one opens the interactive schematic, where every chip and every net on the sheet can be traced pin by pin.

Every chip in this story

30 chips across 2 sheets. Click any of them to open the schematic with that chip selected. A few appear on more than one drawing, because Capcom split some packages across sheets.

← back to the dashboard