Looking at interrupts thrown, the last one seems to be 35F7 function 4300h? According to RB's interrupt list, it's an XMS installation check? http://www.ctyme.com/intr/rb-4765.htm That's at 35f7:00000318?
Strange, looking at the I/O to/from the serial modem, I notice that when it's received the "\rOK\r" from the "AT\r" command, it puts the serial modem into loopback mode?
Hmmm.... WinCheckIt Pro 4 seems to hang the system while executing CKDATA's "Coprocessor Type..." data collection? At least on the Pentium CPU emulation?
Edit: On the 80486 emulation, it goes a bit further, but only a bit... It's now hanging (on WFW 3.11) at the "Bus Type..." step inside CKDATA.
Edit: Making a breakpoint inside Visual Studio reveals that it's inside some V86 mode program, never ever leaving it? The breakpoint I set broke at 4479:0038 inside V86 mode(it's not raising any interrupts anymore).
Edit: I see a CALL 4479:0072 in there? Perhaps that's an indication of that's happening? It looks like it's in an infinite loop? Anyone knows anything about it? The cause seems to be a JL instruction combined with some JZ instruction ands some RETF and weird double POP BP instructions? And something comparing memory and/or registers to 2 and 0? Interrupts seems to be disabled, thus preventing Windows from working properly(it can't do anything anymore, ever).
Edit: This is a log of the hang while it's already happening:
The attachment debugger_checkit_bustype_hanging_20191214_2358.7z is no longer available
So it's somehow pushing the return address, followed by the call itself, which pushes it again? Something doesn't smell right here...
Edit: Perhaps the issue can't be found within this log?
Hmmm... Just tried booting Windows 98 First Edition again. I see some weird behaviour in offset address wrapping happening(wrapping around 2^64 instead of 2^32, which shouldn't happen) during some 32-bit movs, eventually ending at a stack fault with ESP=0xffffffff(of which it faults at esp=10000, so it's using a 16-bit sp pointer out of the 32-bit esp one). Then infinite stack faults happen until triple fault and the system reboots.
Edit: Fixed that. Now Windows 98 seems to hang again? But this time, it's due to a real mode #GP because of EIP=0xFFFF(CS limit is 0xFFFF) and executing opcode 0xFF?
Typical: you fix one bug, another one is revealed(partly).
Just tried Wing Commander: Privateer in Windows 95. It closes windows 95, starts the game and... Once again hangs! ?
Edit: Tried seeing what it's hanging on. This is what it does:
1@6A15:21E startloop: 8B MOV: reg<=680E(=8A; was 8C) 2@6A15:221 03 ADD: reg(=8A, result=8C),6812(=02; from 7bcd2) 3@6A15:225 3B CMP: reg(=8C),r/m @5121(=8B; from 7a5e1); result of substraction=1 4@6A15:22A 73 JNC: -14d(to address 21E, label startloop): jumped 5@21E startloop: 8B MOV: reg,r/m(@680E)
Just a simple manual log of what I see from the used debugger(Visual Studio Community 2019).
So it's obvious that it's inside an infinite loop. But why? Interrupts are disabled all the time(never enabled)... Perhaps timer delay code of 2 ticks of some kind? So that would mean some weird kind of interrupt-related problem?
Just tried running PC-Check on MS-DOS again. It seems to hang when loading what it calls a "Drive Library", executing a ARPL instruction in real mode, which of course hangs infinitely because it's throwing a #UD, which the BIOS interrupt handler just ignores?
Just improved code readability by changing the minify-style code in the CPU instructions(for all from 8086 through 80486, Pentium is unaffected by this(already not minified-style) to the full multiple row code with tabs instead. That should ease debugging of the emulator and show bugs more easily(although comparing them to the instructions above/below them is a bit more difficult because they're multiple rows for almost all instructions now).
Although code that does only a return of the function will still be on one row(e.g. "if (modrm...read8(...)) return;"). The same for each seperated protection check etc.
Hmmm.... When executing the V86mon program on the Pentium again for testing V86 mode, I see the very first IRETD from Protected Mode to V86 mode having the top of the stack(the EIP to return to) contain 0x2008D. Then, immediately when trying to execute the very first instruction, it tries to execute the instruction at F88:20088D, which of course causes a #GP fault(segment limit violation because EIP is past 0xFFFF) while no #GP fault handler is installed(huh?), causing a #DF fault, causing the program to panic and dump it's stack and hang the virtual PC?
Are the high bits of EIP supposed to be used when using IRETD to V86 mode?
Trying to truncate EIP to 16-bits when using IRETD to V86 mode seems to 'work', but V86mon doesn't seem to execute it's testing mix anymore and just returns to the MS-DOS prompt? Trying to run it again(after runing mem.exe) causes an unhandled general protection fault exception?
Hmmm... Tried running Windows 95 First Edition with the latest EIP truncating to 16-bits on IRETD to V86 mode. Running it in Normal mode crashes on an infinite #UD like non-Windows 95 RTM versions of Windows 95, loading the very first vxd driver. But running it in Safe mode seems to continue on somehow?
Edit: Just confirmed Windows 95 First Edition actually booting into the GUI with mouse working during Safe mode boot! So there's a strange problem with the IOS.vxd driver or the driver following it in Normal mode(which seems to be shared among Windows 95 B, Windows 95 C and Windows 95 FE)?
So now Windows 98 FE takes ages to boot, even in Safe mode(3MIPS Dosbox-style cycles emulating a Pentium without FPU)?
Also small note to sytem admin: the above couldn't be added to the previous post with "Edit:" before it, it keeps complaining about:
1General Error 2SQL ERROR [ mysqli ] 3 4Data too long for column 'post_subject' at row 1 [1406] 5 6An SQL error occurred while fetching this page. Please contact the Board Administrator if this problem persists.
OK. So far confirmed(using Task manager in Windows 98 FE) that rundll32 and explorer are actually running processes. (Once again couldn't post to the previous post due to said forum bug).
OK. Eventually I get a Windows is running in Safe mode message, telling me it's for diagnostic purposes etc., clicking OK then shows the desktop(the taskbar etc.) on the screen with the entire desktop(in Safe mode)! 😁 (About 1.5-2.5 hours later in real time)
OK. So far, the Settings menu of the System File Checker on Windows 98 FE doesn't crash the app like on Windows 95 RTM. That's at least a good sign.
Edit: Pressing the Start button makes it gray out and start "Checking files..." as the part above the progress bar says.
Edit: OK. It's checking files and the progress bar is filling up(at least one block).
Edit: OK. So SFC is running it's checks now. (2 blocks in the progress bar).
(Once again, the above couldn't be added due to backend issues(see the earlier mentioned forum error) 😖 ).
Can anyone see something wrong with the instruction emulation itself? I don't see any errors myself, but perhaps I simply don't see them(hidden in plain sight)?