The object controller sheet

▸This sheet is part ofHow sprites work

The subsystem followed end to end, across every sheet that builds it.

What this sheet is for

This sheet is the sprite engine's brain, and it contains no processor at all - just counters and a dozen gates that step through the same routine on every scanline.

9B divides each line into two halves. In the first, the engine hunts: 7C steps through the four bytes of each object while 7B and 7A count from object 0 to object 95. In the second half, what was found is played back onto the screen.

9A makes the clock the whole search runs on. 8C moves on to the next object once the current one has been read and judged, and 6A resets the counters at the start of every line so each scanline searches all ninety-six from scratch.

There is no processor here. The sequence is counters and gates, running the same cycle 15,625 times a second.

Two limits, two chips

The ninety-six is enforced by 8B, which watches the object counter and calls a halt at the end of the list.

The twenty-four is enforced separately. 7D and 8D number the slots as matching sprites are filed, and when the count reaches twenty-four 9D raises the flag that stops any more from being stored. 10C fires the actual write, but only on the right byte, in the right half of the line, and only while there is still room.

Objects are scanned in table order, so the sprites that get dropped from a crowded line are always the ones latest in the list. This is real hardware behaviour that MAME does not reproduce - its draw loop renders all ninety-six with no per-line ceiling.

9C alternates the two line stores so one can be filled while the other is painted, which is what makes the whole scheme work.

Every chip on this sheet

Click any of them to open the schematic with that chip selected in both panels.

← open the schematic for this sheet