My condolences to emulator authors who emulate CGA. :)
In an emulator like DOSBox, only the active raster is rendered, and it attempts to dynamically work out the H/V refresh and aspect ratio. Maybe for historical reasons, since it was originally meant for emulating VGA on a VGA monitor. Same goes for 86box, PCem and MAME... although at least the first two do somewhat better with this demo.
Whereas something like the NES had defined hardware that was mostly identical and so if some feature existed some game somewhere used it.
In NTSC, color is added to the monochrome signal by modulating a quadrature amplitude modulated signal onto a carrier whose frequency is actually within the monochrome image bandwidth itself. NTSC did this for compatibility with black and white TVs of the time. (If that sounds too complicated, it "just" means that changing brightness very fast creates color.)[1]
To get more than 4 colors in CGA, you "just" switch pixels fast enough that you are effectively modulating the color signal yourself! But the problem with CGA is that it doesn't have a graphics mode with high enough resolution to get all those colors. But text mode does, so there's tricks to chop the text lines into pieces which allow puzzling back together a high res image that modulates the color signal.
It's pretty cool.
[1] PAL is the same with a twist, SECAM is very different but "changing brightness very fast" is still accurate.
Dither patterns/"artifact colors" are exactly what I meant, they achieve color by modulating the luminance signal (which is of course the same as "normal" color, but the trick is to let the software influence only the luminance and getting "unintended" colors instead of directly telling the CGA adapter to modulate the color on, and over a separate circuit probably, like what normal 4/16 color mode does).
If you were unlucky enough to have an early model 5150, the board could only take 64k. That limit was however because 4116 memory chips of 16kbit capacity were used. The board could be modified to take the later 4164 chips of 64kbit capacity, in which case it would take 256k. Alternatively, you could use two memory expansion cards to bring the memory up from 64k onboard to 640k total. Although I doubt many people would use such a contraption in practice.
Early model 5150s also required a BIOS upgrade, as a bug would prevent the BIOS from detecting more than 544k of installed memory.
So in theory it is possible to have a 5150 with 640k, and no doubt such machines exist in the wild. But it's probably far more common to find a 5155 or 5160 with 640k. So just like with 8088 MPH I guess that's the 'practical' target of the demo.
However I think everyone is going to have to temper expectations regarding what this will run on. Even my effects (the 3D Glenz objects) couldn’t be debugged on an emulator even though it’s a fairly simple tricked up video mode and a bunch of fairly ordinary assembly code doing VRAM writes that are not timing critical for the screaming fast 3D.
I think it came with software to help you use all that RAM, like a print spooler and a RAM drive. The 1987 version of the manual talks about the software on page ix [1].
(I also noticed the manual mentions you can enable/disable parity checking. I wonder if that would let me leave 1/9 of the chips out since I have a few bad chips and have to use less than 640KiB currently. I should just try to source some replacement chips though.)
Fun fact: The 8-Bit Guy (from YouTube) used to work at AST.
[1] AST SixPakPlus manual (PDF) http://vtda.org/docs/computing/AST/000490-001A_SixPakPlusUse...
I'm a little older and spent a nontrivial amount of time on CGA, so this demo absolutely blew my mind.
Of course, it's never too late to write some wares for XT... I'd prefer to get an actual XT for that, though. I'd fear that if I only ever tested on emulators or clone machines, I would end up writing code that doesn't work on any actual XT :)