That was one option I thought of at first (mentioned in the first section), but the info I found indicated that the /370 models used the same firmware as the "plain" 5170s - if there were any BIOS extensions, they were probably somewhere on the add-on cards. The AT/370 also had 512K of on board RAM, while this BIOS seems to indicate 640K.
Back when the demo was released, there were no emulators capable of running it all the way through. People are free to believe what they want, but as we presented it at a demoparty (Evoke 2022), I can tell you that the organizers wouldn't have allowed it in the compo lineup if they didn't see it running on the hardware in person. :)
I am in awe of GloriousCow's crazy achievement in debugging it on MartyPC and making it work to perfect accuracy... that's true next-level skill, and the rest of the group would undoubtedly echo my sentiment!
It's not every day that an emulator author has to resort to analyzing bus-sniffer traces to debug and fix a demo effect - and certainly writeups that go into this level of detail are few and far between!
Yeah, I should think that's exactly what happened. I was a big AA user too, but at that point in time I wasn't aware of the Atari ST connection (and hadn't ever seen an ST), so whenever I spotted that font in a game I just thought of it as "the Autodesk Animator font", and assumed that's what they used for the artwork. (Sometimes you could even spot tell-tale effects like that "countour gradient" thing, which would confirm it!)
Oh, gotcha - FWIW the fonts I labeled 'Verite' do come from Rendition Verite video BIOS charsets, but those in turn seem to be descended from the 'Phoenix VGA BIOS' type of font, or rather they're in the same loose family of fonts which shared that visual style... can't check at the moment, but it wouldn't surprise me if Rendition used some Phoenix VBIOS derivative too.
I also believe the font used in the VMware VBIOS is derived from that, so those who run a lot of text-mode stuff in VMware may take a liking to it.
It definitely is. Pretty amazing what you can still find out about this stuff after all these years, now that we can cross-reference and search data so easily (and that collectors, preservationists, and emulator authors are still coming up with previously unknown findings).
Thanks for those comments, much appreciated. I'm still planning future updates to that font collection, and I'll probably include straight-up binary dumps of the characters, so you won't have to jump through hoops to convert them (although many of them are already available in this form at https://github.com/viler-int10h/vga-text-mode-fonts - all you need is a hex dump).
Do the Modern DOS fonts have a particular advantage for you, in terms of implementation? If they do, let me know and I'll consider those improvements as well!
It draws you a 'Golden IBM PC' - and then the screen goes "well green, anyway"! At least if you're running it on a monochrome board (where it evidently expects that you're using the green-screen 5151 monitor) - haven't seen the ending in CGA. :)
Fro me, it's things like comparing directories, filename search-and-replace/multi-rename, copying/syncing (locally or over ftp) with editable queues, etc.
The author has done a superb job here. Not only does it have a cycle-exact Intel 8088 implementation (matched with disassembled microcode timings and hardware-verified) - it does the same for the CGA, where the dot clock is 3 times the CPU clock frequency... and it correctly represents the monitor's output, overscan included, which most other PC emulators have never bothered to do.
And those debugging tools are something else, too!
Yeah, that seemed to be the usage in most contemporary literature/magazines. There are also those other architectural factors like the bus width, the number of PICs, the keyboard subsystem and so on, which is why you could have "XT-class" 8086 and even 286 machines (like a Tandy 1000 model or two).
Part of that was used for option ROMs like hard drive controllers, the EGA/VGA BIOS, network adapters, and for EMS; other areas were just marked by IBM as "reserved", which might have scared people off. In early machines there probably wasn't much of anything there, but then video memory needs were still modest enough that A000-BFFF sufficed.
Probably a good thing, because then those 'holes' could be used for UMBs...
I like to think that the original 5150 engineers would get it, but probably won't like it. "What in the nether hells are you doing with our respectable Business Machine?! Go play with an Atari!" ;-)
Ah, I think I get the original question now - you referred to the dynamic blending during the fade transitions, not to the static dithering used in the actual image data. If so, disregard my previous reply (see ajenner's instead). :)
Oh I certainly won't say that it was easy, mind you. The artwork was just done over a long, long period of time. As mentioned elsewhere in the comments, my 8088 MPH blog post from 2015 already shows an early version of one of the images (and a couple are even older). :)
Our toolset for this demo did include an image converter (CGAArt), which can in fact use several version of the CIELAB formulas for its metric, among others. That's by reenigne from our team, who has commented here so I'll let him elaborate on it if he wishes. Personally when I do this sort of artwork, I prefer to tailor it by hand to the target video mode; as you noted, certain parts were indeed converted programmatically, but a lot of that was down to time constraints prior to the party release. In the final version, I plan to rework/redo those.