It's not all reserved by the BIOS, but it's not necessarily free either, so it would be context specific.

The original PC would have an 8KB BIOS at the top of memory, but the rest of the F segment would not be empty. ROM BASIC would be in there somewhere.

Some newer BIOSes such as AMI HiFlex BIOS of the 386/486 era, fill the entire F segment, but are written so that the "runtime" only sits in the upper 32KB, while POST/SETUP sit in the lower 32KB making it safe to overlay UMBs on top of F000-F7FF. Also, if you notice some Phoenix 4.x BIOSes will give "UMB upper limit segment" either on the POST screen or system configuration screen, I believe that is the same concept.

Once you get into the PCI era, PnP BIOS era, etc. I suspect all 64KB are needed at runtime, as these BIOSes are compressed and overlay different parts of code in and out of F000-FFFF during the POST/setup/boot process.

jakethompson1 wrote on 2023-08-10, 22:47:

Some newer BIOSes such as AMI HiFlex BIOS of the 386/486 era, fill the entire F segment, but are written so that the "runtime" only sits in the upper 32KB, while POST/SETUP sit in the lower 32KB making it safe to overlay UMBs on top of F000-F7FF. Also, if you notice some Phoenix 4.x BIOSes will give "UMB upper limit segment" either on the POST screen or system configuration screen, I believe that is the same concept.

Can one use a shadow memory unlocker like The Last Byte Memory Manager (vs EMM386 and friends) and still safely use F000-F7FF on these machines?

Once you get into the PCI era, PnP BIOS era, etc. I suspect all 64KB are needed at runtime, as these BIOSes are compressed and overlay different parts of code in and out of F000-FFFF during the POST/setup/boot process.

Many of these get pretty exotic, using things like unreal mode in the CMOS setup and such.

NJRoadfan wrote on 2023-08-10, 23:01:

jakethompson1 wrote on 2023-08-10, 22:47:

Some newer BIOSes such as AMI HiFlex BIOS of the 386/486 era, fill the entire F segment, but are written so that the "runtime" only sits in the upper 32KB, while POST/SETUP sit in the lower 32KB making it safe to overlay UMBs on top of F000-F7FF. Also, if you notice some Phoenix 4.x BIOSes will give "UMB upper limit segment" either on the POST screen or system configuration screen, I believe that is the same concept.

Can one use a shadow memory unlocker like The Last Byte Memory Manager (vs EMM386 and friends) and still safely use F000-F7FF on these machines?

That is a good question. I first read about the 32KB+32KB AMI thing about a year ago when 386MAX was released as open source on GitHub, and it's one of the tweaks it applies if your BIOS is compatible, to get more UMBs. Then I also read about it in the "Programming the AMIBIOS" book I have. One difference I can think of is that if you just overlay UMBs, you presumably can't hurt anything, but if you've unlocked shadow memory and actually overwritten the 32KB that was put there at boot time, could it be a problem if the BIOS later goes into System Management Mode (which would temporarily deactivate EMM386 et al, but would not revert the BIOS shadowing back) and the SMM code assumes the original F000-F7FF is still there?

NJRoadfan wrote on 2023-08-10, 23:01:

Can one use a shadow memory unlocker like The Last Byte Memory Manager (vs EMM386 and friends) and still safely use F000-F7FF on these machines?

Many chipsets only support only a single read-only/read-write settings for the entire F000-FFFF area. Having writeable shadow memory in F800-FFFF seems like a bad idea to me, as it would be to easy to accidentally overwrite the BIOS. Not having that area writeable on the other hand would mean that you can't use UMBs in F000-F7FF. In case you have a chipset that supports 16K or 32K granularity for shadow configuration in the F segment, this should work with BIOSes that do not need more than 32KB after boot.

Here is another caveat to overlaying anything within F000-FFFF as UMBs. Windows 386 enhanced mode depends on the ability to find an invalid instruction in that region, that will always remain constant through all DOS virtual machines, to use to break out of the DOS VM when the Windows kernel/VxDs/etc. need to be in control of handling a DOS interrupt: https://jeffpar.github.io/kbarchive/kb/071/Q71264/

Thanks all, super helpful. So I suppose there is no programmatic way to detect the size, except to maybe heuristically try to see if a large portion of the address space reads out as 00h or FFh or similar? (like, there is no standardized size field anywhere?)

clb wrote on 2023-08-11, 05:55:

Thanks all, super helpful. So I suppose there is no programmatic way to detect the size, except to maybe heuristically try to see if a large portion of the address space reads out as 00h or FFh or similar? (like, there is no standardized size field anywhere?)

On most BIOSes for 80386 or 80486 computers, you will always have the low 32K of the F segment filled with non-00, non-FF data. But on some (many?) boards, the F000-F7FF is not accessed after POST. There is no standardized field, but if you use QEMM as memory manager, QEMM can use the hardware page flags of the 386+ processor to track what memory areas are accessed. The Quarterdeck diagnostic tool "MFT" is able to display these flags, and shows whether read and/or write accesses to each 4K block of the first megabytes took place since QEMM has been loaded. This can be used to validate whether this memory is used after POSTing.

jakethompson1 wrote on 2023-08-10, 23:24:

Here is another caveat to overlaying anything within F000-FFFF as UMBs. Windows 386 enhanced mode depends on the ability to find an invalid instruction in that region, that will always remain constant through all DOS virtual machines, to use to break out of the DOS VM when the Windows kernel/VxDs/etc. need to be in control of handling a DOS interrupt: https://jeffpar.github.io/kbarchive/kb/071/Q71264/

sounds like only win3x would have a problem with this?

I've used the ROMBreakpoint variable in system.ini when running QEMM. Both QEMM and Hurricane Helix have ROM relocation options (Stealth and Cloaking respectively) that I presume allow part of the F000 segment to be remapped to UMBs. I'll have to check the AMIBIOS on my EISA/VLB board if it has shadowing options in that regions.

rasz_pl wrote on 2023-08-11, 17:38:

jakethompson1 wrote on 2023-08-10, 23:24:

Here is another caveat to overlaying anything within F000-FFFF as UMBs. Windows 386 enhanced mode depends on the ability to find an invalid instruction in that region, that will always remain constant through all DOS virtual machines, to use to break out of the DOS VM when the Windows kernel/VxDs/etc. need to be in control of handling a DOS interrupt: https://jeffpar.github.io/kbarchive/kb/071/Q71264/

sounds like only win3x would have a problem with this?

Unauthorized Windows 95 talks about it and does some measurements showing that Windows 95 spends a good portion of time in V86 mode (handling interrupts, etc.) and I suspect the same applies to Windows 98 and ME as well.

NJRoadfan wrote on 2023-08-14, 02:46:

I've used the ROMBreakpoint variable in system.ini when running QEMM. Both QEMM and Hurricane Helix have ROM relocation options (Stealth and Cloaking respectively) that I presume allow part of the F000 segment to be remapped to UMBs. I'll have to check the AMIBIOS on my EISA/VLB board if it has shadowing options in that regions.

Supposedly a part of the reason ARPL is used as the ROM breakpoint is that 0x63 is the letter 'C' so it's likely to show up in the copyright message.
I don't know if Windows searches for the 'C' starting at F000:FFFF looking downward, or from F000:0000 looking forward. If it's the former, remapping the bottom 32K of the ROM shouldn't hurt since it would find the 'C' in the upper 32K which you aren't touching.

jakethompson1 wrote on 2023-08-14, 02:48:

rasz_pl wrote on 2023-08-11, 17:38:

jakethompson1 wrote on 2023-08-10, 23:24:

Here is another caveat to overlaying anything within F000-FFFF as UMBs. Windows 386 enhanced mode depends on the ability to find an invalid instruction in that region, that will always remain constant through all DOS virtual machines, to use to break out of the DOS VM when the Windows kernel/VxDs/etc. need to be in control of handling a DOS interrupt: https://jeffpar.github.io/kbarchive/kb/071/Q71264/

sounds like only win3x would have a problem with this?

Unauthorized Windows 95 talks about it and does some measurements showing that Windows 95 spends a good portion of time in V86 mode (handling interrupts, etc.) and I suspect the same applies to Windows 98 and ME as well.

most likely win3x did the rom trick to save on ram, win95 didnt have this problem and probably arrenges something else (static allocation down low). Source for win10,2003,2000,xp and nt4 leaked, I dont know if there ever was Win95 leak 🙁 but shouldnt be hard to check what its doing in emulator (86box or pcem).