DOS ain't dead

I just noticed that testing instructions like mov ax, [FFFF] and mov ax, [es:FFFF] do not cause a fault when I boot the physical Pentium 3 (686) machine into bootable lDebug. (You want to install intfaults before running such tests, to have the debugger catch these Real 86 Mode faults in case they do occur.) With cs, ss, or fs overrides the instruction does fault (int 0Ch for ss, int 0Dh else).

If I boot using boot protocol msdos7 hda2 followed by q, which runs a Himem driver, then regardless of the involved segment the instruction does fault. (This is without an EMM that switches to Virtual 86 Mode, the machine is still in Real 86 Mode.)

So I assume that the ROM-BIOS leaves ds and es limits in an "unreal mode" state of higher segment limits than the 64 KiB expected for Real 86 Mode. Did you know that this is done by some systems?

---
l

> I just noticed that testing instructions like mov ax, [FFFF]
> and mov ax, [es:FFFF] do not cause a fault when I boot the
> physical Pentium 3 (686) machine into bootable lDebug. (You want to
> install intfaults before running such tests, to have the
> debugger catch these Real 86 Mode faults in case they do occur.) With cs,
> ss, or fs overrides the instruction does fault (int 0Ch for ss, int 0Dh
> else).
>
> If I boot using boot protocol msdos7 hda2 followed by
> q, which runs a Himem driver, then regardless of the involved
> segment the instruction does fault. (This is without an EMM that switches
> to Virtual 86 Mode, the machine is still in Real 86 Mode.)
>
> So I assume that the ROM-BIOS leaves ds and es limits in an "unreal mode"
> state of higher segment limits than the 64 KiB expected for Real 86 Mode.
> Did you know that this is done by some systems?

Yes. You'd need to verify values of CR0, GDT and IDT but it is possible that some BIOSes, games and other software can/will leave the host in Unreal Mode accidentally.

One fun trick is to write to VGA buffer space using a single 32-bit instruction while in Unreal Mode.

mov ebx,A0000
mov [ds:ebx], byte 1 ; set the pixel "white" using default color palette



https://en.m.wikipedia.org/wiki/Unreal_mode#Uses

https://wiki.osdev.org/Unreal_Mode

> One fun trick is to write to VGA buffer space using a single 32-bit
> instruction while in Unreal Mode.
>
> mov ebx,A0000
> mov [ds:ebx], byte 1 ; set the pixel "white" using default color palette
>

I can read from the word at segment 0 offset B8000 to read the text mode buffer. I just checked again, ds and es have higher limits, cs, ss, fs, and also gs do not. Also, the ROM-BIOS identifies itself as "Award Medallion BIOS v6.0", "Copyright (C) 1984-2000", running an "ASUS MED 2001 ACPI BIOS Revision 1009". At the bottom of the startup screen it reads "06/12/2001-VT694X-MED 2001".

---
l

> I just noticed that testing instructions like mov ax, [FFFF]
> and mov ax, [es:FFFF] do not cause a fault when I boot the
> physical Pentium 3 (686) machine into bootable lDebug. (You want to
> install intfaults before running such tests, to have the
> debugger catch these Real 86 Mode faults in case they do occur.) With cs,
> ss, or fs overrides the instruction does fault (int 0Ch for ss, int 0Dh
> else).
>
> If I boot using boot protocol msdos7 hda2 followed by
> q, which runs a Himem driver, then regardless of the involved
> segment the instruction does fault. (This is without an EMM that switches
> to Virtual 86 Mode, the machine is still in Real 86 Mode.)
>
> So I assume that the ROM-BIOS leaves ds and es limits in an "unreal mode"
> state of higher segment limits than the 64 KiB expected for Real 86 Mode.
> Did you know that this is done by some systems?

The way it works on the original 8086/8088 CPUs, which I think is what should be emulated by default, is obviously that it wouldn't generate a fault (the old CPU's didn't have segment faults). The issue is what byte ends up in AH when you do something like a MOV AX,[FFFFh]. Is it the byte at DS:[0000h] or the byte at the linear address one byte above DS:[FFFFh]. I believe it should be DS:[0000h], but am not 100% positive. I do know when you use high _segment_ numbers they roll over to zero so you can't access the HMA unless you enable A20 (which 8086/8088 CPU's didn't have, either).

> The way it works on the original 8086/8088 CPUs, which I think is what
> should be emulated by default, is obviously that it wouldn't generate a
> fault (the old CPU's didn't have segment faults).

Yes, indeed. I previously discussed this on stackoverflow and on the dosemu2 site. As bartoldeman stated there:

> > it's documented in "Differences From 8086" in the original 80386 programmer's manual. e.g. https://pdos.csail.mit.edu/6.828/2018/readings/i386.pdf
>
> Page 211.

Quoting from there:

> Operand crossing offset 0 or 65,535.
>
> On the 8086, an attempt to access a memory operand that crosses
> offset 65,535 (e.g., MOV a word to offset 65,535) or offset 0 (e.g.,
> PUSH a word when SP = 1) causes the offset to wrap around modulo
> 65,536. The 80386 raises an exception in these cases──exception 13 if
> the segment is a data segment (i.e., if CS, DS, ES, FS, or GS is being
> used to address the segment), exception 12 if the segment is a stack
> segment (i.e., if SS is being used).
>
> Sequential execution across offset 65,535.
>
> On the 8086, if sequential execution of instructions proceeds past
> offset 65,535, the processor fetches the next instruction byte from
> offset 0 of the same segment. On the 80386, the processor raises
> exception 13 in such a case.

For more information on the IP fault, refer to https://www.os2museum.com/wp/does-eip-wrap-around-in-16-bit-segments/ as well.

> The issue is what byte
> ends up in AH when you do something like a MOV AX,[FFFFh]. Is
> it the byte at DS:[0000h] or the byte at the linear address one byte above
> DS:[FFFFh]. I believe it should be DS:[0000h], but am not 100% positive.

Yes, on the NEC V20 (as used by my HP 95LX) it does actually access the byte at offset 0000h, not 10000h, as the high byte. Not sure what Intel's 8086, 186, and 286 did.

---
l

> Yes, on the NEC V20 (as used by my HP 95LX) it does actually access the
> byte at offset 0000h, not 10000h, as the high byte. Not sure what Intel's
> 8086, 186, and 286 did.

And that's something I wouldn't necessarily trust that any of the modern VM's get correct, either. The only way I would believe the test was correct is if I did it on a real CPU.

I know the LOADFIX program included with early versions of DOS was supposed to resolve memory rollover issues that would crash some programs, but I don't know the exact details.