DOS ain't dead

I'am starting to accumulate old hardware that do not have legacy hardware support. So although they seem to run DOS fine you run into problems when running programs and games.

There are products made that bring DOS functionality to windows, And there are products that bring windows resources to DOS.
SO I initially thought that DOS + HX DOS extender and VDMsound could solve some of the issues.
But the pieces do not quite fit.
They also don't solve graphics issues of some old games that use software tricks because hardware support didn't exist (like stunts aka 4D sports driving)

Is it possible to create a tool that can use windows drivers in dos (maybe based on HX dos extender?) Or something that can use DirectX?

That would bring a al lot of now useless machines capable of running DOS.

let me know your thoughts,

regards
Daniel,

> I'am starting to accumulate old hardware that do not have legacy hardware
> support. So although they seem to run DOS fine you run into problems when
> running programs and games.
>

If what you're meaning by no legacy hardware support
is that the machines in-question do not have ISA slots but rather only PCI...

Well then,
these DOS drivers for quite a few different PCI audio cards might help.

http://glennmcc.org/download/pciaudio.zip 56,592,264 bytes

---
--
http://glennmcc.org/

> > I'am starting to accumulate old hardware that do not have legacy
> hardware
> > support. So although they seem to run DOS fine you run into problems
> when
> > running programs and games.
> >
>
> If what you're meaning by no legacy hardware support
> is that the machines in-question do not have ISA slots but rather only
> PCI...
>
> Well then,
> these DOS drivers for quite a few different PCI audio cards might help.
>
> http://glennmcc.org/download/pciaudio.zip 56,592,264 bytes

This looks mostly like SoundBlaster and compatibles drivers. Typically in "legacy free" (read: no serial, parallel, or PS/2 ...OR... USB-only) computers have a more diverse set of audio chips, ranging from Intel ICH variants, Intel HDA variants, AC97 variants, and a few others.

Use a PCI bus enumerator tool or boot TinyCoreLinux and run lspci. Then match the PCI ID to a driver on forums like Vogons, vcfed, or MajorGeeks.

> If what you're meaning by no legacy hardware support
> is that the machines in-question do not have ISA slots but rather only
> PCI...
>
No, i mean systems with chipsets that natively do not support DOS anymore and don't have expansion possibilities.
I'll try to elaborate on this tomorrow (or later today since it is 1:47 AM)

> SO I initially thought that DOS + HX DOS extender and VDMsound could solve
> some of the issues.
> But the pieces do not quite fit.

That's true. Actually, how could you assume that they might fit? VDMSound is based upon the API the NTVDM does supply - and this API is supplied by NTVDM exclusively.

To emulate a (non-trivial) hardware device it's not sufficient to be able to "trap ports". One will also have to "virtualize" IRQs, and, for memory-mapped devices, memory ranges. It's pretty complicated to emulate the VGA in 16-color modes, for example.

The next version of HDPMI will at least support the port-trapping and hopefully also the IRQ-virtualization, both for clients running in ring 3. So, if you're a bit skilled, you may adapt VDMSound to HDPMI. Good luck!

> Is it possible to create a tool that can use windows drivers in dos (maybe
> based on HX dos extender?) Or something that can use DirectX?

Well, possible is a lot, it's software - but it's rather unlikely to come into existance.

---
MS-DOS forever!

> > Is it possible to create a tool that can use windows drivers in dos
> (maybe
> > based on HX dos extender?) Or something that can use DirectX?
>
> Well, possible is a lot, it's software - but it's rather unlikely to come
> into existance.

You mean a wrapper?

https://emulation.gametechwiki.com/index.php/Wrappers

> > If what you're meaning by no legacy hardware support
> > is that the machines in-question do not have ISA slots but rather only
> > PCI...
> >
> No, i mean systems with chipsets that natively do not support DOS anymore
> and don't have expansion possibilities.
> I'll try to elaborate on this tomorrow (or later today since it is 1:47 AM)

OIC, you were meaning to look into DOS functionality
for the onboard audio chipsets in such machines.

Well.... that's a chip of a different color.

---
--
http://glennmcc.org/

> OIC, you were meaning to look into DOS functionality
> for the onboard audio chipsets in such machines.
>
> Well.... that's a chip of a different color.

At least for Watcom C-compiled DOS 32-bit programs, there is this:

https://github.com/wbcbz7/sndlib-watcom

which seems to be a API / library that one can call to such PCI chipsets on newer systems.

Yes, THis is the kind of stuff I was looking for. It may be possible to make a combination of these to support a wide range of newer hardware.

For Windows, everything is money. Hardware manufacturers themselves develop their Windows drivers in exchange for their brands being recommended by Microsoft
In GNU/Linux, there is not corrupt commercial agreement, because the OS is non-commercial, Independent teams and individuals that like low level programming and research reverse-engineer Windows drivers and are constantly updating databases with new drivers for the hardware that's coming. Then, the OS developers include these drivers.

But few to nobody are supporting DOS now, so for a single person who wants to do this, it's a huge task that would take a long time and, by the time you complete it, there will be new hardware and you need to update it.
This is not feasable in the long run. So i am thinging in the line of Wrappers and API ussage for as far as it can be made without the need of constant updating.
I guess it will be in the range of products that supported DirectX but I do not know.

For graphics, there's somewhat more hope. I don't if it is still so, but until recently, most graphics accelerating cards had VESA 3 support. Even with VESA 2, it's already very easy to provide graphics support in DOS, for SuperVGA modes. Of course, if you want support for old games, VGA compatibility is the key. VESA is software, not hardware.

Thanks for all the input.. It gives me hope..

Daniel

> For graphics, there's somewhat more hope. I don't if it is still so, but
> until recently, most graphics accelerating cards had VESA 3 support. Even
> with VESA 2, it's already very easy to provide graphics support in DOS, for
> SuperVGA modes. Of course, if you want support for old games, VGA
> compatibility is the key. VESA is software, not hardware.

Graphics (ie, maintaining VGA-compatibility and a 16-bit Video BIOS and legacy BIOS) is going or has already gone out the window, discarded due to greed and (perceived) obsolesence). Way to go, for manufacturers! Break 30 years of great software (ie, running DOS bare metal on modern systems), just to save a few cents by eliminating the BIOS and legacy 16-bit video BIOS, and kowtow to Microsoft's UEFI-only "requirement." It's absolutely insane, and an awful thing.

Modern systems do not even have VGA-compatibility, let alone VESA 2 or VESA 3. If they do, their legacy VGA video BIOSes are broken, badly broken. There's been some discussion by myself, RayeR, and others here and on VOGONS forum about this. A few "wrappers" to fix VESA-compatibility have been made, but none so far "replace" the onboard VBIOS with a new, compatible VGA BIOS. This should be able to be done in software, particularly for the millions of "onboard Intel VGA" chipset drivers which shipped as a SoC in those millions of second-to-13th generation Intel CPUs. This is exactly what SciTech did with Univbe and Advance MAME project attempted to do with AdvanceCAB, but all of those cards are old, dedicated cards. None were onboard video, for laptops, and never any Intel Graphics were supported because it was too new. Development has stopped with those VGA / VESA wrappers because DOS "died" and there were too many cards to support. At least with Intel Onboard VGA wrapper / bugfix, it would solve MANY problems because of those Intel VGA onboard chipsets being 'common' in modern systems.

(I do not know how to "modify" the Intel on-board VBIOS and "shadow" it in RAM, or if indeed it's easy to do). But it seems like it could be "easier" to do this video fixing / support on modern systems than support all those Intel ICH, IHD, and SKA PCI audio chipsets!).

> Graphics (ie, maintaining VGA-compatibility and a 16-bit Video BIOS and
> legacy BIOS) is going or has already gone out the window, discarded due to
> greed and (perceived) obsolesence). Way to go, for manufacturers! Break 30
> years of great software (ie, running DOS bare metal on modern systems),
> just to save a few cents by eliminating the BIOS and legacy 16-bit video
> BIOS, and kowtow to Microsoft's UEFI-only "requirement." It's absolutely
> insane, and an awful thing.

I agree. It's absolutely insane, and an awful thing. Fixing the systems that are being produced now is not possible. And probably never will be.

> Modern systems do not even have VGA-compatibility, let alone VESA 2 or VESA
> 3. If they do, their legacy VGA video BIOSes are broken, badly broken.
> There's been some discussion by myself, RayeR, and others here and on
> VOGONS forum about this. A few "wrappers" to fix VESA-compatibility have
> been made, but none so far "replace" the onboard VBIOS with a new,
> .......... but all of those cards are old, dedicated
> cards. None were onboard video, for laptops, and never any Intel Graphics
> were supported because it was too new. Development has stopped with those
> VGA / VESA wrappers because DOS "died" and there were too many cards to
> support. At least with Intel Onboard VGA wrapper / bugfix, it would solve
> MANY problems because of those Intel VGA onboard chipsets being 'common' in
> modern systems.
>
> (I do not know how to "modify" the Intel on-board VBIOS and "shadow" it in
> RAM, or if indeed it's easy to do). But it seems like it could be "easier"
> to do this video fixing / support on modern systems than support all those
> Intel ICH, IHD, and SKA PCI audio chipsets!).

I do not have any technical know how to value the possibility of this. But I think that you have a very good point. And found a good direction to aim for.

I have systems in mind from the late nineties until about 2015. When DOS support went out of the window. That is about 2 decades of hardware. Most of those will have the intel onboard chipsets or something similar enough. And are probably strong enough to do this in software* and keep resources for DOS. (*compared to emulating DOS on top of a different OS)

A wrapper (or collection of them) that can do this for sound and graphics in combination with FreeDos for instance could make DOS available for so many systems for years to come.

> The next version of HDPMI will at least support the port-trapping and
> hopefully also the IRQ-virtualization, both for clients running in ring 3.

FYI, I'm working on a "fork" of JEMM which adds support for both I/O trapping/virtualization & IRQ virtualization. It uses an extended version of the Microsoft INT 2F.4A15 API. An extended version of the API was also implemented by Qualitas 386MAX (Bob Smith), and he recently uploaded the source code for it to the Internet.

I obtained some early info from Bob Smith on what he did many years ago for a different project, and in comparing what he sent me to the EMM386 source a few things got changed in the released 386MAX version of the API. What I've done in the JEMM fork is based on the old information and it needs to be "tweaked" a little bit to be compatible with what Qualitas/Bob released. I also need to make adjustments so it will work with JLOAD programs. I haven't had time to work on it lately.

My ultimate intent was to be able to virtualize USB-based devices like sound cards, Ethernet NICs, serial ports, etc. that require low-level hardware-based access and do it from "real" DOS (not requiring DPMI).

I've added some additional features to what Bob did in the API (including IRQ virtualization which Bob's version didn't have). I also know the version of JEMM I started with in my fork is not the latest so it will take some effort to bring it up-to-date.

I'm not sure what to do here. I really don't want this to be a "fork" (I would like to see it get implemented in the "Real" JEMM), but just don't have time to work on it right now.

Anybody want to take it over?

Hello Zyzzle,

> (I do not know how to "modify" the Intel on-board VBIOS and "shadow" it in
> RAM, or if indeed it's easy to do). But it seems like it could be "easier"
> to do this video fixing / support on modern systems than support all those
> Intel ICH, IHD, and SKA PCI audio chipsets!).

I for one would like to know where (or if) I can download these video BIOS images on the Internet. Do you have any leads?

Anyway, I think for a more modern option ROM compliant with PCI 3.0, you might be able to get away with loading the "ROM" image in normal RAM, at somewhere like 0x9000:0 rather than 0xc000:0.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> FYI, I'm working on a "fork" of JEMM which adds support for both I/O
> trapping/virtualization & IRQ virtualization. It uses an extended version
> of the Microsoft INT 2F.4A15 API.

I don't like that API - too immature and "hackish", IMO. The few applications I checked that use that API also intrude into the monitor's context and modify GDT/IDT. So even if you implement that API in Jemm, probably none of those apps would work with it out of the box.

Btw, the I/O trapping is already implemented in Jemm ( actually, it's JLOAD, see JLM.INC - since Jemm's memory model is flat, zero-based, it's best to emulate some of the Win9X ring0 APIs ).

> An extended version of the API was also
> implemented by Qualitas 386MAX (Bob Smith), and he recently uploaded the
> source code for it to the Internet.

I don't like the int2F4A15 API, but compared to the 386xxx sources it tastes like ambrosia.

> I've added some additional features to what Bob did in the API (including
> IRQ virtualization which Bob's version didn't have). I also know the
> version of JEMM I started with in my fork is not the latest so it will take
> some effort to bring it up-to-date.

To mmake that suitable for Jemm, the "IRQ virualization" should be implemented in JLOAD, as a small subset of the Win9X VPICD API.

---
MS-DOS forever!

> I for one would like to know where (or if) I can download these video BIOS
> images on the Internet. Do you have any leads?

Rare as hen's teeth to find raw onboard graphics Intel VBIOS files on the internet. They're usually embedded into the BIOSes of individual manufacturer's BIOS updates, and often encrypted as well, which makes extracting the raw 16-bit images difficult. Best way I've found to get the raw VBIOS code is to extract and dump the individual VBIOSes in DOS with a program like PVIEW or Checkit. Here's a thread on VOGONS about extracting VBIOSes:
https://www.vogons.org/viewtopic.php?t=61451

There's no online repository of these BIOSes that I could find, however the following has some files and a good discussion about checksums and hacking / hex-editing the onboard Intel vBIOSes of old Sandy Bridge / Haswell core systems, with a few VBIOSes posted :
https://winraid.level1techs.com/t/news-intel-sandy-ivy-bridge-and-haswell-vbios-modules/30272/61

At one time Intel itself kept a runnig log of its VBIOS revisions, but it appears to have been taken down. There were some ~60 different revisions of the main 16-bit Intel onboard VGA VBIOS. It is approx 63kb in size.

Personally, I've extracted the Intel onboard graphics vBIOS code from as many old laptops as I have (from Haswell to Kaby Lake), and the code is very similar for them all. The dates in the VBIOS ROM code range from 2013 to 2017, and I wish I could decompile them and shadow the ones which work better (eg, Haswell has good LFB and VBE 3.0, as well as good VGA compatibility on bare metal DOS) and "overwrite" the ones which have broken compatibility (eg, Kaby Lake). Checksums would need to be recalculated, and it's very likely I'd brick the laptop by attempting to do this, however, so I haven't attempted it!

>
> Anyway, I think for a more modern option ROM compliant with PCI 3.0, you
> might be able to get away with loading the "ROM" image in normal RAM, at
> somewhere like 0x9000:0 rather than 0xc000:0.
>
> Thank you!

Hello Zyzzle,

> https://www.vogons.org/viewtopic.php?t=61451
...
> https://winraid.level1techs.com/t/news-intel-sandy-ivy-bridge-and-haswell-vbios-modules/30272/61

Cool, let me check these out (especially the second link).

> compatibility on bare metal DOS) and "overwrite" the ones which have broken
> compatibility (eg, Kaby Lake). Checksums would need to be recalculated, and
> it's very likely I'd brick the laptop by attempting to do this, however, so
> I haven't attempted it!

As I mentioned, you can probably try to load a VGA option ROM image into RAM instead. Check (via the "PCIR" data) that the option ROM is compatible with your actual video card, and run the code from RAM. Maybe do this from within a DOS TSR or device driver, to (re)initialize the video BIOS after system startup. With any luck, this will work.

This is of course a less "permanent" solution than actually flashing the code onto a ROM chip. But it should be less risky.

(My (still very nascent) biefircate project tries to do something similar.)

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> I don't like that API - too immature and "hackish", IMO. The few
> applications I checked that use that API also intrude into the monitor's
> context and modify GDT/IDT. So even if you implement that API in Jemm,
> probably none of those apps would work with it out of the box.

I agree, at least up to a point. Microsoft's implementation was really bad (uninstalls don't always work properly, Word/DWord I/O doesn't work at all, etc.). But the simple fact that it was created and implemented by MS gives it a lot of credence in my book. I think what MS did with the whole VFAT thing to support LFNs was a terrible hack as well (it broke a lot of other programs, including some of MS's own programs), but we're stuck with it. I know this is not the FreeDOS forum, but if FreeDOS is supposed to be pretty much a direct replacement for MS-DOS, at least one of the FreeDOS monitors should support this API.

You're correct that some existing apps need to modify the GDT to do what they need to do (I haven't seen one that modifies the IDT -- that's part of what the API is supposed to do for them). Again, though, that's because of the poor way MS designed and implemented the API (they assumed the implementation would be done with a "simple" TSR where everything was in one segment). At least some of the programs I've seen that needed to do something with the GDT simply ASSUME a specific format in the GDT (which GDT entries were associated with which selectors). That's just a really bad idea (definitely worthy of being called a "hack"), but it worked with MS's poor implementation.

One of the things I do in the new version of the API is provide a pointer to the GDT so that the program can make modifications if needed. I know that's a bad idea from a security/protection perspective, but the whole concept of virtualizing I/O is a security hole anyway (that's part of the reason why NTVDM didn't even allow I/O, at least by default). Of course, it's also possible to create GDT entries some other way and then just reference them without needing to directly mess with the GDT at all.

As far as working "out of the box", the programs won't work with JLOAD either, so that's not exactly a valid reason to not implement it.

> Btw, the I/O trapping is already implemented in Jemm ( actually, it's
> JLOAD, see JLM.INC - since Jemm's memory model is flat, zero-based, it's
> best to emulate some of the Win9X ring0 APIs ).

I know, but I think there needs to be a more generalized way to virtualize I/O than JEMM/JLOAD, and MS provided a way to do it with this API.

> To mmake that suitable for Jemm, the "IRQ virualization" should be
> implemented in JLOAD, as a small subset of the Win9X VPICD API.

I think it would be possible to do both, but haven't yet tried to integrate the JLOAD piece.

> Hello Zyzzle,
>
> As I mentioned, you can probably try to load a VGA option ROM image into
> RAM instead. Check (via the "PCIR" data) that the option ROM is compatible
> with your actual video card, and run the code from RAM. Maybe do this from
> within a DOS TSR or device driver, to (re)initialize the video BIOS after
> system startup. With any luck, this will work.
>
> This is of course a less "permanent" solution than actually flashing the
> code onto a ROM chip. But it should be less risky.
This is a very good avenue to pursue. Heck, a small TSR which could do this automatically every time upon reboot wouldn't be that difficult to write, and would be far less risky than modification of the ROM and reflashing the BIOS and its checksums and so on.

>
> (My (still very nascent)
> biefircate project tries
> to do something similar.)

Thanks very much for pointing out this project of yours! I'm going to try this image and see how I fare. Running 16-bit code on UEFI-only system is very complicated compared to merely "fixing" a bad video BIOS of Intel's, I think. Congratulations for attempting the project. If I can help its progress in some possible way, please send me a PM.

Hello Zyzzle,

> This is a very good avenue to pursue. Heck, a small TSR which could do this
> automatically every time upon reboot wouldn't be that difficult to write,
> and would be far less risky than modification of the ROM and reflashing the
> BIOS and its checksums and so on.



> > (My (still very nascent)
> > biefircate project
> tries
> > to do something similar.)
> Thanks very much for pointing out this project of yours! I'm going to try
> this image and see how I fare. Running 16-bit code on UEFI-only system is
> very complicated compared to merely "fixing" a bad video BIOS of Intel's, I
> think. Congratulations for attempting the project. If I can help its
> progress in some possible way, please send me a PM.

Thanks! The project is still at a very early stage, and still very rough. Fishing out a video BIOS and reinitializing the video card turns out to be the relatively easy part (!), at least on my machine. Now I am a bit stuck at figuring out how to Draw The Rest Of The Dang BIOS.

I will probably send out a request for help at some point in time, and let you know.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> Thanks! The project is still at a very early stage, and still very rough.
> Fishing out a video BIOS and reinitializing the video card turns out to be
> the relatively easy part (!), at least on my machine. Now I am a bit stuck
> at figuring out how to Draw The Rest Of The Dang BIOS.
>
> I will probably send out a request for help at some point in time, and let
> you know.
>
> Thank you!
By, the way if you do not know about it, there is a very exceptional tool called RU.EFI (EFI version), and 16-bit DOS version, RU.EXE) which is an excellent utility to edit MTRRs, PCI Registers (Including onboard PCI soundcards!), BIOS NVME values, and other interesting hardware registers from DOS. Its functionality is similar to the GRUB command setup_var but much easier to use and to navigate. It may be possible to modify VBIOS code directly by using RU.EXE / RU.EFI, but probably very dangerous! But, then I have BIOS backups, and so do you (I hope!). This is link to RU.EFI:
http://ruexe.blogspot.com/

Knowing beforehand that my simple idea would have a difficult and complex answer, I am still surprised at the depth of the response.

By the looks of it, it seems feasible to create a generic solution for sound and graphics. For a wider user base I think a tsr is better than updating the bios because it't not permanent and easier to troubleshoot for a noob like me.

Looking into the intel VBIOS I found something from 2014 that might be useful.

Intel® Open Source HD Graphics Programmers' Reference Manual (PRM)

Hello Zyzzle,

> By, the way if you do not know about it, there is a very exceptional tool
> called RU.EFI (EFI version), and 16-bit DOS version, RU.EXE) which is an
> excellent utility to edit MTRRs, PCI Registers (Including onboard PCI
> soundcards!), BIOS NVME values, and other interesting hardware registers
> from DOS. Its functionality is similar to the GRUB command setup_var but

Let me check this out some time. Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> My ultimate intent was to be able to virtualize USB-based devices like
> sound cards, Ethernet NICs, serial ports, etc.

A real challenge, BTW did you had some time to look on USB 2.0 EHCI onboard hub and topology to be able to run your USB tools on slightly newer (actually 10 years old) HW? Currently all MBs are probably XHCI-only so messing with obsolete EHCI is not solution for future. I vaguely remember we had some discussion about it many years ago, just like to know if there's something new...

---
DOS gives me freedom to unlimited HW access.

hi, any progress with biefircate?
Do you have some testbuid that can load some vgabios image that I could try? What chances you see to run some older VBIOS on 11-th ge. tiger lake? Or did you find some real image? I hadn't time to mess with it.

BTW just a warning, dumping a VBIOS image from RAM of running systems may produce different images that really stored in flashROM chip because some VGAs (I saw on some nvidias) do some changes of VBIOS at boot time. Also some newer VBIOS cannot fit 64k segment so they are decompessed or mapping some parts of larger flash, things going complicated...

---
DOS gives me freedom to unlimited HW access.

Hello RayeR,

> hi, any progress with biefircate?
> Do you have some testbuid that can load some vgabios image that I could
> try? What chances you see to run some older VBIOS on 11-th ge. tiger lake?
> Or did you find some real image? I hadn't time to mess with it.

I have been busy working on other stuff so had not been working on biefircate recently. I am thinking of rewriting some parts of it.

Meanwhile there are some rather old disk images at the "Releases" page (https://gitlab.com/tkchia/biefircate/-/releases). If you boot up one of these in UEFI mode (N.B.!), it should try to search the PC's UEFI firmware volume for something that looks like a classical option ROM.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"