2600 Pacman sure does suck, but to be fair, that video was recorded on a potato at 14hz, making the flickering ghosts inscrutable instead of just annoying.
Here's one that seems to have been recorded at 60hz then downsampled to 30hz with frame interpolation for Youtube. Still shit, but at least you can tell what's going on. Kinda.
Think of it this way: you paid for a Kickstarter project to be delivered in 40 years time, got an early proof of concept showing game play and a nice display box, and the real thing was finished before those 40 years were up.
I always wondered how the video output was controlled without video memory. Do you have some sort of 'current color' register which need to be set to different values during video output, timed with nop loops?
I have coded on several 8-bit machines in 80s, but never on one without video memory. I stumbled over this curious property of the Atari 2600 when Ed Fries wrote 'Halo 2600' a couple of years ago (boss of the Microsoft games business during the late 90' and early 00's).
More or less yes, but it's more than one register. The video output as the scanlines go across is built up from a number of registers. Three registers encode a 20-bit "playfield graphics" layout (blocky background graphics) for half of the current scanline; four registers are higher-res sprite-like things (2 "sprites", 1 "ball", and 1 "missile"), which also do other things like collision detection; etc. You typically do useful work rather than a NOP-loop, though, and just carefully arrange it with cycle-counting, since there aren't many cycles to spare.
An even more minimalist design where you just have one register, the next pixel to output, wouldn't work because the CPU isn't fast enough to update it: the electron beam outputs 3 pixels per CPU cycle, and of course many instructions take more than one cycle, too. Instead an auxiliary microprocessor, the TIA, is clocked 3x as fast as the main CPU and does the real-time compositing of these various registers into the one value to output.
There is also an interesting book looking at a few case studies (one per chapter) of how the Atari's weird hardware influenced the design of some of its games: http://mitpress.mit.edu/books/racing-beam
The book "Racing the Beam" has a great survey of how the 2600 worked and it's a pretty quick and breezy book to read through.
But basically you set various display registers as the scan-line was being drawn. Then you have the time it takes for the electron beam to move down and across to the next scanline to do some setup and calculations and so on. And then at the bottom of the display you have the time it takes for the scanline to get back up to the start position for a frame to do more number crunching.
Basically instead of RAM, you read right out of ROM and fiddle with various display registers either between lines of while lines are being drawn.
It's an old 8-bit "trick" as most people assume the registers get set and then you do something not knowing that you can play with them while things are going on.
That trick wasn't limited to 8-bit. The original Macintosh used a variant of this to generate sound and to adjust the rotation speed of floppy disks. Just past the bitmap for the screen, it had two 740-byte buffers.
It read a single byte from those buffer at the end of each horizontal scan line, and fed it into the sound system/as a PWM signal for the motor of the floppy drive (http://en.m.wikipedia.org/wiki/Macintosh_128K/512K_technical.... I think the section on the floppy drive is incorrect; the original Mac didn't have a IWM; it was all done in software)
If you wanted to generate continuous, non-repetitive sound, you had to fill the sound buffer with new values at the end of each vertical blank interrupt.
Quite a bit easier than on the 2600, as the update frequency is only 60 Hz and the CPU a lot faster, but the same principle, and still quite a challenge at the time, if you wanted to do something in the screen at the same time.
In short, the TIA chip does act as video memory - but not the way we treat it today. It has various registers that you can write into to define how the next line will be drawn. eg, you create a background by writing 20 bits into the 'playfield' register. This is mirrored vertically to fill out a 40-bit wide background, and then you write in a foreground & background colour.
Similar registers exist to hold sprites for a ball, two players, and two missiles.
And then if all of this didn't seem limiting enough for you, your game (the only process running on the machine) is responsible for maintaining most the timing for the television controller itself - so you actually spend most your time managing the TIA, with only a small number of cycles at the end of each line, and a better number of cycles after the last line, but before the next screen starts drawing - in order to actually perform game logic itself.
Wonder if how close they managed to make the ghosts move like the arcade version. Someone reversed engineered how the ghosts chase you, each one chases using a different algorithm which ends up making the game really interesting to play.
Actually all four of the ghosts have different chase algorithms: Blinky aggressively chases you, Pinky and Inky try to get in front of you (setting you up for a pincer attack with Blinky), and Clyde chases you until he gets within a certain distance, then makes a break for the lower left. (Hence why he's considered the stupid one.)
Oh, there are new homebrew games being made for a lot of the major 8-bit machines, still today. Myself, I've been enjoying the revival immensely, especially since the 8-bit machine of my youth rarely got much attention at all from the major industry developers (Oric-1/Atmos), yet today - in the 21st Century - its getting a regular stream of releases from the die-hard holdouts .. and some of them are absolutely amazing products which would have been huge hits back in the day.
We got Space:1999, 1337 (Elite clone), SchoolDaze, Impossible Mission, Oricium, 4K Kong .. a lot of really awesome titles .. in the last few years. Also, new techniques have been discovered and continually refined by the core die-hards, meaning we're seeing things on the platform that we in the 80's could only ever have dreamed of seeing .. new color modes, new ways of handling animation, etc. It really is astounding to return to these platforms, 30 years later, and see new titles being pushed out by the ever-eager hackers who are keeping the platforms alive. Heck, we even got new hardware for the Oric-1/Atmos platform in the form of a dedicated disk emulation system, whose microcontroller alone, itself, is more powerful than the Oric ever was, but which nevertheless is being pressed into the disk-emulating duties that makes the Oric-1, at last complete. ;)
So if you've got an old 8-bit machine in your closet, get it out, wire it up, dust if off, and get out there on the 'net to find the elite groups keeping these systems alive. And remember: old computers never die - their users do!
The surplus of resources on modern PCs makes it possible to make development tools which would have been positively indulgent by the standards of their day- sophisticated debuggers, the ability to pause, freeze and replay execution while inspecting every byte of memory at will, fancy languages that remove tedium, etc.
For my part I made a pretty nice high-level assembler and IDE for the venerable Chip8: http://octo-ide.com
Wow, looks really useful! Its amazing to think how far we've come, and yet return to these limited machines and push them as far as possible. Something we have to keep future generations of developers enlightened about, I think.
Yeah, I used to wait 45 minutes for our overloaded department minicomputer to assemble my cartridge, then download it at 9600 baud (only 16K, so not too bad). At night the assembly times took a few minutes.
On a modern PC, this takes seconds; my fingers and brain are the bottleneck, which is how it should be.
It's so easy to love old-school programming. (For comparison, my comment here is 178 characters.)