After some more improvements, Windows 9x seems to run fine with it.
So does DOOM (and DOOM II). Although those ran before already.

Running test-sbp.exe somehow makes it run into a ARPL instruction that keeps faulting to itself when selecting the DSP audio test?
It could be HIMEM.SYS though.
Edit: Nope. Without HIMEM.SYS it still happens.
It's actually executing an ARPL instruction somehow.
Edit: It literally crashes on that instruction after sending a DSP Enable Speaker command. Either that or the executable is somehow corrupted during the installation process.

Just curious about one little thing:
What does port 388h/389h do on the dual-OPL2 configuration of the Sound Blaster Pro?
I assume writes go to both OPL2 chips? But what about reads? Is it a combination of both chips' results?

Currently my implementation just gives a combined result of reading both chips' status port (basically OR-ing them together).

Improved the DRO and VGM players to support both mono and stereo OPL2 now.
So the DRO player supporting OPL2 mono and stereo, with OPL3 always being rejected when loading.

They will check for mono and stereo OPL2 now, with:
- Mono being redirected to both chips (or one chip if it's a basic single Adlib chip).
- Loading a dual OPL2 VGM or DRO file is rejected unless a dual OPL2 chip is emulated.
- Loading a OPL2 VGM or DRO without OPL2 emulated is rejected.
- Loading a SAA1099 VGM without Game Blaster or Sound Blaster with those chips present is rejected.

The VGM player now also properly supports the alternative SAA1099 ports when it's placed on a different I/O address.
The SAA1099 will report it's base address (either 220h unless Sound Blaster Pro is emulated, where it's moved to 250h).

Managed to disassemble a large part of the sbp-test.exe program. Hopefully I'll find the problem that is occurring in my emulator soon.

Found all kinds of Sound Blaster support functions (for different Sound Blaster handling) as well as some alternative functions for those (effectively duplicates of the same kind of functions), various C-style functions (or what looks like them), some driver support functions for XMS and others (and file I/O) so far.

I think I'm getting close to the function that's going wrong in my emulator and causing the crash though. I see it's doing something that looks related to speaker enable commands or something close where I'm at right now.

Roughly 60%-ish of the functions have been deciphered. Lots of (probably string or data processing) functions are still not documented so far, although those aren't what I'm looking for (although they might be the cause of the crash somehow, seeing the complexity of the crashing function I see executing in UniPCemu).

OK. Had to re-start disassembly, as I've messed up the segments.

I found the point where it outputs the speaker command (the D1h command), but almost immediately I see it afterwards some valid code, after which it ends up in some weird undefined code segment, eventually leading to an #UD exception and a hard reboot of the machine.

Implemented most of the basics to later implement the 8080 instruction set and mode switching on the NEC V20/V30 chips.

Things like flags, instruction parsing and optional modr/m byte configured by the opcode information tables.
Basic flags masking and mode switching to 8080 mode is also implemented (using flags popping from stack only).

All that's required for a full NEC V20/V30 implementation now is:
- Stack adjustments for DS:BP instead of SS:SP.
- NEC V20/V30 non-186 instructions (in other words: it's 0F opcodes).
- Actual 8080 instruction information and redirects.

superfury wrote on 2025-05-21, 12:21:

Implemented most of the basics to later implement the 8080 instruction set and mode switching on the NEC V20/V30 chips. […]
Show full quote

Implemented most of the basics to later implement the 8080 instruction set and mode switching on the NEC V20/V30 chips.

Things like flags, instruction parsing and optional modr/m byte configured by the opcode information tables.
Basic flags masking and mode switching to 8080 mode is also implemented (using flags popping from stack only).

All that's required for a full NEC V20/V30 implementation now is:
- Stack adjustments for DS:BP instead of SS:SP.
- NEC V20/V30 non-186 instructions (in other words: it's 0F opcodes).
- Actual 8080 instruction information and redirects.

If you want to validate your instruction correctness, you can run this CPU instruction exerciser, and compare the CRCs to the results from hardware.
I posted info over here:
https://forum.vcfed.org/index.php?threads/exp … 01/post-1447047

Managed to finish and fix the issues on the CPU emulation code.

The new jumptable and opcode information table are implemented and activated. Verified to still run x86 at least.

Mode switching to/from 8080 is also implemented. All that's left there is those 4 instruction to enter/exit the mode.

And of course filling the tables with data (modr/m substitutes and parameters) and functions required to execute all instructions, of which most should be able to run through the modified modr/m system (just using ModR/M register/register and register/memory accesses and BP/SP direct pointers afaik). Most should be able to map to the x86 handlers directly afaik?

Adjusted the ModR/M system to support 8080 memory addressing of (with MOD=00):
- HL on case /3 (x86 being BP+DI) (same number as the HL register)
- Immediate (stays the same as x86 case, working exactly the same) on case /6
- [SP] uses [BP] when addressed with ModR/M [BX]. Used to address the top of the stack (case /7).

The SP register is mapped directly to BP(register case 5), BC to CX(register case 1), DE to DX(register case 2) and HL to register case 3.

That way I can support pretty much all memory and register modes using plain ModR/M on 8088, by overloading just a few (case /3 and /7) MOD=00b 16-bit ModR/M values (which now depend on the 8080 emulation mode).

Edit: Actually, thinking about it maybe this is enough to actually emulate the entire ModR/M instruction set with just the 8088 instruction handlers doing most of the work, with just a few extra instruction handlers to handle the 8080-specific instructions?

Hmmm... It looks like the absolute conditional jumps (like CZ a16, which is opcode CCh) will need to be done manually? Since there exists no unsigned x86 equivalent?
The same with JMP and CALL instructions (only signed relative addresses exist)?

Went ahead and ran NT 4 workstation again.
It boots fine, but when I run the command prompt and run dir, it runs fine. But when I run "edit", I see it throwing a #GP(0) after detecting the VME's interrupt (executing INT 21h), due to the lookup being set or out-of-bounds of the TSS. It detects that PL in the EFLAGS register isn't 3, so thus the #GP(0) occurs.
I see it briefly displaying what looks like an error code of sorts in the title bar before returning to the MS-DOS prompt, having finished (terminated) the edit.com program? Basically executed and immediately terminates after a single INT 21h instruction it looks like?
Said interrupt pushes an error code of 0 onto the stack, which should be correct?

Tried reinstalling Windows 95 OSR 2.5 ("C") again, but when it reaches the desktop and starts installing the Java JVM for IE4, I get a hard driver driver crash BSOD, which eventually leads to the VMM(01) + 00000350 crashing, crashing the system permanently.

Hmmm... Tried running Hocus pocus again (MS-DOS). Didn't matter if I tried using Virtual 8086 mode (EMS installed) or not (real mode). Both give a divide error and crash.
So the issue there is in the CPU, not in the hardware changes (SB Pro II now I'm testing it with).
Or does it have issues with that sound card?

Found a bug where x86 virtual 8086 mode with VME enabled, when causing a fault (#GP(0)) it would continue to run the instruction incorrectly (in kernel or user space, depending on how far the protected mode handling went), corrupting the process.
Also fixed Virtual 8086 mode, when referring through the IVT instead of the IDT with VME enabled, to properly ignore the Access Rights descriptor byte (as it isn't used in this mode, only in protected mode interrupts). It's now forced to reset (and real mode) values for this case only (becoming 92h).

Some more bugfixes later, I took another look at NT 4.0's MS-DOS prompt (cmd.exe).

I ran command.com, which seems to run, but somehow display updates are very slow or somehow delayed for some weird reason? Like always a command entry behind for some weird reason. It seems to detect the input fine, though, just display updating (text mode) too slow when running command.com for example. I type a full command, and only after pressing carriage return it seems to update the display for some weird reason.

Running edit.com now seems to work properly. Or at least when running it (doesn't update the display, or at least not yet) and then switching to fullscreen mode shows it's actually running.

Switching back to windowed mode, it shows the MS-DOS prompt again, instead of the edit.com application that's actually controlling the 'display'?

Edit: Hmmm... This just seems to be the case when running MS-DOS programs (.com programs at least) from within cmd.exe.
Running edit.com directly from the start menu (using the Run dialog box (found in the Start menu) or Windows+R keyboard combination seems to give a version that properly updates the window.
So it's just some weird issue with the window not updating when nesting MS-DOS programs inside the cmd.exe program? Or maybe MS-DOS program nesting in general, but I didn't verify that yet.
Edit: OK. Through the run dialog box running command.com, which in turn runs edit.com it seems to work fine in windowed mode.

So there's some weird problem with cmd.exe blocking display updates somehow while executing programs? Anyone knows of such an issue with it?

Edit: Hmmm... When running the edit.com inside command.com, viewing a file, the display updates. But only once the mouse (that's a normal graphical mouse cursor) moves when it's in windowed mode?
In fullscreen mode, it seems to update immediately?
So it's not just a problem with command.com. It's a NTVDM issue?

Hmmm... Is Pink Panther in Hocus Pokus Pink a 16-bit windows executable? Perhaps a good one to verify if Windows NT 4.0 can run it?
Setup seems to start up fine so far.
Edit: Managed to install it fine, then installed the Sound Blaster Pro drivers (included in the NT4 installation CD-ROM).
Will check on it later if the game works properly.

Also, interestingly enough, when NTVDM starts up for a MS-DOS application, I briefly see it giving a hexadecimal number with what I think is a dot between it. It's almost immediately replaced with the app name of the executable to run (or stuff like "cmd.exe - edit.com"). Does that code mean anything? Or is it just a version number?

Hmmm... Interesting. It looks like the NT 4.0 workstation OS is actually using INT 10h to setup the video mode during boot?
I see it executing INT 10h with AX=002Eh for example. Thus setting up 640x480x256 (which is the default mode on ET4000 chipsets I think)?

Fixed an issue that caused the NEC Vx0 0F jumptable and opcode information table entries to be used on the 286 and above, thus messing with the 0F opcodes for those newer CPU models.
Added a special exception that will simply skip those specific entries and count them as unmapped, passing them through to their 16-bit version of 286+ or #UD handlers according to the implemented CPU.