I've adjusted it a bit, according to the PCem timing(based on the base timing, which I've assumed from the PCem source code to be the the ATAPI_PENDINGEXECUTETRANSFER_RESULTTIMING, which is 7us). Then I modified all timings to use the same multipliers as PCem does(based on https://bitbucket.org/pcem_emulator/pcem/src/ … fault/src/ide.c).

That just might improve responsiveness.

With the old timings, I get the accesses from EIP addresses >= 0x80000000:

1Write sector count
2Read sector count
3Write drive/head(drive 0)
4Write drive/head(drive 0)
5Write drive/head(drive 1)
6Write drive/head(drive 1)
7Write sector count
8Read sector count(AA)

Those are the accesses by Windows NT 3.1 in protected mode (the kernel or driver executing those). No commands are written to the command port.

Each drive select takes 50us.

Edit: Slightly more detailed notes on the disk accesses:

1Write sector count(to primary master, value AA)@8040706C
2Read sector count(to primary master, value AA)@80407004
3Write drive/head(to primary master, value A0)@8040706C
4Write drive/head(to primary master, value A0)@8040706C
5Write drive/head(to primary slave, value B0)@8040706C
6Write drive/head(to primary master, value A0)@8040706C
7Write sector count(to secondary master, value AA)@8040706C
8Read sector count(to secondary master, value AA)@80407004

Hmmmm.... Something interesting happens when I use the ET4000 to run the Windows NT Hardware Qualifier disk(created under Dosbox from the CD-ROM disk image and an UniPCemu-created 1.44MB floppy disk iamge). When running with the ET4000 hardware, the screen gets messed up.

Edit: Interestingly, disabling the ET4000 PCI(which effectively does nothing but to be detected) still garbles up the screen when detecting it somehow?

Edit: Just retried NT 4.0 with the breakpoints for EIP addresses >=0x80000000 on most IDE ports(except the status port). I only see one port access there: It keeps reading the Drive Address register a few times before crashing with the Inaccessable boot device BSOD(0000007B(0xFF85CED0,0x00000000,0x00000000,0x00000000)).

One interesting thing is that during the Windows 3.1 setup's first phase(through 9 floppy disks), it asks to press Ctrl+Alt+Delete to reboot the computer. But since that doesn't work(for some reason), I use the emulator's functionality to reboot instead(using a cold reboot). Will that cause problems with the NT installation?

It definitely doesn't have to be super accurate, all the timings in my emulator are approximate (but deterministic). You definitely should be getting identify commands.

FWIW, the order of commands I'm seeing with a single HDD attached for NT3.5:

1 - Probe PCI config space (I'm emulating the PIIX).
2 - Identify
3 - Software Reset (via controller)
4 - Probe config space again
5 - Identify
6 - Software Reset
7 - Set features 0x66
8 - Initialize drive parameters
9 - Recalibrate
10 - Reads

I adjusted the timings according to PCem's multiplier, but on UniPCemu's ATAPI result timing(7ns). So 7ns for the packet command, and all others multiplied by integer factiors(PCem's https://bitbucket.org/pcem_emulator/pcem/src/ … fault/src/ide.c based timings, so ATAPI PACKET is 7us times 1, seeks are 7us times 200 etc.).

The hdd I/O is unchanged from before(in my breakpoint results). One thing that's changed is the ATAPI sector count register not being writable anymore and I've removed the primary slave by unmounting it. All that does is remove the primary slave from the debugger breakpoints triggering.
It still tries to write then read the ATAPI secondary master sector count register and then crashes.

NT 3.1 doesn't access the PCI configuration space(ports CF8-CFF).

What does Windows NT do with a IDE HDD on Primary Master, no Primary Slave, Secondary Master and Slave being ATAPI/IDE CD-ROM drives(UniPCemu's case with single hdd)?

Does the second part of the setup(after disk 9 reboot without pressing ctrl-alt-del and simply closing the emulator and restarting it and booting the hdd(XT-IDE Universal BIOS used)) boot in your emulator?

The primary master uses the ATA-1 specification, while the CD-ROM drives use the ATA/ATAPI 4 specification(+Microsoft Media Status Notification enhancement(which is optional)).

After rebooting after copying disk 9 with the correct Ctrl+Alt+Del, it still crashes at the same point(with error code 0000007B (0xFF831BA8, 0x00000000, 0x00000000, 0x00000000)).

Although that second number seems to have changed to FF831BA8 instead, compared to earlier BSODs.

Now trying to reinstall Windows 95a again. Maybe it'll fix the problems that occur during first boot(corrupted files)? Or perhaps the problem stays, because a CPU problem still exists? Only time will tell.

Edit: The crash from safe mode after rebooting Windows 95 still happens at exactly the same EIP value(Fault D being raised(#GP fault), according to the BSOD), during Safe Mode boot(Pressed F8 when it says "Starting Windows 95..." and chose Safe mode).

One interesting thing is that hal.dll seems to either call or fault into the ntoskrnl, according to the stack trace that's displayed.

Would that happen on a normal boot of Windows NT 3.1? Is it legal to make hal.dll calling or faulting into the ntoskrnl image(as hal.dll is sandwitched between two ntoskrnl.exe in the stack dump of the BSOD)?

Anyone? Jepael, do you know anything about this(with your Windows OS knowledge)?

Hmmmm... I remember having set a protected mode-style IRET(to a non-V86 destination), but don't seeing it triggered somehow. And Windows 95 is crashing on a CPL 3 'task'? So is it using RETF to get to that task, or is some privilege rule being broken somewhere?

Edit: Nope. It's an IRET from the kernel(?) at 0028:c00013d1 to 117:00003056 with EFLAGS becoming 0x212?

Selector 117 has a base of d5c0 and a limit of d1df? It has the granularity and D-bits cleared, so it's something that's using 16-bit protected mode?
Edit: So it's using something from the MS-DOS memory area, which is running in protected mode?

Hmmm... Debugging segment loads from PL3 protected mode, I see a far jmp(to 3b:20c) using a 16-bit jmp, which is marked as an user-mode segment, while locafed in kernel memory? That can't be right? That's from 9f:cac2.
Edit: Hmmmm.... It simply fetches an INT instruction(0xCD) from there? That can't be right, as it's supposed to be having kernel privilege, thus throwing a page fault?
Edit: Nope. It's a part of kernel code that's in a user-level page, in the kernel's address range?

Edit: Hmmmm. It's apparently an interrupt handler routine of the protected mode 32-bit kernel:
https://archive.org/stream/NTDocumentation/In … System_djvu.txt
At the start of Chapter 3, it says:
[quote]Another observation we can make from the protected mode vectors shown in
Figure 3-1 is that each one is at an offset of 2*intnum in the Int 30h segment. The
first lOOh entries in this array are the default protected mode vectors that are used
for each VM. Their corresponding addresses will be from 3b:0000 to 3b:01fe. Note
that the address for the Int 2f handler lies outside this range. This is because VMM
has already overidden the default entry by installing a callback at 3b:0208. The
default protected mode vector which this handler should chain- to would be at
3b:005e. [/code]

So that offset it's calling is the interrupt handler number multiplied by 2. So that's the 0x106th handler. Since that's above the interrupt handler range, it's the 7th handler after the interrupt handlers. So what is it?

Just gave OS/2 a try again. It immediately crashes trying to load CR2 with a value. Then I found out that it was checking bit 31 and 0 for invalid values for CR0, while actually loading the a non-CR0 control register:S

Immediately fixed that. Now it at least continues on to the initial screen of the setup, prompting for a disk change.

It doesn't seem to continue on. The OS/2 warp 4 boot screen is displayed, but the Floppy Disk Controller motor keeps running, so it's probably hanging somehow?

Edit: Just tried OS/2 warp 4 on UniPCemu's 80486 emulation. This results in the following faults and screen(I do see it throwing a whole range of Page Faults?) :

Hmmm... OS/2 warp 4 really doesn't seem to like the INT3 instruction that's being executed somehow?

Hmmm.... Interestingly enough, I see Windows 95 crashing on opcode 89 46h (some MOV instruction) in protected mode only(due to a Page Fault on some address within the low memory hole range(A0000-FFFFF) that has a PTE of 0?)? The only thing fixed is the CR registers no longer faulting on afaik.

Edit: The faulting address pointing to somewhere within the XT expansion ROM area... Maybe some BIOS ROM that's not correctly loaded or misaddressed? Perhaps the XT IDE ROM?
Edit: it's address CB1008?
Edit: It's in protected mode, at memory location being executed being 0028:c0fdf17a?
C000-C6000=VGA BIOS
C6000-C8000=XT-IDE BIOS

But this address is way further, at the CB100 range? What is supposed to be there?
Edit: Hmmm.... The last interrupt started was interrupt 0x50, while the last segment write was a IRET writing value 0x28(the kernel code segment of Windows 95), which is the final step during an IRET isntruction. It uses a 16-bit operand size with 32-bit address size.
The instruction executed at said fault is 6689466A. That's MOV [ESI+6A],AX. The value of ESI is cb0f9e.

Just tried NT4 from the CD-ROM running "WINNT /b" from the i386 folder using a Windows 95 bootdisk. After formatting the harddisk, WINNT complains about not being able to write the boot loader to the harddisk?

Just been thinking about something: Does BSY clear DRQ? So when BSY is set, is DRQ always cleared(blocked from being 1)?

Edit: Applying said zeroing during BSY being set(thus DRQ becoming 0 when it's set) does speed up harddrive accesses it seems. But it still doesn't read past those 8 sectors(4K of data)?

Having improved the #DB exception to work properly, Windows NT 3.1 now properly 'boots' into a GUI during the second phase of setup(after first reboot). But then, the screen is messed up(black vertical stripes all over), with it reporting that the hardware is incorrect and to run setup again? I just ran setup again from the start(without reformatting the hard disk), but it didn't work? It still gives the same error message after the reboot with Ctrl+Alt+Del(inputted twice in UniPCemu to work properly).

Just tried doing a clean install of Windows NT(with hard disk formatting completely(which according to the hard drive emulation isn't anything other than just reading the entire hard drive(not writing anything during that point in the setup))). It still crashes out in the same way(with the very same error message as before)?

The graphical mode also seems to have it's entire background (everything but the mouse) only rendered half or partly for every character? This happens even on the VGA emulation?

The only things that don't have that issue is the mouse, the STOP logo and the close button itself? All other components seem to have that issue?

Anyone knows something about this issue?