Stunning. I don't really have a great pulse on what a 5150 is capable of; when I was born, the world already had 386s. That said, I do have a Tandy luggable that I believe is meant to be compatible, and while it doesn't pass the flight simulator test, it's definitely a good introduction to just how limited these machines really are. You can't expect decent mod playback, unless you're reenigne.
My condolences to emulator authors who emulate CGA. :)
To me it seems like PC emulators tend to use the wrong approach with CGA. It's a fixed-frequency standard, so in principle it shouldn't be all that different from what you see in a typical emulator for the C64, Amstrad CPC etc.: the frame is rendered at a fixed resolution and refresh rate, just as the monitor or TV would display it (overscan area included!); the size and positioning of the active raster within that area are determined by the timing parameters sent to the (emulated) display controller.
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.
The PC world quickly became “the subset of features that work on PCs and clones” which means that shortcuts are often taken - both in clone development and emulators.
Whereas something like the NES had defined hardware that was mostly identical and so if some feature existed some game somewhere used it.
It's the lowest end of the IBM PC lineup: 4.77Mhz 8088 CPU, max 256KB RAM, CGA graphics (4 color graphics and 16 color text modes), PC speaker sound (no sound card). So, this is beyond incredible. IIRC, more than 4 color graphics modes are achieved by relying on pixel bleed with CGA's monitor signal output.
"Pixel bleed" sounds like it isn't really doing it justice. More than 4 colors on CGA are usually achieved by using the composite output, which is actually plain NTSC.
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.
That was how the predecessor 8088 MPH worked.
Area 5150 however is aimed at a TTL RGBI monitor, and as such, does not use NTSC composite artifacting. It can only display 16 colours at once. So in this demo, you get 640x200 in 16 colours, where additional colours are implied by using dither patterns.
(Technically 8088 MPH did more or less the same, except these 'dither patterns' would result in NTSC artifact colours).
Thanks, I should have written "more than 16 colors", forgot that CGA has a 16 color mode without tricks.
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).
Actually the RAM was expanded in this demo out to 640kb. This was necessary for some of the effects in combination with the loader. Such expansion boards were available back in the day.
That's fair; my understanding was that this was a pretty common thing to expand on a 5150, but I'd love to know if anyone has personal experience with having owned one back in the day.
Yes, especially somewhat later in the life of the 8088, most applications would demand quite a bit of memory, and the 640k configuration became standard for the later 5160s and most clones.
So I wouldn't be surprised if 5150 owners also upgraded the memory on their machines.
The AST Six Pak Plus card was quite a popular upgrade.
It could add up to 384k, so if you had 256k on board (fully loaded later model 5150), there's your 640k.
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.
I still have my PC (that my mom bought for our family, used, in 1987). It has an AST SixPakPlus which expands memory up to 640KiB, game port (analog joystick and digital buttons), parallel port, serial port, real-time clock with battery (if you didn't have that you'd have have DOS ask you for the time and date every time you booted up).
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.
Technically it all runs in 500kb I think (not sure if this includes DOS). And this was intentional because the guys had in mind what people would typically have available.
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.
There's plenty of YouTube videos about it, search for something like "commander keen cga" or "xt games cga" to get a feel for what it usually looked like.
I'm a little older and spent a nontrivial amount of time on CGA, so this demo absolutely blew my mind.
I am trying to be a bit humble since my experience is definitely limited, but to be clear, I do have some experience with an XT clone at least. Still, I haven't written very much code targeting an XT machine, and especially, I have never mucked with CGA beyond BIOS routines. I've got to imagine that even Commander Keen had to be doing some pretty hot tricks, even though the only novel technique I'm aware of is the EGA adaptive tile refresh one, not anything CGA.
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 :)
Is dosbox being used as an example, or was that actually the emulator? I find this intriguing. I would've assumed PCem or MESS was a better choice for writing a demo for something like an XT computer. Dosbox is useful but it definitely hits me as something that is emulating a software library per se, and only the hardware as an accident of that, a valid approach that is a lot less useful for programmers working under it...
I used the DOSBox debugger to debug several of the effects during the making of Area 5150, but other than that I used real hardware. 86Box is probably the most accurate one at the moment but still isn't accurate enough to run the entire demo correctly.
Given that the demo targets AT-class hardware, it is unlikely that something like PCem or MESS was used, because in those cases you'd actually have to select an AT-configuration to make it work, instead of an XT-configuration.
DOSBox does not have this option, it always emulates AT-class hardware, in which case this demo 'just works'.
My condolences to emulator authors who emulate CGA. :)