VOGONS


First post, by superfury

User metadata
Rank l33t
Rank
l33t

Can it even be done on such a machine? Afaik, the FDC BIOS that's on the BIOS ROM of the Deskpro 386 can't handle the 18 SPT that's used for the floppy disk, making Windows program it with EOT=Fh instead of the proper 12h.

Is there a way for the BIOS to correctly program the FDC? In DMA mode(e.g. with Windows 95, NT 3.1, MS-DOS) it isn't an issue, but Windows NT 4 seems to program it for non-DMA mode, making it fail to load the ntdll.dll library off the second boto disk?

Edit: I see the last read from the floppy disk (setup disk #2) being at 26/0/8, 8 sectors long, finished because of DMA TC. ending up at 27/0/1?

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 1 of 6, by superfury

User metadata
Rank l33t
Rank
l33t

OK. Having added the FDC BIOS from http://www.malinov.com/Home/sergeys-projects/ … sa-fdc-and-uart, I now see Windows NT 4 changing the read data request's maximum sector number to 0x24 for most acceses, but 0xF at the end of the loading process with the initialization error. So a CPU error?

Edit: It's 8 sectors at 1a/0/8 from disk #2 that's last read into memory. Anyone knows more about this?
TC is reached, with 4K being read to D000-E000, count 0xFFF(thus 0x1000=4K being transferred). the page address register being 0x49, thus 49D000-49E000 being loaded by the DMA transfer from the 8 sectors of the FDC(a 4K memory block being loaded through DMA).

So perhaps the issue isn't with the 4K load itself, but somehow the starting of whatever's loaded at said address that's failing?

CR2 is 96000h, so some access down to user mode was failing or last handled?

Looking at the current TLB contents, I can see that 0x80000000 seems to have all of the RAM mapped in a direct fashion(linear to physical memory mapping, just like Linux has). I also see just one some single page mappings in the TLB (FFD00000 to VRAM at B8000 and FFDF0000 to 279000, FDC13000 to 5B000, FF6EE000 to 404000, FFDFF000 to 278000). one seemingly direct mapped memory(at 80000000 to PA 0) for what seems to be the full physical memory range? The value in CR2 isn't present in that map, so it must be the cause of the BSOD somehow?

Edit: After looking at all the page faults thrown for the user-mode memory addresses(everything below 0x80000000), I actually see one and the same instruction(0FB7 MOVZX) keep throwing page faults from a very low memory address in 4KB increments all the way up to 0x96000! The modr/m parameters of said instruction have a calculated offset that's exactly those 4KB page increments.
Could it be that the page fault handling in the OS is somehow getting itself into a loop?
The flags pushed are 0x0000 in all cases with those instructions.
Looking at the CS:EIP of the faulting insruction reveals that all those exceptions take place at only one instruction: 0008:8018B47B.

It starts with opcode A5 at 8:80139e8e from addresses 10000h until 33000h.
Then it starts faults for opcode 89 within page 40000 at 0008:8018a065 and opcode C7 at 0008:801b286f(both after each other twice).
Then I get the 0FB7 opcode faulting at 8018b47b for address 40000h through 96000h.

After it returns to said instruction, the PDE is loaded with 380867h, while the PTE is loaded with 49C025h.

So the PDE is user,present,writable. And the PTE is user,present,readonly. Thus the result becomes user,present,readonly(for user mode only, since it's a user mode page).
Edit: OK. Found out a bit more: The GDT is at 80036000(400h bytes long), while the IDT follows it immediately at 80036400(with a size 800h bytes long, thus the entire IDT is mapped).

Edit: Hmmm... The last data read from the FDC during that part is from offset 75E00 on the second disk(8 sectors, so 4KB). The first 2 sectors seem to contain some program(seeing as it starts with the MZ header), then the rest of the sectors contain zeroed data.

Hmmm... Looking at what data is read from the disk, those seem to be the first 8 sectors containing the contents of ntdll.dll? Although I haven't verified it yet.
Edit: Just verified using a combination of XVI32(to copy the blocks from the file and disk) and WinMerge to compare them(ntdll and the 8 blocks at address 75E00 in the disk 2 image). They fully match.
So the 8 sector load from the disk is the first 4K block(first page) of ntdll.dll.
And the issue is somewhere after that, loading/executing the ntdll.dll executable.

This is what happens:

Filename
debugger_NT4_setupstarting_20200511_1437.7z
File size
2.66 MiB
Downloads
4 downloads
File comment
NT4 setup starting ntdll.dll on UniPCemu.
File license
Fair use/fair dealing exception

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 2 of 6, by superfury

User metadata
Rank l33t
Rank
l33t

Just found something interesting related: http://www.delorie.com/djgpp/doc/rbinter/it/86/25.html
It's a list of all known INT 2eh functions that can be passed in EAX.

So I see it calling function 21h(CreateSection), then function 0Fh(Close), then it reaches INT 3, which traps to the debugger and shows the BSOD.

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 3 of 6, by ATauenis

User metadata
Rank Member
Rank
Member

NT 4.0 requires at least 486 CPU, so it will not work on 386. Probably replacing 386DX with a 486DLC should help.

FDC problems are not fatal for NT installation. NT4 can be installed from copy of CD-ROM on HDD, through MS-DOS. This method is faster than install from FDD+CD, but limits size of C: partition to 2 GB.

Also it can be installed directly from CD through a diskette with Plop boot manager.

2×Soviet ZX-Speccy, 1×MacIIsi, 1×086, 1×286, 2×386DX, 1×386SX, 2×486, 1×P54C, 7×P55C, 6×Slot1, 4×S370, 1×SlotA, 2×S462, ∞×Modern.

Reply 4 of 6, by superfury

User metadata
Rank l33t
Rank
l33t
ATauenis wrote on 2020-05-15, 12:54:

NT 4.0 requires at least 486 CPU, so it will not work on 386. Probably replacing 386DX with a 486DLC should help.

FDC problems are not fatal for NT installation. NT4 can be installed from copy of CD-ROM on HDD, through MS-DOS. This method is faster than install from FDD+CD, but limits size of C: partition to 2 GB.

Also it can be installed directly from CD through a diskette with Plop boot manager.

The emulated system is already upgraded to a 80486SX. So just that shouldn't be the problem. It seems to have something to do with the loading/execution of the first 4KB of ntdll.dll(the last 4KB block loaded from disk 2 of the setup disks created using "winnt /ox").

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 5 of 6, by ATauenis

User metadata
Rank Member
Rank
Member

Try to install without using of floppies. NT4 is not 3.51, it can be installed in floppyless mode (install MS-DOS 5.0-6.22, copy i386 folder, then run winnt /B /X).

2×Soviet ZX-Speccy, 1×MacIIsi, 1×086, 1×286, 2×386DX, 1×386SX, 2×486, 1×P54C, 7×P55C, 6×Slot1, 4×S370, 1×SlotA, 2×S462, ∞×Modern.

Reply 6 of 6, by superfury

User metadata
Rank l33t
Rank
l33t
ATauenis wrote on 2020-05-16, 09:58:

Try to install without using of floppies. NT4 is not 3.51, it can be installed in floppyless mode (install MS-DOS 5.0-6.22, copy i386 folder, then run winnt /B /X).

It at least copies over the files in that way.
Edit: It managed to reach the reboot point:

The MS-DOS based portion of Setup is complete.
Setup will now restart your computer. After your computer restarts,
Windows NT Setup will continue.

If there is a floppy disk in drive A:, remove it now.

Press ENTER to restart your computer and continue Windows NT Setup.

Edit: And after pressing ENTER and rebooting the machine that way, I get a:

*** STOP 0x0000007B (0xFDC13BD4,0xC0000034,0x00000000,0x0000000)
INACCESSIBLE_BOOT_DEVICE

p4-0200 irql:0 SYSVER 0xf0000565

So once again a BSOD, which was the same as executing said setup from the autorun installer in Windows 95 RTM, if I remember correctly.

Edit: CR2 is 0x40000, CR3 is 0x30000.

1341-Windows NT 4.0 BSOD after rebooting setup.jpg
Filename
1341-Windows NT 4.0 BSOD after rebooting setup.jpg
File size
154.33 KiB
Views
61 views
File comment
NT4 BSOD after rebooting the machine normally by pressing ENTER(after rebooting into the Windows NT 4.0 setup option in the boot menu(previous OS was NT 3.1)).
File license
Fair use/fair dealing exception

The hard disk itself is in it's ready state(only set bits in the status register is DRDY and it's SC bits, so it's waiting/ready for a new command to execute).

Since CR2 is 0x40000, that would mean the last page fault was in user space?

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases