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?

Have been checking out NT 4.0 workstation's setup disks booting today.

So far, I saw the loading of addresses 0x40000 through 0x96000 page faulting.
Right after 0x96000 it seems to report the error of the PROCESS1_INITIALIZATION_FAILED BSOD.
So I'm getting closer to the actual problem?

Edit: Looking at the file size of NTDLL.DLL, it matches the amount of 4K blocks loaded exactly? So it's probably loaded the entire NTDLL.DLL file at the 0x40000-0x9650F memory range.
CR3 points to 0x30000 as usual on Windows NT it seems (perhaps 9x as well as far as I can remember)?

UniPCemu's new memory viewer functionality really comes in handy now! 😁 Although a simple memory dump which I've already taken also works (combined with a hex viewer).
Been thinking though... Perhaps an address converter would come in handy as well with this (a simple linear to physical memory address converter to convert addresses to use with the memory viewer).
NTDLL's final blocks seems to be at physical address 00846000 (linear address 0x96000).

Edit: Just implemented an extension to the memory viewer (with some extra functions added to the paging unit). It is now (in source control only so far) able to display virtual memory besides memory. This is triggered by the triangle button combined with the cross button on the PSP-style inputs (numpad 8 pressed, then using numpad 2(cross) when releasing numpad 8(triangle) as a trigger, working the same way as the other triggers for the triangle).
So it's triggered like the old memory viewer, but using cross instead of square. And circle behaves as the same kind of modifier, but triggers a memory dump instead.

So now you can use the debugger to view physical memory as well as virtual memory.
The virtual memory has a slight bonus feature, where the memory that's unmapped displays as unmapped memory(all ones), but if the cursor is placed on such an address, the color of it and the headers will become dark orange instead (indicating it's not mapped by the paging unit according to the paging tables in memory).

Memory is viewed using the virtual memory viewer with the CPL of the currently executing instruction. Beware that if the instruction transfers to a different kind of privilege level (user vs kernel), the memory addresses will display according to the memory in the changed privilege level (so for an return instruction it would be as viewed from the location after the return finished).

Using the virtual memory viewer with an address that's not RAM or ROM will cause state issues like the CPU accesses do (like for example being mapped to flash ROM that's not in ROM mode causing possible state changes in the connected hardware) for the address translation to RAM addresses. The RAM access itself only affects the RAM modules itself directly (it's not going through the entire memory controller, so it won't be able to properly read connected ROMs or video adapter memory, just as the physical address memory viewer does). So the ROM and VRAM accesses only happen when the page tables themselves are in ROM or VRAM. The memory pointed to be the page tables can only reside in RAM to view, otherwise returning unmapped memory or the memory below said chips (that's blocked by the memory mapped device usually, depending on the motherboard chipset).

Address 200 and onwards in the ntdll.dll file (Address 40200 in linear memory) seems to match what's in the file with what's in the emulator memory?
Edit: Just added some more support to the virtual memory viewer. It will now ask if it's to use kernel privilege (forcing CPL 0) for memory accesses. Otherwise, it will use the debugged instruction's privilege level (unless canceled, which returns to the debugged instruction).

Just have been looking at the data that's loaded at 0x40000. It doesn't match the file contents at all until address 0x200?
Is that supposed to happen with NTDLL.DLL?

I just thought of something: 0x200 is exactly the size of a floppy disk sector? And the sectors/cluster setting is exactly 1, so 512( =0x200 ) bytes is exactly 1 cluster? So it's the first cluster of NTDLL.DLL that's being incorrectly read somehow?

Edit: The directory entry is at 0x4240 in the disk image (file offset 4200h is the start of the directory entry, so sector 21h).
Using this description of the entry (https://www.eit.lth.se/fileadmin/eit/courses/ … description.pdf) tells me the file starts at cluster 912. physical sector: 33+cluster-2=physical sector 943.
So sector 943 is actually the first sector in the file NTDLL.DLL's file contents.

So perhaps the read of sector 943 is somehow failing?

Edit: I see it reading (sector numbers in the file, in 512 byte reads):
0
0 again
1
2-7
1
A
8
9
10
11
12
13
14
15
19
20
21
22
23
24
25
26
33
40000 page faulting here (NTDLL's first 4KB)
7
944 (seems to be some file data like NTDLL.DLL?)
945
946
947
948
949
950
951 (something like "Global flag" (in 2 byte units for each character)?
...

So it almost looks like the first sector is incorrect somehow? It starts with sector 7, which probably should be sector 943 instead?

The FAT entries for the first sector should be at location (912*3)/2=0x558th byte in the FAT, which starts at sector 1 (0x200 in the file). Thus starting at 0x200+0x558=Address 0x758 in the file, or sector 3(LBA addressing), offset 0x158. Said value of the next cluster is 391h. So the next cluster should be 913, so physical sector 944 is the next sector to read, which seems to be correct (at address 76000h)?

Edit: The read of sector 7 seems incorrect?
Edit: OK. It's the third page fault at address 0x40000 that's failing somehow?
Edit: Hmmm... I see it's trying to read CHS 2A,0,8. But it somehow resolves to sector 7, which shouldn't be possible?
Edit: OK. That was because the floppy Implied Seek was updating the track to use, but forgot to make it recalculate all other values other than the CHS (so actually applying the new track to the disk image start position and sector number for example).
Edit: Fixed that seems to have fixed the loading of ntdll.dll itself.
Now I get a IRQL_NOT_LESS_OR_EQUAL STOP 0x0000000A?
But at least the NTDLL.DLL loading problem is gone now! 😁
Edit: Hmmm... I see some #UDs in Virtual 8086 mode somehow? Probably V86 escapes (LXS #UD instructions)?
Edit: Apparently, it's NTOSKRNL crashing on 80140E76 on a read operation to address 40A0D with IRQL of FFh? That's according to https://docs.microsoft.com/en-us/windows-hard … t-less-or-equal ?
Edit: The #UD is opcode C4C4?
Edit: OK. So 40A0D seems to be non-present (PDE is present, PTE is 0x80, so not present and faulting)?
Edit: So, during the 30000h page directory, it's 0 (OK), but when at 93C000h the PTE is 0x80, which seems to be incorrect?

OK. After the latest improvements regarding the EXT bit in the protection fault handling (setting it automatically in some cases) and resetting the BIOS ROM and CMOS RAM (and reconfiguring it), Windows NT 4.0 workstation's floppy disk boot disk 2 seems to continue booting!

At least it's getting to saying 'Loading Keyboard Layout Library KBDUS.DLL'! 😁

Edit: OK. It should be performing an implicit seek, but for some reason the seek doesn't advance and simply abort?
Edit: OK. So it's trying to seek to track 0x42, but never finishes the seek correctly somehow?
I see the seek operation being setup by the read sector command, but it never reaches it's termination on the correct track, thus never continuing the command correctly (effectively hanging the controller)?
Windows NT 4.0 seems to probably wait for the read to return it's results (probably using DMA, although that doesn't matter much in this case), which it never does, thus hanging up the Windows NT to wait for data that never arrives properly.
Looking at the timer that should be ticking after the fact, it never seems to reach it's terminating position (at the correct track), so something's definitely interfering there...
Edit: Hmmm... It's not properly setting it in positioning mode (which it should for the seek to read data at the correct track due to implicit seek being enabled), so the timing handling thinks it's performing an incorrect read data command timing and terminates the timing, leaving the OS waiting forever for completion.
Edit: Hmmm... Perhaps it's a problem with the MSR setting the positioning mode bits required for this to work properly...
Edit: It seems to be that was exactly the problem that was causing Windows NT 4.0 workstation setup to hang, waiting for the floppy drive to give it's sector data it's been instructed to read.
Now I manage to get onwards to the CD-ROM based part of the setup! 😁