programming in the
twenty-first century

It's not about technology for its own sake. It's about being able to implement your ideas.

100,000 Lines of Assembly Language

I occasionally get asked about writing Super Nintendo games. How did anyone manage to work on projects consisting of hundreds of thousands of lines of 16-bit assembly language?

The answer is that it's not nearly as Herculean as it sounds.

The SNES hardware manual is a couple of hundred pages. I don't remember the exact number, so I'll shoot high: 400 pages. Add in a verbose 65816 assembly language book and combined we're talking 800 or 900 pages tops. That's eight percent of the total I came up with for having a complete understanding of an OS X based computer: nearly 11,000 pages.

Sure, there are whole classes of errors that you can make in assembly language that are invisible in C. For example, here's some old-school x86 code:

mov ax, 20
mov bx, -1
int XX

This sets up a couple of parameters and calls an interrupt. It looks right, it works, it may even ship in a commercial product, but then there's a new MS-DOS version and it crashes. Why? Because the second parameter should be passed in the dx register, not bx. It only worked because a previous interrupt happened to return -1 in dx, so the second line above isn't actually doing anything useful. But those kinds of errors are rare.

The secrets of working entirely in assembly language are being organized, thinking before implementing, and keeping things clean and understandable. That sounds a lot like how to write good Javascript or C++. Steve McConnell's Code Complete is actually a guidebook for the Super Nintendo game programmer.

But all this talk of programming languages and hardware is backward. Jordan Mechner designed and built the original Prince of Persia on an Apple II. The game and the editor for laying out the levels are written in assembly code for the 8-bit 6502. He kept a journal while writing the game.

You might expect the journal to be filled with coding philosophies and 6502 tricks, but there's little of that. Sure, he's doing difficult tech work behind the scenes, but that's not what he's writing about. They're the journals of a designer and a director, of someone living far away from home after graduating from college, with long detours into his screenwriting aspirations (and don't let that scare you off; they're fascinating).

He may have had second set of coding journals, but I like to think he didn't. Even if he did, he was clearly thinking about more than the techie side of things, in the way that a novelist's personal journal is unlikely to be filled with ramblings about grammar and sentence structure.

(If you liked this, you might enjoy The Pure Tech Side is the Dark Side.)

permalink April 13, 2012



twitter / mail

I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.

Where are the comments?