DOS ain't dead

I saw this on hackernews. PC BIOS for EFI machines. Alleges to boot FreeDOS in QEMU and some physical machines. I wonder if this could be improved.

https://github.com/FlyGoat/csmwrap

> I saw this on hackernews. PC BIOS for EFI machines. Alleges to boot
> FreeDOS in QEMU and some physical machines. I wonder if this could be
> improved.
>
> https://github.com/FlyGoat/csmwrap

I was hoping that this would boot MSDOS 4.0 under
Virtualbox.

I ticked "enable EFI" and the bootia32.efi took
effect and produced a lot of verbiage, but hung
instead of booting DOS like I was hoping would
happen.

I was hoping that Seabios wouldn't hard poll the
keyboard, so that Virtualbox would stop maxing
out a CPU.

And even if MSDOS did its own hard polling, I
was hoping it would still work for PDOS/386
which has the same issue.

Is there a way of making Virtualbox work?

> I saw this on hackernews. PC BIOS for EFI machines. Alleges to boot
> FreeDOS in QEMU and some physical machines. I wonder if this could be
> improved.

Good idea, we discussed use of seabios before (remembers me biEFIrcate theme). Unfortunately cannot boot on my work legacy free HP Zbook core i7-11850H, nVidia RTX A2000 :(
https://ibb.co/ymw4GsDn

EDIT: it seems I hit the problem:
It is almost required to run CSMWrap with above 4G decoding disabled in your BIOS/UEFI. As UEFI firmwares are likely to place GPU's VRAM BAR above 4G, and legacy BIOS are 32bit which means it can only access the first 4G of memory.

I have to check if my SETUP has an option for 4G decoding disable, I doubt a bit...

BTW there are still modern MBs with relative good CSM support, this one can boot Win98 on 14th gen core :)
https://www.youtube.com/watch?v=G7qm3GFy9tg

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

Unfortunately my HP SETUP doesn't contain any option related to "4G decoding" :\

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

> EDIT: it seems I hit the problem:
> It is almost required to run CSMWrap with above 4G decoding disabled in
> your BIOS/UEFI. As UEFI firmwares are likely to place GPU's VRAM BAR above
> 4G, and legacy BIOS are 32bit which means it can only access the first 4G
> of memory.
>
> I have to check if my SETUP has an option for 4G decoding disable, I
> doubt a bit...
Unfortunately it seems no UEFI-only setup would ever have such an option, especially on 64-bit systems! I've never seen it even on old BIOS systems.

And it is also "impossible" to shim this disabling through some sort of pre-loader which modifies the registers directly before the .efi file loads?

I guess it would be possible to modify the framebuffer BAR but it would break UEFI graphics driver without notifying about that and also there would need to be enough free space under 4GB. As modern VGA has over 4GB VRAM it might be problematic. I don't know how much space wastes the MMIO of modern GPU. Enginners may tend to not take much care when they have 64-bit address space... :P

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

> I guess it would be possible to modify the framebuffer BAR but it would
> break UEFI graphics driver without notifying about that and also there
> would need to be enough free space under 4GB. As modern VGA has over 4GB
> VRAM it might be problematic. I don't know how much space wastes the MMIO
> of modern GPU. Enginners may tend to not take much care when they have
> 64-bit address space... :P
However, for onboard graphics using system RAM, memory allocated to VGA can be set to low amounts, like 32mb or 64mb, more than enough for VESA modes in DOS up to and beyond 2048x1536 32 bpp. But, these onboard graphics of course have no CSM. Or, at least, I've never heard of one that does have. So, you "need" a modern video card and those have at least 4GiB RAM nowadays.

MMIO on "modern" CPUs can waste quite a lot -- between 512 mb and 1GB in the 3Gib to 4GiB address range. However, as we know most DOS stuff only works in signed 32-bit memory ranges anyway (2 GiB-1).

> However, as we know most DOS stuff only
> works in signed 32-bit memory ranges anyway (2 GiB-1).

I wasn't aware of that. What is causing that limitation?

My Zbook has dual VGA but only onboard (intel GPU) is available at boot. And neither has legacy VGA BIOS. I'm not sure if intel GPU is still VGA compatible at registers level. But I suspect it hanged for other reason, I'd like to see bootlog on working system how it should continue after hanged on my system...

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

I just tested CSMWrap on windows10-only tablet Notebook TrekStor SurfTab twin 11.6 with Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz. It has AMI Aptio UEFI 32-bit without CSM.
I put CSMWrap on USB stick and boot it via boot menu (that can be enabled in setup) and it let me boot DOS. I can run commandline tools but most of those using TUI or GUI doesn't work (don't display any output, maybe due to direct VGA access). Even simple programs like Edit, Qbasic, MicroManager. A few that works are e.g. GRUB4DOS or Heaven7 demo...
I also tried to run SBEMU but it didn't recognize any sound HW.
There should be PCI HDA device:

PCI device #8 found at bus: 0, dev: 21, func: 0
Vendor ID: 8086h (intel)
Device ID: 22A8h, Revision ID: 54, Class: 04h (multimedia device)
Sub-Class: 01h (audio device)
IRQ: 255, INTA, Cache line: 64B, Latency: 0
BAR: 91400000h, 00000000h, 91834000h, 00000000h, 00000000h, 00000000h

So good, CSMWrap works at leas for some basic DOS programs on bare metal that would be never possible on systems without CSM...

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

> I saw this on hackernews. PC BIOS for EFI machines. Alleges to boot
> FreeDOS in QEMU and some physical machines. I wonder if this could be
> improved.
>
> https://github.com/FlyGoat/csmwrap

> Current Status
> CSMWrap has been successfully tested to:

> Boot FreeDOS.
> Boot Windows XP and Windows 7 in QEMU (q35 and PIIX4 machine types)

Latest release 1.2.3 can boot MS-DOS 7.10 also only in commandline

A small milestone - Doom can run on UEFI class 3 (legacy free) netbook:
http://rayer.g6.cz/1tmp/csmwdoom.jpg
VGA compatability was a bit improved as SeaBIOS VBE ROM was replaced by original intel Cherry View VBIOS dumped from another UEFI FW. But there are still lot of issues. It shown, that dumped VBIOS contains some HW specific block ($VBT) thats unable to run on built-in netbook LCD but only external LCD via microHDMI. VGA compatability is better but broken another way. Doom lost keyboard control as probably KBD handler gets overwriten by DOS/4GW or Doom one. And any attempt to call VESA VBE cause hang so in this case it's worse than SeaBIOS VBE. But I hope it could be resolved...

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

> A small milestone - Doom can run on UEFI class 3 (legacy free) netbook:
> http://rayer.g6.cz/1tmp/csmwdoom.jpg
> VGA compatability was a bit improved as SeaBIOS VBE ROM was replaced by
> original intel Cherry View VBIOS dumped from another UEFI FW. But there are
> still lot of issues. It shown, that dumped VBIOS contains some HW specific
> block ($VBT) thats unable to run on built-in netbook LCD but only external
> LCD via microHDMI. VGA compatability is better but broken another way. Doom
> lost keyboard control as probably KBD handler gets overwriten by DOS/4GW or
> Doom one. And any attempt to call VESA VBE cause hang so in this case it's
> worse than SeaBIOS VBE. But I hope it could be resolved...
Did you get VESA VBE running at resolutions of 640x480x8 or above in the same netbook with SeaBIOS on the same legacy-free netbook? How about SBEmu and / or VSBHDI?

This is a huge milestone, another "impossible" feat accomplished. Hopefully the project will continue to improve and various patched VBIOSes can address the problems you've seen. It seems like a whole world opening with the "cracking" of UEFI on non-BIOS systems, a substantial and important step at preserving legacy DOS on castrated post-2020 UEFI systems.

My experiments have been less successful. Have not got this working yet on my single non-legacy UEFI laptop.

I'm not so optimistic, at least on this device.
With SeaVBIOS only very few programs can work in VESA modes - VMT, Heaven 7 demo and with intel VBIOS none.
With SeaVBIOS std VGA graphics don't work - doom, only with intel VBIOS but for some reason keyboard doesn't work during the game.
I still didn't solve how to properly configure intel VBIOS for built in LCD so I still need to attach ext. LCD via HDMI. I was digging around a lot but didn't find a never VBIOS than build 1014. On some intel forum thread I read, that Cherry View VBIOS was canceled and they dropped the support (probably intel management did some optimalisation of engineers allocation to not waste more time with legacy projects). So for newer platforms (intel IGP) there are no VBIOS at all and SeaVBIOS capabilities are very limited. In theory, if intel gives enough documentation and/or opensource linux driver one could write VBIOS initialization part and integrate it to SeaVBIOS but not easy task...

I tried SBEMU/VSBHDA but it didn't recognize the HDA audio device. I didn't try more, maybe adding of some PCI ID would be enough...

BTW the latest version of CSMWrap 1.3.0 added a feature that it can load alternative vbios from a file - no more need to recompile, if file is not found it would use vbios built in the uefi fw or seavbios if none.

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