VOGONS


Reply 280 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

Hmmm... Tried booting Windows 2000 CD-ROM on the new i440fx motherboard emulation.
It actually starts loading the files! The floppy disk version hanged before it could start loading said files (directly after the RAID/non-something devices press F6 query).
Edit: It gets to the "Setup is starting Windows 2000", after which it ends up hanging the CPU with a cleared interrupt flag HLT instruction? That's at address 0008:803a6089 of the thread:
TR=28:80837000
FS=30h:FFDFF000
CR3=30000

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

Reply 281 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

Just tried the Windows NT 4 workstation CD-ROM booting 0n the i440fx emulation.
Somehow, it boots, while failing on the i430fx BIOS?

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

Reply 282 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

Just managed to find and fix a bug with compiling UniPCemu using Android Studio, causing the SDL2_net functionality to be virtually unused by the project (it's module is actually compiled and included, but UniPCemu won't call any SDL2 initialization and assumes it isn't included). The old ndk-build method relied on it to have been passed with the ndk-build command line parameters to include said code, while the Android Studio project never would include it.

Said functionality is now automatically included when the ndk-build process in Android Studio finds that a module makefile(Android.mk to be exact) is found in a folder called 'SDL2_net' in the location mentioned in the README.

Although this now means that when said SDL2_net folder contains an Android.mk, you must have the SDL2_net module uncommented inside the org/libsdl/app/SDLActivity .java file, otherwise the app initialization will crash the app(because the SDL2_net module isn't loaded).

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

Reply 283 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

One little notice to users of the UniPCemu's Master branch: It is now moved to the default branch instead, to match other well-known repositories

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

Reply 284 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

Just implemented support for multiple CPUs (for multiple Pentium Pro / Pentium II CPUs).
The basic framework is already adjusted. Also implemented a proper lock signal for all emulated CPUs(them blocking each other LOCK instructions when multiple appear).
DMA also looks at said signal if to begin a transfer or not(affects e.g. LOCK CMPXCHG or LOCK XCHG).

Also the BIU is adjusted so that it can handle parallel CPUs now.

The only thing that's actually left is the implementation of receiving APIC packets on the local APIC of any CPU that's not the boot CPU. So the APIC packets to the other CPUs won't actually reach said CPU(neither from the IO APIC or using the command register). So that's the last thing left to implement, currently (afaik).
Edit: That's implemented now as well.

The only thing remaining is some Settings menu option to select 1 or 2 CPUs to emulate(currently it's hardcoded at 1 CPU). That's only for Pentium Pro and up.

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

Reply 285 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

OK. Having enabled the second CPU, it's receiving a SIPI, but it eventually reaches 8000:10000, which triple faults the CPU because of a #GP(0) fault in real mode that can't be handled somehow?

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

Reply 286 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

OK. Having moved all variables to their respective CPUs, somehow all architectures (and CPUs) fail to boot? That's even on the XT?

The Compaq (according to the POST code) even complains about floppy drive port and video card issues?
Obviously, I've broken something with the migration of all CPU variables or perhaps even before that?

It looks like it somehow sets a weird video mode(low-res mode?) on all VGA graphics cards? Huge text is displayed?

Looked through all code but the new CPU core code(the code for each instruction), but didn't find any errors in converting it?
Edit: Managed to find the offending bug: the direct memory access variable(used in the generic CPU support modules) was being used in the CPU support modules, but the actual CPU cores(the 8086 core in this case) weren't all using that variable. That would cause the 8086 to use the non-CPU specific one(which was left over from the move to the CPU) while all other cores properly used the CPU-specific one.

Edit: Then found an issue with regards to some locks on the CPU structures, which would need circumvention when called from within a CPU handler (in this case requiring the simple clearing of the CPU structure using memset() instead of deallocating and reallocating the memory).

Edit: Just adjusted the CPU to be able to execute a locked RESET and INIT. So now the APIC, 8042 and PPI can properly execute a INIT or RESET without the CPU having to need to release the CPU lock to reallocate registers. It will simply clear the registers if such a method is used, fixing the need for a release of the lock while resetting/initializing the CPU.

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

Reply 287 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

OK. It takes a while to load(I just implemented the Remote Read Command), but Windows NT 4.0 setup now properly boots from CD-ROM! 😁

Edit: Windows NT 4.0 still only sees 1 CPU installed? Even though the BIOS actually reports 2 CPUs installed? Does NT 4 not support multiple processors over the APIC
It literally says:

1 System Processor [1024 MB Memory] MultiProcessor Kernel

The BIOS actually displays it's having 2 processors? The BIOS is setup for MPS 1.4 and leaves the second processor with the INIT state(thus waiting for a SIPI message).

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

Reply 288 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

Just modified the CPUID mode to be dynamically assigned during runtime.

It can now be configured for:
- Modern operation: unknown settings set EAX=EBX=ECX=EDX=0 (Normal operation compatible with most OSes).
- Limited to leaf 1: Limits the reported leaf past 1 to leaf 1 (supporting Windows NT 4.0).
- Set to DX on start: Sets the resulting EAX value to the DX from reset. Leaf is ignored(early Pentium emulation, to support Windows NT 3.1).

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

Reply 289 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

Just found a CMPXCHG bug: all arithmetic flags other than the zero flag(other than as mentioned in the processor documentation's operation's section), iow all other arithmetic flags, were missing from said instruction and thus not updated!

Little sidenote: Are these resulting flags even used by programs and OSes?

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

Reply 290 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

OK. Having fixed said CMPXCHG bug and RESET/INIT behaviour on the i430/i440fx, reinstalling Windows NT 4.0 from the beginning now fully hangs before showing the mouse cursor in the GUI part of setup?
Edit: That's with 2 CPUs. With 1 CPU it happens like before(triggering a 8042 CPU RESET).

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

Reply 291 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

Just adjusted the 80486 CMPXCHG and XADD instructions, as well as the Pentium CMPXCHG8B instruction to properly use the BIU. So now, in both cases, proper bus locking will occur(as it should, especially important in MultiProcessor configurations which UniPCemu can do properly now (up to 2 CPUs)). Previously, it would ignore any bus locks and just executed each instruction atomically(but not allowing other CPUs to take control or race for concurrency as they should(when both CPUs try to take control of the bus, both would have taken 'control' without locking, each executing a locked instruction without taking into account if the other CPU was locking the bus)). It also improves the cycle-accuracy of the 80486 and Pentium in this case, as well with respect to the data read/written without locks.

As a little side note, those were the final instructions that still needed conversion to the BIU and cycle-accurate method of implementation. So now all cores are properly cycle-accurate as they should have been(the 80486 and Pentium weren't fully 100% yet).

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

Reply 292 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

Just tried the Windows 2000 setup again... Something interesting happened (not hanging anymore when starting the Windows 2000 setup's post-loading phase), after fixing the CMPXCHG, CMPXCHG8B and XADD instructions to be cycle-accurate and properly locking. That's directly after setup says at the bottom of the intial file loading "Setup is starting Windows 2000".

1361-Windows 2000 setup BSOD when starting the second phase kernel from CD-ROM.jpg
Filename
1361-Windows 2000 setup BSOD when starting the second phase kernel from CD-ROM.jpg
File size
37.79 KiB
Views
46 views
File comment
BSOD inaccessable boot device
File license
Fair use/fair dealing exception

So it's having a inaccessable boot device instead of hanging now?

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

Reply 293 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

Just took a look at Qemu's way of handling the IDE hardware. I saw a few things:
- ATA Read sector(s) command clears the error register (required for Windows apparently)?
- With UniPCemu itself: setting the device signature cleared the selected drive in the drive/head register(incorrect behaviour).
- Resetting a non-existant drive needs to report non-Ready(incorrect behaviour).
- According to Qemu: Starting a new ATA drive command clears the error register?

So two little bugs with UniPCemu's signature and ready status.
And two little bugfixes found by looking at Qemu(the error register being cleared at executing a new command and after a read sector(s) command(for Windows).

Now the long delay at the end of the BIOS (the i440fx BIOS that is) is now seemingly gone! 😁

Edit: Trying Windows 2000's setup reveals something interesting: it seems to say that it's loading Windows 2000, but no actual disk access or anything is performed at all? The status registers are unread and the error register isn't read as well? It just gives the 0x0000007B (0xF2463848, 0xC0000034, 0x00000000, 0x00000000) STOP error when starting the kernel it seems?

Edit: This might have something to do with Qemu's win2k-hack apparently? Is this the cause of it(too fast ATA IRQs for writes apparently)?

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

Reply 294 of 294, by superfury

User metadata
Rank l33t
Rank
l33t

Windows NT 4.0 workstation still seems to have the reboot issue? Or is it some corrupt file? Can't seem to get Bochs to POST/boot the i440fx BIOS, though. Can 86box use the Bochs-formatted disk image? With SPT=63, heads=16?

Edit: Just reset most Bochs settings to their default values, enabled the i440fx with the Bochs BIOS, then proceeded to boot UniPCemu's disk image with it. It booted without any issues on Bochs, getting to the step of asking for the NT 4.0 workstation CD-ROM.

So the disk image itself isn't having any errors in it? There's actually a CPU bug in UniPCemu somewhere?

Edit: The final messages I see when comparing the Bochs console against UniPCemu's faults:
- I see both emulators throwing a #GP(0x000B) due to an invalid IRET to user mode with a kernel mode segment selector(0x000B=kernel selector 0x0008, RPL=3).
The first what I see Bochs dump after that is some KBD information(typematic, delay, repeat rate) followed by the parallel port(unsupported bits), then enabling the FIFO on COM1&COM2, finishing with the ATA CD-ROM not having any disc inserted.

UniPCemu I actually see throwing the #GP(0x000B), but didn't check any of the other hardware mentioned after that. I'll need to check that out now...

OK. All I see is command F3 being written to the PS/2 keyboard, followed by 0x20. Then a 8042 CPU reset follows that, which isn't supposed to happen? Perhaps a keyboard issue?
Edit: After looking at it executing, it seems like command 0xF3 never properly entered it's result phase for the parameter being written. Thus the host would never receive the ACK from the PS/2 keyboard!
Edit: That's fixed now. The kernel still seems to error out on a page fault at C1140000 now, though? CR3=3945000 now.

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