DOS ain't dead

Strange code at 0x9F00:0x000 (equal to 4KB) after boot (AMI UEFI DUAL BIOS).
It includes MONITOR and MWAIT instructions, among others, and jumps to protected mode.
What could it be?
Is there any option in UEFI to get rid of it?

> Strange code at 0x9F00:0x000 (equal to 4KB) after boot (AMI UEFI DUAL
> BIOS).
> It includes MONITOR and MWAIT instructions, among others, and jumps to
> protected mode.
> What could it be?
> Is there any option in UEFI to get rid of it?

Some notebooks or mainboards allow to switch between legacy BIOS and UEFI.
Just try to switch into legacy BIOS setting.

---
DOS-u-akbar!

> Some notebooks or mainboards allow to switch between legacy BIOS and UEFI.
> Just try to switch into legacy BIOS setting.

I changed all settings to "legacy" but still have conventional memory reduced by 4KB.
An additional 6KB is taken up by XBDA.

Hm, is that code active (called)? Does it belongs to some interrupt vector? What if you zeto this block?

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

Hello RayeR,

> Hm, is that code active (called)? Does it belongs to some interrupt vector?
> What if you zeto this block?

I am curious too. Also, if it is in RAM, then it should be possible to place a breakpoint somewhere in the code block.

Hello CandyMan,

Also, are you running DOS from UEFI, without using any built-in legacy BIOS? What is the procedure you are using for this?

Thank you!

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

> Also, are you running DOS from UEFI, without using any built-in legacy
> BIOS? What is the procedure you are using for this?

Hi, AFAIK DOS and also all non-UEFI aware Windows (Vista and older) depends on BIOS services and MBR loader so you need to have CSM enabled in your UEFI. The problem is that CSM is no longer required as part of standard and manufacturers will happily get rid off it :\

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

> Hm, is that code active (called)? Does it belongs to some interrupt vector?
> What if you zeto this block?

No interrupt vector in the array points to this code.

> Also, are you running DOS from UEFI, without using any built-in legacy
> BIOS? What is the procedure you are using for this?

Old-style booting is required to use the BIOS. UEFI booting does not access BIOS interrupts and runs system code in protected mode immediately.

> > Hm, is that code active (called)? Does it belongs to some interrupt
> vector?
> > What if you zeto this block?
>
> No interrupt vector in the array points to this code.

I think this might be related to the CSM entry point. I'm not familiar enough with UEFI and CSM to know what's going on, but am guessing that CSM is set up something akin to the old DOS DPMS or Cloaking mechanisms for TSR's. That is, there is a small amount (a "stub") of real-mode code needed to do a small amount of initialization before switching to protected mode and most of the "real" code is located in memory only accessible from protected mode. Particularly if they use high-level languages to virtualize the BIOS, it would be so wasteful of real-mode memory that it would never fly. Old BIOSs were almost always written in assembly for this reason. If this is the case, entries in the IVT would not necessarily point directly at the segment, but would get there indirectly after a few steps into the real-mode interrupt handler code.

That's my best guess, anyway.

> > Also, are you running DOS from UEFI, without using any built-in legacy
> > BIOS? What is the procedure you are using for this?
>
> Hi, AFAIK DOS and also all non-UEFI aware Windows (Vista and older) depends
> on BIOS services and MBR loader so you need to have CSM enabled in your
> UEFI. The problem is that CSM is no longer required as part of standard and
> manufacturers will happily get rid off it :\

But, isn't it possible to boot through LILO and / or GRUB in Linux UEFI bootloader, and then load (emulate?) legacy MBR mode, and pass this code by in order to then boot native DOS? I hope it is so.

And, my laptop available memory in DOS is not the usual 655360 bytes, either. It is about 6kb reduced as well. Every laptop I've used, except ones based on the old Atom 32-bit processors have never showed the full 640kb of low memory available when booting DOS. A vintage 2016 Dell laptop reduced low memory by about ~70-75 kb, cause unknown, but it was almost not usable for DOS purposes because of that. And BIOS didn't have any "disable" options, either.

And board manufacturers are going to gladly eliminate CSM since it will save them a nickel or a dime per montherboard manufactured. It is a sad day for legacy compatibility. The only boards to support CSM in future will be high-end "retro" boards, which will be 10x as expensive as boards of today due to capitalistic greed and an intentionally created market. Sad, indeed.

I've saved a few legacy MBR boot BIOS boards myself for just this purpose of maintaining bare-hardware DOS compatibility. Emulation is for the dogs, I want to boot DOS baremetal.

Hello CandyMan,

> > Also, are you running DOS from UEFI, without using any built-in legacy
> > BIOS? What is the procedure you are using for this?

> Old-style booting is required to use the BIOS. UEFI booting does not access
> BIOS interrupts and runs system code in protected mode immediately.

Oh, OK. Thanks for clarifying this.

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

Hello Zyzzle,

> But, isn't it possible to boot through LILO and / or GRUB in Linux UEFI
> bootloader, and then load (emulate?) legacy MBR mode, and pass this code by
> in order to then boot native DOS? I hope it is so.

The main problem is that you need a legacy BIOS (or an emulation of such a thing) which knows how to talk to the classical MBR or floppy disk bootloader.

The classical bootloader needs to invoke legacy BIOS services --- as documented in Ralf Brown's Interrupt List and elsewhere --- to read disk sectors, write to the screen, read from the keyboard, find the amount of conventional memory, etc.

UEFI also has similar services, but the programming interface is totally different. So a bootloader will need to talk to UEFI in a totally different way. Alternatively, the boot disk must have some extra code to emulate enough of the legacy BIOS "on top of" UEFI, for stuff to work.

And that is the hard part. :-\

(I am kind of hoping that there is some sort of existing code project which tries to do this emulation. Because it seems this stuff is indeed hard.)

Thank you!

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

Yes, problem are BIOS services that all the DOS stuff depends on, no compatible with UEFI. Aslo UEFI runs in pmode or 64b long mode so not compatible with RM stuff anyway. Last chance may be SeaBIOS that can be compiled as CSM and firmware modders who could insert such CSM back to where it should be...

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