Just found out that the interrupt mechanism that's triggered(INT 18h) when it can't load any U-ROMs(e.g. U18/U19 for XT) when starting the emulator in IPS clocking mode causes the CPU to hang in some weird way.

I've now replaced it with a simply clearing of the interrupt flag and switching the CPU into a HLT mode, causing the CPU to become set in a permanent halt mode until the emulator is closed. This allows e.g. the packet server(now supporting SLIP and PPP(new!!!)) to run without any BIOS ROMs when the CPU is in IPS clocking mode at last! Previously the interrupt that was started somehow made the CPU hang instead(which it shouldn't). Although the main thread was still active, the CPU wasn't, causing all hardware to stop processing any and all timings, thus effectively hanging stuff like the server component(which is an addition to the modem component) to not do anything as well(not even starting and restarting the server, which is a part of the main modem timing loop).

So now at least the server will properly run with all possible settings that are available(and even without ROMs, which aren't necessary when running the packet server only).

Just found a little misfeature when trying The Games: Winter Challenge(a game I used to play a lot around 2000 on my dad's old 486) in UniPCemu. Although the keyboard didn't respond to much during gameplay(checking the old Ski Jump challenge in training mode), I tried using the joystick instead.

Then I found out a little 'misfeature' on the joystick input/enabling of primary/secondary controllers in the generic input module(not the hardware):
When the input was in gaming mode, the controller would connect normally. But when in any other mode(e.g. keyboard/mouse or direct input modes), it would disconnect the joysticks due to having no joystick input to give in said modes). So it would disconnect the joystick(s) from the game port while using the kegboard/mouse to start e.g. joystick detection or a program that autodetects it.

I've now changed said joysticks(when connected using it's gaming mode input setting set to any joystick) to actually always report as present, just not giving any buttons pressed or joystick movement axes coordinates(just at 0,0) when the input mode isn't in gaming mode(at which point it starts setting the buttons/joystick values as the user inputs it using the current gaming mode joystick and buttons(mapped to the PSP-mode's face buttons(Cross,Square,Triangle,Circle and a single analog stick. The XBox 360 controller supporting more(currently just the right stick is mapped to the Throttle(gravis analog pro, x-axis) or Logitech Wingman Extreme Digital's Twist(also x-axis only)).

Just have been improving the packet method based on the linux source code(https://github.com/torvalds/linux/blob/master … /joystick/adi.c) where I added a press of the buttons(clearing the bits when read from the game port) when starting to transmit a new packet when in digital mode. All bits that are sent using changes on their respective 1(bits 7 and 5) or 0(bits 6 and 4) buttons after that(during transmission) using normal toggling of said bits(each toggle on the 1 or 0 bit being a transfer of said bit on said channel. And of course bits 7/6 transfer the lower bits, while bits 5/4 transfer the upper(including the 00h byte) bits.

Hmmm.... Is that ID packet that it's expecting after a pulse sequence really required for the detection and use of the Logitech Wingman Extreme Digital joystick? Or is it just supposed to send a packet when it receives that trigger&delay sequence(see said adi_init_digital function in linux)?
Edit: Also, is it supposed to do something different every time it receives said sequence(instead of just sending a packet with the data of the current status of the controller)?

Hmmm... On the Pentium, Jazz Jackrabbit now always crashes when loading(except without sound settings, which it asks for then quits back to the MS-DOS prompt from it's normal graphics mode)?

Edit: Even on the 80486, I now get "Unhandled excpetion 000C at 0020 132F ErrCode 0000"?
Edit: Also on the 80386, but after switching to graphics mode. There's something very wrong now.

Just found and fixed a little issue with timing of 80(1)86 GRP2 opcodes starting to write their results back at the same time as the calculation starts(only when the BIU is idle at that cycle), instead of when the calculation is complete(and it's cycles elapsed).

OK. Something in my ET4000 changes somehow killed off 8088 MPH a bit: various screens are now half width instead of full width... That's not good.
Edit: OK. Definitely has something to do with that. The credits screen is also half width, with the right half of the screen showing the last full screen(the final 3 developers of the screen just before the credits) instead of stretching the whole thing to whole width.

It also occurs with the 3D vector images and racing the beam part.

Hmmm... After fixing a bug with privilege level changes throwing #SS(0) on stack faults and instead the proper #SS(elevatedSS), Windows 98 once again changes!

It now crashes on the following opcode instruction throwing a #UD: "8c bc 58 be", which uses an invalid segment register!

Edit: I did see invalid LOCK prefixes on PUSH instructions, though(also #UD faulting)?

Just tried Jazz Jackrabbit on the Pentium again. It just hangs executing LLDT AX in real mode throwing #UD?

Just tried booting NT 3.1 again(not reinstalling it with the latest CPU bugfixes though) with ET4000 graphics.

It now successfully starts the setup wizard for the second part of setup! 😁

Although the display is messed up(text within dialog, excluding buttons). The entire display is messed up, except if you move the mouse(during mouse movement, it's sort of OK, except for the text inside a window)?

Perhaps I'll try to reinstall it fully, maybe that helps.
Edit: That 'fixes' the text, but the windows now all have some kind of DIV8 timing it looks like, getting a horizontally black barred display again?

Only images seem unaffected by the black bars?
Edit: Most buttons past the beginning are entirely black now.

Anyone knows what might be the cause?
Edit: VGA has the same issue. So it's not a video adapter problem itself, but a OS rendering problem?

Hmmm... I see it writing to VRAM (when starting the GUI) values 0xFF with a map mask register of 0xF.\

The renderer is in plain planar mode, so it's a plain 640x480x16 graphics mode that's setup.

Weirdly, all VRAM is(when the GUI is started) filled with 0x6 bytes, thus resulting in the pixels 00000110 being smeared accross the screen(on all four planes, so the color is white with 1, black with 0).

That's kind of weird to initialize it that way?
Edit: The graphics mode itself seems setup correctly, at least.

It's the memory addressing when writing to VRAM that's not working or used like normal?

Edit: It's writing to VRAM and reading from VRAM in planar mode, so writes are selected by the map mask register(set to 0xF, thus writing to all planes), while reads are selected by the read map select register(set to 0, thus selecting plane 0 to read from).

It's sometimes reading values from VRAM. That seems fine.

But when writing, the data rotate register is 0x08, so... The 0xFF byte on all planes is ANDed with the latches, which contain 0x06 bytes for all planes, then proceeding to write those to all the four planes?

Hmmmm... It was expanding the bits from the set/reset register literally accross all 4 planes(e.g. 0x6 becomes 0x06060606 on the dword in VRAM). It's supposed to do something different instead(0x00FFFF00(setting plane 1&2 to 0xFF instead of all planes to 0x6)) as the input to the bitmask operation?

Edit: Booting the system again seems fine(at least after the first reboot when cancelling the setup, it complaining about Windows not being fully setup yet and to run setup again).

So the issue was with two parts:
- VGA write mode 2 uses the low 4 bits only. The upper bits are discarded(previously, it would just look them up into a 4-bit lookup table like Dosbox, which would overflow the table index if the upper 4 bits were set 😖 ).
- VGA write mode 3 uses an set/reset byte expansion on the set/reset register(so each bit turns into 0xFF or 0x00 for said plane) instead of a full expansion(copying the set/reset register's low 4 bits as a 8-bit value to all 4 planes).

So that's another 2 bugs with the VGA controller fixed. 😁 Of course that counts for SVGA as well(as they're extensions of the VGA chipset(ET4000/ET3000 chips).

Edit: The seems to have done the trick. Windows NT 3.1 setup is finally displaying itself correctly, including windows and all! 😁

Edit: OK. During the file copy phase, it can't read the floppy disk #9(probably because it's 1.44MB disks in a 720K floppy disk drive? ). Then a lot of errors because of missing files etc(probably because those are supposed to have been copied over)?
Edit: OK. Managed to get through the setup until reboot, although with lots of missing files(because of obvious reasons with the floppy disk and the BIOS support of it(probably)).

Edit: OK. Setup 'completes' without any accounts being setup. Then, starting Windows NT 3.1, I'm greeted with the Ctrl-Alt-Del finger salute. Entering it twice(weird behaviour in UniPCemu for all OSes, including MS-DOS, BIOS, Windows 9x, Windows 3.x and NT 3.x(only one working so far and tested)), but can't logon because I didn't create any accounts during setup.

So it's booting successfully, but unusable due to not being able to logon. But at least it's something! 🤣

Edit: Although Windows 95 RTM can't seem to properly access floppy disks correctly as well, so that's not a very big surprise there(also setup mentioned that it couldn't load required floppy disk stuff, so perhaps that's part of the cause? (Although that was after the file copy part)).

Just tried NT 4.0 workstation as well(since 3.1 seems to, well, boot(except no proper floppy support)), but it results in the old STOP: 0x0000007B(0xFF6378D0, 0, 0, 0) BSOD (INACCESSIBLE_BOOT_DEVICE).

So there's still some unknown issue that's causing it to not be able to boot the second floppy disk?

Jazz Jackrabbit still seems to hang during it's intro? Still no more than a static blue screen(no sound) in protected/V86 mode(himem and/or emm386 loaded), crashes on real mode(stack fault)? And without sound settings it will display a graphic message to run setup.exe, returning to MS-DOS?

Hmmm... Comparing the full install from Dosbox SVN Daum with UniPCemu's full install shows only one different file: "MDRV004D.MUS". Anyone knows something about it?

Hmmm... Interesting: all bytes that differ between the Dosbox SVN Daum install and UniPCemu's are 00h in the Dosbox install? Those are(on UniPCemu's side):
237=01h
248=40h
250=20h
251=02h
254=05h
260=01h
264=01h
268=44h
269=2Fh
275=70h

Anyone knows more about that?

After fixing some 'bugs' with the FDC not keeping the Seek End flag intact in various cases(as well as invalid interrupts on implied seek, seek/recalibrate not clearing the ST0 bit while seeking(only setting it when completing), Read ID missing implied seek functionality(completing seek to the current track if still seeking(ST0's Seek End bit isn't set)), and both Read ID and Format Track using the previous used head value instead of the HD value in their parameters).

Having fixed those FDC issues, Windows NT 3.1 now properly can read the floppy disks from disk 9 onwards when booted for the first time! 😁

Edit: Hmmm... Perhaps that also fixes the NT4 workstation issue with it's booting not recognizing the first/second floppy(when it starts the OS proper, like Windows NT 3.1 does after the first reboot, with the blue screen and disk checks)?

Yay! Windows NT 3.1 is now booting and installing correctly! I managed to log in using the created user account! 😁

Edit: Hmmm... NTFS conversion didn't happen?
Edit: OK. NT4 goes weird: It gives me a:

1STOP: c0000221 Unknown Hard Error
2 \SystemRoot\System32\ntdll.dll

So clearly no longer misdetecting the used floppy disk drive(a-drive 1.44mb, b-drive 720k(due to compaq bios limitation on bit 6 of the floppy disk cmos byte)).

But now it's crashing on the ntdll.dll library?

Hmmm... After recreating the disks using the latest virtualbox version, it still crashes virtualbox.

But UniPCemu once again changes on NT 4:

1*** STOP: 0x0000006B (0xC000012F,0x00000003,0x00000000,0x00000000)
2PROCESS1_INITIALIZATION_FAILED

Edit: And Bochs seems to be able to successfully boot using the disk1/disk2 combination, loading setup without crashing.

So Virtualbox has an issue with NT4's floppy-based boot and UniPCemu has a CPU or hardware/floppy problem?

Hmmm... Windows NT 4 workstation says on the top of the crash screen "MultiProcessor Kernel"... Isn't that supposed to be "UniProcessor kernel" for the 80486?

OK. Trying to run "winnt /ox" from within UniPCemu for the correct "UniProcessor kernel" makes it complain about virtually every file after the first few, saying that the files copied don't match to the original?

Edit: Looking at the files inside the disk image, it contains lots of 0xF6 bytes?

Edit: Figured out the issue: With consecutive writes on floppy disk sectors(also on reads erroring out), the sector number of the originating command was calculated, instead of using the proper values for the specified next sectors(CHS value of the next sector on the same track and/or side(depending on multitrack settings too)).

Thus e.g. a block write of n sectors would have all sectors, finishing with the last sector(which becomes the only sector written) written to the CHS location on the disk of the specified parameter of the command, instead of the proper next sectors following said parameter's CHS value on the disk. So a 18-sector write to 0,0,1 would write to 0,0,1(first sector data); 0,0,1(second sector data); 0,0,1(third sector data) etc. instead of proper 0,0,1;0,0,2;0,0,3 etc.

The same issue was happening with any error codes on both reads and writes. So reporting the wrong error location if reads/writes fail on consecutive(past the first sector) sectors.

Edit: At least all those errors writing the disk disappeared. 😁

Edit: When reaching disk 2 of NT4 workstation and loading the setup, looking at what the last load from the floppy was(just before the crash), I can see by searching the dll files for a text match of the sector's contents using the xvi32 hex editor, that it's still loading ntdll.dll when giving the error message? It's the sector containing the part of the file about 10% from the EOF(comparing to the extracted file)?

Why is it crashing with a BSOD while loading ntdll.dll? I see it's probably being loaded in the low memory area, at what looked like addresses 0x400000 and up(comparing PFLA agains floppy disk reads)?
Bochs boots it without issues.

Just tried WinCheckIt 4 on Windows 95. It no longer crashes when collecting data about the hardware etc.(mainly the Bus type and FPU detection parts). That's probably due to the MOV to/from memory and AL/AX/EAX bugfix(and a certain modr/m mov instruction using said address incorrectly after said mov to/from EAX was executed).

OK. The last release of UniPCemu(from 20190728) still ran Jazz Jackrabbit without visible issues. So now it's just a matter of applying newer commits until it fails to run properly?
Edit: 20190731 is also confirmed to be running(that includes the install of the most recent commits). So the installation itself is fine, it's something in the CPU or hardware that's going wrong when running the game(including on the 80386), that's causing a stack fault to make it crash.
Also temporarily changed the memory size to 8MB to speed up the memory checks(they take ages when reaching 10MB until 16MB for some weird, unknown reason?).
Edit: 20190812 still has it running. So those paging improvements and bugfixes aren't the cause.
Edit: 20190825 is also fine. So that makes the GPL v3 licensed version commits of UniPCemu still run the application without issues.
Edit: 20190908, same.
Edit: 20191004, same.
Edit: 20191110 00:04, same.
Edit: 20191110 00:30, same.
Edit: 20191120 01:38, still running there.
Edit: 20191121 00:26, still running.
Edit: 20191122 12:00(which was one of the main bugfixes to get Windows 95 RTM running, together with it's previous commit), still running.
Edit: 20191122 12:30, still running.
Edit: 20191122 22:18, still running.
Edit: 20191123 13:22, still running.
Edit: 20191123 16:14, still running.
Edit: 20191123 18:11, starts crashing the Jazz Jackrabbit game(Sound Blaster 2.0 selected in the settings).

Edit: 20191123 18:19, crashes with stack fault.
Edit: 20191128 12:25, crashes with stack fault.

I know it crashes when I started the parallel interrupt work, so that's at around after 20191123 18:19.
Edit: Yup. That one crashes with a stack fault (exception 0xC).

Edit: So the primary cause of the crash is commit 20191123 18:11. In that version, Jazz Jackrabbit starts crashing with the stack fault.
Edit: In that version, the Sound Blaster has improved version numbers. Version 1.5 runs without issues. When selecting version 2.0, Jazz Jackrabbit hangs when starting the video playback when the game starts(static blue screen).
Edit: So perhaps, it's a SB2.0 or DMA channel 2-specific issue?
Edit: Just confirmed: it's a SB 2.0 issue. With SB1.0/1.5 it will run without issues. Only with 2.0 it hangs.
Edit: Found some missing commands that are possible according to Dosbox:
https://github.com/dreamer/dosbox-staging/blo … re/sblaster.cpp

Command 0x04 apparently gives 0x88 on SB2.0 and 0xFF on SB 1.x
Also, command 0x90 is pretty much an alias to command 0x1C (is it really? Other than it being 'high speed'?)

Those were missing from UniPCemu's emulation of the SB2.0.
Edit: Apparently some more: 90h, 1ch and 98h are now implemented.

I only see one auto-init DMA command being started, then immediately afterwards, it crashes?

OK. Just found some weird bug: when running Windows 95 RTM, it boots, but somehow refuses to respond to any input other than mouse movement after the very first mouse click/key press?