← Will the real Real Mode please stand up?

The PC floppy subsystem →

Posted on March 18, 2011 by Michal Necasek

The previous post talked about real mode on 286+ processors which behaves more like a slightly modified variant of protected mode rather than the old 8088/8086 processors. Real mode with non-compatible selector bases or limits is usually called unreal mode or big real mode. Even though Intel never clearly documented the behavior in detail, it is more or less set in stone thanks to our dear friend, backwards compatibility.

That’s because unreal mode had some rather prominent users—one of them was Microsoft’s HIMEM.SYS, used on nearly every PC in the 1990s. While disassembling HIMEM.SYS might be instructive, it would be a waste of time in this case, since Microsoft published the full source code to several HIMEM.SYS 2.x versions. That way, the evolution of the code can be easily traced.

HIMEM.SYS version 2.00 from July 1988 was quite straightforward and used BIOS INT 15h, function 87h to move data to and from extended memory above the 1MB line. However, that function isn’t particularly efficient. On 286 systems, it must reset the CPU, which isn’t fast. On 386 systems, assuming that the BIOS even implemented a 386-specific method without resetting the CPU, it still may have been slow. What’s worse, the BIOS block move had a tendency to block hardware interrupts for too long (a significant problem for serial port communications, notably modems).

In August 1988, HIMEM.SYS version 2.03 implemented a new method of copying memory on 386 compatible processors, using unreal mode (or Big Real mode as it’s called in the HIMEM source) when the processor isn’t already in protected (or more specifically, V86) mode. The method is remarkably simple: A simple string copy instruction is used, copying doublewords where possible, with ESI/EDI offsets beyond 1MB and ES and DS loaded with 0. That of course does not work in standard real mode. However, HIMEM.SYS installs a handler for interrupt 13 (General Protection Fault, or #GP). The #GP handler simply enters protected mode, loads a descriptor with zero base and 4GB limit into ES/DS, and immediately exits protected mode again. The memory move is then automatically restarted. Interrupts are disabled only for very brief periods of time, hence the danger of losing interrupts is very low.

A noteworthy side effect of this method is that the extended selector limits remain in effect, even when HIMEM.SYS is not being actively used. That means the next time extended memory is accessed, there will be no #GP and the memory move will succeed. Running with extended ES/DS selector limits does not cause harm to DOS applications. If some application switches to protected mode and sets the standard 64KB selector limits on the way back, HIMEM.SYS will simply extend the limits again the next time it is called.

The above method was obviously not usable on 286 systems. However, HIMEM.SYS version 2.06 added a new code path which avoided the BIOS thanks to the well-undocumented LOADALL instruction. LOADALL can be used to load the entire internal CPU state, including hidden registers. HIMEM.SYS modified the hidden segment base registers to point to the source or target memory location above 1MB. The processor was never switched out of real mode. The block move was done with interrupts enabled, although if an interrupt actually occurred, the selector bases had to be reprogrammed and the move restarted. The LOADALL method was then the only 286 code path, because V86 mode was not applicable (in other words, the CPU was always in real mode when executing HIMEM.SYS and LOADALL could be used).

Why wasn’t LOADALL used for the 386 code path in HIMEM.SYS? It simply wasn’t necessary because switching to protected mode and back avoided the need for undocumented instructions. Indeed, later processors (Pentium and above) removed LOADALL. A similar effect might still be achieved through SMM (System Management Mode), but only in a model-specific manner.

One of the biggest difficulties HIMEM.SYS implementors faced was the lack of standardized A20 line control. The PC/AT BIOS could (and had to) control the A20 line, but this functionality was unfortunately not exposed. PS/2 systems and various clones used other, more efficient A20 control methods, not necessarily PC/AT compatible. HIMEM.SYS contained a large chunk of code detecting the host type and installing a system specific A20 handler. HIMEM.SYS version 2.06 already contained four different handlers (PC/AT, PS/2, HP Vectra, and AT&T 6300) and later versions only added to that number.

The methods used by HIMEM.SYS were also employed by Microsoft Windows. Memory management product from competing companies (Qualitas, Quarterdeck, etc.) often used similar methods.

This entry was posted in DOS, x86. Bookmark the permalink.

← Will the real Real Mode please stand up?

The PC floppy subsystem →

Leave a Reply

Your email address will not be published. Required fields are marked *

Comment *

Name *

Email *

Website

Δ