How the background scrolls

Why you cannot scroll by moving things

The obvious way to scroll is to shift the picture. On a 3MHz Z80 in 1985 that is not merely slow, it is impossible: a screenful of tile numbers is over a thousand bytes and it would have to move every frame, sixty times a second, on a processor that is already sharing its memory with the video hardware.

So Commando does not move the picture. It moves the question. The map stays exactly where it is in memory and the hardware simply asks it for a different address than it did last frame. That single decision is the whole of sheet 1/3.

The C board is the smallest of the three, forty-seven chips, and roughly half of them exist to perform one addition very quickly indeed.

An adder in the address path

The main CPU writes a scroll position to C808 and C809 - two bytes, because the world is wider than 256 pixels - and a matching pair at C80A and C80B for vertical. Those registers do nothing but sit there holding a number.

That number is added, by '283 adders, to the beam position coming from the H counter, and the sum is what addresses the map memory. When the game increases the scroll register the beam position has not changed at all - but the address the hardware fetches from has, so different tiles appear under the same pixels. The picture slides.

The cost is a handful of adders and precisely nothing per pixel. No copying, no CPU time, no extra memory bandwidth. The same trick, with different chips, runs the vertical scroll on sheet 2/3.

Scrolling done the cheap way, and the only way that costs nothing per pixel. Rather than move any data, the hardware adds the scroll position to the beam position before the sum ever reaches the map memory. The picture slides because the machine is looking somewhere else, not because anything was copied.

Tiles, because storing pixels is unaffordable

The map is not stored as a picture. It is stored as tile numbers, each one standing for an 8-by-8 block of pixels whose actual appearance lives in ROM. This is why a large world fits in a small memory: the ground repeats constantly, and each repetition costs one byte.

Sheet 2/3 holds that map, at D800 to DFFF in the CPU's address space, alongside a parallel attribute area giving each tile its colour set and its mirror flags. The CPU and the display share this memory on a time-slice, taking alternate access windows, which is why the game can write to the map while it is being displayed without tearing the picture.

Mirroring is again doing real work here. A tile can be flipped horizontally or vertically by its attribute bits, which quadruples the apparent variety of the artwork for the price of two bits per map entry.

Turning a tile number into pixels

Sheet 3/3 is six 27128 EPROMs and a shift-register pipeline. The background is three bits per pixel - eight colours - and those three bits come from three separate ROMs read in parallel, doubled into two banks, hence six chips.

Eight pixels are fetched at a time and clocked out one per dot. Horizontal and vertical flip are handled by exclusive-ORing the low address bits before the fetch and by choosing which end of the shift registers to read, the same technique the sprite board uses for the same reason: it costs a few '86 gates instead of four copies of every graphic.

Out of this comes a three-bit pixel that goes to the colour mixer on the A board, where it loses every argument. The background is the bottom layer: any sprite or character pixel that is not transparent covers it. Its palette range is fixed at entries 0 to 127, the lower half of the 256-colour table.

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

47 chips across 3 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