Thinking about upgrading my Sound Blaster 2.o to a Sound Blaster Pro (CT1330) though. Just double the OPL2 chips and mixer support added (no tricky OPL3 stuff or custom MIDI synth required).
I'd need to make the existing OPL2 chip emulation modular (like the CPU) though, to make it emulate two chips simultaneously.
Edit: Got a SoundBlaster Pro full version ready to verify and commit. Don't have a PC on hand eight now, so it's still stored on my local storage. After compiler validation it can go into the git repo to verify against software.
The basic dual-OPL2 I've already implemented there. And I'll still need to implement the volume controls (mapping the register values to amplification factors and apply them to various hardware) and input/output filters of the card.
Oddly, Dosbox calls the MIDI volume control (register 26h) register in the mixer the FM volume control instead? Is that an error in the official documentation or an error in Dosbox?
Edit: Gotten a basic implementation implemented, with stereo support. Although stuff like volume and input control isn't implemented yet (registers not masking off unused bits and the registers having no effect), the basic Sound Blaster Pro should be implemented. All that's mainly left now is to verify it (and implement those volume controls ofc).
Edit: A small bugfix: stereo mode seems to require high speed mode (command 90h or 98h). Examples in documentation render a single mono sample before starting the stream with a high speed command, where stereo would fail if command 14h (in the example given in the documentation) would render a single byte buffer in stereo before the steam starts properly. So thus only high speed commands seem to be affected by these settings.
Edit: Managed to implement a basic mixer, calculating volumes for the different possible audio sources.
Although the actual multiplication factors that are calculated aren't applied to the various input/output devices audio inputs/outputs yet.
Edit: Most volume settings are applied now. Only sound input (unknown if it's Mic or Line in that's applied) and MIDI output (since it's a different device that's rendering) isn't applied. Master volume is now mapped onto all channels that are available (voice, FM, CD audio, Game Blaster (although not having a dedicated volume control, using the master volume only and a static 100% volume otherwise). So only inputs aren't applied, together with external hardware (Game Blaster card at an alternative address being applied master volume only).
Edit: I notice something odd though. The setup of the Sound Blaster Pro (not Pro 2!) reports the sound card as a Sound Blaster Pro 2 for some reason? The DSP version should be 3.00, so that's not a Pro 2? Various documentation I can find confirms that.
It's also the only command I see it executing during setup until that message appears?
Edit: I clearly see it executing just a DSP version command, which returns version 3.00. But the MS-DOS setup wizard still tells me it's detected a Pro 2 card?
Edit: Found a bug in the OPL2 chip emulation where the low status bits (lower 5 bits) were cleared. It's supposed to be reporting bits 1 and 2 set (according to Dosbox and 86box, just two emulators I cross-checked real quick). In this case looking at the code of the setup wizard that detects the sound card installed reads those ports and takes a different path if those aren't setup properly. Maybe that's the cause of the board being detected as a Pro 2 card?
Edit: Linux OPL2/3 drivers seem to agree?
https://android.googlesource.com/kernel/msm/+ … /opl3_lib.c#136
Edit: Fixing that, together with OPL2 left/right chip selection (for ports baseaddr+0 through baseaddr+3 as well as for port 388h/389h), the Sound Blaster Pro is now properly detected. 😁
Edit: Modified the Sound Blaster command/data registers to keep their own state seperated from the DMA modes. Thus it can always receive commands and send/receive data(parameters or actual data) on those ports. The DMA now keeps it's own track of it's active command, allowing pausing and resuming properly.
I did notice that before this improvement, Windows 9x seems to eventually halt DMA for some unknown reason (the halt DMA 8-bit Sound Blaster command), never receiving a continue or new DMA command it seems?
Edit: Fixed those issues. Now audio works fine in Windows 9x (also Doom 1/2 tested).
Only test-sbp.exe seems to oddly always crash on an ARPL instruction in real mode. So there's some weird CPU bug?
Edit: Went on the route of disassembling test-sbp.exe in much of it's entirety. Gotten most subroutines figured out already (the ones cerning the DSP and adlib at least). Just a small amount of functions left, but most seem to be some kind of text-parsing functions or data processing functions of some kind, which I don't know what they're doing. Also found various c-style functions too (figured they are memcmp, memcpy, strcpy, strcat) and duplicates of the sound blaster functions, but with a differently sourced I/O base port variable. One annoying thing is that it's assumed CS=DS, even though it can't because it seems to store code in some of the variable's storage locations.
