Compaq Deskpro 386 CPU emulation issues?

Emulation of old PCs, PC hardware, or PC peripherals.

Re: Compaq Deskpro 386 CPU emulation issues?

Postby superfury » 2018-5-29 @ 12:58

I'm trying to find out the entry address of CS:IP when running the DOTT.EXE(Day of the Tentacle). I've looked at the exe file through a hex editor, but I can't seem to make any sense of the address that's stored? According to https://github.com/libyal/libexe/blob/master/documentation/Executable%20(EXE)%20file%20format.asciidoc , offset 20(hex offset 14h) should contain an value relative to the start of the file, which is AC 19 16 12, so that means it's loading at *:19AC? Is that the address I should point UniPCemu to for debugging this app?

I notice that the command line somehow seems to be ignored? Anything put on the command line is ignored, always printing the information and then crashing on a NULL load?

It does say
Code: Select all
Unknown flag: 'by 0
'


Anyone knows anything about this?

Finally, it ends with:
Code: Select all
run-time error R6001
- null pointer assignment
superfury
l33t
 
Posts: 2403
Joined: 2014-3-08 @ 11:25
Location: Netherlands

Re: Compaq Deskpro 386 CPU emulation issues?

Postby superfury » 2018-5-31 @ 19:30

Strange that the test386.asm testsuite tests and validates so many instructions(except 80-83, 00-3F and 0F00-0F01 ranges) in real and protected mode, but still UniPCemu fails pretty much all protected-mode software in one way or another? EMM386, as well as unreal mode seems to wotk without visible problems, but DOTT, Windows 3.0(all 286+ protected mode software I know of atm), Jazz Jackrabbit, Windows 95 setup, Doom, Microsoft Flight Simulator 5.1 all crash in one way or another, either returning to the command line(DOTT does that as well as ignoring it's parametersOhelp is printed on the screen) before crashing on a NULL pointer load), not working properly(MSFS5.1 missing output on screen) or hanging the CPU in one way or another(all other cases). Windows 95 setup is even observed jumping to junk memory, executing 0000h instructions forever!

Edit: Although CheckIt Diagnostics runs out of EMS memory when running the EMS memory check using EMM386.EXE(From MS-DOS 6.22).
The EMS test suite from the Lo-tech EMS 2MB board checks the EMS RAM out correctly, oddly enough. So it's probably some error executing CheckIt! Diagnostics?

Edit: The new breakpoint functionality for breaking on reaching an IP(ignoring CS for said address) seems to work. Each time I execute the tentacle.exe file, the debugger triggers on said address:D So that's at least a starting point for the executable.
superfury
l33t
 
Posts: 2403
Joined: 2014-3-08 @ 11:25
Location: Netherlands

Re: Compaq Deskpro 386 CPU emulation issues?

Postby superfury » 2018-6-01 @ 14:11

I've managed to make a little(common log format) log detailing what happens when I execute tentacle.exe without any parameters:

debugger_DOTTfailingtorun_UniPCemu_20180529_1555.7z
TENTACLE.EXE running without parameters.
(2.5 MiB) Downloaded 7 times


Can anyone see what's going wrong there?
superfury
l33t
 
Posts: 2403
Joined: 2014-3-08 @ 11:25
Location: Netherlands

Re: Compaq Deskpro 386 CPU emulation issues?

Postby superfury » 2018-6-10 @ 17:46

Just managed to fix the IBM AT Diagnostics disks to check out the CMOS correctly. There was a problem with setting any date in BCD format earlier than 19th century. I've modified it to now enable the binary format both when selecting a century earlier than the minimal date it's able to handle(1970/1/1 00:00 to be exact). When it detects a program is trying to set a date earlier than 1970, it will automatically patch to and from 1970-2069 and set it to binary mode. Binary mode is also enabled when a non-BCD value is loaded into the century byte.

Binary century mode simply disables updating of the century byte, to keep it's contents unchanging, allowing for normal data storage in the century byte without it being overwritten when time is updated based on emulated/real time.

This seems to fix the CMOS checks the diagnostics disk does to verify the CMOS RAM.

Edit: After the time is asked, it somehow still ends up back at said error when setting the time(directly after entering a new date to initialize the clock)?
superfury
l33t
 
Posts: 2403
Joined: 2014-3-08 @ 11:25
Location: Netherlands

Re: Compaq Deskpro 386 CPU emulation issues?

Postby superfury » 2018-6-12 @ 14:53

Just managed to fix some bugs that were producing doubled ModR/M displacement instead of only adding the displacement once. Now stuff like Pinball Illusions continues onward(Pinball Illusions crashes after the intro, while not changing the video after displaying the horizontal stretching effect during the intro(sound continues though))?

Edit: Odd that even with those changes, Micrsoft Flight Simulator 5.1 still doesn't give any output?

Edit: The Windows 95 setup now crashes on a 8E8F1400 MOV CS instruction, which is invalid from 80186 onwards?
superfury
l33t
 
Posts: 2403
Joined: 2014-3-08 @ 11:25
Location: Netherlands

Re: Compaq Deskpro 386 CPU emulation issues?

Postby superfury » 2018-6-13 @ 07:12

Just found some more bugs in the ModR/M calculations and checks. 16-bit memory writes through the BIU were using the ModR/M object instead of the offset(strange that the whole thing runs somewhat correctly in that case at all). The same problem applies to 16-bit and 32-bit memory access checks(the parameter object being loaded into the offset instead of the offset within the parameter object). Odd that the compilers didn't see that bug.
The same problem also applies to direct access to ModR/M referenced memory(used with protected-mode only instructions).
superfury
l33t
 
Posts: 2403
Joined: 2014-3-08 @ 11:25
Location: Netherlands

Re: Compaq Deskpro 386 CPU emulation issues?

Postby superfury » 2018-6-13 @ 13:44

Now trying to boot Windows 3.0 in 80386 extended mode(no command line parameters on 80386 CPU). I see it page faulting to 0028:80005EE4 some times, then it's back at the command prompt?

Edit: I see the page fault handler looking at bit 1 of something, then jump somewhere, exchange some registers and execute a INT 20h, which faults and returns to the MS-DOS prompt?
Edit: It seems to fault on address 0x06F4011E? It's faulting on a "MOVZX EAX, dword [ESI]" instruction?

Edit: I seem to get a double Page fault when executing a INT 0x20 from the Page Fault handler of Windows 3.0?

debugger.log
INT 0x20 reached during Page fault handler?
(30.29 KiB) Downloaded 3 times


Anyone?
superfury
l33t
 
Posts: 2403
Joined: 2014-3-08 @ 11:25
Location: Netherlands

Re: Compaq Deskpro 386 CPU emulation issues?

Postby superfury » 2018-6-13 @ 21:52

Hmmm.... According to Ralf Brown's interrupt list, that final INT 20h that's executed might be a kernel VxD call? But since UniPCemu doesn't directly support breakpoints breaking past 2 dwords after the current instruction, I'll need to set another breakpoint immediately past the call, so 10 bytes after the EIP of INT 20h that's called by the page fault handler, if I understand correctly?

Of course a simple memory dump would make clear what service is called(Although I'll need to use the Paging TLB cache from within Visual Studio to find out it's physical address, since RAM dumps using UniPCemu are physical RAM dumps of emulated RAM after all, although I'll need to take the RAM remapping used by UniPCemu into account).
superfury
l33t
 
Posts: 2403
Joined: 2014-3-08 @ 11:25
Location: Netherlands

Re: Compaq Deskpro 386 CPU emulation issues?

Postby superfury » 2018-6-14 @ 17:42

Currently the Page faults happen at the following locations(all being caused by non-present NULL PTE/PDE):
0028:802000BD, error code 0. Cause: Linear address 06f4011e. Page fault handler at 0028(32-bit mode flat descriptor):80005EE4. Cause Opcode: 0FB706h MOVZX instruction.
0028:80007FDC, error code 0. Cause: Linear address 0782002f. Page fault handler at 0028(32-bit mode flat descriptor):80005EE4. Cause Opcode: 32-bit 830B08h OR instruction.

It then returns to the MS-DOS prompt?

debugger_Windows3.0_faultingtwice_exittoMSDOS5prompt.7z
Common emulator log from the first page fault until reaching the MS-DOS prompt(visible on the screen and usable).
(1.3 MiB) Downloaded 3 times


Edit: It seems to look for bit 2 of a byte that's at the address 2Eh bytes above the bottom of the stack, but the stack of the fault(Page fault after all) only contains 10h bytes pushed by the interrupt handler(the kernel is the cause of the page fault after all)?

Edit: Currently using https://defuse.ca/online-x86-assembler.htm to help me disassemble the instructions UniPCemu fetches to verify them. Originally used ODA, but that website seems to keep giving 500 errors?

Can you tell me something about this, crazyc? It seems to return to real mode, even though it's a protected-mode kernel???

Edit: Hmmm.... Some problems seem to have arisen booting Minix somewhere after the commit of 2018/05/29 15:55... Guess it's checking time to find out said bug(booting Minix 2.0.4 until it crashes, at which point the causative commit should have been found)...

Edit: In essence, a few big changes have been made since then: fixing stack problems with privilege level switch using RETF/IRET to lower privilege level(as well as fixing hardware to time properly in small ammounts, e.g. CD-ROM emulation problems) at commit 2016/06/05 13:42, REP fix at 2018/06/07 11:43, small updates until 2018/06/10 19:23, start of modr/m fixes and 8086 undefined opcodes at 2018/06/11 14:50, then the 32-bit ModR/M and relative JUMP/SET fixes in the most recent commits.

Edit: The privilege level switch commit checks out.
Edit: Still running until the REP(Z/NZ) fix. All that's left until the start of the ModR/M fixes are the RETF/IRET conditional clearing(when invalid at the lower privilege level) of the segment registers, the CMOS fixes and the saving of the CMOS when entering the Settings menu, at which point it's back to the last ModR/M fixes.
Edit: Whoops. The checks used when returning to a lower privilege level using RETF/IRET were clearing/zeroing the segment register when the present bit was set(so with valid segments instead of invalid segments) or the system bit was set(thus a valid code/data segment), instead of cleared. Thus clearing the segment registers even when not supposed to. :S

Edit: Having fixed the privilege lowering RETF/IRET bug, Minix boots again :D
superfury
l33t
 
Posts: 2403
Joined: 2014-3-08 @ 11:25
Location: Netherlands

Re: Compaq Deskpro 386 CPU emulation issues?

Postby superfury » 2018-6-17 @ 11:46

That latest RETF/IRET bugfix combined with the fix of EBP as an index defaulting to DS somehow hangs Pinball Illusions now?

Edit: The cause seems to have been incorrect audio card configuration when starting the game.

Now I'm getting a GP(0) due to MOVSW with the code segment descriptor in ES, which is illegal? What could be the cause?
superfury
l33t
 
Posts: 2403
Joined: 2014-3-08 @ 11:25
Location: Netherlands

Re: Compaq Deskpro 386 CPU emulation issues?

Postby superfury » 2018-6-22 @ 22:02

With the latest fixes, top-down data segment limits are now also checked against a max offset of 0xFFFF(FFFF), depending on the D/B-bit in the descriptor. Also, offsets are now wrapped to 16/32-bits for the base offset(from modr/m and immediate addresses, as well as (e)sp values), then after wrapping have up to 0(byte), 1(word) or 3(dword) added for each byte in the access to result in a 17/33-bit number which is then checked against the limit normally(as 64-bit numbers, since no 33-bit numbers exist in c). Thus a word at address 0xFFFF/0xFFFFFFFF(depending on address size) or dword at 0xFFFD+/0xFFFFFFFD+ will now check for accesses to 0x10000+ or 0x100000000+, thus properly faulting according to 80286+ specifications(wrapping after the protection phase during execution is still to 32-bits or 16-bits, depending on address size). So accessing a word at base 16-bit offset 10000+ will properly wrap to offset 0(the same with 32-bits base offset 100000000+).

So the specification and the wrap is now properly being applied(always wrapping after the check phase, though, during execution of the actual memory reads/writes).

Somehow Windows 3.0 triple faults on it's very first INT 0x20 VxD driver call during a page fault handling on a non-present page?
superfury
l33t
 
Posts: 2403
Joined: 2014-3-08 @ 11:25
Location: Netherlands

Previous

Return to PC Emulation

Who is online

Users browsing this forum: No registered users and 2 guests