Fix 16-bit mode instruction pointer wrap-around

[donno2048]

Not all x86 CPUs are even able to run in 32-bit mode, which creates portability issues.

Specifically, the problem I'm facing which prompted me to open this issue is running code that relies on the fact that on 16-bit mode when ip is 0xFFFF it'll wrap back to 0, v86 breaks this functionality as it uses eip causing it to continue to 0x10000.

[copy]

Do you have a minimal reproducing testcase? Ideally something that runs in qemu and doesn't in v86.

[donno2048]

Sure, The problem is that because we're talking about BIOSes it can't be minimal...

[donno2048]

Here is a pretty minimal VGA BIOS:

mov ax, 0xA000
mov ds, ax
mov dx, 0x3C0
mov al, 0x7
out dx, al
out dx, al
mov al, 0x60
out dx, al
mov dl, 0xC4
mov ax, 0x302
out dx, ax
mov dl, 0xC9
mov al, 0x1F
out dx, al
out dx, al
out dx, al
mov dl, 0xCE
mov ax, 0x1005
out dx, ax
mov ax, 0xFF08
out dx, ax
mov dl, 0xB4
mov ax, 0x2701
out dx, ax
mov ax, 0x4802
out dx, ax
mov ax, 0x4807
out dx, ax
mov ax, 0xF09
out dx, ax
mov ax, 0x8F12
out dx, ax
mov ax, 0x9015
out dx, ax
mov [0x30], WORD 0x730
hlt
times ($$-$+0x10000) db 0

If you run it on QEMU there will be a white '0' character on the first row of the screen.

If you run it on V86 it won't run anything.

To make it run on V86 you'll have to switch times ($$-$+0x10000) db 0 with something along the lines of:

times ($$-$+0xFFFC) db 0
nop
jmp $$

Or more traditionally:

times ($$-$+0xFFF0) db 0
jmp $$
times ($$-$+0x10000) db 0

[donno2048]

@copy sorry for bugging just wondering if there's an update on this?

[copy]

The testcase is useful, thanks for that.

This issue will be difficult to fix in a way that doesn't negatively affect performance of other programs. I currently don't really have the time to look into it, and it's not really a priority either, as it doesn't seem to affect any OSes we currently run.