Hi! Not sue if this helpful in any way, but Win32-based emulators of the 1990 used weird instructions and often crashed or shew (showed?) weird behavior on certain CPUs or under certain situations.

@Jo22: Interestingl Do you know if any of them ran on Windows 95 RTM or OSR("A) without any updates? Since OSR 2.0 and up still crash.

Also, I've just fixed the new parameter to not automatically start using any connected joystick when the emulator is started. It will now properly start off with no joysticks (when using the multiplayerjoysticks parameter) and only start using a joystick when it's connected while the window has focus. That should fix the issue of having one connected when the parameter is given to the app, preventing it from using said joystick when starting up(for all instances that start up when the emulator instances are launched with a joystick already connected, while all responding to the very same joystick(which they shouldn't in this case)).

Now the two steps I've mentioned should actually work. Simply start the instances using the parameter and connect/reconnect the joystick to associate with the window while the window has focus.

So a simple two-player setup:
1. Start the two instances of UniPCemu with the parameter multiplayerjoysticks. This can be done easily by creating a shortcut to the executable and adding a space followed by multiplayerjoysticks to the command line. In the case of Windows shortcuts, it can be done by creating the path to the filename and adding the parameter manully (for example:

1"C:\pathtoexecutable\UniPCemu_x64.exe" multiplayerjoysticks

). Replace C:\pathtoexecutable with the path that the UniPCemu build resides in.
2. Give focus to the first window
3. Plug in the first joystick (or take it out and reinsert it) to associate it with the first window.
4. Give focus to the second window.
5. Plug in the second joystick (or take it out and reinsert it) to associate it with the second window.

Now, at this point both windows will respond to the joystick, no matter which one (or if neither) has focus. They each will respond to their own joystick(the first window to the first joystick, the second window to the second joystick).

Although it's currently only supported by builds from the source code in the repository. It isn't released yet on itch.io.

superfury wrote on 2020-08-17, 17:02:

@Jo22: Interestingl Do you know if any of them ran on Windows 95 RTM or OSR("A) without any updates? Since OSR 2.0 and up still crash.

Hi, yes, they should. I'm currently reviving an older thread that I created a few years ago.
Most of the emulators that I discovered in the few days/weeks seem to run on Win32s.
That's why I responded to your thread.
As Win32s started out as a sub set of the Win32 API introduced with Win NT 3.1,
I thought they might be useful for testing also. 🙂

Jo22 wrote on 2020-08-17, 18:02:

Hi, yes, they should. I'm currently reviving an older thread that I created a few years ago. Most of the emulators that I discov […]
Show full quote

superfury wrote on 2020-08-17, 17:02:

@Jo22: Interestingl Do you know if any of them ran on Windows 95 RTM or OSR("A) without any updates? Since OSR 2.0 and up still crash.

Hi, yes, they should. I'm currently reviving an older thread that I created a few years ago.
Most of the emulators that I discovered in the few days/weeks seem to run on Win32s.
That's why I responded to your thread.
As Win32s started out as a sub set of the Win32 API introduced with Win NT 3.1,
I thought they might be useful for testing also. 🙂

Funny that you mention 16-bit windows. I've just fixed a CPU bug(found from Bochs' IRETD behaviour as well as when reading the The Old New Thing blog posts relating to Windows 95. There I found this(confirmed by Bochs): https://devblogs.microsoft.com/oldnewthing/20 … 404-00/?p=93261

It mentions an undocumented IRET(D) behaviour popping off 16-bit SP or 32-bit ESP(Depending on IRET or IRETD), but loading either SP or ESP with it, which is determined by the D/B bit in the descriptor(undocumented by any documentation on IRET/IRETD I've seen). So 32-bit IRET with 16-bit stack indeed loads SP with an ESP value(if the upper bits are set), causing an invalid stack pointer in that case.

Is there any software that relies on the high bits of ESP being left alone by the IRETD instruction?
Edit: Oooh! Interesting... It seems to fix Windows 95 OSR2.5("C") to finally properly boot?
Edit: Yay! Win95 "C" is properly booting (at least on the i430fx configuration)! 😁
Edit: The same for Windows 98 FE for it's first reboot! 😁

Congrats, well done! 😁

Eventually Windows 98 setup gets to the second and final reboot, after which it crashes when updating the system files once again?

No such issues on Windows 95 C/OSR 2.5 through. Perhaps a Windows 98-specific problem? It did mention some kind of error while it was building the driver database during the second part of setup?

Edit: After fixing the HDD reset, it seems to boot fine (according to bootlog.txt)?
The GUI of Windows 95 First Edition seems to run fine.

There did were some errors message boxes at two points(just 2 error messages/boxes) during the second part of setup, though.

Edit: After a while, it successfully makes it up to the desktop in Windows 98 First Edition! 😁
CD-ROM wasn't working, though?

Was testing it on the Pentium with i430fx motherboard emulation, though. Didn't test it on the old Compaq Deskpro 386 yet.

OK. So why the hardware isn't working: it didn't have any drivers installed(as in: just the PnP autodetected serial modem! 😖 )...

Running the Add New Hardware Wizard makes it detect pretty much all hardware that's emulated.

Although clicking the finish button takes a looooooooooong time to process?

Or perhaps it's fixed by simply reinstalling it?
Edit: The Add New Hardware wizard detects the various non-PnP hardware and then crashes when clicking Finish?

Managed to greatly improve the speed of loading/saving the SETTINGS.INI file. It will now load and save very fast, making a great loading/saving time difference on the PSP builds.

I did notice, however, that when restarting the emulator something goes horribly wrong on the PSP builds. I see (by enabling the logging of startup/shutdown of the emulator components) the adlib weirdly failing to restart once the emulator restarts(and it's initializing the adlib for the third time)?

I also managed to fix some memory leaks causing the deallocation of the BIOS ROMs and BIOS option ROMs to stay allocated and overwritten when restarting the emulator using the settings menu options for them.

Edit: Although the speedup is at a cost of ~500KB of extra RAM, with 1MB more now being reserved for that. That means 1MB less RAM (11MB installed RAM left in my test i430fx system) on the PSP.
But the loading time of starting the emulator and saving settings is reduced a lot now(only about ~5 seconds, compared to the earlier 30 seconds(for both saving and loading settings)).

Hi! I don't know if this is helpful at all in your case, but the book "Porting to Win32" (ISBN 0-387-94572-5) is interesting to read.
It covers the differences of Win31/NT/95/32s.
High-Level stuff only, of couse, since the focus was on portability..
Anyway, it's nice to have, I think. If you see a cheap, used copy, you may consider reading it. 🙂

Managed to pretty much restore functionality to the SDL 1.2 builds of UniPCemu(with improved documentation on seperating the new split of 32-bit and 64-bit SDL 1.2 libraries and how to configure them to build on Visual Studio).

Found a pretty much old bug in the current Windows 10 libraries: when sdl_events.c compiles, it reaches a check in windows.h's included winnt.h. That check performs a sanity check for alignment of some variable, which always seems to fail, no matter what alignment is setup in the project(SDL in the case) alignment settings? It's comments say it should be default, but for some reason it's not properly appled(it checks some 32-bit or 64-bit doubleword to be 64-bit aligned, which it seems to fail always on 32-bit builds)? Something called a LARGEINTEGER is supposed to be 64-bit aligned, which it isn't on 32-bit builds(causing a compile error)? 64-bit builds have no issues with that. Although it can be disabled with a define, it isn't safe according to the code in said header.

I'm testing that with SDL 1.2.15.

OK. So far no errors on the Windows 98 first boot part. It went on to reboot for a second time eventually(unattended, didn't notice until I checked on the progress later). So far about 1 day ahead just performing the second part of setup.

It seemed to have properly autodetected some hardware(monitor unknown and another piece of hardware it seems). It asked for the drivers location on the CD-ROM(which I made a copy of on disk using WinImage, since it doesn't seem to have CD-ROM support loaded yet at that point).

Setup goes on very slow. So far made it to the second reboot without any errors popping up. It just detected some more hardware and looks like it doesn't do much atm. Almost a full day(with checking in on it once every few hours) on the second part of setup with second reboot included. Currently it's busy with it's 3rd bootup, having detected those two devices and continuing on, I hope...

So far no errors yet 😁 No crashing DLLs that happened during the previous setup.
Although I'm doing a reinstall with the previous Windows 98 installation already there in this case. Perhaps it'll skip the registration steps etc.?

Did get a logon prompt already, though (if I'm remembering it right)?
The HDD indicator is flashing up once in a while, though(reads/writes), so it has to still be doing something at least.
The mouse is also still responsive.

Edit: Ah. Another updating system settings window&progress bar...
Edit: Success. Settings up Personalized Settings...
Edit: It reached the desktop without any errors! 😁
Edit: All hardware is present in the device manager! 😁
Edit: Shutting down the system to make a backup of it...
Edit: It's not fast, but running stable now it seems?

OK. Just checked what Windows 95's hardware detection wizard does when detecting the Sound Blaster IRQ. It seem to request the IRQ, then checks both PICs for the occurance of the IRQ by reading the IRR.
It seems to do this 3 times (or perhaps 4), after which it seems to be giving up?
Anyone knows more about this?

I do see it giving an IRQ acnowledge to the Sound Blaster by reading it's status register for each of those interrupts?

The IRQs happen at 10us after the request was made to the Sound Blaster DSP chip.

Just tried running Wing Commander: Privateer again on UniPCemu.

It doesn't crash anymore! It will correctly run it's bootup now! 😁

Perhaps that little change in the way the stack pointer is loaded for 32-bit IRETD to 16-bit stacks(with the B-bit cleared), loading only SP instead of full ESP (like Windows 95 B/C and Windows 98 FE required to boot)?

Perhaps some kind of CPU bug is still there? When trying to run WinEject's Settings(from the notification area), it'll crash somewhere inside user.exe it seems? It's throwing a divide by zero fault there(trying to signed divide 0x2xxxx by 4, which results in 0x8xxx, which faults due to it being a different sign than what's dividing and divided)?

Just managed to fix a little keyboard input issue. When pressing the Application / Compose / Context Menu (Windows) key, SDL2 seems to report a different key than SDL 1.2(didn't notice because both are defined in SDL2). In SDL 1.2 it reports SDLK_MENU, while on SDL2 it actually reports SDLK_APPLICATION instead(although SDLK_MENU is still defined).
So that caused said key to not be recognized properly on SDL2.

Those latest improvements are now released on itch.io! So that means that Windows 9x(at least up to 98 First Edition) all properly work now. It also fixes the i430fx, CPU issues, improved MPU soundfont rendering, has the new removable media status notification support(for software that supports it) and now can support gaming using multiple instances running multiplayer with multiple XBox 360 (the only PC game controller currently supported by UniPCemu's code mapping of buttons) controllers(on Windows/Linux)! For example, playing Rise of the Triad in multiplayer with 2 players and XBox 36o controllers over a serial modem connection now works!

Hmmm... Managed to start Hiren's Boot CD 7.8 with the current version, running PC-Check 5.50 without crashing during boot. The CPU tests verified it as having 'no bugs', but once running all motherboard tests, it seems to hang on the "System Timer" test, passing the "Clock Ticking Check" test then hanging on the "Channel 0 Interval (mS) . " test, saying "Testing"? Why would it hang on such a test?

Edit: Hmmm... It seems to wait for CMOS register A(status register A) bit 7 to set... That's the Time update in progress flag!

Edit: Turns out it was being set when 244us was left until an update starts. But once it triggered(which was done while updating expired only), it would also trigger the time update itself, which immediately would clear said flag, never alowing software to see it!
Edit: Luckily, it's an easy fix! Just check if to set the flag all the time instead of during ticking only. Although it counts 244uS until an update, which happens multiple times per second in UniPCemu. That's 32768 times a second in UniPCemu, thus each 30us?

Edit: Now it's an immediate divide overflow error at that point?
Edit: Just changed the 244uS delay to set the bit for 244uS when updating the current time(and throwing IRQs etc because of updated second causes). It will still immediately update the time registers when this happens, but will just keep the update bit set for 244uS into the next second for software to detect it's ticking.
Would that be enough? What about accurate?

Of course, it will set for 244uS after each time the whole seconds changes, which happens at most 32768 times for each emulated second in CPU emulation time. Each of those ticks will update the time with a new timestamp if not blocked by setting the bit up to stop the clock ticking. When a new timestamp is loaded into the CMOS date/time registers that way(with a different amount of seconds in Unix timestamp), a timer is started for 244uS to set(when the timer starts) and clear the UIP bit(when the timer expires). Of course, it'll happen after the registers are already updated(at the moment it becomes 1, the Y/M/D HH:MM:SS registers(and their related registers, if any) are updated with a new value). The value will become 0 from the 244uS being elapsed in emulated time until the amount of Unix timestamp seconds changes once again, causing it to be set again for another duration etc.
Of course, it's setting and changing in seconds time will depend on the relative speed of the timekeeping. Said timekeeping uses the normal UniPCemu timekeeping at realtime(when setup like that, causing it to update using the system clock(depending on the OS UniPCemu runs on), which might be faster than the emulated system is running at (so at 20% realtime emulation speed(the CPU running at 1/5th of a real one's realtime speed), it'll update 5 times in a emulated second based on CPU cycles and other hardware timing(PIT, sound cards, video cards etc.))) or cycle-accurate(when set to cycle-accurate mode, which causes the timer to run at emulated speed instead, at emulated time intervals(so 1 second emulated = 1 second on the RTC)).

OK. So that latest bugfix moving the 244uS timing to the start of the new second instead of before any 32768Hz time update fixes the clock tests, but causes the time to run at an incorrect speed(according to the app, as well as CheckIt Diagnostics) due to it being in realtime instead of emulated time(which uses different timekeeping(PIT-based) at a different pace). Of course, setting it to cycle-accurate mode fixes that, although it doesn't run at realtime speed anymore if that's setup(obviously) as the CMOS/RTC time source for the given architecture.

Edit: It also means that if less than 31 ticks on the CMOS 32768Hz clock is taken for a second to pass in realtime mode(less than 946uS emulated time to tick a second or less), it will cause the highest bit of Status Register A to be stuck to 1 permanently instead, causing software to think the clock is always updating(which it actually isn't in that case).

Just implemented some improved MIDI synth behaviour, with better modulator ADSR attack, ADSR decay fixed, sostenuto implemented and exclusive class implemented(immediately stopping the affects voices from playing without release).

Also added a 4K 4:3 aspect ratio to the list. So that way it should be displayed better on 4K displays as well.

Managed to fix the volume as well (unrequired high-pass filter of 18.2Hz(RC filter)). Now the invalid volume overflows shouldn't occur anymore.

It's still very loud, though?