Hacker News Reader

Comment by MatthiasWandel | Hacker News Reader

For games that scrolled the screen, those had to happen essentially between scans, so a lot of tricks were employed. Fixed addresses in the code, unrolled loops, and self modifying code to avoid the expensive zero page indicrect indexed addressing mode (the slowest instruction on the CPU). The other trick was to start moving the first line of screen just after it got displayed, which would give you nearly two jiffies to do it before the scan caught up to you on the next frame.

View on HN

It's crazy how much work went into those old games. I have a feeling those programmers weren't even paid that well considering how few people owned computers back then (so the market can't have been large).

If you ever play(ed) the Atari 2600 version of River Raid, you got to witness some SERIOUS tweaking to work around the limits of that console. Every scanline processed on the fly during the vertical blanking interval. No screen buffer. The animation was soooo smooth.

My first job out of college at Atari in 1982, writing game cartridges for the 400/800 computers, paid $25K a year. My first raise after a year was to $30K.

There were programmers in other divisions making royalties off of their games. Tod Frye famously got $700K or so for his terrible version of 2600 Pac-Man (it was terrible not because he was a bad programmer, but because marketing decided that 2K of ROM had to be enough, and he was smart enough to pull off a miracle . . . of sorts).

Also, the OP apparently doesn't know how to unroll loops, which is the first thing you do to your game's hot spots. (Never had to resort to self-modifying code).

The Pac-Man cart was 4k, not 2k. But maybe it should have been 8k, like Ms. Pac-Man later was.

You are correct on both accounts :-) (I mis-remembered the ROM size).

No need, it can easily happen during the scan. As long as the scan and update memory location never meet, there's absolutely no problem.

Reply on news.ycombinator.com