Retro-engineering a video game system.
lucidscience.com
lucidscience.com
As a result, the animation is super-smooth and doesn't show any tearing artifacts. Which is funny, considering that you could still see tearing on the Windows desktop until Vista (the underlying hardware had long been double-buffered, but operating systems took forever to make full use of it).
You mean like, say, on an Apple ][.
But the Apple ][ is actually a good illustration of my point. Due to the cost of memory back then, Wozniak had to make many compromises in the hardware design, which resulted in a number of very odd visual artifacts. For example, if you tried to move a colored sprite around on screen, the colors of pixels in odd and even columns would flicker between two different four-color palettes.
The retro-engineered video subsystem in the article is essentially the same resolution as the Apple ][, but with greater color depth and none of the compromises, all because the cost tradeoffs have changed so much in the last 30-odd years.
http://en.wikipedia.org/wiki/Texas_Instruments_TMS9918
I don't think the price of memory was the main design driver of either of these approaches.
However, I think I can make a good argument that memory price was the main factor. As a hardware engineer, the only reason you'd ever use tricks like indexed color (palettes), foreground/background color per character (like CGA or the TMS9918), even/odd column color restrictions (like the Apple ][), and all the rest is to save memory.
Once you can afford enough memory to store your full color depth for every pixel in the frame buffer, your display hardware actually gets simpler -- it's just a straight pipe from memory to screen with no extra logic (other than your D-to-A conversion in the old days). No indexing, no complicated bit-packing schemes, no switching of color palettes during horizontal or vertical retrace.
Tons of effort and creativity went into that stuff, but it was all obsolete once memory got cheap enough.