A great old-timey game-programming hack

A story from the 8-bit PC era shows what it really meant to push hardware to its limits. According to the account, a programmer had managed to squeeze a graphically impressive arcade game almost faithfully onto a 1980s-era PC. The only problem was that the game was unplayable: it ran too slowly, and the choppy motion broke the player's immersion in what was, after all, a side-scroller.

When a friend was asked to review the code, he found it already tight. Loops had been unrolled, unneeded draws eliminated, and every obvious optimization was in place. As the article explains, the real issue was that graphics hardware of the time did almost nothing. To draw anything on screen, the programmer had to move every byte personally; there were no texture mappers or blitters.

The game spent most of its time redrawing the background. Each frame required drawing nearly a screen's worth of background tiles, shifted for the player's position. Each tile was 28 by 28 pixels, and each pixel took half a byte, so a tile sat in memory as 28 rows of 14 bytes each. The screen buffer, meanwhile, was laid out as 240 rows of 160 bytes.

According to the report, the trick lay in the 6809 processor's auto-increment addressing modes. These let the programmer copy four pixels at a time while advancing both the source and destination pointers. Copying a full row meant repeating that seven times, then adjusting the destination pointer to the next row. Doing all of that 28 times produced a single subroutine.