VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've been trying to get the 4GB partition on the i440fx working properly.

But somehow, when I select any mode (Large or LBA or Auto) instead of Normal, the BIOS just detects a 5xxish (504 or 528) drive?
Is it actually using the Large addressing mode in Normal mode (to report larger sizes correctly)?

The BIOS reports a date of 08/14/98-i440fx-<C-P6ND>C-00 with a (C) 1984-95. v4.51PG.

This even happens if I boot the Partition Magic 5.0 floppy disks I've modified the NT 4.0 NTFS partition with (from 504MB to 4GB).

"Normal" mode gives 4295MB reported to the OS (Second POST screen says "CHS, Mode 2, 4295MB")?
Partition Magic reports 4095MB only in this translation case.
It reports the reduced amounts when translation modes are enabled (set to LBA, Auto or Large).
Edit: It won't boot NT4 anymore, reading the HDD infinitely before NTLDR even starts? So probably the MBR code?
Edit: It went past the first phase correctly, started converting the FAT partition to NTFS so far (having been formatted at ~3GB, 3145936 kilobytes to be exact as chkdsk reports it during conversion, 3072MB as I specified it during install's formatting phase)...

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++

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:

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

The cursor is on the next row, column 0.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 2 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++

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.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 3 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++

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

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 4 of 6, by NJRoadfan

User metadata
Rank Oldbie
Rank
Oldbie

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

Reply 5 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++
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).

Filename
debugger_WindowsNT_NTFSVBR_booting.7z
File size
1.82 MiB
Downloads
6 downloads
File comment
Windows NT 4.0 NTFS booting on UniPCemu going wrong
File license
Fair use/fair dealing exception

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

Filename
WinNT_NT4 boot sector_full8K.zip
File size
20.6 KiB
Downloads
6 downloads
File comment
VBR boot sector full disassembly
File license
Fair use/fair dealing exception

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 6 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++

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:

Filename
WinNT_NT4 boot sector_full8K_20220707_0022.zip
File size
22.57 KiB
Downloads
11 downloads
File comment
Boot loader further figured out.
File license
Fair use/fair dealing exception

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.

Filename
WinNT_NT4 boot sector_full8K_20220707_0232.zip
File size
24.3 KiB
Downloads
6 downloads
File comment
Boot loader figured out until inside the FSI parsing.
File license
Fair use/fair dealing exception

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:

Filename
WinNT_NT4 boot sector_full8K_20220707_0335.zip
File size
24.39 KiB
Downloads
7 downloads
File comment
Boot loader figured out until after the FSI parsing 3AD crashing function.
File license
Fair use/fair dealing exception

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io