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:
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:
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).
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?
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.
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)?