Just improved the modem emulation to perform ATD* and ATA asynchronously (only one of those two at a time though).

So when the modem receives an command for one of those two, the command is performed in the background and other commands can be given in the meanwhile, at least until the connection gives it's result (so ATH can abort the call for example).

Edit: Although Telemate won't start properly (due to some CPU bugs afaik), running MODEMD70(Modem Doctor 7.0?), I could test the new functionality a bit.

Although SDL3 still seems to have issues detecting a disconnect, trying to connect to it while it's 'ringing' (SDL3 reporting the connection even though it already disconnected) properly makes it (SDL3) report the disconnect, causing the modem to drop the connection properly.

Another new thing that can be done now, is when dialing out or answering a connection, you can use ATH before it completes (or any other command for that matter). So triggering ATD*/ATA to dial/answer, then immediately sending ATH(or low DTR if enabled) it will immediately drop the connection attempt as soon as possible (causing a disconnect on the request before it finishes connecting if possible). Other commands will work as well, but the effect of ATD*/ATA will take it's documented effect once it succeeds connecting (causing the new data mode to be applied if enabled). So you can get:
ATDTgoogle.com:80
ATH
NO CARRIER
OK

or:
ATDTgoogle.com:80
ATS0=1
OK
CONNECT 57600

or combined even (if you're really fast enough to send those commands before it finishes):
ATDTDgoogle.com:80
ATS0=1
OK
ATH
NO CARRIER
OK

Of course one way to do that is make it perform a really slow failing connect to some weird address (I remember SDL on Dosbox running Windows 95 for example literally hanging for a second or 10 trying to connect).
One nice thing is that UniPCemu now no longer hangs in those cases, as it performs the connect using multithreaded resolution and connecting now. So the main thread isn't blocked and keeps being responsive, while the parallel threads grind away at trying to make the connection in 2 steps (1 thread started for IP resolution(in parallel with emulation, which closes itself when it's ready), main thread starting another thread for connecting using that (in parallel with emulation, which closes itself when it's ready), finally the main thread parses the connection and makes it ready for use.
The receiver otoh is working much like before, although SDL3 has some extra functionality which should (excluding above error) make the receiving of a dial be more accurate using TCP. But too bad, the SDL3 library messes up a bit there (reporting ready to read when it isn't connected anymore).

Thinking about it, UniPCemu (and it's common emulator framework I use for 2 projects so far (UniPCemu and my (WIP, never finished) GBemu project, which was based off a javascript gameboy emulator tutorial (https://imrannazar.com/series/gameboy-emulati … n-in-javascript). If you look closely at some parts of that source code, you can still see some leftovers of the same kind of naming methods in UniPCemu's function names and handling, like MMU_rb etc.).

Just adjusted the packet server a bit.
The following protocols have been renamed (using their improved or official names now):
- "ipxslip" becomes "slipx". That's "SL" from "SLIP" combined with IPX.
- "ethernetslip" becomes "sleep". So it fully matches the SLEEP protocol now (what it actually is and has been all along, the Serial Line Ethernet Encapsulation Protocol).

I also fixed the sleep protocol to be properly not filtering out non-IPv4 packets, which it shouldn't have been doing all along. The normal MAC adress filtering stays the same, as it should be used always for client MAC addresses no matter what.

I still need to implement the SLEDFS protocol (see SLIP/SLIPX, but for the EDFS protocol), though. I've already implemented such a thing for SLIPX, but EDFS is still only implemented in the PPP negotiation now (mainly because I was busy rewriting the LSPPP driver for EDFS support first for the current commit of UniPCemu).

Improved the size of the UniPCemu repository and it's subrepositories a bit. Ran BFG (https://rtyley.github.io/bfg-repo-cleaner/) to remove any files bigger than 1MB (they weren't supposed to have been committed) from my repository history. Although this changes the commit hashes, the repository code still seems intact.
Though that's only 3 files in commit history in total (all big data files from Visual Studio back in the day, that weren't supposed to be committed at all, and due to .gitignore aren't committed anyway in current versions of the compiler combined with the ignored file types).

That shrinks the entire repository by at least some 120MB ish size, with it just being 114MB now, with 77.6MB in the SDL2 subrepository (the app itself is only 8.92MB for it's code, with the common emulator framework only being 2MB in size (unchanged) and the PSP tools repository only being a small 70.8KB (unchanged).

Improved the ET4000 and ET4000/W32i emulation to add an PCI interface for specifying the memory block to handle linear memory mode in.

On the ET4000AX emulation, it specifies bits 22-31 for the addressed window.
For the ET4000/W32i emulation, it specifies bits 24-31, with bits 22-23 coming from CRTC register bits 0-1, if the higher 3 bits are properly set to the following (after being flipped):
- 000b: Legacy mode (map to 0MB using legacy VGA mode)
- 110b: BAR-based mode (supplying 8 or 10 top bits)
The lower 2 bits are the aperture used if the BAR is 8 bits (ET4000/W32i behaviour) or unused on ET4000AX.

Improved the PCI bus and PCI-to-PCI buses a bit.
All loops that run through the allocated devices and buses (contained in a single list) now use linked lists instead of full-blown 256-entry arrays.
This improves handling of less than 256 (usually it's only a few used, depending on installed devices) to become a relatively small loop of only a few entries.
It essentially keeps two lists: one list of allocatable entries (which aren't used yet) and one list of newly allocated entries (each new entry added is added to the front of the list).

The lists allow backwards and forwards traveral (doubly linked lists), although they're only attached to a single start-of-list pointer each (which is the most recently allocated item (allocated list) or first item to allocate (freed list).
The current algorithm simply traverses the lists from start till the end to use their functionality though. It being doubly linked mostly just helps with debugging the whole thing.
Instead of all entries being spread accross multiple 256-entry variables and pointers, they're now each packed into one structure that contains all data for a specific PCI device that's allocated. This includes things like function handlers handling memory/io/PCIRST#, configuration space pointers (to the local configuration space data block supplied by the module that registers itself as a PCI device), interrupt line status and PCI traversal and Device/Function addressing. The bus addressing part of it is now actually handled by the root bus directly or the parent PCI-to-PCI bus.
Although PCI-to-PCI buses are fully implemented, they aren't used yet, as not enough slots are filled yet for the module to add those to it's registration (also taking up 1 entry for such a PCI-to-PCI bus with backing configuration). Basic handlers for the configuration space data and PCIRST# handling are also implemented for the PCI-to-PCI bus to use (using either a custom function with extra functionality or the basic function mappings that has the documented basics implemented (basic routing of PCI-to-PCI bridges is built into the PCI basic handling already, both for PCI configuration and PCI memory/IO accesses)).

One thing that's also changed is that registered devices/buses parent bus ID during registration or updating actually indicate the registered PCI handler ID instead of the physical bus number now.

Hmmm... After implementing the ET4000/W32P documentation based PCI command and status registers (and initialization PCIRST# values for those) somehow the moyherboard BIOS doesn't list (during summary display before trying bootstrapping) or enable the video card's command register's bit 0/1(IO and memory bar mapping enable bits) anymore? So it's aborts detecting the card for some reason, when the command and status registers are now properly implemented afaik (without that handling of those 2 register writes and PCIRST resetting them to defaults, it detects them properly)?

Improved intermediate EIP when handling paging and faults. The intermediate EIP is now stored seperated, instead of overwriting the instruction's EIP during a fault.
So for example:
- When running an instruction with 5 bytes length at F000:FFF0:
-- The intermediate EIP is pointing to F000:FFF5
-- The instruction EIP is pointing to F000:FFF0.

During faults, the instruction EIP is restored, while during paging (which interrupts the instruction), the intermediate EIP is restored properly now.
Previously, this would cause paging in from memory to reset EIP to the instruction EIP, instead of leaving it at the intermediate EIP. Also, any fetching would update said instruction EIP to point to the next instruction, so the program's idea of the executed EIP would go wrong too! 😖

You can imagine the troubles this causes... Instructions randomly re-executing with incorrect EIP (not matching the BIU EIP, which behaves as it should due to having it's own idea of EIP), while the virtual EIP (the jump/interrupt etc.'s idea of EIP) gets reset to the idea of the instruction's EIP on each paging in. And page faults would of course also use this virtual EIP. That results in pure chaos on the executed program and OS.

Just tried a little fun test to see how the APM emulation inside UniPCemu works now.

Tried to put the system in APM sleep mode and wake it up using the keyboard.
Unfortunately, the APM call somehow managed to be triggered during the key press itself (the key-down event). The issue is right after, when releasing the key before the APM handling finishes. So the key-up is received too soon, which causes the handler to not respond to it properly while putting the system in a sleep state 😖
So the 8042 input buffer is filled with the key-up scancode of the triggering key, raising the IRQ line that is supposed to trigger waking up. But since the APM handler never seems to properly finish before that happens (and the CPU can't handle it), the key-up event gets stuck in the 8042, which raises the IRQ line, which will never be handled because the CPU is put in sleep state by the APM handler. And the wake-up event on the hardware never triggers because the key isn't released after the APM handler returns (which is after the beep).

Basically the keyboard is too fast in it's reponse to the key-up event, causing the APM handler to deadlock on it's response (which is after the beep finishes).

One way to 'fix' it's response to be proper is to hold the triggering key until the beep starts and finishes beeping (when running The Troubleshooter).

Edit: Hmmm... Running my own version of the APM calls from a c program (adjusted version of shutdown.exe : https://github.com/superfury/shutdown ) seems to run without issues. It properly manages to reach the standby state, then waking up properly using the IRQ line being raised by the keyboard controller. Because it doesn't trigger the APM call within the keyboard handler perhaps?

Anyway, it's working fine there. I can see that the CPU and screen are effectively disabled as they should in said mode (the emulation speed goes up (since it's below 100% speed as the host CPU can't handle the full speed of the emulation at 3MIPS when the CPU is running), indicating that the CPU is disabled, and the screen is blanked as is configured in the motherboard BIOS settings).

At last managed to get the string instruction (REP etc.) fixed to run properly again.

The main issue that was happening was that any kind of interrupt (INTA, NMI, SMI) would not properly reset the EIP of a running instruction to the start of a string instruction when needed.
Also, NMI and SMI weren't handling CPU-specific resetting of EIP during a running string instruction, thus pointing to the (incorrect) next instruction instead of the instruction being interrupted (causing it not to be restarted properly, instead running the next instruction that follows the interrupted instruction).

So for example a string instruction being interrupted by NMI or SMI would restart as the next instruction, instead of properly restarting itself (on newer CPUs).
And on older CPUs, the bug for NMI wasn't being handled as well.

Other than that, the 808x also wouldn't handle the CPU bug with string instructions being interrupted by NMI/INTA properly, as it wasn't detecting the repeating instruction being active correctly (assuming it wasn't active and thus returning to the next instruction always, leaving flags REP-related incorrectly set in the instruction state).

Hmmm... Jazz Jackrabbit for example still crashes loading the second world from the menu it seems?
I noticed the PC Doctor also crashes when scrolling down to the advanced modes past mode 2Dh? It gives me a stack overflow error?

Hmmm... Managed to crash MS-DOS 6.22 even, playing a rad tune using radplay, then dropping the CPU to 1KIPS speed, typing some stuff to make the keyboard buffer overflow and then increasing the CPU speed?

Is that expected of MS-DOS to happen if you mess with CPU speed that extremely?

radplay is still running it seems, although it now displays:

1Internal stack overflow
2System halted

Operating like Windows (tested 95 RTM and 3.11) seem to boot properly again, at least, on the newly fixed EIP intermediate saving and REP prefix bugfixes. 😁

The random stack faults seem odd, though? Those shouldn't happen afaik? Or is that in part caused by the 1 KIPS instruction speed I was testing with (combined with too fast hardware timers for that case to handle, drowning in IRQs)?

Just improved the logging and text generation of ASCII character generating a bit:

- Memory and I/O accesses now use proper UTF-8 encoding of logged textual values for reads/writes.
- Test MIDI display now properly displays the voice preset name as ASCII instead of incorrectly encoded UTF-8.

Also, logging is now changed to include the UTF-8 BOM (UTF-8 codepoint U+FEFF) when creating the logging file, to improve UTF-8 support on text editors.

Improved the codepage support a bit, when logging.

Logging now converts the used OEM 437 ASCII code points to Unicode code points (based on the 0-1F and 80-FF ranges on the wiki page).
Although 2 control characters(0D and 0A) aren't translated by the logging algorithm ): they instead are converted to line breaks depending on the OS (and invalid sequences removed). So 0D becomes 0D0A on Windows for example.

Improved various logging issues.
Now CP437 ASCII (encoded as UTF-8) is properly parsed and converted when logging.

Filenames on Windows are also improved to use the proper UTF-8 codepoints when converting from WCHAR past U+10000 (the shifts were correct but used a bit too few on the second/third bytes of the UTF-8 encoding, clearing bits 11 and 17 when they shouldn't.

Edit: And also implemented the U+25A1 (white square) unicode character glyph. It now replaces any character that isn't defined into the used fonts (which is pretty much all unicode character points, except the used CP437 character points (and the custom character glyphs at 100000h+ for the application itself to use (which are the PSP face buttons and the ejected CD tray icon))).

Improved the PCI-to-ISA bridge emulation a bit.
It can now piggy-back when a different PCI-to-ISA adapter is registered (like onboard southbridge PCI-to-ISA adapters) and provide it's service there.

So for example, the PIIX and PIIX3 PCI-to-ISA bridges can use this PCI-to-ISA emulation to provide their surfaces to devices added to them (or if no such southbridge exists, use the provided default bridge instead).

And after implementing the generic PCI-to-ISA bridge to be handled for all known PCI-to-ISA bridges implemented (previously they would be handled with only the PCI configuration space implemented).

Basically, the allocation structure is the same, except the PCI configuration space is remapped to the PCI-to-ISA adapter space in the background, which handles the I/O and memory apertures.
The configuration space is still handled by the normal i4x0/85C496/7 chipset, just the ISA windows being routed through to connected devices on the adapter.

On the adapter, it's now guaranteed that every implementation of the motherboards have either their own PCI-to-ISA adapter (like the PIIX/PIIX3 southbridge), or an added generic PCI-to-ISA adapter for most devices.
And the PCI-to-ISA specific device for the video card (implemented for the Tseng video cards and VGA video card) is also present in all those cases, allowing the video card to be remapped when required (to provide linear memory mapping anywhere in memory, using either port 3CD or CRTC register 30h's low 2 bits to select a 4MB (or 1MB) window inside the 16MB ISA aperture provided by it's PCI-to-ISA bridge). The video card PCI-to-ISA bridge also has some identification (on real chipsets this would be handled by a special chip loading the register values serially. In UniPCemu's case it's simply loaded on PCIRST# handling). The identification is basically just that the Subvendor/Subdevice ID are loaded with 100C(Tseng)/0000h(VGA) and 3203h(ET4000/W32i)/3200h(ET4000AX or ET3000AX)/0000h(VGA). Although VGA pretty much identifies itself as a normal documented PCI-to-ISA bus with just the VGA on it (it effectively doesn't require remapping). It can still be detected to be on said bus like all other cards by remapping the IO/memory space and detecting if the card disappears though.

On that subject, how does Windows 9x for example detect a device being on a ISA bus? Does it just move the area mapped or unmap it and look for disappearing hardware?

Found a bug in the new x86 emulation (since after last release). The GRP4 /6 PUSH r/m8 opcode was incorrectly pushing 16-bit modr/m (reported as a bug by the modr/m subsystem checking for register destination of incorrect word-size).
Also found and fixed some bugs in the 808x-only GRP4 far CALL/JMP instructions loading CS incorrectly with 8-bit modr/m.

Managed to fix Android SDL3 builds by downgrading to SDL 3.1.1. Anything from 3.1.3 onwards goes weird with the rendered pixels (the mouse positioning in Windows in full screen is still wonky. Touch on Android works properly in all orientations, but somehow the SDL 1/2-compatible code won't render properly when I use the texture to rotate 90 degrees clockwise for landscape mode? It stretches way too much somehow (fullscreen/full surface texture rendering)?). Also, portrait mode on 3.1.3+ is stretched incorrectly to full screen? Though that might be wanted behaviour.

Improved the SDL2/SDL3 power handling a bit.
It now uses the SDL power interface to detect if the battery is present, charging, full, power supply and the battery percentage for the emulation to use (using the emulated 82347 chip (i430fx/i440fx APM? )).

So it will detect the actual battery percentage and AC power status and act according to it (provided the chip enables it, enabled by software).