VOGONS


Reply 520 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just modified the IMD and DSK image formats to be properly using Little Endian as well.

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

Reply 521 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Now just reordered the CPU(EU) and Paging Unit struct fields for more locality and less slack space.
Measured at i7-4790K, with 3 MIPS 440fx and ET4000/W32:
This speeds up the CPU emulation and paging so much that it went from ~20% to ~27% in full blown protected mode with paging! 😁
The POST clearing memory is the same, with clearing memory(REP STOSD for all RAM) now at ~33% still.

OS/2 warp 4 seems to have some outliers at 38% though. 😁
Edit: It still crashes somehere running cmd.exe apparently (with some dll being mentioned)?

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

Reply 522 of 591, by GloriousCow

User metadata
Rank Member
Rank
Member

Sounds like a lot of good improvements. I'd politely suggest some improvements to the user interface. The font you use for the menu system is very hard to read at 1440p and nearly impossible at 4k. A PC user is greeted with "press select" on startup, which isn't very friendly since we have no select button. Some message to the effect of "No valid ROMs found" would be useful rather than a black screen, etc.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

Reply 523 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++
GloriousCow wrote on 2022-09-23, 13:58:

Sounds like a lot of good improvements. I'd politely suggest some improvements to the user interface. The font you use for the menu system is very hard to read at 1440p and nearly impossible at 4k. A PC user is greeted with "press select" on startup, which isn't very friendly since we have no select button. Some message to the effect of "No valid ROMs found" would be useful rather than a black screen, etc.

The manual does specify (in the command-line parameters of the app) a way to deal with high resolution screens:
https://bitbucket.org/superfury/unipcemu/wiki … ne%20parameters

The fullscreenwindow command-line parameter basically adds support for stretching the app to a fullscreen window (excluding the task bar), as used by SDL2.
Although it doesn't have a way of manually enforcing another option it supports: when it detects that the DPI is more than 96 DPI, it will change the display mode of the rendered text on-screen to be rendered like on Android devices, stretching it accross the screen.

Also, for the "select button", in the documentation it properly says it's mapped to the backspace button on a keyboard when not in direct input mode.
Also, the Set button works in that case as well (at the bottom right corner of the screen).

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

Reply 524 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just improved the XT PIT to behave more like it's official 8253 chip (instead of a 8254) by keeping only one flipflop(actually just modifying both read and write flipflops instead of only read flipflop on reads and write flipflop on writes) for both reads and writes to a counter.
That might improve the compatibility issue with the XT BIOS? Perhaps that's what was causing the issue?

Edit: OK. With that change making it a 8086@4.77MHz causes it to start booting properly. The other hangs at POST 02h.

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

Reply 525 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just fixed the Vita build to properly use SDL2_net to supply network support (the loading/unloading and (de)initialization of the net modules was missing).
Also both the Switch and Vita builds had an issue in the required define to make the code start initializing and enabling the SDL_net and related code.

So just tested on Vita3k for the build and it seems to be able to properly detect the support and connect to other locations now.

The SDL2_net code is now also enabled on the Switch, but somehow it can't connect to any website?
Is there something still needing to be loaded for it to work (some missing net modules or something like that)?

Edit: It didn't seem to work yet?

Then I added the switch socketInitializeDefault call and socketExit call. Now the Switch seems to properly be able to be connected to at least (tested with Ryujinx)?

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

Reply 526 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just added some more optimization.
Just made the ATA update function faster by precalculating the two drives for the ATA channel and checking both master and slave drives for activity to perform before checking them individually.

This bumps up the maximum speed reached up to 35% when clearing all memory on the i7-4790K executing a REP STOSD on a large amount of installed RAM (~500MB in the testcase, for Windows 95's limits of usable RAM).

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

Reply 527 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found a bug within the memory mapping of the Compaq Deskpro 386 machines.
It was counting the Compaq RAM on the motherboard as out-of-range instead of it properly existing, causing the FA0000h memory block to not work properly.

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

Reply 528 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just improved the memory size limits for all remaining 32-bit and 64-bit address buses.
They're now autodetected to at most 8GB RAM installed (4GB without PAE supported CPU installed).

Next I modified the MMU to support more than 8GB RAM being installed, by compressing the entire 4GB-8GB memory area precalc for memory block translation into a single entry (as it's the same for any address past 32-bit addressing (past 4GB-1 byte).
It also saves a bit of memory on the precalculation tables, roughly 200-300KB, which is noticable on small memory builds like the PSP (as it doesn't has much available anyway on it's smallest memory models (PSP-1000 models)).

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

Reply 529 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just cleaned up the modem and paging linked list code to use some more clean code and less void to list item casting all the time.

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

Reply 530 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just improved the common emulator framework code a bit.

It will now, when using older versions of SDL2, be able to detect the linked version of SDL2 (which is any SDL2 supported version).

So if it now detects that it's compiled against an old enough version of SDL2 (2.0.2 and 2.0.4 support still being depending on compiled library due to required functions for them), it will do something new now:
If it detects that it's compiled against an older version than 2.0.11 that would need the Windows RDP patch, it will double check against the linked SDL2 version to check if it's 2.0.11 or newer. If it detects 2.0.11 or newer, it will not apply the RDP mouse movement patch.
Otherwise, the old behaviour is maintained.

So if it's either compiled against 2.0.11 or newer (or a new enough revision of SDL2) or running with an updated library of 2.0.11 or newer, it will not perform the RDP mouse movement patch.
So it will support SDL2's RDP speed patch if SDL2 supports it (according to that detection against both linked and compiled version numbers (based on revision number (from Mercurial days of SDL2) and/or version) ).
In the case of compiled version, it will check the Mercurial version (if valid) for both (if supported). If mercurial version fails or is unsupported, it will fall back to the default behaviour of just checking the linked version of SDL2.

So that way, it will be supporting said RDP patch on both older and newer SDL2 versions (if compiled with 2.0.11 and older it will work as well now).

Edit: Just adjusted most of the hints given to SDL to be able to support a wide range of SDL versions as well (although them being set on older SDL2 versions doesn't have any effect).
So if compiled with the app name hint on a older SDL2 version, it will run on said version, but perform the app name hint on any version that's new enough.

All of UniPCemu hints now effectively are handled in this way. If they're undefined on the compiled SDL2 version, it will define it manually instead to provide compatiblilty if the library is updated to a newer version that does support it.
The only things that don't scale like this are the 2.0.2 and 2.0.4 audio and display features themselves, as well as the mouse events filter on the simulated event. But they can't be used anyway, since they require things to be always linked to compile at all.

Verified proper behaviour compiled with SDL 2.0.10 (for some basic support) and then updating the SDL2 dll to the latest version.

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

Reply 531 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just modified the 2.0.2/2.0.4+ video events to be upwards compatible, as they don't require the SDL2 library itself (by linking against that version or newer) to compile those (as in function calls).
It will manually define the two events that are supported, since they aren't in that case.

Some other events, like the 2.0.4+ audio device event handling (as well as it's audio module handling of that) as well as the multithread code adjustment on 2.0.2+ (since it requires SDL_DetachThread to be used) are left requiring said versions to be compiled against (and at least linked against, although newer versions are allowed).
They're required to be compiled against to be enabled, since the compiled program can't be upwards compatible on those, since they require support on the library to even be compiled (requiring the SDL_DetachThread function (2.0.2+) and various audio functions (2.0.4+) to be built against).
So it's possible to compile against 2.0.0 with all other additional features built in to be supported when using later SDL2 versions (by replacing or force-loading a newer SDL2 library as documented by SDL2's documentation) on the latest commits, but things like adding audio devices(requiring compilation against 2.0.4+) and the improved multithread support (requiring compilation against 2.0.2+) can't be active if compiled against SDL2 libraries before those versions that released those two features.

So it will still run with most features compiled on 2.0.0+, improved multithreading compiled on 2.0.2+ only and finally audio device autodetection (and (un)mounting those audio devices automatically) compiled on 2.0.4+ only.
All other newer SDL2 features are always compiled in and are only active if the SDL version that's linked against (which can be manually updated) when running the app is new enough to support said functionality.

So you can now:
- Compile against 2.0.0 (missing out on improved multithreading support and audio device autodetection with add/removal support by SDL2 when using newer SDL2 libraries).
- Compile against 2.0.2 (missing out on audio device autodetection when using newer SDL2 libraries).
- Compile against 2.0.4 with full support of any newer SDL2 functionality (currently up to 2.0.18 features supported).

The other features (up to 2.0.18 atm) are always supported if replacing the SDL2 library (or through SDL2's documented methods of replacing it with another compatible version) with a newer version without recompiling UniPCemu.

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

Reply 532 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... What would be better for a current release (taking the above improvements into account)?

- Releasing the app with SDL 2.0.10 with full upgradability to current versions (can be done by replacing the SDL2.dll with a newer version).
- Releasing the app with SDL 2.0.18 with all features it supports already usable (although this can be done manually as well) or any newer version. The issue with these is that they have broken SDL_WINDOWEVENT_ICCPROF_CHANGED event handling that causes them to hang the app when RDP disconnects on Windows 10 at least.

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

Reply 533 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found a bug in the ATAPI DEVICE RESET command. It wasn't clearing the bits of the status register correctly (leaving bits 5,3,2,0 of the register set if they were).
Now it's clearing those bits, but the first PACKET command received from the host (any command really) restores said bits (and might override that on completion).

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

Reply 534 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Those latest bugfixes are now out on the project's itch.io page.
So those fixes fix stuff like OAKCDROM.SYS to detect both drivers properly in all cases again (some CD-ROM-booting functionality before running it was screwing up it's detection, like on the i440fx or i430fx with CD-ROM in the boot order having priority over the booted disk trying to read sectors off of it, causing an error which didn't properly persist and clear with the ATAPI DEVICE RESET command (according to documentation on ATA/ATAPI-4)).

Said error bit is now properly implemented, with it being persistent for any PACKET commands erroring out without execution of said command if the command isn't a INQUIRY or REQUEST SENSE, with INQUIRY setting the error bit after execution to identify Unit Attention (assumed to be, providing it shouldn't error out on the next command after that).

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

Reply 535 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just improved the Inquiry command (as a quick post-update update to the project's last release) to not report the Unit Attention when completing said command.
The drive will still parse the command if a Request Sense is received (like it did before, clearing the internal Unit Attention flag) or throw an error if a command other than the Inquiry or Request Sense is attempted (while the Unit Attention is set internally).

The main difference here is that the Inquiry itself will no longer respond with a Unit Attention condition if one is set (since it has valid results). Any command other than the two still reports it without attempting execution, including invalid commands (until the Unit Attention is handled with a Request Sense, it keeps being reported).

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

Reply 536 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found an issue with the handling of x86 PDPTE entries in UniPCemu's CPU emulation.

It was checking the PDPTE entries and reading them uncached from memory, while instead it should have been checking them when CR3(during PAE mode), CR0(with paging bit being set while PAE is enabled in CR4) or CR4(with PAE being set with paging enabled in CR0) is loaded.

It will now load all 4 PDPTE entries into the cache, checking them all and properly throwing a #GP(0) if any are invalid (according to all reserved bits and the present flag(non-present ignoring the reserved bits)).
Then once the page table walk is attempted for any reason, the PDPTE entries in cache are only checked against their present bit (as all other bits are assumed to be canonical due to their being loaded in the CPU Paging cache) instead of being read from memory (as is documented).

Edit: Just fixed said cache to properly throw and rollback errors when the PDPT entries in PAE mode are invalid for use (any reserved bits set when present).

Edit: Just modified the PAE PDPTE loading as follows:
- CR3 reloads PDPTEs if PAE is enabled.
- CR0 always reloads PDPTEs only if paging is enabled or disabled (bits 31 and 0 are changed).
- CR4 only reloads PDPTEs IF PAE is set while paging is enabled.

Then, also added for CR4 is that it checks for unimplemented bits for a CPU (Pentium features before Pentium, Pentium Pro features before Pentium Pro etc.), also throwing a #GP(0) if that happens (prevents above actions for the PDPTEs from happening).

Also, if the bits don't change in any way (thus not changing the enable state of PAE paging), the PDPTEs aren't reloaded (so writing the same value to CR0/CR4 has no effect on paging).

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

Reply 537 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

OK. Does anyone know about the x86 PAE page-directory-pointer-table? Is it only loaded from RAM when CR0/CR4 enables PAE and when CR3 is reloaded with PAE already enabled?

The documentation on the Pentium Pro says nothing about it?
And some other documentation (like http://www.rcollins.org/articles/2mpages/2MPages.html) says nothing about caching?

https://c9x.me/x86/html/file_module_x86_id_177.html says that the enabling of PAE and writing to CR3 (when PAE is enabled) triggers a load of the entire PDPT's 4 entries into the processor (this is what UniPCemu does now in it's latest commits)?

Edit: Also a little question: does the PSE bit in the CR4 register affect x86 (Pentium Pro and Pentium II) PAE mode in any way? The Pentium Pro Family developer's manual seems to imply that it enables (non-reserved) or disables(making reserved) the large pages of PAE mode (the 2MB pages)? Is that true?

Edit: OK... I see Windows 2000 not using PAE but PSE instead? Never see any 4MB pages in there though?
Edit: Just found a bug in the PGE bit. When CR3 is written by the CPU and global pages are cached, they aren't evicted from the cache when this is done while CR4's PGE bit is set to 0. Thus global page invalidation fails?

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

Reply 538 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm... Does clearing CR4's PGE bit flush the TLB or not? Or is this only when CR3 is written afterwards?

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

Reply 539 of 591, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just finished implementing SMM and some basic hardware support for generating SMI#.

Now the i430fx/i440fx support various SMI# generation (based on IRQs raised(IRQ 1,3,4,8,12) and/or based on writing to the APM control register, as well as normal APIC generated SMI).

The fast off timer of SMI isn't supported yet though (mainly because I still got to figure out how to implement that).
Edit: Just implemented the fast off timer. So that should make some basic functionality for most purposes emulated now (SMM, SMI#, IRQ raised and NMI triggers for Fast Off).

Just set it up for 1 minute and instead it gets (Fast Off SMI timer) set to 16 minutes(the granularity is set to 1 minute) for some weird reason? I tested it by adding 23760000000 to the current counter to make it overflow and trigger the SMI immediately (for testing), but it still sets it to 1 minute granularity and a Fast Off timer of 16 ticks(16 x 1 minute = 16 minutes)?

And register A2 in the configuration space is completely cleared?
Edit: OK. The issue was with the using of the northbridge chip registers instead of the correct southbridge chip for checking conditions. Whoops.
Working now! 😁

Although it seems to hang for some reason at the end of the POST?
Edit: Hmmm... SMBASE in the CPU became zeroed when starting the last SMI?
Edit: OK. SMBASE in RSM was being loaded from 7EFB(the last byte of SMBASE and the first 3 bytes of the (empty) SMM revision ID)! This was loading an invalid SMBASE into the CPU.

That's SMM on CPU #0. At SMBASE=30000 (starting at 3000:8000).

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