viler

Strange... if it does, that's not my doing - it seems to work fine with the VPN I use, but I'll look into it. Thanks for the heads up.

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.

Appreciated, thanks!

Video footage of it running on real hardware: https://www.youtube.com/watch?v=BdM5j96tEpE

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. :)

Yep, mentioned that in the intro to the article - recommended ++!

Fro me, it's things like comparing directories, filename search-and-replace/multi-rename, copying/syncing (locally or over ftp) with editable queues, etc.

Yes, and Area 5150 too :)

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!

A couple of GUIs written in assembly this century are MenuetOS and KolibriOS.

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.

It doesn't really - for this particular technique an ANSI-art editor should do (and was in fact used for almost all graphics in this demo, to one degree or another). :)

I suppose there's a wee bit of physics if you want to fine-tune the results for a particular CRT monitor... not that we've really done much of that for the party-version, but there's some research on the original IBM 5153 CGA monitor at https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale....

It should! Definitely runs on a 5160, and the 5155 is practically the same planar in a different enclosure.

Yes, the 'Macrocom Method' section shows how it's done over the RGBI output, as used in this demo - the sample artwork shown there is in fact a much earlier version of one of the still images in Area 5150. :-)

Although while working on this one, I couldn't help noticing that the IBM CGA (5153) monitor wasn't showing things quite as expected. That led me down another rabbit hole: https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale...

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.

I maintain a static blog which is small-time enough, but I did want a comments section - essentially it's the only public way I have to interact with readers directly, since I'm not a fan of the whole social networking thing. Email works, of course, but some form of visible Q&A can be helpful to others too.

Back when I set it up, I couldn't find a ready-made solution that looked good enough, so I chose to roll my own (basically an email form plus a hack to extract the json comment data from the message and rebuild the site). Since I'm dealing with a low volume of feedback, I don't have an issue with moderating/approving each comment beforehand, and spam isn't a problem... but this article could sure be helpful if that ever changes.

Impressive work! Makes sense that this would require writing directly to the framebuffer - that was the oldschool way after all, and it's pretty cool to see this done on a modern device.

Cheers for the comments. I'm still improving and tweaking this script - planning to test a fully 16-bit-per-component version of the filter chain, to eliminate any artifacts that might still exist. (Also, halation/diffuse glow for color CRTs isn't yet true to real-life visual results, but that will be improved.)

A lot of the differences people ascribe to CDs vs. LPs may not be due to the medium, but to different paradigms used when mastering audio for one or the other.

Very true. A project I'm working on involves some scrolling and animation on older hardware at 60Hz. Looks absolutely smooth on the CRT, but when emulated on a modern display there's always some kind of trailing/blurring.

Yes - that's a great point. Although from the article, it seems that most of the latency isn't down to the display, but to the CPU/GPU part of the chain?