OSDev.org

As the title stated, will it be safe to run real mode code under unreal mode(large mode) and A20 line enable.
Because I need to R/W memory at high address and using some BIOS interupt function, will such config crash in BIOS call?

it will not crash. bios interrupts will work properly in unreal mode. nowdays most of the intel configs will boot in unreal mode by default, but older intels, and all amd-s will require to set unreal mode.

Hi,



It's mostly safe, but (depending on which BIOS functions you use and a few other things) there's a (relatively small) chance that the BIOS will use protected mode and disable unreal mode (restore 64 KiB segment limits) when you're not expecting it. Note: This is most often a problem caused by network cards, RAID controllers and SCSI controllers that don't use (slow) IO ports; where the device's ROM has to enable protected mode to access the device's memory mapped registers.

To guard against that it's a nice idea to hook the BIOS "interrupt 0x0D" handler, where your code would:

• Check if the interrupt's "return CS:IP" points to the area your code is in, and jump to the original BIOS interrupt handler if it's not
• Check if the master PIC chip sent an "IRQ5" (by reading the PIC chip's "In Service Register" and checking bit 5), and if IRQ5 is in service jump to the original BIOS interrupt handler
• Otherwise (if your code was interrupted and it's not an IRQ) assume the interrupt was caused by a general protection fault (which was caused by your code using unreal mode when segment limits have been restored unexpectedly), and re-enable unreal mode and return to the instruction that cause the general protection fault

That way, if anything ever does restore real mode segment limits your "interrupt 0x0D hook" will auto-fix the problem and continue as if nothing happened.


Cheers,

Brendan

That's very much what I do in Smaller C's unreal mode. Except, I don't check CS:IP to belong to my code in #GP/IRQ5 handler. And I allow for nested #GP/IRQ5 handling. On the first invocation of the #GP/IRQ5 handler I check the IRQ5 ISR bit in the PIC. If it's set, I then call my custom handler which may do something or nothing and request the original handler to be invoked. If IRQ5 ISR is not set, it must be a #GP. On more deeply nested invocations (in reality, just one or we're screwed), I assume it's a #GP (triggered by the IRQ5 handler). This lets me use unreal mode code in all ISRs as well, including the IRQ5 ISR.

You're right, there is also that occassion that BIOS will also use unreal mode and also restore the ds(or es) back to the limit 0xffff, so it is nessasary to do like you've stated.

For A20, it's designed for backward compatibility for those ancient software abusing wrapping at the end.
So if your real mode code rely on that, it's not safe. AFAIK BIOS should not rely on that, but BIOS can always surprise you.