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)?