OK. It also seems to hang(everything but mouse movement) after W95 RTM setup having accepted the license agreement and checked drives A and B, with the latest bugfixes and improvements?

Edit: OK. It seems to still respond, but with an incredibly large delay of some kind?
Perhaps the Win95 desktop is having issues gettting enough CPU time somehow?
The mouse itself (movement at least) is always responsive, though(but not reponding to button presses, except perhaps at the beginning, at the little time the desktop is just shown(if you're fast enough)).

test386.asm can't find any bugs with my emulator, both in IPS clocking mode and cycle-accurate mode(doing that to verify BIU/cycle-based issues).

Anyone knows something more I can use to verify the CPU emulation?
Windows 95 RTM seems to be getting worse and worse somehow(since the commit of 2019-12-03 01:27)?

Ooooohhhhhh.... Just ran a memory dump after test386.asm finished with it's HLT instruction, then compared it against Bochs' memory dump as instructed on the test386.asm's README.md file.

The results are interesting:

So still something weird going wrong there somehow? Or perhaps a CPU incompatibility(newer CPU on Bochs)?
Edit: Perhaps a wrong build of test386.asm(one with the Bochs flag disabled?)...

Edit: Just ran Bochs and UniPCemu with the Bochs flag enabled(thus fixing Bochs' issues with some instructions the test suite stresses(ARPL or some same kind of instruction throwing faults differently I believe?)).
Now the Bochs memory dump and UniPCemu's memory dump fully matches each other.

So the testsuite still checks out 100%.

Then what can possibly be going wrong?

OK. Just tried copying WinCheckit 4.0 for MS-DOS from the two floppy disk images to the hard disk image and ran it.

The system board test ran without errors it seems, except for the CMOS time seeming to have issues(time being 1-1-1970 in the CMOS, 1-1-1980 in MS-DOS).

Then selecting the Memory Test, it says "Creating a swap file. Please wait ...", then "Divide error" in the bottom right of said window appears? So there's some weird kind of memory problem in UniPCemu somehow? But I have no idea what or where, other than it applying to it creating a swap file(on the second HDD image)?

Just found a little bug related to CPU resets and initialization.

If there was an active execution state while resetting or initializing(e.g. emulator cold restart) that was executing an instruction that didn't finish yet, the after-reset state would continue using the active execution phase(e.g. instruction execution, task switching or interrupt handling).

The same kind of issue could occur when a push instruction was busy handling while the CPU was being reset(leaving the push still marked as busy while the new instruction would execute), although this could also apply to any other new instruction being started in the middle of it.

OK... Something seems very wrong somewhere...

Trying to recreate the NT4 install disks from the CD-ROM (using WINNT /ox) seems to get up until veryifying abiosdsk.sys, then I see the FDC drive motor turned off? It seems to be hanging verifying said file after copying it to the disk?

The Compaq Deskpro 386 CMOS settings are properly setup for 1.44MB for drive A(although the BIOS doesn't officially support it)? Then why is it not properly verifying said disk? That's on creating disk 1 already?

The same kind of issue appears when booting the install disks(Loading NTOSKRNL)?

Edit: Yay! More FDC issues. Somehow, the FDC has issued an error condition(ST0=0x40, ready for a new command) which isn't handled properly or expected by the WINNT floppy disk creation software?

Managed to get Windows 95 setup running again, past it's floppy drive checks onto the main installation(after confirming the license agreement).

The main issue seems to have been the recalibrate command, which needed to set the error condition(bit 6) and Unit Check of ST0 when a disk isn't in the drive(although still behaving like normal with the ST3 register for BIOS detecting the 40/80-track drives correctly).

OK. Once nice thing I've noticed installing Windows 95 again, is that it seems to properly autodetect the ET4000 graphics card instead of the old VGA card now! 😁

The initial release of Comanche: Maximum Overkill ran in protected mode without using a standard DOS extender. It would refuse to run when EMM386 or QEMM was loaded.

That version of the game might be a good test case.

I remember reading somewhere that later revisions of the game used a more well-behaved DOS extender.

digger wrote on 2020-03-01, 17:35:

The initial release of Comanche: Maximum Overkill ran in protected mode without using a standard DOS extender. It would refuse to run when EMM386 or QEMM was loaded.

That version of the game might be a good test case.

I remember reading somewhere that later revisions of the game used a more well-behaved DOS extender.

I'll look into that once I'm done with Windows 95 and Jazz Jackrabbit(maybe even before Jazz, but at least after Win95).

One nice thing Windows 95's first boot told me is that there were some unimplemented result read handling for the FDC. So the DUMPREG and LOCK commands were causing Abnormal polling error codes instead of properly succeeding 😖
There was also a little bug in the result size of the LOCK command being 0 bytes instead of 1 byte, although since it's a simple byte++>=size(where size=0), this won't have any effect on the result phase directly(since 1>=1 and 2>=1 both count the same).

Having fixed those, I don't see more FDC issues with Windows 95 RTM's first boot so far(Currently at Programs on the Start Menu step)...
Edit: Now at the reboot for the first normal boot of Windows 95 RTM... So far so good...
Edit: Seemed to run fine when booted. When selecting the display properties' tab for the display resolution and color depth, it messaged me that the graphics card wasn't properly installed(and requests a hardware detection wizard to be started)?
Edit: The Add new Hardware wizard just thinks that the Standard Serial Mouse is removed for some reason? It's still plugged in though(at COM1)?
Edit: OK. It's not removed at all.
Then I removed the ET4000(which had 2 duplicates in the System properties page) and then ran the Add new hardware wizard again to add it back in.
A reboot will tell if it's working properly now...
Edit: OK. Gray screen when rebooting, which seems to hang Windows 95?
Edit: OK. Manually rebooting the machine makes it display a new hardware detected after reboot. Then, after another reboot(which has not issues), display seems to be running fine(no error messages).
There seems to be some big delays with input sometimes, though?
Edit: Yay! No error messages from the video adapter driver anymore! 😁
Edit: After reinstalling the graphics drivers, they seem to work fine(in 16-bit color mode). Although the 32-bit color mode setting it offers will mess up the display(because the DAC doesn't actually support that).

OK. Having implemented timing(1 sector) for the Read ID command and 1 seek for Recalibration, I now see Windows 95 executing a Read Sectors command on the boot record(CHS 0/0/1 with EOT set to 0x28!, which is ignored due to MT being used with DMA), which reached TC at sector 2, thus reporting sector 0/0/3 in the result.

Then, Windows 95 seems to somehow triple fault, as the emulator immediately garbles up the display and the BIOS POST shows itself again?

OK. Added a bit of timing (1 sector for Read ID, 1 step for recalibrate) for two commands.

Then I modified the reset command to keep the Seek End flag intact(most docs, except emulators, all say that it just sets the top 2 bits of ST0 and leaves the others(bits 5,4,3) alone while 2,1,0 will become the head&drive for drives 0,1,2,3 during subsequent sense interrupt commands)?

So now, after resetting, it issues Read ID, which will result with ST0=0x20(because bit 5 is untouched by the command) for disk 0 head 0 being used for the command.

But once Windows sees that, it'll issue a recalibrate(ok), sense interrupt(ok), then once again resets(huh?) and a specify command before displaying the drive not ready message?

Anyone knows what's going on?

I've just changed it up a bit again. Now ST0 is cleared during reset, but the high 2 bits are reset when using polling mode only. Also some other missing registers(except the DOR) are now reset when resetting the DOR bit 3 or when setting DSR bit 7(which will reset by itself and because the reset functionality clears the register).

One other thing that's now changed is that the DOR isn't cleared by a reset anymore, it's just left as it was before(as is documented).

Edit: I now see:
- A reset.
- Sense interrupt x4
- Seek to track 1
- Then seek back to track 0.
- Another Read ID command
- Recalibrate
- Sense Interrupt
- Reset
- Sense interrupt x4
- Specify
- Seek (immediately completes because unchanged track).
- Sense interrupt
- Seek (same as before)
- Sense interrupt
- Read sector(E6h) 0/0/1, EOT=36. Reaching TC after 1 sector.
- Seek (same track).
- Sense interrupt
- Read sector (E6h) 0/0/1, EOT=36...

On the second sector of said transfer(because TC=0 on the first sector), it somehow errors out when TC=0, then reading on the second sector? Strange... Why would it error out on the second sector?

Edit: On another try, I see it properly reading a second and third sector, which reaches terminal count, so the transfer finishes(it enters the result phase with a result of 0/0/4 in the CHS fields(both physical and the idea of the controller)).

Then I see it executing what seems to be a Read ID command, which triggers an IRQ, and then Windows 95 simply triple faults it seems?

Just found a pretty big overflow bug in the newly added caches of the MMU. When it was using DMA accesses mapping to memory, it was using entries 4-7(the CPU using entires 0-3(for write(0), normal read(1), prefetch read(3))). Those entries 4-7 are the same lookup type as 0-3, but excluding prefetch(so 4 is DMA write and 5 is DMA read).

Since those caches weren't updated to becomes 8 instead of 4 entries, the DMA caches are overflowing the buffer (and it looks like the DMA data was following it in RAM, seeing as I noticed weird DMA addresses being generated when looking at it earlier).

I also found out that those DMA caches weren't yet updated when the memory mapping has changed(it would keep the cached data in there for the DMA caches only, the CPU caches were correctly updated).

Edit: Having fixed those bugs, Windows 95 no longer crashes. But the 3-sector read is followed by at least a few Read ID commands and Windows 95 RTM fully hanging for some reason?

Just changed the Read ID command and all other commands(just a little bit, not having effect on the commands themselves, just the Read ID command) a little bit.

Now, when you execute a Read ID command(both for DSK disk images and normal img files), it will report the next sector (starting with the one after the last accessed sector on the physical disk) for each time the Read ID command is executed. Although this will not have any effect on the disk rotation speed(it's applying said speed to read/write/format operations only), it will create the illusion that the disk is actually spinning on the current track.

So if you've last accessed 0/0/1, it will report 0/0/2 all the way until 0/0/18(if SPT for the disk is 18 SPT), after which it will wrap back to 0/0/1 again.
Although with DSK disk images, it will use the physical position of the last read/write/format sector to calculate the next sector on the track(it will take any sector that's there right after the sector that was last accessed). And of course that wraps back to the first sector as well.
Although simple read and write operations will make it scan the entire track for the specified C/H/S identification, which it will use to identify the sector the program is trying to access(so fake sector numbers will work, as long as the track and side of the identification match what it's trying to access). So if the first sector is 0/0/1, the second 0/0/3, the third 0/0/2, trying to read 0/0/3 will read the second sector on the track for the specified side. If it's not found with the head/track combination on the current head and track, it will fail the operation.

Would that be correct behaviour?

OK. With the most recent changes, the WinCheckIt 4.0 MS-DOS disk is booting without visible issues now.

Although it will still seem to corrupt the hard disk somehow? It will try to write it's diagnostic collection file on the hard disk, which is formatted using MS-DOS 6.22 FAT16. It will really corrupt that hard disk unfortunately.

Edit: OK. During it's "Processor Type..." check there's a Divide error?

Managed to find a bug with exception handlers being handled, then causing a faulting IRQ/NMI on it's first instruction. When a fault was handled it would go to the handler. That prepares and handles the fault and finishes the instruction.
Then, before handling the next instruction, it would check for IRQ/NMI interrupts. Said interrupt handling would commit the state, but forget to reset the fault raised status and fault level(normal/double/triple fault indicator). That wouldn't be done before the IRQ/NMI handler is finished and it would start to fetch a new instruction(which would reset the fault status and level).
So, when it would fault(raising e.g. #GP to single fault and terminate the instruction). Then, it would see and start an IRQ/NMI handling, which would fault with e.g. #GP. So since the fault handling wouldn't reset before the IRQ/NMI, it would see #GP+#GP, thus becoming a #DF fault instead. Even worse when the previous instruction was a #DF fault instead of #GP fault, since #DF+#GP=Triple fault.

Glad that's fixed now. 😁

I've just tried the Wing Commander: Privateer game again. It still seems to hang at a simple loop at 6909:0000021e. It's 3 instructions that keep looping: mov eax,dword ds:[si]; add eax,dword ds:[si+04]; cmp eax,dword ds:[5121]; jnc 0000021e.

Perhaps some kind of timing loop? But the interrupt flag is disabled during the execution of this, so if it's some kind of timing loop to make the main game process more input, it'll never trigger because any IRQ(IRQ0(PIT) or IRQ8(CMOS) being counted I'd assume) is masked off by the interrupt flag being cleared during execution of this code!

Anyone knows anything about this program? Does it try to do something weird with the interrupt mechanism or something related?

Edit: Speech card to Sound Blaster(IRQ 5, port 220) and Music card to NONE seems to still hang the intro.
Edit: The same for those settings reversed.
Edit: The very same issue occurs when both Music and Speech card options are set to NONE. So the issue isn't related to the emulated sound card(Sound Blaster 1.0 configured that I'm testing it with). It's somehow a timing loop of some kind that's always used?

Just been thinking: jemm.ovl seems to be a normal MZ-executable for MS-DOS. Would it be possible to run a little testsuite of sorts to stress test it for problems(If jemm has such a thing)?

Edit: Ah, interesting! Running jemm.ovl directly(by using a copy renamed to jemm.exe) makes it spout out something: "JEMM overlay version 4.35".

I've made a ~67GB log of privateer running in V86 mode(filtered the V86 mode only): https://www.dropbox.com/s/bqp195sqwce52ux/deb … er_hang.7z?dl=0

Can anyone see what's going wrong?

Edit: OK. In said log, it all goes wrong when reaching 7442:0000021e. The interrupt flag is disabled, thus an unending loop.

Edit: Hmmm... Searching upwards for "It" (without quotes) seems to reveal the last point interrupts were enabled(trap flag is never set anyways).
Edit: Just confirmed searching for different combination of the interrupt and trap flags. The trap flag is never set in the log, thus can be used as an effective interrupt flag search term("It" and "it").
Edit: Hmmm.... 7442 seems to be some kind of subroutine that's called by other code segments to handle stuff like (at least) timing and delaying? I see it called many times to increase the counter it's hanging on 7442:00000102(starting at 7442:00FF through 7442:0108, the counter being at 7f79:5121). But the place it's hanging on is another piece of code in there, which does the opposite: wait for some kind of other counter to become(or pass over) said value that's increased in that routine. So that counter is being increased by one routine, while the hanging routine waits for that counter to match some other value(perhaps to delay the program)?

Windows 95 still boots without issues. So does MS-DOS 6.22 and Windows NT.

Now the weird part: booting the first MS-DOS 6.22 setup floppy will make it hang on an instruction using 16-bit offset FFFFh with a 16-bit MOV instruction? This will cause it to infinitely #GP fault(in real mode)?

Edit: Just tried booting it on the XT(had to lower interrupts on when any non-Sense Interrupt command is started due to the BIOS not executing the required Sense Interrupt after recalibration completes(huh?) to lower the interrupt line).
It says it's inspecting the hardware, then reboots with a error 20 in the Generic Super PC/Turbo XT BIOS.
That's not supposed to happen I think?