Hmmm... Booting seems fine during the FAT to NTFS conversion part.
Then, for the GUI boot after that nothing happens? Just the messages from the BIOS, followed by nothing happening(the last printed on screen was:

1Boot from ATAPI CD-ROM : Failu e ...

The cursor is on the next row, column 0.

OK. After comparing the boot record between the FAT(first part of setup) and NTFS(after the first boot converting it and then failing to boot it again), I see two bytes different in the MBR.
This changes the number of sectors in the parition (but leaves CHS unaffected) from 7FFFA1h to 6001A1h (offsets 1CA-1CD in the MBR).

Edit: Disassembling the entire code and adding comments on it in IDA, it seems to be fine.
Since it doesn't change (other than the parition size in sectors field), it should still just load fine.
So the problem is probably in the VBR or in the NTLDR file itself?
Various characters on the screen getting erased seems weird behaviour? Anyone knows anything about that?
Edit: I see it loading the entire 8K of the boot sector to segment D000, then jumping to D000:266.

Hmmm... The boot loader crashes at 0D00:0510, trying to access DS(0D00):EAX+C, where EAX=8888xxxxh. So the 8888 part causes a #GP fault in real mode because it's out of range of the 16-bit address range of the DS segment descriptor cache (which has a limit of 64KB).

1. Try another BIOS, the one you are using may have IDE translation bugs.

2. Windows NT 4.0's setup creates a FAT16 partition to the target size you want before converting to NTFS. Given that FAT16 has a maximum size of 4GB (64k clusters are supported on NT), you may be bouncing off the limit. I know the setup program is buggy with larger partitions because of this. Its best to install NT on a small partition to start and then resize it afterwards.

https://nt4ref.zcm.com.au/bigdisk.htm

NJRoadfan wrote on 2022-07-02, 19:46:

1. Try another BIOS, the one you are using may have IDE translation bugs.

2. Windows NT 4.0's setup creates a FAT16 partition to the target size you want before converting to NTFS. Given that FAT16 has a maximum size of 4GB (64k clusters are supported on NT), you may be bouncing off the limit. I know the setup program is buggy with larger partitions because of this. Its best to install NT on a small partition to start and then resize it afterwards.

https://nt4ref.zcm.com.au/bigdisk.htm

Probably not, from what I can see.
The VBR and following 8K(VBR included) is loaded correctly.
The instructions executed when it's loading itself(the remaining 8K-512 bytes) matches what's on the disk.
It's after the RETF to it's D00 segment when it's performing CPU errors, causing the crash?
Although I don't know why the high word of EAX is 8888h. It should be 0000h(to not crash at said point).

Edit: It's loaded somewhere earlier from address D000:0242 in RAM.
That, in turn, is gotten from ECX earlier. Also from address D000:024A (during an addition instruction).

This is what I got from disassembling the VBR code (for comparison on what's going wrong):

Hmmm... Decoding the data in the VBR gives me the following information:
Bytes/sector: 512
Sectors/cluster: 1
Volume reserved sectors: 63 sectors
Volume start (calculated): 63(reserved sectors)=Sector 63
MFT start: cluster 318A3h
MFT sector start: 318A3=318A3.
MFT table start=631c400h=((318A3h(start cluster)*1h(sectors per cluster))+(3Fh(reserved sectors)))*200h.
This is correct info, as it points to it's first FILE structure, from what I can see?

But the VBR is somehow perhaps screwing that up?

That's based on the combined info of
https://pcrepairclass.tripod.com/cgi-bin/data … c2/ntfsvbr.html
https://thestarman.pcministry.com/asm/mbr/IntNTFSfs.htm

Edit: Managed to figure out some more of the boot loader:

The basic loading of sectors from disk looks like it should work properly to be (at least, as long as the upper part of the EDX register during that divide instruction is never set).

Looking further, it seems to be parsing the $MFT records at least. So that would mean that the disk reading itself is working properly?
There's just another thing in RAM going wrong during the NTFS boot loader phase?

Edit: Gotten quite a bit further on documenting the NT 4.0 boot loader.

So looking at what UniPCemu is doing, it looks like it actually loads the correct sector from the disk. So the basic problem isn't the INT13h services or the hard disk itself. It at least reaches the sub_D4A9 function correctly, from what it seems.
Somewhere, parsing the HDD's FSI (MFT actually), something goes horribly wrong somewhere? It's getting quite complicated, but it seems to be scanning for some 0x20 attribute (probably)?
Edit: Hmmm... http://inform.pucp.edu.pe/~inf232/Ntfs/ntfs_d … ute_header.html has some more information on how those attribute records inside work.
Edit: OK. At about D000:00003AD I see it in disassembled territory for the last time.
Edit: The final point reached: