OK. It (with the exception of the now working floppy-based part of setup) manages to get the GUI starting for the second part of setup.

Then, the mouse cursor displays and operates properly, after which some HDD activity follows after which it resets the emulated system?

So there's still something going on with the CPU which NT doesn't like somehow?

OK. I do see it faulting one other type of fault: #NM faults for FPU emulation?
Perhaps it doesn't like that?

The only other hardware I/O that's going on seems to be VGA I/O and HDD/CD-ROM I/O?

OK. The BIOS int 13h call seems to fail for the NT CD-ROM boot because it's using drive FFh, but it only allows hard drives up to 82h?
So perhaps during the CD-ROM boot, FFh in DL is somehow incorrect (it's supposed to be 81h for the first CD-ROM drive?)?

Edit: This is what happens during booting of the Winodws 2000 Pro CD-ROM:

It looks like it's loading the value from the HDD0 parameter table in the EBDA (value 0xFF) into the DL register incorrectly, causing the failed boot?
Anyone can see what's going wrong here?

Edit: The i440fx seems to boot it without issues?
Edit: Although, on the i440fx, it will eventually BSOD with a INACCESSABLE_BOOT_DEVICE.

I'm seeing something a bit similar with ELKS v0.4.0 (this is the same setup as the Linux tests).
https://github.com/jbruchon/elks/releases/tag/v0.4.0
But is this just another artifact of Bochs BIOS?

If I convert the 2.88MB floppy into an .ISO and boot that, it boots just fine.

1$ cat porte9.log 
200:00:03:95.09705: $Revision: 14218 $ $Date: 2021-04-09 06:45:42 +0000 (Fri, 09 Apr 2021) $
300:00:08:02.07861: ata0-0: PCHS=567/16/7 translation=none LCHS=567/16/7
400:00:15:12.01755: Booting from 07c0:0000
500:00:17:31.01218: int13_harddisk: function 15, unmapped device for ELDL=81
600:00:17:49.03846: KBD: unsupported int 16h function 03

However the hd32-fat.bin image they provide fails to boot (it asks to press a key, then resets):

1$ cat porte9.log 
200:00:04:01.07031: $Revision: 14218 $ $Date: 2021-04-09 06:45:42 +0000 (Fri, 09 Apr 2021) $
300:00:08:20.03941: ata0-0: PCHS=567/16/7 translation=none LCHS=567/16/7
400:00:15:34.08879: Booting from 0000:7c00
500:00:15:37.09846: int13_harddisk: function 02, parameters out of range 0000/0003/003d!
600:00:17:14.09674: int13_harddisk: function 02, parameters out of range 0000/0003/003d!
700:00:18:88.08296: int13_harddisk: function 02, parameters out of range 0000/0003/003d!
800:00:20:65.02300: int13_harddisk: function 02, parameters out of range 0000/0003/003d!
900:00:22:35.01290: int13_harddisk: function 02, parameters out of range 0000/0003/003d!

With the Minix one it's similar:

1$ cat porte9.log 
200:00:03:95.04908: $Revision: 14218 $ $Date: 2021-04-09 06:45:42 +0000 (Fri, 09 Apr 2021) $
300:00:08:73.05269: ata0-0: PCHS=567/16/7 translation=none LCHS=567/16/7
400:00:16:59.00043: Booting from 0000:7c00
500:00:16:65.08327: int13_harddisk: function 02, parameters out of range 0000/0000/000f!
600:00:18:67.06548: int13_harddisk: function 02, parameters out of range 0000/0000/000f!
700:00:20:65.07670: int13_harddisk: function 02, parameters out of range 0000/0000/000f!
800:00:22:64.09694: int13_harddisk: function 02, parameters out of range 0000/0000/000f!
900:00:24:66.06416: int13_harddisk: function 02, parameters out of range 0000/0000/000f!

I've been thinking... Perhaps the issue with Windows NT 4.0's booting isn't in the CPU itself but in the hardware somehow?

I do see it clearing some CMOS registers (most notable the shutdown byte) before triggering a CPU reset through command 0xFE of the 8042?
So perhaps there's a hardware issue somehow (not a CPU issue)?

Windows 2000 still fails to boot at all though (when starting Windows 2000's setup phase(after all the loading of the modules) it simply errors out with a INACCESSABLE BOOT DEVICE (STOP 0000007B)?
So perhaps there's some weird storage medium issue?
I did see it issued some ATAPI commands (Request Sense command resulting in 16(0x10) bytes result), but I don't know if that's part of the issue? I do see the various registers loaded with 0x12 in the loaded variables(so it's requesting 18 bytes and receives only 16)?
Although the cylinder high/low of the CD-ROM reports 0x12, which is kind of odd?
Perhaps some kind of issue with the ATAPI emulation? The sense packet contains 0x8 in it's extra length field(so it should be 0x10 in length)?
Edit: Just increased the length of the sense packet to 18 bytes(0x12) and always cleared the new bytes to 0 for compatibility.

Edit: No changed in Windows NT 4.0? It still crashes like before?

Just modified the i430fx/i440fx to set the INIT pin instead of the RESET pin when performing a soft reset when not through the hard reset register in the i430fx/i440fx PCI configuration space and register selection.
So it will have a slightly different effect when getting a shutdown/8042/PPI reset, causing the APIC to reset differently.

OK. Having gotten the Windows NT 4.0 workstation properly booting, I'm now trying to get Windows 2000 to boot.
But when it reaches the "Starting Windows 2000" phase after loading all drives, it delays a very long time, then proceeds to blue screen with a BSOD saying:

1*** STOP: 0x0000007B (0xF2463848,0xC0000034,0x00000000,0x00000000)
2INACCESSABLE_BOOT_DEVICE

So it doesn't see the boot device it just booted from anymore?
Edit: Just converted the PCI IDE interface to a ITE IT8211F interface. Those actually have drivers for Windows NT in them, so that should add some compatibility for those operating systems (perhaps it gives 2000/XP setup a chance to boot).

Microsoft update seems to have drivers for it?
https://www.catalog.update.microsoft.com/Sear … 1283%26DEV_8211

Hmmm... To create an F6 disk for the ITE IT8211F IDE, would it be enough to just copy the cat, sys and ideatapi.inf file to a floppy and let Windows 2000 setup see it? Or does it require some extra oemsetup.inf or creation in some way for it to load?

Edit: OK. So I've added a simple txtsetup.oem file based on http://rmprepusb.blogspot.com/2013/06/txtsetu … oppy-disks.html :

1[Disks]
2d1="IT8211 Installation Disk by Superfury(diskf)",\,\ 
3[scsi]
4iteatapidisk=iteatapi_Driver
5[HardwareIds.scsi.iteatapidisk]
6id="PCI\iteatapidisk","IT8211disk"
7[Files.scsi.iteatapidisk]
8inf=d1,iteatapi.inf,iteatapidisk
9catalog=d1,iteatapi.cat,iteatapidisk
10driver=d1,iteatapi.sys,iteatapidisk
11[Defaults]
12scsi=iteatapidisk

Would that be enough to get the ITE drives working with 2000 and up?
Windows 2000 setup seems to read the file correctly, at least.
Edit: Hmmm... http://www.osronline.com/article.cfm%5earticle=264.htm explains it a bit better...
So (rewriting it according to said article):

1[Disks]
2disk1="IT8211 Installation Disk by Superfury(diskf6)",\iteatapi.inf,\ 
3[scsi]
4iteatapi="ITE IT8211 ATA/ATAPI Controller"
5[HardwareIds.scsi.iteatapiservice]
6id="PCI\VEN_1283&DEV_8212","iteatapiservice"
7[Files.scsi.iteatapi]
8inf=disk1,iteatapi.inf
9catalog=disk1,iteatapi.cat
10driver=disk1,iteatapi.sys,iteatapiservice
11[Defaults]
12scsi=iteatapi

Would that be correct?
Edit: It loads it at least.

OK. Just restored the old PC87415 PCI IDE as a setting for the PCI IDE to use.
Now it can be toggled during device initialization between emulating either the new IT8211F chipset or the old PC87415 chipset.
Still need to implement the setting in the SETTINGS.INI file and settings menu to change that behaviour over to the new chipset though.
Edit: Just implemented it in the SETTINGS.INI file and settings menu.
Edit: Also, just fixed some issues with the old PC87415 responding to addresses added at the newer IT8211F chip (which it obviously shouldn't, although not addressable by software running inside the emulated system).
Said setting of the emulated PCI IDE chip is also configurable on the architecture settings, so different architectures can use different PCI IDE adapters on them.

OK. The documentation of the IT8211F is a bit weird:
- The list of PCI configuration registers (Table 6-1) says:
Both Vendor ID and Subsystem Vendor ID is 1283h.
Both Devide ID and Subsystem Devide ID is 8211h.
This matches the INF driver entry of the ITE IT8211 ATA/ATAPI Controller's "8211/DX" entry.
But when looking at the PCI register descriptions, it says the following:
Vendor ID is 1283h. This matches table 6-1.
Devide ID is 8212h. This is the 8212 according to the IT8211F Preliminary Specification 0.2.
Subsystem Vendor ID and Subsystem Devide ID is 0. Also specifies a 8212, like the Device ID? That's a "8212/DX" according to the INF driver.
That matches the INF driver entry of the "8212/DX" entry.

UniPCemu has the vendor/device ID of 1283:8212(The "8212/DX" entry) and 1283:8211 in the subsystem vendor/device IDs.
So that would match neither.

What I'm emulating is the 8211F, so both should be 1283:8211?

So the new txtsetup.oem file (for the 8211F device on UniPCemu) is:

1[Disks]
2disk1="IT8211 Installation Disk by Superfury(diskf6)",\iteatapi.inf,\ 
3[scsi]
4iteatapi="ITE IT8211 ATA/ATAPI Controller"
5[HardwareIds.scsi.iteatapiservice]
6id="PCI\VEN_1283&DEV_8211&SUBSYS_82111283","iteatapiservice"
7[Files.scsi.iteatapi]
8inf=disk1,iteatapi.inf
9catalog=disk1,iteatapi.cat
10driver=disk1,iteatapi.sys,iteatapiservice
11[Defaults]
12scsi=iteatapi

https://www.downloadwindowsdrivers.info/pci/v … ubsys_82111283/
So that seems to confirm (also mentions the 8211f in one of it's links) that both should indeed be 1283:8211?
Or perhaps it's some weird wackyness because it's a preliminary specification?
Edit: Modified both device/vendor IDs for the 8211/DX behaviour for now.

OK. Rewrote the txtsetup.oem file:

1[Disks]
2disk1="IT8211 Installation Disk by Superfury(diskf6)",\iteatapi.inf,\ 
3[scsi]
4iteatapiID="ITE IT8211 ATA/ATAPI Controller"
5[Files.scsi.iteatapiID]
6inf=disk1,iteatapi.inf
7catalog=disk1,iteatapi.cat
8driver=disk1,iteatapi.sys,iteatapiService
9[HardwareIds.scsi.iteatapiID]
10id="PCI\VEN_1283&DEV_8211&SUBSYS_82111283","iteatapi"
11[Config.iteatapiService]
12[Defaults]
13scsi=iteatapiID

That's according to the rmprepusb.blogspot.com article.

OK. Now Windows 2000 reaches the "Diamond Multimedia Systems SCSI Host Adapter" being loaded and seemingly hangs?

Hmmm...

https://www.startech.com/en-us/cards-adapters/pciide2

It has a package with drivers.
In there is a txtsetup.oem with the following contents:

1ITERAID_2000   = "ITE IT8212 ATA RAID Controller (Windows 2000)", ITERAID
2
3[HardwareIds.scsi.ITERAID_2000]
4id = "PCI\VEN_1283&DEV_8212","ITERAID"
5[Config.ITERAID]
6value = "", Tag, REG_DWORD, 1
7value = "Parameters\PnpInterface", 5, REG_DWORD, 1

Perhaps it should be used instead, or those sections added (the PCI\ part changed and the Config.ITERAID added to the [Config.iteatapiService] section?

Or perhaps replacing the entire disk contents with the package after extraction (if it fits on the 1.44MB disk)?
Edit: It should fit on a 1.44MB disk (even 720K if needed)? Just extract the Drivers folder inside the drivers package onto an empty floppy disk and use it like that?
Edit: Yay:/ Managed to get at an #UD inside the BIOS ROM. Although it might be my own fault for closing it while flashing it (or some earlier corruption)? Easily fixed by replacing it with it's uncorrupted version, if that's the case (it's just a file for the emulator after all).
Edit: Just changed the hardware device ID to 8212h and subsystem ID to 0000:0000 for the 8211F the driver expects.
So now the 8211F follows the documented registers (but not the table 6-2 for the (subsystem) vendor/device IDs) as documented at https://datasheetspdf.com/pdf/1091938/ITE/IT8211F/1
So it's effectively the 8212 as said card is using.

OK. Just fired up the new memory viewer, looking at the address that's pointed to by the first parameter of the BSOD (address F2463848).
It contains some seemingly garbage at the start (44,00,46,00,88,16,10,E1), then followed by the string "\ArcName\%s" (without quotes), which seems to be the actual boot path? But it doesn't have anything filled into it (the %s is printf syntax)?

Microsoft documentation on Bug Check 0x7B holds the explanation for the "garbage", it's an UNICODE_STRING structure holding a pointer to the actual string.

mr.cat wrote on 2022-04-29, 10:31:

Microsoft documentation on Bug Check 0x7B holds the explanation for the "garbage", it's an UNICODE_STRING structure holding a pointer to the actual string.

OK.
So the string is at E1101688h with 44h out of 46h bytes used?

superfury wrote on 2022-04-29, 11:01:

mr.cat wrote on 2022-04-29, 10:31:

Microsoft documentation on Bug Check 0x7B holds the explanation for the "garbage", it's an UNICODE_STRING structure holding a pointer to the actual string.

OK.
So the string is at E1101688h with 44h out of 46h bytes used?

Yeah that's what I was thinking as well. The Microsoft page says this could be hard to debug, but don't let that discourage you 😁

OK. That locations contains the string:
"\ArcName\multi(0)disk(0)cdrom(159)" followed by a NULL(0) terminator.
(Great that I've added some simple ASCII display into the memory viewer 😁 )

It seems this same BSOD also happens in qemu if you use "-M isapc". Perhaps related.