How sprites work

The same engine, one year later

If you have read the Commando pages, this will feel familiar, and that is the point. Capcom did not redesign the sprite engine for Ghosts'n Goblins; they reused a working one. The sheet titles are the giveaway - 96 OBJECTS DATA RAM and 24/96 OBJECT CONTROLLER are the same names, in the same hand, on the same numbered sheets.

The principle is unchanged. The screen will not wait, so for every scanline the hardware walks the whole object table asking each entry "are you on this line?", keeps the ones that are, and assembles them into a buffer one line ahead of the beam. Two buffers alternate, so one is filled while the other is displayed.

The object record is identical too: four bytes, with the attribute byte carrying the flips, the colour, the top bits of the picture number and - borrowed into bit 0 - the ninth bit of X, so a sprite can hang off the left-hand edge.

What actually changed

Two things differ, and both are worth knowing.

More pictures. Commando's sprite code was 8 bits plus a 2-bit bank select, and one of its four banks was never even fitted. Here the code is a genuine 10 bits - MAME assembles it as the code byte plus two more bits lifted out of the attribute - giving 1024 possible sprite pictures against Commando's usable 768. Ghosts'n Goblins simply has more to draw.

A bigger table, but not more objects. Commando's sprite table was 384 bytes at FE00, exactly 96 records of 4 bytes. Here the table is 512 bytes, at 1E00 to 1FFF, which is room for 128. That looked like a contradiction against the sheet lettered 96 OBJECTS DATA RAM, and it took reading two sheets to settle.

The memory really is wired for 128: both RAM chips on sheet 1/9 have their top address line grounded, and the DMA is jumpered to fetch the whole 1E00 to 1FFF window. Nothing there stops at 96.

The stop is on sheet 2/9, and it is a single gate. The record number is carried on OB2 through OB8, and record 96 in binary is 1100000 - which is to say, the first record whose OB7 and OB8 are both set. One NAND gate watches exactly those two bits and produces /OVER96, which goes back to sheet 1/9 and shuts the scan down. Records 96 to 127 are addressable, reachable, and never looked at.

So the sheet title is telling the truth about the engine rather than the memory. The hardware could carry 128 objects; Capcom spent one gate to say it carries 96.

The parts of the engine, sheet by sheet

1/9 holds the object table and the per-object test: two cascaded adders that subtract the sprite's Y position from the current scanline, and a NAND that fires only when the answer lands inside a sixteen-line window. 2/9 is the controller - the counters that walk the table, the gate that stops them at 96, and the per-line ceiling. 3/9 is the densest sheet on the board: the per-line object stores, and the row arithmetic, which turns out to be a genuine subtracter rather than an adder - the latches feed it from their inverted outputs, which is a two's-complement negate done for free.

The per-line ceiling on 2/9 is worth a sentence of its own, because it is the same trick the sister board uses, gate for gate. The slot counter is five bits, so it can address 32 slots - but its preset inputs are strapped to binary 8, so it loads 8 and counts to 31. That is 24 slots, and the twenty-fifth sprite on a line is simply never stored.

4/9 is where the pixels live - six EPROMs and a set of '194 shift registers that push eight pixels out one at a time. Because a '194 shifts either direction, a mirrored sprite is the same artwork clocked out backwards, so no reversed copy of any graphic is stored.

5/9 and 6/9 are the two line buffers, near-mirror images of each other, alternating every scanline. That is what buys the engine its time: it never has to keep up with the beam, only stay one line ahead of it.

The drawings behind this story

Each one opens the interactive schematic for that sheet.

Every chip in this story

107 chips across 6 sheets. Click any to open the schematic with that chip selected.