VOGONS


i430fx/i440fx motherboard emulation issues?

Topic actions

Reply 60 of 71, by superfury

User metadata
Rank l33t++
Rank
l33t++

After some more fixes to the APIC(mainly to do with the IR lines triggering and the LVT registers triggering methods), it now seems to be converting the disk to NTFS on the APIC! 😁

I see hard disk activity at least, with the APIC being used!

Although I've set it up for 1 processor instead of the previous 2 processors right now... Have to test with 2 processors later.

Edit: It looks like the NTFS conversion completed(although it didn't show anything on the display about it), issued a CPU RESET through the 8042, after which the BIOS somehow returned control to the OS without rebooting?
Or the reboot itself has an issue? It ends up executing a permanent blocking HLT instruction(interrupt flag is cleared) from the only CPU that exists (when in single-CPU mode at least)?

It's a 0008:80005AF7 in plain protected mode, with CS base being FFFF0000h. So Physical Address 7FFF5AF7, with a limit of FFFFh?
Also, all interrupts are fully disabled? Both on the APIC and PIC(both masked off)?

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

Reply 61 of 71, by superfury

User metadata
Rank l33t++
Rank
l33t++

Having reinstalled NT 4.0 from the beginning(the CD-ROM booting part), it seems to now be hanging on executing CPUID instruction with leaf=0? Said leaf returns 2 in EAX (Since it's a Pentium II it's emulating) and keeps calling said CPUID instruction over and over? It doesn't seem to like something about it? Or is it trying to detect something weird?

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

Reply 62 of 71, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found a bug in the handling of RESET vs INIT. INIT was also clearing the TSC, which it shouldn't, according to the manuals?

Perhaps that's causing Windows NT 4.0 to hang on the synchronization of the TSC counters?
Edit: It eventually continues onwards with booting. It just takes a long time before it's finished whatever it's checking.

Edit: Hmmm... It reaches the GUI, displays it, then seems to be hanging in the CMPXCHG8B emulation(which the CPU actually supports directly), which is described here.

It looks like it's hanging at the wait block, executing said instructions again and again?

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

Reply 63 of 71, by superfury

User metadata
Rank l33t++
Rank
l33t++

I'm just wondering... Is SMI support essential for OS booting? UniPCemu currently ignores it and always leaves SMI and SMIACT# disabled? The Local APIC accepts it, but discards it.

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

Reply 64 of 71, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just added support for the last unimplemented(other than SMI) APIC delivery mode: Lowest Priority mode.

I just looked at how it works by looking at Bochs, then implemented it in UniPCemu.

So the only APIC mode that's not implemented yet now is the SMI delivery mode. But that won't fire, since SMI is barely emulated at all(no instruction support nor SMIACT# support(other than the i430fx/i440fx hardware supporting it)).

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

Reply 65 of 71, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just checked the Windows NT 4.0 boot again. It's seeming to cause the reset because a read-only page is being written to?

Address=C1141000 (final erroring out before reset through 8042):
- Still to be looked into.

Address=C1140000:
PDE=042963
PTE=FC6921
CR4=91h
PDE=4KB PTE!
Erroring out on the PTE, causing 8042 reset to happen?

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

Reply 66 of 71, by superfury

User metadata
Rank l33t++
Rank
l33t++

Managed to improve both the IO APIC and APIC when sending IPIs to multiple processors to allow it to wait for the specified processors to receive the IPI packets properly. So when multiple Local APICs are sent a IPI, it won't finish the arrival of said packets(by clearing the pending bit at bit 12 of the ICR or IO vector entry) until all recipients actually have received and acnowledged their IPI packets.

Just as I've implemented said functionality into the IO APIC's handling, I notices it wasn't properly receiving required interrupts anymore. Then I noticed that the check for pending packets(which is an array for multiple vectors, each saying if said vector is still pending something. If it's cleared, it's supposed to fill said data to make the transfer) was being incorrectly coded. So instead of checking if the specified IR line was already busy, it would instead check if the IR lines variable existed(forgetting the index into the array), thus always resolving to boolean TRUE(because of C/C++ specifications), thus always using the current CPU targets that weren't loaded yet(thus always 0). So no single CPU would ever receive such an IO APIC packet, no matter what the destination was.
Glad that's fixed! 😁

And in the meanwhile Windows NT 4.0's kernel was waiting for those interrupts to arrive to sync the APIC timer with the IRQ8(CMOS) timer! Which would of course never arrive, because it was effectively being sent to a literally 'nowhere' CPU(it was being sent to a non-existing CPU effectively, from the APIC protocol).

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

Reply 67 of 71, by superfury

User metadata
Rank l33t++
Rank
l33t++

Now, there I was, wondering why Windows NT 4.0 would take such a ridiculously long time to boot. Then I tried doing some digging in what it was spending it's time on. I saw it ticking some time using the RDTSC instruction. OK, perhaps it's the time synchronization? Then I tried jumping outside of said spinning loop. Then I saw it's actually reading port 3F6, with the port returning 0x00h because it's set for the non-existant primary slave (it only has the primary master drive emulated for this setup). So perhaps because I skipped the auto-detection in the BIOS, it's somehow trying to detect the primary slave and waiting for it to become ready to send a command? Which it of course never will?

Edit: Changing said BIOS settings to not use the primary slave("None" instead of "Auto") disables the auto-detect and makes Windows NT 4.0 properly boot again.

Although it eventually still pulls the CPU reset line through the 8042? Anyone has any clue why it would be doing so? Is this supposed to happen during a NT 4.0 first boot (setup GUI phase)?

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

Reply 68 of 71, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. I was wondering what was taking the i440fx so long to start booting when I disabled the primary slave in the BIOS...

It turns out it's somehow doing some waiting loop on the status port(which reads 0x00) of the primary slave?

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

Reply 69 of 71, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... Trying to migrate Windows 95 "C" (OSR 2.5) from i430fx to i440fx seems to hang on either ENABLE.VXD after VKD.VXD (normal mode, the PS/2 keyboard???) or previously VPD.VXD(the printer???)?

I started it up in safe mode and removed all PCI specific hardware but the normal hard disk ones(removed the PCI controller though, the intel chip that was there)?

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

Reply 70 of 71, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. Weird. Windows 95 seems to hang during shutdown on waiting for a value at virtual address C1079000, which according to paging is at FFFFD000? That's in the middle of the BIOS ROM?

The TLB entry says that C107902D maps to FFFFD000? So it's checking some value in the BIOS ROM instead of what it's supposed to? It's returning 0x00? This keeps looping while it's zeroed?

Looking at that location in the BIOS ROM reveals it's supposed to have 2F 01 41 43 46 47 01("\x01ACFG\x01" in C/C++)... So why is it reading a 0x00 there?

Edit: OK. It's reading the BIOS ROM alright. But the flash ROM is overriding some functionality, always returning the Status register, which is giving 0x00 as the status(the last flash status)? That's not supposed to happen!

Edit: It perhaps was a little bug left in the BIOS flash chip: When receiving a PCI reset command, it was supposed to clear it's status register and return to normal BIOS ROM mode. But the flash chip wasn't doing so, thus kept stuck in the status phase instead of properly resetting when receiving a PCI reset command(the PCI Reset Control register at port CB9).

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

Reply 71 of 71, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just managed to get a hold of the Intel BIOS flash chip documentation. Then improved it's status register a bit(bit 7 always set to report being ready for a new command, even when cleared). Errors writing a byte or clearing a block now properly reported in bits 4(byte written fail) and 5(block erase fail). Simple returning/setting 0x80 in the error register when clearing the error register or board hard reset.

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