VOGONS


Reply 540 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found out about something:
It appears that the SMRAM save state area (the 200h bytes) is at SMBASE+8000+7E00, not at SMBASE+7E00.

Just adjusted the read and write code for that area to be applied said 32K (so at 64K and below instead of 32K and below).
Could that have been the issue?

So in the initial SMRAM code that would mean:
- Base 30000, save state area isn't at 37E00-37FFF.
- Base 30000, save state exists at 3FE00-3FFFF.

Is that correct?

Edit: Just fixed the remaining code (the ROM for the version field was still on on the first 32K block of the memory set in the SMBASE).

Now the OS is actually booting again. I even see it remapping the SMBASE for the two CPUs to A0000h (first CPU) and B0000h(second CPU).
Although once it starts booting it changes it back to both point to A0000h for some unknown reason? Ah, that was just my watch showing the active CPU followed by the first CPU and second CPU SMBASE registers (the first CPU was the active CPU).
So SMM seems to run fine now? 😁

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

Reply 541 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. Tried Windows XP Home setup for once. I see it in a loop doing stuff with debug register storage.
Interestingly enough, both EDI and CR2 have the value 0xCDCDCDCD in them?
CR3 is 0x39000 and CR0 is 0x80000011.

It's saying it's "Setup is loading files (Intel IDE BUS Driver)...".
It's XP Home x86 build 2600 English.

It keeps running some code at 0008:32D6E7. CS,SS,DS,ES are 4GB, FS,GS are 255GB (upper 4 bits cleared) and TR has a limit of 77FFF base 0x24450.

Something went very wrong there I think.

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

Reply 542 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just improved SMM a bit. Now the GDTR and IDTR access rights are also initialized, loaded (initialized instead also during LGDT/LIDT, just loaded during RSM) and saved(although in RSM only). Setting GDTR/IDTR present bit to 0 causes a #GP(0) on the CPU (resulting in a guaranteed triple fault if happening because of IDTR due to the recursiveness in throwing a fault).

I also implemented the RSM control bit 0 function (loading the alternative DR6 low 16 bits into DR6 low 16 bits, overwriting it's previous state).

According to https://www.sandpile.org/x86/smm.htm , all that's missing from UniPCemu's SMM implementation now is:
- A20M# (P6 7F18) : Is this required at all to be implemented (P6 only)
- SMM status (P6 7F1E) (what is this?)
- shutdown (P6 7F23)
- sreg_status0 (P6 7F28) (what is this?)
- sreg_status1 (P6 7F68) (what is this?)

Anyone knows how those work?

Edit: Just implemented the shutdown byte to be saved as 1 when shutdown was raised (before a CPU RESET is received) and causing the shutdown cycle to happen again on the used chipset when raised by RSM (if the byte in the SMM state map was non-zero).

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

Reply 543 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just implemented some final pieces of the SMM handling of the i430fx/i440fx/i450gx chipsets:
- INIT during SMM is kept pending until SMM completes.
- Implemented all SMM system/break handling and STPCLK# handling.
- Implemented STPCLK to make the CPU permanently halt after it's BIU is done with memory.

So basically, power management is now fully implemented (the only thing that's not implemented is the USB support in SMM, which isn't emulated anyways).

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

Reply 544 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just did something a bit more user-friendly this time.

I just added a simple ejected CD-ROM caddy to the custom font set used by the app (although only in 8x8 pixels, as that's the limited size of the implemented font). It's basically a circle with a square dot in the middle and a ] bracket at the bottom. If a drive is detected to have been in ejected state for a CD-ROM drive, not only will it display the CD-ROM ejected drive letter but also the ejected tray glyph right below it. So it's more clear that it's not a drive write but instead a CD-ROM drive being in ejected state.

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

Reply 545 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. Just added a copy of the Win95 hardware profile of the i440fx and tried to boot on the Compaq...
It immediately crashed into a not-working MS-DOS prompt?

CheckIt on i440fx w95 crashes on INVD #GP(0) in V86 mode testing the HDD? The collection process fails also.

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

Reply 546 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just improved the STPCLK handing to affect interrupts to be masked when not in SMM or NMI handlers (this is an internal flag stored in the CPU, with the SMM flag cleared by RSM and the NMI flag cleared by IRET).

So now the NMI handlers get masked inside the CPU handling itself (insteaad of in the hardware).

And the STPCLK doesn't affect the CPU, unless the SMM and NMI flags are cleared (so not executing in SMM or handling an NMI handler until IRET).
The masking of NMI and the CPU being in SMM both allow it to run for as long as said flag is remaining set (ignoring STPCLK). Then, once IRET(NMI) or RSM(SMM) is finished, the STPCLK becomes active again (halting the CPU).

Also, while STPCLK is active, interrupts by (A)PIC are also masked if NMI isn't masked and SMM isn't running (effectively ignoring STPCLK while NMI or SMM is running).

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

Reply 547 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just improved the Compaq memory mapping with the new precalcs a bit.
Now, the upper 386KB of RAM is mapped at location 0 (in the buffer), followed by the conventional memory (at 0x60000), then followed by mid and eventually higher RAM.

Memory mapping is now also based on additive addresses and substractive address, using normal addition (and storing substraction in a special way for memory saving, as it happens less).

It also fixes any memory aliasing that would occur with the 1-16MB memory area on the Compaq Deskpro 386 architecture.

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

Reply 548 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just fixed the 15MB ISA memory hole to actually start at 15MB till 16MB, instead of at 15MB+640KB till 16MB.

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

Reply 549 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Windows 95 on the i440fx (Pentium II CPU) did something weird running WinCheckIt 4.0. It started trying to execute a INVD instruction in ring 3 Virtual 8086 mode when checking the hard drive (although ran from the main menu immediately after erroring out on the data collection process (failing to open/save the CKD file or something like that) during the first run and no data been collected successfully)?

Although that was before the latest memory bugfix on the Compaq system. It might have changed now, didn't verify yet.

Edit; Some issue also happens on the Compaq Deskpro 386 without data collection (selecting the no data option): Divide error it says in the hard disk test, before closing (within the text-mode MS-DOS like window).

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

Reply 550 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Checkit 5.0 also gives interesting results. When running the RAM test for the first time on the Compaq Deskpro 386 Windows 95 A edition, it will just reboot windows without running? And then it spews out that that app didn't run for some reason?
Starting it once again after that results in the app being executed, throwing a Divide Error and crashing the program and OS in MS-DOS mode.

Also, if data collection has properly been ran on the WinCheckIt 4 program, no divide error during the HDD test occurs and the HDD starts reading sectors to verify (if that's what it's doing, skipping 5-7 sectors each time in a downwards direction on the 2GB Windows 95 HDD image)?

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

Reply 551 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Anyone knows what might cause this invalid INVD instruction in V8086 mode and collection fail on 486 chips and newer? Does this happen on a real 80486 as well? Is WinCheckit 4.0 simply incompatible with anything newer than a 80386?

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

Reply 552 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just improved the settings file and configuration layout a bit.

Now all hardware-specific settings (which directly affect the emulated hardware instead of output/input) have their settings moved to the architecture-specific CMOS section.

So that means that different architectures now have the older common hardware settings (video settings, audio settings, modem settings and BIOS ROM mode) automatically transferred into the new fields on the different sections for the architectures on load.

So that allows for the user to select different hardware configurations between different architectures (like say a plain accurate IBM XT video and audio on a XT, slightly more modern hardware on AT/Compaq and the latest blazing supported hardware on the newer architectures), with each architecture keeping track of it's own installed hardware.
All of course fully customizable like they already were, but now the settings have been seperated for each architecture instead of using the same settings for all architectures and their used operating systems.

Although things like mounted disks are still not seperated with different architectures, it might prevent weird stuff like changing video cards and other hardware on one architecture (for an OS) and having the other architecture OSes being affected by that. So it basically splits the architectures like a modern VM does (although still having the disk images as a common setting instead of split architecture settings, but that's a whole lot less required to keep track of to prevent things like OSes suddenly getting the different hardware than what they were installed on).

The transferring of settings works just like the CPU settings moving did:
1. Load the old field setting into a variable, defaulting to the actual default value if not present.
2. Load the new setting from the settings file, defaulting to the old value loaded in step 1.

Then, when saving, only the new settings are written to the file (causing the old setting to be removed and the default setting(because the old value isn't present) to become the actual default value when loading the default setting.

Basically, it's just loading the new setting from the file, but instead of defaulting to the actual default, it loads that default from the old setting that actually defaults to the default value itself.
Basically combined with only saving the new location value in the file, this performs the following change to the file when loading (priority below) and saving:
default (if old setting not present)-> old setting(if not present) -> new setting(if present).

The priority order of the effective value is that the setting that's loaded is the last in the chain that's available. And that field is only saved into the new setting field(the old field being effectively removed when saving). That essentially drops the old setting from the chain to allow the new setting to behave normally when loading/saving, with the old setting overriding the default value of the new setting to essentially transfer the old setting (if present and valid type) to the new setting if not present or valid.

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

Reply 553 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just added something missing to the OPL2 CSM mode: note-off triggering.
It was forcing the note on (basically triggering it, forcing it to interpret the register bit as set compared to the old value).
But the note-off on the second sample never happened.
So now, it will simply un-force the interpretation of the bit in the register to be set when rendering the second sample (before it's rendering the samples for all channels), restoring the functionality of the normal note-on and rhythm registers (making their note-on values responded to instead of ignored again).

Writing the normal registers note-on/rhythm bits with 0 will do the same, although the note-ogf timer might trigger after that. If that happens, it's like the writes in-between are written again. It will re-trigger, but shouldn't be an issue unless the effective value changes (which it shouldn't usually, as non-forced equals non-forced).

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

Reply 554 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just managed to improve the input modes of the emulator a bit.

Now, states like ctrl/alt/shift/capslock are properly seperated and kept (not doing anything when no change occurs).

The input method on PSP-like consoles (PSP/Switch/Vita etc.) also had their face buttons modified (X/Y/A/B, triangle/square/cross/circle or numpad 8,4,2,6 depending on input device) to be able to support inputting all combinations of the four buttons at the same time. The only exception being the gaming mode inputs, which function like they did before (just ctrl/alt/shift in any combination with or without another key for any mappable button).
The capslock method of the input methods (lbumper+rbumper or L/R on a keyboard) is also slightly improved to function with less overhead.

So that turns the PSP-style danzeff-ish keyboard input method to support four buttons (plus ctrl/alt/shift in any combination) at the same time now, thus making it more versatile using that input method.

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

Reply 555 of 555, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've just modified the serial port COM0COM support in UniPCemu to allow adding ::COM0COM:: after a specified port. That will force the COM0COM to be detected, if it isn't already (thus allowing to use the unpatched official signed drivers).
Then verified the serial port in it's modem configuration to actually behave as it's supposed to.
Now to check if Windows 10 can actually use the modem. That's when it gets interesting.

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