VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

Is there any software that can be used(easily) for determining bugs in x86 protected mode emulation? E.g. missing or too many faults etc, paging emulation, general protection fault tests, stack fault tests, not present fault tests etc.?

EMM386 works without noticable problems, as do Megarace and Microsoft Flight Simulator 4(version 5.1 runs, but doesn't display the upper part(the part containing the output of the view mode. It just displays gray color?).

Hottobar's test386.asm testsuite already checks out 100%.
Linux won't boot, so xoreaxeaxeax can't be run as well.

Anyone?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 15, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Well, CheckIt! and NSSI can test 16/32-Bit protected mode..
Though perhaps not as thoroughly as you may need, since these are general purpose diagnostic programs.
As a stress test, Linux/Minix or OS/2 aren't bad either, I think. Anyway, these depths of x86 aren't my league. I'm just an user.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 2 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Running the MS-DOS boot.com on the minix.mnx image results(tutorial from https://virtuallyfun.com/wordpress/2009/10/09 … dos-minix-2-04/) in the following(running from MS-DOS 5.0 in UniPCemu instead of Dosbox):
1. I'm greeted with a message telling me to choose something. I press enter.
2. It starts the kernel, then proceeds to mount four partitions?
3. It then reboots(triple fault?) after seeing a flash on the screen about some little text with a turning thing again(on the third row I believe):

First steps of the booting process:

496.jpg
Filename
496.jpg
File size
65.33 KiB
Views
1778 views
File comment
First step of the Minix booting process from MS-DOS 5.0a
File license
Fair use/fair dealing exception
497.jpg
Filename
497.jpg
File size
15.67 KiB
Views
1778 views
File license
Fair use/fair dealing exception
498.jpg
Filename
498.jpg
File size
16.9 KiB
Views
1778 views
File license
Fair use/fair dealing exception
499.jpg
Filename
499.jpg
File size
22.41 KiB
Views
1778 views
File license
Fair use/fair dealing exception
500.jpg
Filename
500.jpg
File size
26.66 KiB
Views
1778 views
File license
Fair use/fair dealing exception
Last edited by superfury on 2018-05-16, 12:24. Edited 1 time in total.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 3 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

And the final steps before crashing(triple fault it seems):

501.jpg
Filename
501.jpg
File size
30.94 KiB
Views
1778 views
File license
Fair use/fair dealing exception
502.jpg
Filename
502.jpg
File size
35.42 KiB
Views
1778 views
File license
Fair use/fair dealing exception
503.jpg
Filename
503.jpg
File size
39.34 KiB
Views
1778 views
File comment
Last screenshot before crashing(which shows a flash of something starting)
File license
Fair use/fair dealing exception

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 4 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Looking at the CPU state itself, it seems to triple fault. The previous instruction was running at CS base address E400. So it's somewhere in the kernel?

The base of CS is still E400, with a 4GB limit. All other segments have a base of 1A400 with a limit of 4GB. CPL is zero, so it's still in the kernel.

It seems to have encountered an #UD exception(for executing a FFFFh instruction), at logical address 05c70009h(the value of EIP when the instruction starts)? Paging is disabled(so it's trying to execute non-existant physical memory). Anyone knows anything about this? Previous opcode was C3h(A RET instruction).

Edit: OK, it's already running in protected mode during the loading stage. So somewhere after that, after loading init, it ends up at an unknown 0xFFFF opcode?

Edit: Here's a common emulator log of the kernel loading (starting somewhere within the kernel image loading) and crashing(look for #UD in the log):

Filename
debugger_UniPCemu_bootingminix_loadingexecutableimages.7z
File size
1.16 MiB
Downloads
55 downloads
File comment
Common emulator log of protected mode loading the images until crashing*look for #UD).
File license
Fair use/fair dealing exception

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 5 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

It seems that at line 380309 it enters protected mode, thus the start of the kernel running? It's starting at physical address 91AD0, offset 0934?

Edit: Looking back into the code, the accompanying CALL to the invalid RET seems to be at row 438553?

The call that's supposed to accompany the RET that's failing:

	Paged(w):0001C740=C7(Ç); Paged(w):0001C741=05(); Paged(w):0001C742=00( ); Paged(w):0001C743=00( ); Physical(w):0001C740=C7(Ç); RAM(w):0001C740=C7(Ç); Physical(w):0001C741=05(); RAM(w):0001C741=05(); Physical(w):0001C742=00( ); RAM(w):0001C742=00( ); Physical(w):0001C743=00( ); RAM(w):0001C743=00( )
RAM(p):0000E9D0=AB(«); Physical(p):0000E9D0=AB(«); Paged(p):0000E9D0=AB(«); RAM(p):0000E9D1=00( ); Physical(p):0000E9D1=00( ); Paged(p):0000E9D1=00( ); RAM(p):0000E9D2=00( ); Physical(p):0000E9D2=00( ); Paged(p):0000E9D2=00( ); RAM(p):0000E9D3=00( ); Physical(p):0000E9D3=00( ); Paged(p):0000E9D3=00( )
0030:000005c2 E8 39 06 00 00 calld 00000c00 RAM(p):0000F000=FC(ü); Physical(p):0000F000=FC(ü); Paged(p):0000F000=FC(ü); RAM(p):0000F001=56(V); Physical(p):0000F001=56(V); Paged(p):0000F001=56(V); RAM(p):0000F002=57(W); Physical(p):0000F002=57(W); Paged(p):0000F002=57(W); RAM(p):0000F003=06(); Physical(p):0000F003=06(); Paged(p):0000F003=06()
Registers:
EAX: 0001c790 EBX: 0000de50 ECX: 00000028 EDX: 00091ad0
ESP: 00002344 EBP: 00002360 ESI: 00096bac EDI: 000001fe
CS: 0030 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0018 TR: 0000 LDTR: 0000
EIP: 000005c2 EFLAGS: 00007006
CR0: 0000fff1 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 000000020b94003f IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0N11oditsz0a0P1c
RAM(p):0000F004=B8(¸); Physical(p):0000F004=B8(¸); Paged(p):0000F004=B8(¸); RAM(p):0000F005=21(!); Physical(p):0000F005=21(!); Paged(p):0000F005=21(!); RAM(p):0000F006=00( ); Physical(p):0000F006=00( ); Paged(p):0000F006=00( ); RAM(p):0000F007=00( ); Physical(p):0000F007=00( ); Paged(p):0000F007=00( )
RAM(p):0000F008=00( ); Physical(p):0000F008=00( ); Paged(p):0000F008=00( ); RAM(p):0000F009=8E(Ž); Physical(p):0000F009=8E(Ž); Paged(p):0000F009=8E(Ž); RAM(p):0000F00A=C0(À); Physical(p):0000F00A=C0(À); Paged(p):0000F00A=C0(À); RAM(p):0000F00B=8B(‹); Physical(p):0000F00B=8B(‹); Paged(p):0000F00B=8B(‹)
RAM(p):0000F00C=74(t); Physical(p):0000F00C=74(t); Paged(p):0000F00C=74(t); RAM(p):0000F00D=24($); Physical(p):0000F00D=24($); Paged(p):0000F00D=24($); RAM(p):0000F00E=10(); Physical(p):0000F00E=10(); Paged(p):0000F00E=10(); RAM(p):0000F00F=8B(‹); Physical(p):0000F00F=8B(‹); Paged(p):0000F00F=8B(‹)
0030:00000c00 FC cld
Registers:
EAX: 0001c790 EBX: 0000de50 ECX: 00000028 EDX: 00091ad0
ESP: 00002340 EBP: 00002360 ESI: 00096bac EDI: 000001fe
CS: 0030 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0018 TR: 0000 LDTR: 0000
EIP: 00000c00 EFLAGS: 00007006
CR0: 0000fff1 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 000000020b94003f IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0N11oditsz0a0P1c

SS:ESP is 0018:00002344 at the moment the CALL occurs. It's 00002340 after that? The logical address of the return address is 0001C740.

When the RET occurs, SS is still 0018, so that one's correct. ESP is 233E, so it's one 16-bit entry popped too much somewhere in between?

Edit: OK, let's look at the pushes and popping in between:
First, PUSH ESI,EDI and ES(pushing 32-bit entries on the stack):

0030:00000c01 56 push esi
Registers:
EAX: 0001c790 EBX: 0000de50 ECX: 00000028 EDX: 00091ad0
ESP: 00002340 EBP: 00002360 ESI: 00096bac EDI: 000001fe
CS: 0030 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0018 TR: 0000 LDTR: 0000
EIP: 00000c01 EFLAGS: 00007006
CR0: 0000fff1 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 000000020b94003f IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0N11oditsz0a0P1c
Paged(w):0001C738=FE(þ); Paged(w):0001C739=01(); Paged(w):0001C73A=00( ); Paged(w):0001C73B=00( ); Physical(w):0001C738=FE(þ); RAM(w):0001C738=FE(þ); Physical(w):0001C739=01(); RAM(w):0001C739=01(); Physical(w):0001C73A=00( ); RAM(w):0001C73A=00( ); Physical(w):0001C73B=00( ); RAM(w):0001C73B=00( )
0030:00000c02 57 push edi
Registers:
EAX: 0001c790 EBX: 0000de50 ECX: 00000028 EDX: 00091ad0
ESP: 0000233c EBP: 00002360 ESI: 00096bac EDI: 000001fe
CS: 0030 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0018 TR: 0000 LDTR: 0000
EIP: 00000c02 EFLAGS: 00007006
CR0: 0000fff1 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 000000020b94003f IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0N11oditsz0a0P1c
Paged(w):0001C734=18(); Paged(w):0001C735=00( ); Physical(w):0001C734=18(); RAM(w):0001C734=18(); Physical(w):0001C735=00( ); RAM(w):0001C735=00( )
0030:00000c03 06 push es RAM(p):0000F010=7C(|); Physical(p):0000F010=7C(|); Paged(p):0000F010=7C(|); RAM(p):0000F011=24($); Physical(p):0000F011=24($); Paged(p):0000F011=24($); RAM(p):0000F012=14(); Physical(p):0000F012=14(); Paged(p):0000F012=14(); RAM(p):0000F013=8B(‹); Physical(p):0000F013=8B(‹); Paged(p):0000F013=8B(‹)
Registers:
EAX: 0001c790 EBX: 0000de50 ECX: 00000028 EDX: 00091ad0
ESP: 00002338 EBP: 00002360 ESI: 00096bac EDI: 000001fe
CS: 0030 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0018 TR: 0000 LDTR: 0000
EIP: 00000c03 EFLAGS: 00007006
CR0: 0000fff1 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 000000020b94003f IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0N11oditsz0a0P1c
0030:00000c04 B8 21 00 00 00 mov eax,00000021 RAM(p):0000F014=44(D); Physical(p):0000F014=44(D); Paged(p):0000F014=44(D); RAM(p):0000F015=24($); Physical(p):0000F015=24($); Paged(p):0000F015=24($); RAM(p):0000F016=18(); Physical(p):0000F016=18(); Paged(p):0000F016=18(); RAM(p):0000F017=3D(=); Physical(p):0000F017=3D(=); Paged(p):0000F017=3D(=)
Registers:
EAX: 0001c790 EBX: 0000de50 ECX: 00000028 EDX: 00091ad0
ESP: 00002334 EBP: 00002360 ESI: 00096bac EDI: 000001fe
CS: 0030 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0018 TR: 0000 LDTR: 0000
EIP: 00000c04 EFLAGS: 00007006
CR0: 0000fff1 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 000000020b94003f IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0N11oditsz0a0P1c

Then POP ES(reverse of the earlier push) only pops a 2-byte entry? Is this correct behaviour?

	RAM(p):0000F038=F3(ó); Physical(p):0000F038=F3(ó); Paged(p):0000F038=F3(ó); RAM(p):0000F039=26(&); Physical(p):0000F039=26(&); Paged(p):0000F039=26(&); RAM(p):0000F03A=A4(¤); Physical(p):0000F03A=A4(¤); Paged(p):0000F03A=A4(¤); RAM(p):0000F03B=07(); Physical(p):0000F03B=07(); Paged(p):0000F03B=07()
RAM(p):0000F03C=5F(_); Physical(p):0000F03C=5F(_); Paged(p):0000F03C=5F(_); RAM(p):0000F03D=5E(^); Physical(p):0000F03D=5E(^); Paged(p):0000F03D=5E(^); RAM(p):0000F03E=C3(Ã); Physical(p):0000F03E=C3(Ã); Paged(p):0000F03E=C3(Ã); RAM(p):0000F03F=00( ); Physical(p):0000F03F=00( ); Paged(p):0000F03F=00( )
RAM(p):0000F040=8C(Œ); Physical(p):0000F040=8C(Œ); Paged(p):0000F040=8C(Œ); RAM(p):0000F041=D9(Ù); Physical(p):0000F041=D9(Ù); Paged(p):0000F041=D9(Ù); RAM(p):0000F042=8E(Ž); Physical(p):0000F042=8E(Ž); Paged(p):0000F042=8E(Ž); RAM(p):0000F043=5C(\); Physical(p):0000F043=5C(\); Paged(p):0000F043=5C(\)
RAM(p):0000F044=24($); Physical(p):0000F044=24($); Paged(p):0000F044=24($); RAM(p):0000F045=04(); Physical(p):0000F045=04(); Paged(p):0000F045=04(); RAM(p):0000F046=8B(‹); Physical(p):0000F046=8B(‹); Paged(p):0000F046=8B(‹); RAM(p):0000F047=44(D); Physical(p):0000F047=44(D); Paged(p):0000F047=44(D)
RAM(r):0009FB1D=70(p); Physical(r):0009FB1D=70(p); Paged(r):0009FB1D=70(p)
Paged(w):0001C98D=70(p); Physical(w):0001C98D=70(p); RAM(w):0001C98D=70(p)
RAM(p):0000F038=F3(ó); Physical(p):0000F038=F3(ó); Paged(p):0000F038=F3(ó); RAM(p):0000F039=26(&); Physical(p):0000F039=26(&); Paged(p):0000F039=26(&); RAM(p):0000F03A=A4(¤); Physical(p):0000F03A=A4(¤); Paged(p):0000F03A=A4(¤); RAM(p):0000F03B=07(); Physical(p):0000F03B=07(); Paged(p):0000F03B=07()
RAM(p):0000F03C=5F(_); Physical(p):0000F03C=5F(_); Paged(p):0000F03C=5F(_); RAM(p):0000F03D=5E(^); Physical(p):0000F03D=5E(^); Paged(p):0000F03D=5E(^); RAM(p):0000F03E=C3(Ã); Physical(p):0000F03E=C3(Ã); Paged(p):0000F03E=C3(Ã); RAM(p):0000F03F=00( ); Physical(p):0000F03F=00( ); Paged(p):0000F03F=00( )
RAM(p):0000F040=8C(Œ); Physical(p):0000F040=8C(Œ); Paged(p):0000F040=8C(Œ); RAM(p):0000F041=D9(Ù); Physical(p):0000F041=D9(Ù); Paged(p):0000F041=D9(Ù); RAM(p):0000F042=8E(Ž); Physical(p):0000F042=8E(Ž); Paged(p):0000F042=8E(Ž); RAM(p):0000F043=5C(\); Physical(p):0000F043=5C(\); Paged(p):0000F043=5C(\)
RAM(r):0001C734=18(); Physical(r):0001C734=18(); Paged(r):0001C734=18(); RAM(r):0001C735=00( ); Physical(r):0001C735=00( ); Paged(r):0001C735=00( )
Reading from RAM(r): 00020BAC=6B (k)
Reading from physical memory(r): 00020BAC=6B (k)
Reading from paged memory(r): 00020BAC=6B (k)
Reading from RAM(r): 00020BAD=B2 (²)
Reading from physical memory(r): 00020BAD=B2 (²)
Reading from paged memory(r): 00020BAD=B2 (²)
Reading from RAM(r): 00020BAE=00 ( )
Reading from physical memory(r): 00020BAE=00 ( )
Reading from paged memory(r): 00020BAE=00 ( )
Reading from RAM(r): 00020BAF=A4 (¤)
Reading from physical memory(r): 00020BAF=A4 (¤)
Reading from paged memory(r): 00020BAF=A4 (¤)
Reading from RAM(r): 00020BB0=01 ()
Reading from physical memory(r): 00020BB0=01 ()
Reading from paged memory(r): 00020BB0=01 ()
Reading from RAM(r): 00020BB1=92 (’)
Reading from physical memory(r): 00020BB1=92 (’)
Reading from paged memory(r): 00020BB1=92 (’)
Reading from RAM(r): 00020BB2=40 (@)
Reading from physical memory(r): 00020BB2=40 (@)
Reading from paged memory(r): 00020BB2=40 (@)
Reading from RAM(r): 00020BB3=00 ( )
Reading from physical memory(r): 00020BB3=00 ( )
Reading from paged memory(r): 00020BB3=00 ( )
Writing to paged memory(w): 00020BAC=6B (k)
Writing to physical memory(w): 00020BAC=6B (k)
Writing to RAM(w): 00020BAC=6B (k)
Writing to paged memory(w): 00020BAD=B2 (²)
Writing to physical memory(w): 00020BAD=B2 (²)
Writing to RAM(w): 00020BAD=B2 (²)
Writing to paged memory(w): 00020BAE=00 ( )
Writing to physical memory(w): 00020BAE=00 ( )
Writing to RAM(w): 00020BAE=00 ( )
Writing to paged memory(w): 00020BAF=A4 (¤)
Writing to physical memory(w): 00020BAF=A4 (¤)
Writing to RAM(w): 00020BAF=A4 (¤)
Writing to paged memory(w): 00020BB0=01 ()
Writing to physical memory(w): 00020BB0=01 ()
Writing to RAM(w): 00020BB0=01 ()
Writing to paged memory(w): 00020BB1=93 (“)
Writing to physical memory(w): 00020BB1=93 (“)
Writing to RAM(w): 00020BB1=93 (“)
Writing to paged memory(w): 00020BB2=40 (@)
Writing to physical memory(w): 00020BB2=40 (@)
Writing to RAM(w): 00020BB2=40 (@)
Writing to paged memory(w): 00020BB3=00 ( )
Writing to physical memory(w): 00020BB3=00 ( )
Writing to RAM(w): 00020BB3=00 ( )
0030:00000c3b 07 pop es RAM(p):0000F044=24($); Physical(p):0000F044=24($); Paged(p):0000F044=24($); RAM(p):0000F045=04(); Physical(p):0000F045=04(); Paged(p):0000F045=04(); RAM(p):0000F046=8B(‹); Physical(p):0000F046=8B(‹); Paged(p):0000F046=8B(‹); RAM(p):0000F047=44(D); Physical(p):0000F047=44(D); Paged(p):0000F047=44(D)
Registers:
Show last 102 lines
EAX: 00000000 EBX: 0000de50 ECX: 00000000 EDX: 00091ad0
ESP: 00002334 EBP: 00002360 ESI: 0009fb1e EDI: 0001c98e
CS: 0030 DS: 0018 ES: 0021 FS: 0018 GS: 0018 SS: 0018 TR: 0000 LDTR: 0000
EIP: 00000c3b EFLAGS: 00007012
CR0: 0000fff1 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 000000020b94003f IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0N11oditsz0A0p1c
RAM(p):0000F048=24($); Physical(p):0000F048=24($); Paged(p):0000F048=24($); RAM(p):0000F049=08(); Physical(p):0000F049=08(); Paged(p):0000F049=08(); RAM(p):0000F04A=0F(); Physical(p):0000F04A=0F(); Paged(p):0000F04A=0F(); RAM(p):0000F04B=B7(·); Physical(p):0000F04B=B7(·); Paged(p):0000F04B=B7(·)
RAM(r):0001C736=00( ); Physical(r):0001C736=00( ); Paged(r):0001C736=00( ); RAM(r):0001C737=00( ); Physical(r):0001C737=00( ); Paged(r):0001C737=00( )
RAM(r):0001C738=FE(þ); Physical(r):0001C738=FE(þ); Paged(r):0001C738=FE(þ); RAM(r):0001C739=01(); Physical(r):0001C739=01(); Paged(r):0001C739=01()
0030:00000c3c 5F pop edi
Registers:
EAX: 00000000 EBX: 0000de50 ECX: 00000000 EDX: 00091ad0
ESP: 00002336 EBP: 00002360 ESI: 0009fb1e EDI: 0001c98e
CS: 0030 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0018 TR: 0000 LDTR: 0000
EIP: 00000c3c EFLAGS: 00007012
CR0: 0000fff1 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 000000020b94003f IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0N11oditsz0A0p1c
RAM(r):0001C73A=00( ); Physical(r):0001C73A=00( ); Paged(r):0001C73A=00( ); RAM(r):0001C73B=00( ); Physical(r):0001C73B=00( ); Paged(r):0001C73B=00( )
RAM(r):0001C73C=AC(¬); Physical(r):0001C73C=AC(¬); Paged(r):0001C73C=AC(¬); RAM(r):0001C73D=6B(k); Physical(r):0001C73D=6B(k); Paged(r):0001C73D=6B(k)
0030:00000c3d 5E pop esi
Registers:
EAX: 00000000 EBX: 0000de50 ECX: 00000000 EDX: 00091ad0
ESP: 0000233a EBP: 00002360 ESI: 0009fb1e EDI: 01fe0000
CS: 0030 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0018 TR: 0000 LDTR: 0000
EIP: 00000c3d EFLAGS: 00007012
CR0: 0000fff1 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 000000020b94003f IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0N11oditsz0A0p1c
RAM(r):0001C73E=09( ); Physical(r):0001C73E=09( ); Paged(r):0001C73E=09( ); RAM(r):0001C73F=00( ); Physical(r):0001C73F=00( ); Paged(r):0001C73F=00( )
RAM(r):0001C740=C7(Ç); Physical(r):0001C740=C7(Ç); Paged(r):0001C740=C7(Ç); RAM(r):0001C741=05(); Physical(r):0001C741=05(); Paged(r):0001C741=05()
0030:00000c3e C3 retd Physical(p):05C7E409=FF(ÿ); Paged(p):05C7E409=FF(ÿ); Physical(p):05C7E40A=FF(ÿ); Paged(p):05C7E40A=FF(ÿ); Physical(p):05C7E40B=FF(ÿ); Paged(p):05C7E40B=FF(ÿ); Physical(p):05C7E40C=FF(ÿ); Paged(p):05C7E40C=FF(ÿ)
Registers:
EAX: 00000000 EBX: 0000de50 ECX: 00000000 EDX: 00091ad0
ESP: 0000233e EBP: 00002360 ESI: 6bac0000 EDI: 01fe0000
CS: 0030 DS: 0018 ES: 0018 FS: 0018 GS: 0018 SS: 0018 TR: 0000 LDTR: 0000
EIP: 00000c3e EFLAGS: 00007012
CR0: 0000fff1 CR1: 00000000 CR2: 00000000 CR3: 00000000
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
GDTR: 000000020b94003f IDTR: 000000000000ffff
FLAGSINFO: 00000000000000vr0N11oditsz0A0p1c
Physical(p):05C7E40D=FF(ÿ); Paged(p):05C7E40D=FF(ÿ); Physical(p):05C7E40E=FF(ÿ); Paged(p):05C7E40E=FF(ÿ); Physical(p):05C7E40F=FF(ÿ); Paged(p):05C7E40F=FF(ÿ); Physical(p):05C7E410=FF(ÿ); Paged(p):05C7E410=FF(ÿ)
Physical(p):05C7E411=FF(ÿ); Paged(p):05C7E411=FF(ÿ); Physical(p):05C7E412=FF(ÿ); Paged(p):05C7E412=FF(ÿ); Physical(p):05C7E413=FF(ÿ); Paged(p):05C7E413=FF(ÿ); Physical(p):05C7E414=FF(ÿ); Paged(p):05C7E414=FF(ÿ)
Physical(p):05C7E415=FF(ÿ); Paged(p):05C7E415=FF(ÿ); Physical(p):05C7E416=FF(ÿ); Paged(p):05C7E416=FF(ÿ); Physical(p):05C7E417=FF(ÿ); Paged(p):05C7E417=FF(ÿ); Physical(p):05C7E418=FF(ÿ); Paged(p):05C7E418=FF(ÿ)
Reading from RAM(r): 00000030=87 (‡)
Reading from physical memory(r): 00000030=87 (‡)
Reading from paged memory(r): 00000030=87 (‡)
Reading from RAM(r): 00000031=00 ( )
Reading from physical memory(r): 00000031=00 ( )
Reading from paged memory(r): 00000031=00 ( )
Reading from RAM(r): 00000032=02 ()
Reading from physical memory(r): 00000032=02 ()
Reading from paged memory(r): 00000032=02 ()
Reading from RAM(r): 00000033=05 ()
Reading from physical memory(r): 00000033=05 ()
Reading from paged memory(r): 00000033=05 ()
Reading from RAM(r): 00000034=9F (Ÿ)
Reading from physical memory(r): 00000034=9F (Ÿ)
Reading from paged memory(r): 00000034=9F (Ÿ)
Reading from RAM(r): 00000035=00 ( )
Reading from physical memory(r): 00000035=00 ( )
Reading from paged memory(r): 00000035=00 ( )
Reading from RAM(r): 00000036=02 ()
Reading from physical memory(r): 00000036=02 ()
Reading from paged memory(r): 00000036=02 ()
Reading from RAM(r): 00000037=05 ()
Reading from physical memory(r): 00000037=05 ()
Reading from paged memory(r): 00000037=05 ()
00:14:17:67.05584: #GP fault(00000033)!
Reading from RAM(r): 00000068=6E (n)
Reading from physical memory(r): 00000068=6E (n)
Reading from paged memory(r): 00000068=6E (n)
Reading from RAM(r): 00000069=FE (þ)
Reading from physical memory(r): 00000069=FE (þ)
Reading from paged memory(r): 00000069=FE (þ)
Reading from RAM(r): 0000006A=00 ( )
Reading from physical memory(r): 0000006A=00 ( )
Reading from paged memory(r): 0000006A=00 ( )
Reading from RAM(r): 0000006B=F0 (ð)
Reading from physical memory(r): 0000006B=F0 (ð)
Reading from paged memory(r): 0000006B=F0 (ð)
Reading from RAM(r): 0000006C=EE (î)
Reading from physical memory(r): 0000006C=EE (î)
Reading from paged memory(r): 0000006C=EE (î)
Reading from RAM(r): 0000006D=06 ()
Reading from physical memory(r): 0000006D=06 ()
Reading from paged memory(r): 0000006D=06 ()
Reading from RAM(r): 0000006E=70 (p)
Reading from physical memory(r): 0000006E=70 (p)
Reading from paged memory(r): 0000006E=70 (p)
Reading from RAM(r): 0000006F=00 ( )
Reading from physical memory(r): 0000006F=00 ( )
Reading from paged memory(r): 0000006F=00 ( )
00:14:17:67.05840: #GP fault(0000006B)!

Edit: Another code bug revealed with the POP ES instruction: it wasn't using the operand size to perform the 16-bit POP. So it was always increasing/decreasing (E)SP with 2 instead of the proper 4.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 6 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Yay! More progress:

538-Minix login - Some commands not found.jpg
Filename
538-Minix login - Some commands not found.jpg
File size
68.33 KiB
Views
1745 views
File comment
Minix reaching the login prompt. Some commands cannot be found?
File license
Fair use/fair dealing exception

Although some command cannot be found within it's filesystem?

Edit: Yay! A prompt from Minix is now showing up(after entering root as username and waiting for a while!) 😁

#

Edit: Prompt seems to be slow, but working! 😁

540-Minix is running!.jpg
Filename
540-Minix is running!.jpg
File size
71.67 KiB
Views
1744 views
File comment
Minix is running!
File license
Fair use/fair dealing exception

Edit: Compiling itself seems to fail due to not being able to write to the /tmp directory or a subdirectory within it(some compiler code about write error writing some temporary file).

"part" seems to run fine.

Running "shutdown" properly returns to the loader. Then running set gives the correct information. Finally running exit returns to the MS-DOS prompt:D And of course the MS-DOS prompt is running fine.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 7 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Retrying Windows 3.0 after the bugfixes seems to crash into a 0xFFFF opcode 0x75(JNZ imm8)?

(DLX) Linux 10MB image from Bochs now only types 'L'(without ' ) on the screen, hanging into what seems like the HDD BIOS(mapped at C6000)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 8 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

I'm just thinking: since minix (mostly) runs without problems(except some strange various commands(like rm(which exists when running from the command line within Minix)) not being found when starting the daemons and services on bootup of the Minix OS(rm,sysenv,sleep,elvprsv,cleantmp,mkdir to be exact, see the above screen capture)), would it be somehow possible to run xoreaxeaxeax from within it?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 9 of 15, by hottobar

User metadata
Rank Newbie
Rank
Newbie
superfury wrote:

Hottobar's test386.asm testsuite already checks out 100%.

superfury wrote:

Edit: Another code bug revealed with the POP ES instruction: it wasn't using the operand size to perform the 16-bit POP. So it was always increasing/decreasing (E)SP with 2 instead of the proper 4.

I know test386.asm does not test all the protected mode operations (my emu doesn't work and still it passes the test), but something basic like this should be tested and detected.
Thanks for the heads up, I'll add a issue on the tracker.

What other bugs have you fixed that can be easily tested for?

Reply 10 of 15, by hottobar

User metadata
Rank Newbie
Rank
Newbie

You could also try to run some demanding protected mode DOS game, like Pinball Illusions.
Look at what that game throws at me when I try to run it with my emu: https://github.com/barotto/IBMulator/issues/32

Reply 11 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried Pinball Illusions on UniPCemu. It gives a stack fault(stack exception in the description) instead:

541-Pinball Illusions stack exception.jpg
Filename
541-Pinball Illusions stack exception.jpg
File size
53.43 KiB
Views
1628 views
File comment
Stack exception occurring in UniPCemu
File license
Fair use/fair dealing exception

This is on my Compaq Deskpro 386 emulation(80386 processor).

Simplified common emulator log:

Filename
debugger_pinballillusions_stackfault_UniPCemu20180518_1927.zip
File size
181.28 KiB
Downloads
59 downloads
File comment
Debugger log without registers and memory transactions.
File license
Fair use/fair dealing exception

It even looks like it's throwing multiple stack faults after each other(fault handling throwing stack fault?)

Edit: Looking further up the log, there's a #GP fault(#GP(0)) which eventually throws a stack fault. Said #GP fault is a address-size overridden XLAT using the CS segment(instruction bytes 2E 67 D7)?

So it's executing a XLAT CS:[EBX+AL], where EBX=0x2AC7, AL=0x69. So it's reading a byte at CS:2B30?

Looking at the interrupt cause(internal emulator flag for verifying the kind of fault that's the cause of the exception when accessing memory parameters), it says the cause is cause 3, which is a system segment access rights breach(Code, execute-only(w/(w/o)conforming) being read by the instruction as data. CS has access rights 0x9B, which means code, nonconforming, executable and readable, not accessed and valid.

So there's definitely a problem with my emulator's protection handling there. It shouldn't do that on reads, since it's executable and readable?

Edit: It seems the protection module itself works fine. It's the XLAT instructions(both 16-bit and 32-bit versions) that were faulty: it was checking memory against a write(for the memory operand) instead of a proper read.

Edit: Now I see it continuing until loading offset 0x48B4E(Which according to the screen is the value of EDI)? I see it's faulting on a MOV instruction. Odd...

544-Pinball Illusions GP fault.jpg
Filename
544-Pinball Illusions GP fault.jpg
File size
40.28 KiB
Views
1623 views
File comment
GP fault on Pinball Illusions
File license
Fair use/fair dealing exception

Edit: It seems to be using FS:EDI to address the MOV to write. It's an 8-bit MOV. The instruction that's decoded is 0x64 67 88 07. According to onlinedisassembler.com, it's an MOV BYTE PTR FS:[EDI],AL instruction. The cause of the fault is a limit violation(cause #6). The FS descriptor contains 0004933b74a08b4b(little endian format of the 64-bit descriptor that's loaded). So the limit is 0x48B4B. The EDI registers contains 0x48b4e, so a clear limit violation. Now the question: why is EDI 3 higher than the limit? Some substraction going wrong? Or too much added somewhere?

546-Pinball Illusions GP fault.jpg
Filename
546-Pinball Illusions GP fault.jpg
File size
40.28 KiB
Views
1623 views
File comment
New GP fault on Pinball Illusions. This time because of actual limit violation.
File license
Fair use/fair dealing exception

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 12 of 15, by hottobar

User metadata
Rank Newbie
Rank
Newbie
superfury wrote:

It's the XLAT instructions(both 16-bit and 32-bit versions) that were faulty: it was checking memory against a write(for the memory operand) instead of a proper read.

Adding this as well to the test386.asm issue tracker.

Reply 13 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

What does the last UniPCemu bug(XLAT checking for writes instead of reads) have to do with test386.asm? Checking for PUSH/POP *S correctly modifying the stack would be correct to test there, but the bug within UniPCemu's XLAT checking against writes instead of reads doesn't have a specific bug on that instruction on a real CPU, unless you want to test read/write faults on EVERY single opcode?

Edit: P.S. the fault I'm dealing with currently seems to either take place BEFORE your faulting problem, or your piece of code(indicated by the image in your issue tracker) doesn't get triggered in UniPCemu.

I can tell you it displays some information(base and extended memory detected(~400K and 3M)), executes three drive reads with large delays in between, after the third hard disk access, another delay, after which the invalid EDI register memory operand crashes the app into it's fault handler.

What do you see happening in your case? (In common log format, I end up with a huge 14GB text file which takes about 3 hours basically hanging my PC with only 8GB physical RAM(Pagefile about 40GB large, Windows 10 swapping like crazy to become pretty much unresponsive until finished(+poweron every 30 minutes due to power saving sleep mode timer)).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 14 of 15, by hottobar

User metadata
Rank Newbie
Rank
Newbie
superfury wrote:

unless you want to test read/write faults on EVERY single opcode?

No that would be unfeasable. At this point it's more like a reminder to add a test for XLAT, which is missing. But you're right it won't probably detect your particular bug.
The goal is to test as much as possible for the correct execution of the various opcodes, so that you can narrow your search. Right now many instructions are not tested at all.

superfury wrote:

What do you see happening in your case?

It happens well into the introduction, just before this scene:
Pinball%2BIllusions%2B-%2B%2BMain%2BMenu%2B304x224.png

Made a video 😵
https://youtu.be/BSaULB7mCh0

Reply 15 of 15, by superfury

User metadata
Rank l33t++
Rank
l33t++

Doesn't reach there in my case. at the 14 second mark, UniPCemu #GP faults because of the invalid [EDI] during a MOV. So at about the point the sound driver seach pops up(which it doesn't in UniPCemu, crashing instead).

Edit: Odd, just tried to run the 360K Compaq Deskpro 386 setup disk 1. It will eventually run a loop calling interrupt 21h, but interrupt 21h vectors to F000:1BD0, which is somewhere inside the BIOS ROM instead of MS-DOS?

Edit: Something's clearly going wrong there.

One other odd little thing I notice with MS-DOS games, Maniac Mansion 2: Day of the Tentacle(just gotten that one last friday on the PS Vita:D ) doesn't seem to repond well(at all) to command line parameters? It will always display the help for the parameters followed by an NULL segment fault?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io