LSS10999 wrote on 2024-04-28, 01:01:I suppose all Intel boards have good MPS tables allowing the HAL to work... or maybe it's just that NT 3.51's MPS HAL only under […]
Show full quote
I suppose all Intel boards have good MPS tables allowing the HAL to work... or maybe it's just that NT 3.51's MPS HAL only understands Intel chipset and not others (I remembered seeing "GenuineIntel" mentioned in the HAL binary).
EDIT: The amount of CPUs usable is determined by a registry key. Theoretically up to 8 CPUs can be used from what I've tested on VirtualBox. BearWindows supposedly had a kernel patch allowing using up to 32 CPUs, but it's not public. I wonder if anyone had contacted him about the patch before...
Personally I never succeeded in booting NT 3.51 across several systems when installed into disks attached to SATA controllers (all failed with INACCESSIBLE_BOOT_DEVICE). Only when it's connected to a PATA controller did it work. Setting SATA controller to IDE or AHCI didn't matter, and one of the systems I tried NT 3.51 on was AMD (760G chipset, using Standard PC HAL since MPS cannot be used).
Again... I must have missed something very important...
A little update. I managed to build a debug version of UniATA 0.47b and enabled it to print everything it could on the boot screen via a registry value. I did so by making the changes to the registry from the VM before moving the modified system folder to my actual system. The log output scrolls very fast so I have to first do a video capture from my phone then analyze its contents frame-by-frame.
The debug log had mentions of my SATA controller, which is currently in AHCI mode (8086:8d02), and it did find my controller at its intended location (00:1f.2). After a lot of fast-scrolling outputs UniATA's DriverEntry exited with a status code of 0xc00000c0 (per ScsiPortInitialize), then the 7B bugcheck happens with fastfat.sys (I'm using the FAT32-enabled one) listed on top of the stack.
I couldn't find any useful info on the meanings of the value returned by ScsiPortInitialize at the moment so I don't know whether this means a successful init. UniATA's output, at least the parts that I could figure out when analyzing the video capture, did not appear to explicitly suggest errors on the part regarding SATA/AHCI controllers, though it did print some apparently failed output when detecting ISA and MCA controllers (which I think should be expected).
If the output value suggests a successful init, then maybe it's really the FAT32-enabled fastfat.sys that was to blame for the boot failure here. On the other hand, I also attempted running Windows 3.11 on the same system and so far only Standard Mode worked. All attempts to get 386-enhanced mode working were not successful. So... maybe my disk/partition layout is a bit problematic for those OSes?
PS: From UniATA's debug output, the driver apparently detects VMs such as VirtualBox during its init. Haven't looked into the details, though.