I don't have any ESS based card at the moment but I happened to find just recently Terratec 16/96 on ebay. It hasn't arrived yet. I was hoping that ESS would be the one without any issues but I suppose that was too much to hope for. Every chip seems to have some sort of issue. But at least on this case it is really good if ESS has separate volume for waveblaster connector. That is a big plus.
MIDIto already prevents mixer reset command and it will restore all volumes by itself to the levels stored when MIDIto was loaded. The problem is that Gabriel Knight is a protected mode game and port trapping does not work on protected mode games. MIDIto can restore the volume levels when returning back to DOS even if the game was a protected mode game. But in this case, since the ESS is SBPRO compatible with DSP 3.xx, it will restore the standard SB Pro volumes. For SB16/32/AWE volume registers 30h-47h will also be restored. I can and will add the ESS AuxB to the list of volume registers to be restored.
But for Gabriel Knight it won't help. Midi stays silent, unless for some reason it resets the mixer before entering protected mode. But at least the volume could be restored when the game quits. I don't know if it is possible to use RTC interrupt, for example, and try to restore volumes from interrupt handler when the game is running. I don't know if the protected mode extender would allow that or not. I can try to experiment with that later.
I don't have any ESS based card at the moment but I happened to find just recently Terratec 16/96 on ebay. It hasn't arrived yet. I was hoping that ESS would be the one without any issues but I suppose that was too much to hope for. Every chip seems to have some sort of issue. But at least on this case it is really good if ESS has separate volume for waveblaster connector. That is a big plus.
MIDIto already prevents mixer reset command and it will restore all volumes by itself to the levels stored when MIDIto was loaded. The problem is that Gabriel Knight is a protected mode game and port trapping does not work on protected mode games. MIDIto can restore the volume levels when returning back to DOS even if the game was a protected mode game. But in this case, since the ESS is SBPRO compatible with DSP 3.xx, it will restore the standard SB Pro volumes. For SB16/32/AWE volume registers 30h-47h will also be restored. I can and will add the ESS AuxB to the list of volume registers to be restored.
But for Gabriel Knight it won't help. Midi stays silent, unless for some reason it resets the mixer before entering protected mode. But at least the volume could be restored when the game quits. I don't know if it is possible to use RTC interrupt, for example, and try to restore volumes from interrupt handler when the game is running. I don't know if the protected mode extender would allow that or not. I can try to experiment with that later.
OK, thanks for the explanation. I have another idea that can help but I do not know if you want to change the workflow of your TSR this way. Namely adding a hotkey that can restore the original stored mixer settings while a game is running. So your TSR would also install a keyboard interrupt handler and the hotkey would restore the original mixer values every time you press the hotkey. Just and idea. In theory this should work also with protected mode games since does not require any port trapping.
Thanks.
Hotkey would work if the game hooks keyboard interrupt properly. But I'm sure some just capture keyboard completely. But support for hotkeys could be added eventually.
After writing my last reply I though of much better way than using RTC or any other timer interrupts. To hook INT 13h instead. Basically that would mean mixer settings could be checked and restored every time game accesses hard disk. So mixer restore would be done during game loading times. And even better, there is idle interrupt that the BIOS calls when waiting hard disk IRQ (seek time before data transfer can begin). It is not always available but when it is, the mixer checking and restoring could basically be done without any performance penalty at all. And it should work with protected mode games.
Release 8 is now ready! I wanted to get this ready before Christmas. I hope this is not too rushed release.
So here are the changes:
* Added INT 13h handler to mixer locking. This allows limited protected mode
support (volumes are restored when reading data from hard disk).
* Added ESS detection (at least for ES18xx models, not sure about ES16xx and
ES17xx) and support for AuxB (MIDI) volume
* Added -dsp command line parameter for SB16/32/AWE DSP fixes (Sound Blaster Pro
support etc.)
The INT 13h handler is very basic and has room for improvements if it turns out to be useful. It can be disabled if it gives problems (specify NO13 to mixer locks). The ESS 18xx is now detected and AuxB lock is added to default locks. I did not find proper datasheets for ESS 16xx and 17xx but if they are similiar to 18xx then they should be supported as well. 19xx is not supported so mixer locking works just like on any other SB Pro compatible card.
But the most important feature (and perhaps most unimportant feature at the same time) is the new -dsp command line parameter. It will fix Sound Blaster Pro support for SB16/32/AWE among other small fixes. Like Turn on speaker and Turn off speaker commands are fixed by setting voice volume to zero and then restoring it back to normal.
aitotatwrote on 2021-12-23, 13:44:Release 8 is now ready! I wanted to get this ready before Christmas. I hope this is not too rushed release. […] Show full quote
Release 8 is now ready! I wanted to get this ready before Christmas. I hope this is not too rushed release.
So here are the changes:
* Added INT 13h handler to mixer locking. This allows limited protected mode
support (volumes are restored when reading data from hard disk).
* Added ESS detection (at least for ES18xx models, not sure about ES16xx and
ES17xx) and support for AuxB (MIDI) volume
* Added -dsp command line parameter for SB16/32/AWE DSP fixes (Sound Blaster Pro
support etc.)
The INT 13h handler is very basic and has room for improvements if it turns out to be useful. It can be disabled if it gives problems (specify NO13 to mixer locks). The ESS 18xx is now detected and AuxB lock is added to default locks. I did not find proper datasheets for ESS 16xx and 17xx but if they are similiar to 18xx then they should be supported as well. 19xx is not supported so mixer locking works just like on any other SB Pro compatible card.
But the most important feature (and perhaps most unimportant feature at the same time) is the new -dsp command line parameter. It will fix Sound Blaster Pro support for SB16/32/AWE among other small fixes. Like Turn on speaker and Turn off speaker commands are fixed by setting voice volume to zero and then restoring it back to normal.
Merry Christmas to everyone!
Hi,
Thanks for the update. And Merry Christmas to you also!
I would like to report that this version successfully fixed Gabriel Knight 1 muted Midi/AuxB problem on (at least) ESS 1868.
Thanks again.
Release 9 is now ready. No new features this time. Just some fixes and improvements to the INT 13h handler. Now the INT 13h handler restores locked volumes only and once per 64kB of data read.
But I have something else as well: FIXYMF. It is the Yamaha YMF71x fix from MIDIto separated to fixymf.com. It is supposed to be executed just after unisound and that is all. Nothing needs to be configured. It uses the same SET BLASTER string as unisound so the R### must be set if some other control port is used. FIXYMF can be used with other initialization programs as well but the R### must be added to SET BLASTER string if control port is other than the default 370h.
FIXYMF does not require EMM386 or QEMM and it also works even on 8088 (I don't know if the cards work on 8-bit slot) so FIXYMF is a very good alternative if EMM/QEMM cannot be used. Of course there is no mixer locking so if game messes with master volume, then the fix no longer works. Also you cannot use FIXYMF and YMF lock from MIDIto at the same time. FIXYMF and MIDIto can be used at the same time but you need to use locks just like with any other SB Pro compatible, without the YMF lock.
Make the mapping range four didgit so it also can map into the PCI I/O range. Some PCI sound cards can have their MPU-401 interface accessed that way without even initializing the card, see the spreadsheet in my signature for sound cards that allow this.
To expand on that idea, could you perhaps also add the option to redirect Adlib ports 388h and 389h to specified ports in the PCI I/O range, so the PCI cards in Kamerat's spreadsheet that can expose their Adlib/OPL3 capability in that higher port range can be made to work in real mode games, even on newer motherboards that don't support subtractive decode?
I know at that point it really broadens the scope of the tool, since it was initially just meant for MPU-401 MIDI redirection, but why stop there? 🙂
I'm already planning OPL redirect for next version so hopefully it will help with PCI cards as well.
I've been trying to avoid PCI sound cards on DOS so I have very little experience with them. I'm wondering how much port redirection will help. If PCI I/O range has the OPL ports available it might not be enough since most likely the PCI card is mute until it is initialized with DOS drivers. And those same DOS drivers should make the OPL available from Sound Blaster and Adlib addresses.
PCI OPL would be useful if there is only one ISA slot on the system and, for example, AWE64 installed to it. Then the real (or better than CQM) PCI OPL could be mapped to Sound Blaster and Adlib addresses to get best of both. But the PCI card would have to be initialized as a second Sound Blaster so it would be essentially just like two ISA cards.
Or is there something about PCI sound cards that I should know?
I'm trying to think what is needed from the OPL redirecting feature and here are some things. I haven't started yet so nothing is set. There are much more things to consider than just map one OPL over another.
First, what kinds of multi sound card configurations you might have and why is the OPL redirecting useful?
Configuration 1:
You have AWE64 (or just any otherwise good card but with bad OPL) as your primary card (SET BLASTER in autoexec.bat points to that card). Then you have a good SB pro compatible or maybe even a real SB Pro 2 to compensate for the weaknesses of the AWE64. That would mean the second card would provide better OPL3 (or MPU401 but that is not needed here).
So configuration 1 is AWE64 + sbpro compatible with good OPL. I think this configuration is the most common (and I use it as well).
Configuration 2:
As configuration 1 but you also have Sound Blaster 2.0 or clone. Basically you have this card for CMS but it also has a real OPL2 that could be used for Adlib support.
Configuration 3:
You have AWE64 and some OPL3 card that is not Sound Blaster pro compatible (like PAS16 or Adlib Gold). This configuration needs to be handled differently than configuration 1 as you will soon see.
Configuration 4:
Like configuration 1 but you have a second sbpro compatible card as well! But why? So you could choose between CQM, ESFM and real OPL3, for example.
Configuration 5:
Configuration 3 plus Sound Blaster 2.0 or clone. One more to choose from but no Sound Blaster pro mixer.
And some configurations that I can forget or can be handled with some of the above:
Configuration 6:
AWE64 + Sound Blaster 2.0 or clone. You might want the SB2.0 for CMS and Adlib. And you likely have already configured AWE64 with unisound so that Sound Blaster address space plays CQM (OPL3) and Adlib address space plays OPL2. You don't need MIDIto here except for the Game Blaster detection chip emulation.
Configuration 7:
AWE64 + sb pro compatible OPL3 card + non sb pro compatible OPL3 card. Essentially the same as configuration 1 or 4
Configuration 8:
AWE64 + two non sb pro compatible OPL3 cards. Anyone actually has a setup like this? Essentially the same as configuration 5
Configuration 9:
AWE64 + real Sound Blaster pro 1. Like configuration 6. You most likely have it already set so that MIDIto is not needed at all.
So we can simplify all above to a three different scenarios:
A: AWE64 + Sound Blaster Pro with good OPL3
B: AWE64 + good OPL (2 or 3) card that does not have Sound Blaster pro mixer
(C: A + B so we can forget it. Supporting the A and B will also cover C)
I'm going to remove the -a command line parameter and merge it with the new -fm parameter. How should it work? This is what I have in mind:
Map to Adlib and SB address space (from SET BLASTER=A###):
1-fm=a240 ; Use OPL from address 240h with LIN mixer 2-fm=a240m ; Use OPL from address 240h with SB pro compatible mixer from 240h 3-fm=a240x ; Use OPL from address 240h without any mixer support 4 5-fm=a388,d##### ; Use OPL from address 388h with LIN mixer and use delay of ##### jumps 6-fm=a240m,d ; Use OPL from address 240h with SB pro compatible mixer from 240h and use minimum delay 7-fm=a388x,d1 ; Use OPL from address 388h without any mixer support and use delay with one jump (external mixer) 8 9-fma= ; Like above but maps only to Adlib address space of 388h and not to Sound Blaster address space 10-fmsb= ; Maps only to Sound Blaster address space and not to Adlib address space
Dual OPL support:
1-fm=ar240 ; Use OPL from SET BLASTER=A### as left OPL and OPL from 240h as right OPL connected to LIN 2-fm=ar240m ; As above but use FM mixer from 240h for right OPL 3-fm=ar240x ; x should not be used with dual OPL mode 4 5-fm=ar388,d ; Use 388h as right OPL connected to LIN and use minimal delay for BOTH OPLs 6 7-fm=al240m,ar260m ; Use OPL at 240h as left OPL and OPL at 260 as right OPL. Both have SBpro compatible mixer so use it 8-fm=al240,ar260m ; Use OPL at 240h as left OPL connected to LIN and OPL at 260h as right OPL with SBpro mixer 9-fm=al240,ar260m,d ; Same as above but delay for BOTH OPLs
What plays from Adlib address space? Both by default but that can be changed from Sound Blaster Pro 1 mixer register 06h that needs to be emulated in the dual OPL mode. (Actually I'm not quite sure how it behaves but I do have CT1330A to test with)
To disable OPLs:
1-fma=off ; Disable OPL at Adlib address space (to force CMS detection without -cms flag) 2-fmsb=off ; Disable OPL at Sound Blaster address space (never needed?) 3-fm=off ; Disable OPL completely (never needed?)
So the Sound Blaster pro mixer is handy because it means there is no need to connect the other card to AWE64 Line-IN. So external mixers can be easily used but are not necessary. When connected to AWE64 Line-IN, the LIN volume will be used to control FM volume.
Did I forget anything? Are the command line parameters easy enough?
I've been trying to avoid PCI sound cards on DOS so I have very little experience with them. I'm wondering how much port redirection will help. If PCI I/O range has the OPL ports available it might not be enough since most likely the PCI card is mute until it is initialized with DOS drivers. And those same DOS drivers should make the OPL available from Sound Blaster and Adlib addresses.
It would be interesting to mimic the dual-OPL2 behavior due to the way how they are initialized even though the main idea was about port redirection. There is one game called Sardonic that uses the dual-OPL2 chips found on the SBPro1 for the title music and one can notice the stereo separation which doesn't work on OPL3 compatible chips.
The other is from Ultima Underworld that supports dual OPL2. The other is from Prince of persia supporting single OPL2.
The interesting thing about them is that left channel is played with AWE64 (CQM) and right channel if played with Yamaha YMF71x (real OPL3) with 20% stereo mix to smooth the differences a little. Sounds promising but the biggest problem is to get both volumes to the same level. That needs to be done manually.
Another thing to note is that there seems to be little reverb on Prince of Persia sample. Maybe it is the differences between CQM and OPL, or maybe the other have slightly more internal delay. But that is not a big problem, the dual OPL mode is of course meant for games actually supporting dual OPL.
The other is from Ultima Underworld that supports dual OPL2. The other is from Prince of persia supporting single OPL2.
The interesting thing about them is that left channel is played with AWE64 (CQM) and right channel if played with Yamaha YMF71x (real OPL3) with 20% stereo mix to smooth the differences a little. Sounds promising but the biggest problem is to get both volumes to the same level. That needs to be done manually.
Another thing to note is that there seems to be little reverb on Prince of Persia sample. Maybe it is the differences between CQM and OPL, or maybe the other have slightly more internal delay. But that is not a big problem, the dual OPL mode is of course meant for games actually supporting dual OPL.
Nice dual OPL mode playback emulation!
Speaking of the reverberation effect on Prince of Persia, did you set any reverb or chorus value when initializing the AWE64 card thru AWEUTIL? This affects the FM synth playback on that card.
No reverb or chorus was added to AWE64. I need to test with two same kind of cards. If the reverb was caused by differences between CQM and OPL3, then it might be possible to fix it with software delay loop. Another alternative is that it was caused by EMM386. I don't know how directly it outputs data from port trap code.
I made one more recording (same link as before). This time from Cycles (Adlib game) but now CT2940 with real OPL3 plays left and YMF right channel. Sounds much better than the CQM+YMF combo. YMF does have little lower volume than the CT2940. It is very hard to adjust them to be equal.
I made one more recording (same link as before). This time from Cycles (Adlib game) but now CT2940 with real OPL3 plays left and YMF right channel. Sounds much better than the CQM+YMF combo. YMF does have little lower volume than the CT2940. It is very hard to adjust them to be equal.
Due to varying components used on sound cards even real OPL3 can sound slightly different. It can be bassy like on a real SBPro2 or quieter like most later ISA sound cards.
MIDIto release 10 is now ready! There is no control to level the differences between different types of OPL chips but I'll experiment on that for next release.
Release 10 is mostly about FM redirection and related things but there is one Midi related change: when redirecting midi you now have to use "-midi=a300" instead of just "300" like on previous release. This change is done so midi and FM ports would be defined in the same way. Also the -midi command line parameter allows other things to be implemented later (like IRQ redirection).
-fm and related FM redirection command line parameters are much more complicated than I would like them to be. But they allow a lot of different types of configurations so the complexity cannot be avoided. See the readme for more documentation. But here is a quick guide for most common use cases. I suppose the most usual use case would be to map Yamaha OPL3 from some other card to replace CQM from some otherwise good Creative card (likely AWE64).
So if your Sound Blaster (SET BLASTER in autoexec.bat points to it) is at port 220h and the OPL3 card is at 240h, then you would do one of these:
1-fm=a240 2-fm=a240l 3-fm=a240x
What is the difference? First one maps FM mixer from SET BLASTER card to FM mixer to the card at 240h. So it must be Sound Blaster Pro compatible. The middle one, the one with 'L', maps FM mixer to Line-IN mixer. So you must connect the card at 240h to SET BLASTER cards Line-IN. Good thing about the Line-IN solution is that the OPL3 card at 240h does not have to be Sound Blaster Pro compatible (but then the 240h must point to OPL3 address and it might not always be the same as card base address). The last one, with 'X', simply ignores FM mixer. Any FM volume change to SET BLASTER card is simply ignored (but it does program the SET BLASTER cards now unused OPL).
If the destination card has OPL2 instead of OPL3, then use the -fm2 parameter. It maps the OPL2 only to OPL2 addresses and leaves the OPL3 adresses for the SET BLASTER cards OPL3. Also you need to make sure to use OPL2 address, like 388 or 2x8 since OPL2 is not located at Sound Blaster base address like OPL3.
Setting up the dual OPL emulation is not harder at all. If SET BLASTER card is used for the left channel, then just do either of these:
1-fmr=a240 2-fmr=a240l
You can speficy stereo mix with 'M'. The below would use 25% stereo mix:
1-fmr=a240l,m25
Note that Sound Blaster pro has 3-bit mixer and it does not have enough resolution for any miracles. SB16 has 5-bit mixer and that is a lot better but both of the cards must be SB16 compatible unless you use the Line-IN mode and the SET BLASTER card is SB16. You cannot use 'X' since dual OPL requires mixer for panning effects.
OPL delays can be specified like the stereo mix but with 'D'. The below will map OPL2 from card at 240h (note that OPL2 is at 248h) with no mixer and 3 jumps of delay.
The dual OPL emulation works nicely on my SBPro2 + AWE64 setup. 👍
I suggest adding a new parameter to set which SB address will be used to manage the line-in mixer because the BLASTER environment variable on my main old computer is set for the SBPro2 and said card is connected to the AWE64 line-in. I can change the BLASTER environment variable temporarily but I prefer a more convenient way for this.
Another note is that games using dual OPL2 only works fine as long as I don't use the l or x parameter after setting the address for the left/right FM synth.
