9

I have this very faint recollection from my late elementary school days back in the end of 1980s of a very specific piece of MS-DOS software that claimed to do what was an incredible thing to an eighth-grader of the day.

The software was marketed with a claim that it would make an EGA graphics board able to emulate the 640x480, 16 color high-res mode of VGA. At our school, we had a computer classroom full of 80286 machines of the day, complete with EGA boards and monitors. I recall trying the software up once in one of those boxes, bringing with me a painting program on a floppy that I had carefully set up to run in VGA mode; the program, named "Dr. HALO" or something like that, was well suited for this testing because it had to be configured for a specific graphics board and would only run at all if the machine could support the chosen mode, not gracefully downgrading if the setup was not met.

To my awe, the painting program did indeed start up and run when the emulation software was active (the emulator deployed as a TSR program, as did a lot of MS-DOS utilities at that time). I had neither the time nor the knowledge to systematically test the performance or reliability aspects, so I can't say how good or usable the emulation would have been in productive use; back in the day it proved its point to me by just showing that such emulation was possible (or, at least, I was reasonably sure that it worked).

Now, decades later, I'd be very interested to find some references as to what was the name of that software, who the developer was, and how the VGA emulation worked. Alternatively, should such emulation not be possible, I'm also interested in that fact and why it is so; I was quite sure that I managed to run the painting program in VGA mode (we had a VGA machine at home, so I could tell the appearance of VGA graphics from EGA), but I do recognize that I was a thirteen-old kid, and it's been a long time.

Improve this question
14
  • You could hook INT 10h and emulate all the BIOS video calls. But any program that did serious graphics would write directly to video memory, and that would be harder. Unless their memory layouts are compatible in some clever way? I don't recall exactly how those worked.
    – Nate Eldredge
    Commented Sep 10, 2022 at 21:05
  • @NateEldredge Actually the direct video memory access is identical. Programs meant to run on an EGA card should in general run directly on a VGA card as well, as the VGA card should just be a register compatible superset of EGA.
    – Justme
    Commented Sep 10, 2022 at 22:59
  • 1
    sounds like EGA counterpart of VGA SciTech's UniVBE which was VESA extender for VGA cards allowing SuperVEGA and VESA functionality (LFB and high color included) on old VGA cards... maybe they started on EGA? there where also other emulators like VGA/EGA for hercules (this was SW that simply translates memory VGA image uses into hercules B&W image) etc...
    – Spektre
    Commented Sep 11, 2022 at 7:03
  • @Spektre UniVBE is different. For a supported card, it implements the VESA BIOS Extensions interface for it, so programs can use the VBE interface without knowing which video card it is. So old cards can't implement LFB or high color if they don't have that, but on cards that do implement LFB or high color, these features can be made available through VBE, so a program only needs VBE driver and no specific driver for each card. This is different if a drawing program actually expects to see VGA hardware and uses it directly, it won't work by emulating VGA BIOS on an EGA card.
    – Justme
    Commented Sep 11, 2022 at 11:42
  • 3
    In addition to what's been said above: certain advanced EGA cards of the time (e.g. ATI EGA Wonder 800) did support 16-color VGA modes. So, it could be that the software in question indeed simply hooked some BIOS interrupt vectors to trick any other programs running on the machine into thinking that the machine is equipped with a VGA card. The following bug report and the discussion that follows might be educational: github.com/86Box/86Box/issues/588
    – DmytroL
    Commented Sep 19, 2022 at 8:23

1 Answer 1

Reset to default
8

Sounds quite unlikely it would actually work, but there are a few prerequisites, limitations and assumptions where it might be possible for an EGA card with a TSR to emulate a VGA card for simple purposes.

The only thing directly compatible is the access of video memory via memory segment A000h and setting the read/write bit planes so that definitely is not a problem.

Generally a VGA card would be directly BIOS and register compatible with a program expecting an EGA card in the system, but not vice versa.

There are many things that can be problems.

First of all, EGA card must be expanded to 192k or 256k of memory, in order for the frame buffer to hold data for a 640x480 image. This may not be a huge issue as later EGA cards may have been sold fully populated. It would definitely work with 128k or less. VGA cards always came with full 256k of memory, and later clones with even more than that.

Second thing is, the EGA monitor has no mode with 480 visible lines, and since EGA monitors only support two fixed frequency rates, it is unlikely the horizontal rate could be increased by 37% to show 480 visible lines instead of 350, unless in the unlikely case it was an multisync monitor with EGA interface. As the pixel clocks are also fixed, having more lines would drop the refresh rate. So the assumption might be that you can see the default 350 lines out of 480, and maybe scroll up/down with some keyboard/mouse shortcut if the TSR allows for it.

Third assumption is that the drawing program only uses BIOS functions for controlling the card in order for the TSR to emulate it. While EGA and VGA are quite similar, if not even register compatible in basic functionality, the difference is that in general VGA registers can be read but EGA registers are in general write-only. So the program can't perform read-modify-write operations of VGA registers on an EGA card. The TSR just basically needs to set a 640x350 mode instead of 640x480 if the program requests 480-line mode via BIOS video mode set call.

The VGA registers also can't be emulated by the TSR, as the 286 CPU has no mode where it would support trapping IO port accesses while still being capable of running real mode x86 code. A 386 could do just that in VM86 mode, which is why many virtual hardware emulators required EMM386 in order to run. So the program must either use the BIOS functions which the TSR can emulate, or like what early VGA programs did, just write to registers without reading like it has to be done on EGA cards.

And obviously the EGA card will be limited to the selection of 64 colour default EGA palette, as there is no VGA RAMDAC with a colour look-up table to convert the 6-bit EGA colour values to 18-bit RGB value for analog RGB conversion.

So what you describe might be possible, but it would require that the drawing program is quite simple and does not use VGA hardware directly. It is plausible that the drawing program is very simple and it uses the BIOS for most things and uses EGA compatible IO port writes when necessary to control how to directly access the video RAM.

It also possible that the program simply detects there is no VGA and continues in EGA mode.

Improve this answer
15
  • 1
    there are ways on CRT to double the number of scan lines exploiting interleaving, but the SW could simply skip or merge some lines to compensate... similar emulators did exist for other cards like VGA UniVBE, Hercules ... so its not hard to expect or far fetched EGA had also some. btw. there where also even more "magical" emulators like 3Dfx emulator ...
    – Spektre
    Commented Sep 11, 2022 at 7:14
  • 4
    @Spektre Do you mean interleaving or interlacing? Standard EGA card can't output an interlaced signal, and even if it could, only 400 or 700 line intelaced modes would be available on standard EGA monitors. Interleaving, or switching between odd and even 240 lines in 350 line mode would need to be done by setting start address for each frame in timer or VBLANK interrupt, and requires doubling the row span from 640 pixels to 1280 to skip every other line, which should be doable. Software processing, like how CGA can be emulated on Hercules card, is not possible in this case, no memory.
    – Justme
    Commented Sep 11, 2022 at 10:07
  • 2
    As for the magical emulators, they really need a 386 or higher to emulate hardware that does not exist in software. For example emulating a Sound Blaster or Roland MT-32 on a Gravis Ultrasound.
    – Justme
    Commented Sep 11, 2022 at 11:45
  • 1
    Some EGA-style chipsets supported interlacing, and I wouldn't be surprised if some monitors could accommodate some combination of horizontal and vertical scan rates, either interlaced or not, that could manage a 480-line display. An NTSC-format video frame which is about what the EGA would use in lower-resolution mode would nominally have 480 potentially visible scan lines, though a screen would usually be sized so that some of them would be covered by the bezel. Some monitors with a vertical size adjustment may be able to show all 480, however.
    – supercat
    Commented Sep 11, 2022 at 16:46
  • 1
    @Justme Assuming you get an EGA card to do proper interlacing (maybe reprogram the vertical total by +/-1 on each refresh, and adjust the starting address accordingly), you can run the standard EGA 640x200 timing with more scanlines reaching into the overscan area, and possibly some extra scanlines dropping the vertical frequency to something like 57Hz, to get to a 640x240 frame, which results in a 640x480 interlaced image - at a horrible flicker, of course. Software like Dr. HALO just uses the ROM to initialize a video mode and doesn't touch the starting address or the vertical by itself...
    – Michael Karcher
    Commented Jul 26 at 18:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .