so, you have an architecture that was made to be CP/M compatible, and this explains why 8086 has "Real-Mode", but ... wait, what is "
Unreal-Mode"?
it has been mentioned here and there in Grub (legacy), and it looks to me like a
hardware bug in the CPU design, so, it won't work on some CPUs(1), but when it works it's an exploit that you can use by setting the CPU in Protected Mode, then setting the descriptor cache's limits for your segment registers to any value higher than 64Kbyte, and finally setting back the CPU in real-mode, and ...
... and boom, the magic power of quirks breaks the 64Kbyte limit of real mode segments while retaining 16-bit instructions and the segment * 16 + offset addressing mode by tweaking the descriptor caches.
- code still limited to 64Kbyte
- data allowed accessing 4Gbyte
- CPU in real mode!!! 16bit!!!
it's useful when you're trying to load something that will run in 32-bit mode which is larger than what you are allowed to load in "conventional" (I mean without the Unreal Mode trick) Real Mode memory and you don't want to bother writing a protected mode driver yet, but you also want to avoid switching between real and protected mode to copy chunks from the conventional memory buffer into extended memory.
(1) tested on
- PC, AMI BIOS, intel 486-DX2 ---> it worked
- PC, Phenix BIOS, intel PentiumII ---> it worked
- AppleMini, Apple BIOS, intel Core2 dual ---> it worked
- Acord RiscPC/x86_guest_card, A1 BIOS, AMD 586 ---> it worked
- Acord RiscPC/x86_guest_card, A1 BIOS, Cyrix Cx486 ---> it didn't work!!! <---- Is it a problem?!?
- Acord RiscPC/x86_guest_card, A1 BIOS, Cyrix C5x86 ---> it didn't work!!! <---- Is it a problem?!?
untested on Xeon, Opteron, etc
edit:
solved