Racing the Beam Explained - Atari 2600 CPU vs. CRT Television

Well, if you think it's possible, try coming up with even the core of an architectural basis for 1. a declarative language for describing the same things PostScript describes, 2. which allows the rasterization of arbitrary shapes at arbitrary DPI (PostScript is DPI-oblivious — it's up to the printer what DPI it's printing at!); 3. and which also works for vector plotters , that will never rasterize the data you're sending at all, but will actually follow the bezier curves, like the 2D version of 3D-printer GCODE; 4. and which enables the implementation of this rasterization and/or plotting on a variety of affordable hardware architectures in the 1980s — where the 1980s was a time where CPU power wasn't too expensive, but where memory prices were at an absolute premium. So your printer might have had a CPU as powerful as your computer's in it, to crunch PostScript — but definitely wouldn't have had the memory to buffer a full rasterized page. --- To put that last constraint another way: PostScript was designed to be rasterized in a way that enabled printers to do something much akin to "Racing the Beam" ( this video ). In both the display-rendering and printing cases, this was done in 1980s hardware, because 1980s memory was too expensive for most systems to be dedicating it to hold a buffer to asynchronously pre-render into and then read from when drawing. So instead, in both cases, you must render+rasterize in one motion, programmatically and extremely efficiently. And the obvi

Kinda cool, I've never seen these techniques all in one place before. Growing up, I thought that SNES mode 7 scaling was so cool: link The article mentions about halfway down the page that what made the 80s road rendering technique possible was racing the beam. Where say an Atari 2600 would toggle the color at certain pixel counts as the TV's electron beam swept the screen, producing graphics that seemed otherwise impossible from such underpowered hardware: link this video Some engines allowed for say 8 hardcoded sprites this way by toggling colors at each sprite's position, with various rules about overlapping, so sprites would flicker sometimes when they were next to each other.

While I'm really happy we have faster systems now, there was something fun about about having to subvert constraints in games, and so satisfying and lovely when you did it right. HN folks are probably familiar with raster interrupts ( link ) and "racing the beam." I always associated this with the Atari 800. You weren't "supposed" to be able to do stuff like link , but Display List Interrupts made that possible. What I didn't know until recently was how much Atari 2600's games owed to this kinda of craziness: this video It's stuff like this that makes me think that if hardware stopped advancing, we'd still be able to figure out more and more interesting stuff for decades!