MaliceX wrote:

Progress update on SAPI! patch retrieval, here's a rundown (using SAPI.COM): - need to work out correspondence of C0, E0 and ma […]
Show full quote

Progress update on SAPI! patch retrieval, here's a rundown (using SAPI.COM):
- need to work out correspondence of C0, E0 and maybe BD registers
- melodic patches begin at 0x0A
- All patches are 2x2op (no modulation between channel pairs, only additive)
- Instrument register bye order: 20, 40, 60, 80, ??, 23, 43, 63, 83, ?? ??. 20*, 40*, 60*, 80*, ??*, 23*, 43*, 63*, 83*, ??*, ??*, ??*, ??*, ??*, ??* (those denoted * are second port)
- 0x19 (25 byte) instruments
- Percussion is all 2op with a slightly different byte format order (TBD)

Interestingly, the SAPI driver supports pitch bend range extension via RPN/Data Entry commands, as well as a number of other MIDI CC's. It would be nice if the Windows driver could use this.

I have the original installation disks from my '94 sb16, which includes the Super Sapi FM driver, and it does not match the driver that is available at soundshock. I've attached the disks to this message, just in case you've got the wrong data.

I'm a big fan of the way the Super Sapi patches sound. I used to compose with an old version of cakewalk and the Super Sapi general midi sounds. It would be great to be able to finally be able to get these sounds without having to fire up my old 90's era PC...

I'd extract the patches myself to help out, but I don't know the first thing about ymf262 programming. (And after re-reading your post above, I'm still unable to follow how you extracted the data.) How exactly did you do this?

This driver set is different from Voyetra's Super SAPI!, this is Creative's own implementation for the SB16 (I have this set already).

Basically, since DOSBOX emulates the SB16 and the drivers happen to be compatible, it was a matter of getting it to log the OPL playback output, then a process of retrieving the register writes (I work with the VGM format since there are utilities for that; there's a DRO2VGM converter which allows me to then use VGM2TXT to look at the commands in detail). Then it's just a matter of using a Hex editor (trial-and-error) to search for any patterns in what could look like fixed-length register data, and compare the values to the logs.

I'm waiting on someone to do a recording of a MIDI being played through an ESFM-based card, cause I may have already got the patch data from the driver, but at the moment there's no way to determine what is what without blindly guessing.

But at any rate, all of the above mentioned seemingly use 2x2op, so that's something I need to work out next in getting to work.

Anyway, a friend (ValleyBell) finished dissecting the unknowns for the SAPI! driver patch structure. http://vgm.mdscene.net/misc/SAPI_COM_Ins.txt (he's a much better reverse-engineer by far)

Hmm, the Windows SuperSAPI driver I posted came from an older Soundblaster 16 driver bundle. Sounded exactly like the DOS drivers and the SAPI driver that came with my old Packard Bell Aztech card.Its how I remembered it sounding 15 years ago. Creative's later driver bundles switched to the Microsoft reference driver, mostly on cards that came with the Creative Music Synthesizer clone chip.

MaliceX wrote:

Basically, since DOSBOX emulates the SB16 and the drivers happen to be compatible, it was a matter of getting it to log the OPL playback output, then a process of retrieving the register writes (I work with the VGM format since there are utilities for that; there's a DRO2VGM converter which allows me to then use VGM2TXT to look at the commands in detail). Then it's just a matter of using a Hex editor (trial-and-error) to search for any patterns in what could look like fixed-length register data, and compare the values to the logs.

Nice, the latest build shows up and works on Windows 7 x64.

leileilol wrote:

Nice, the latest build shows up and works on Windows 7 x64.

Yeah, it might have turned out it had something to do with the solution targeting a platform kit incompatible with XP so glad that's working now.

Can someone post the forked driver here? MDScene. net doesn't seem to be up at the moment.

I don't know what use these two IBKs have toward the fork. These are the Lee Jackson IBKs used in Rise of the Triad 1.1-1.2 (which were regressed in 1.3). Lots of undefined instruments, so probably best to merge in with fatman patches...

They're nabbed from the GPL source code release of ROTT, a few subfolders deep so not immediately noticable.

I think bisqwit's adlmidi already have mappings for those IBKs, in addition to Duke Nukem 3D and Doom, so I'm probably not going to bother with those. Once I get easy user-switchable patches happening, you can switch whatever the hell you want. I'll just need time to get the necessary utilities made which I'll be doing over the christmas summer holidays. I do plan on putting together my own bank as well, since there doesn't appear to be many percussion bank replacements.

Anyway, the alternative banks (fmsynth and maui) I've only attached because I wanted to see for myself what these IBKs from Jamie O'Connell's FMSynth (you can find it on www.midiox.com - win98 only though) driver sounded like, seeing as there appears to be nothing else that can use them.

Also, since mdscene is down (gofddamnit oerg866), consider this the main page until I open up my personal domain: https://bitbucket.org/djtubig-malicex/opl3-synth-driver

I tried loading the User mode driver in a Win98 virtual and it doesn't work. Is the driver not compatible with Win98?

MaliceX wrote:

I think bisqwit's adlmidi already have mappings for those IBKs, in addition to Duke Nukem 3D and Doom, so I'm probably not going to bother with those.

I tried Adlmidi, I couldn't find any mapping that sounds like ROTT.

valnar wrote:

I tried loading the User mode driver in a Win98 virtual and it doesn't work. Is the driver not compatible with Win98?

No. Also, use DOSBOX if you want to use emulated OPL3 in Win98.

MaliceX wrote:

valnar wrote:

I tried loading the User mode driver in a Win98 virtual and it doesn't work. Is the driver not compatible with Win98?

No. Also, use DOSBOX if you want to use emulated OPL3 in Win98.

Thanks... it wasn't that I wanted to run it actually in a virtual machine (VMware in this case), but that is what I used to test it. I'd love to run it on a real Windows 98 machine without a FM enabled sound card as that would be better for DOS games that have FM. If this only runs on NT kernel machines, I fail to see how it is of any use except for musicians. Is that the point?

The main issue is that there doesn't appear to be a compatible way of supporting Win98 WDM drivers without breaking forward compatibility with more common/recent Windows operating systems. One would need to create a new fork dedicated to function for WIn98. Additionally, most games that actaully use FM around that era would be using the card's OPL2/3 port address directly via DOS, which this driver can not support. The most you will get, is MIDI playback in FM, and that's it.

Hence why using DOSBOX is probably a more preferable option at this point, otherwise you will have better chances with getting an authentic ISA/PCI OPL3-compatible card for your real WIn98 machine (since drivers actually exist for them).

Before the year ends, although I haven't progressed with the 4op business, I can say there is an update to the forked OPL3 usermode driver.

• Fixed the sustain bug (hanging notes on repeated sustained notes should be gone now)
• Implemented CC126/127 (Mono/legato and Poly mode switches)
• Refactored note off functionality to also facilitate immediate note cut (functional dependency issues as well for sustain fix).
• Fixed percussion pitch offsets for maui and fmsynth. Some patches still sound off, as it turns out they were made for Rhythm mode channels which this currently does not use at all.
• Fixed long-release pitch bend behaviour

Grab it at the same place
Source: https://bitbucket.org/djtubig-malicex/opl3-synth-driver
Binary: https://dl.dropboxusercontent.com/u/1287967/opl3driver.rar
WinRT Binary: https://dl.dropboxusercontent.com/u/1287967/W … exe/opl3emu.dll (means of selecting MIDI device is exactly the same as Win8(.1) - for advanced users only.

MaliceX's original post wrote:

Just a small unrelated update. I have managed to get this usermode driver working on a jailbroken Windows RT (Microsoft Surface 1st gen tablet) with some minimal modifications to the source solution in VS2012. Unfortunately, due to registry differences in my investigation so far, since there is no means of MIDI playback out-of-the-box, I have resorted to using the WinRT build of DOSBOX to pass through MIDI playback with its MPU401 emulation.

Any owners of a jailbroken Surface RT interested in testing this, feel free to reply.

EDIT: Guys, check the first post of this topic. Seems khokh2001's made an update with a new OPL3 emulator core.

I'm freaked out by how this plays GAME12.HMP in Descent... It sounds just like the setup program almost.

EDIT: Crashes trying to play Duke2thm.mid

Faulting application name: winamp.exe, version: 5.5.7.2830, time stamp: 0x4b4e4d1e
Faulting module name: opl3emu.dll, version: 0.0.0.0, time stamp: 0x52c14260
Exception code: 0xc0000094
Fault offset: 0x00009648
Faulting process id: 0x5ec
Faulting application start time: 0x01cf08770c7161e5
Faulting application path: C:\Program Files (x86)\Winamp\winamp.exe
Faulting module path: C:\Windows\system32\opl3emu.dll
Report Id: 4b66d4ef-746a-11e3-89e2-d43d7e9147da

EDIT: Crashes on all the MID files I have that Bobby Prince made of Duke 2 except for Makecry.MID What's going on here...?

EDIT: DracoNihil, can you try this version and tell me if there are still any issues? That MIDI works for me with the current build.

Apologies for triple-posting. Another update:
Win32 Binary: https://dl.dropboxusercontent.com/u/1287967/opl3driver.rar

• 2x2op patch bank support. I've included a custom bank (selection of fatman+maui+random patches I like)
• ~EXPERIMENTAL~ CC72-74 support (attack, release, "brightness"). GM-2/XG compliant, but may not sound good with all patches among other known issues.
• XG-style Drum bank switching. May reserve this behaviour once I get SysEx reset handled.

Given the changes in note allocation behaviour to facilitate 2x2op, I need to investigate a few issues with regards to polyphony note stealing. If anyone would like to assist or otherwise report their test music, it would be much appreciated.

Likewise, I would also recommend posting issues here:
https://bitbucket.org/djtubig-malicex/opl3-sy … h-driver/issues

It's working fine now! I wonder what was causing the division by zero though?

DracoNihil wrote:

It's working fine now! I wonder what was causing the division by zero though?

Caused by me not programming unfinished features defensively enough. 😢

Having said that, although it's not perfect yet, I am one step closer to getting those 2x2op banks from Creative, Voyetra, and Roland, onto this thing. Chances are, certain features like voice detune, are gonna need to be implemented later. 😖

I'm noticing (though this could be Winamp's fault) that when some MID files loop, the patches become totally screwed and turned into drum tracks (mostly fixed by setting the bank MSB to something then back to 0, I actually had this happen to a few soundfont's too funnily enough) in addition, the polyphony starts getting eaten up. I don't suppose this is the polyphony note stealing bug you're mentioning?