VOGONS

Common searches


Sierra/Dynamix sound driver hacking

Topic actions

Reply 20 of 324, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

MT-32 music with SB sfx seems to be working in QFG2 version 1.102 with the attached patch. I'll let those more familiar with the game than myself decide if it's fully working or not. Extract the archive into the game directory and make sure soundDrv=MTBLAST.DRV is in the RESOURCE.CFG file. If you subsequently want to switch to the MT32.DRV or SNDBLAST.DRV drivers then delete the separate SOUND.* files. I've increased the SB initialization timeout in MTBLAST.DRV to where there should be no problem at 10000 cycles and even higher, so I hope that resolves the speed issue.

Attachments

  • Filename
    qfg2_mtblast.zip
    File size
    128.24 KiB
    Downloads
    535 downloads
    File license
    Fair use/fair dealing exception

Reply 22 of 324, by tikalat

User metadata
Rank Member
Rank
Member

(MUNT) Okay with 1.104 + 1.105 (Anthology). I don't know if the other digital samples are re-recordings of the MT-32 ones?

Decided to play around with the broken driver some more (if I can't fix this, I'm not good enough for Krondor).

So added in polyphonic + channel aftertouch. Raised polyphony to 255. All unused by game but like HunterZ + collector mention - maybe some hobbyist can take advantage of them (I finally get it now).

The init detection problem looks to be in the SB IRQ wait routine:

(broken QFG2 merged driver)

xor cx, cx
mov dh, 49h ; 'I'
call sub_2108
mov dx, cs:word_54
add dx, 0Ch
mov al, 40h ; '@'
call sub_1FC0
mov al, 64h ; 'd'
call sub_1FC0
mov al, 14h
call sub_1FC0
xor al, al
call sub_1FC0
xor al, al
call sub_1FC0
xor ax, ax
mov cx, 200h

loc_209F: ; CODE XREF: sub_203E+69j
; sblaster fix!!
hlt


cmp cs:byte_56, 0
jnz short loc_20AC
loop loc_209F
mov ax, 3

Note: SCI0 uses the hlt too. Wonder why they took it out later. 😕

At 32000 cycles, I didn't have an init problem. Left the default code times alone. I should raise all the default loop times too though like ripsaw8080.

The GMBLAST.doc is really helpful. Read it over again and caught a missing IRQ handler address (remapping...).

edit:
Attached is a working QFG2-only merged driver. Plus ripsaw8080's sound files. With source and notes.

Note that there could be a problem with the current hacked resource files - the 1st track is always for Adlib. Replacing it with MT-32 device ID may accidentally use the Adlib MIDI channels + instrument programs.

I'm not sure though - don't know what happens when the interpreter sees two identical device tracks. 😮

But the digital works like ripsaw8080 promises. 😉

edit2:
Re-added 255 polyphony again.

edit3:
It's not a problem - interpreter just uses the first $0c track info. But since each sound resource only holds music or sound effect, there's no conflict.

Attachments

  • Filename
    QFG2 MTBLAST.7z
    File size
    276.04 KiB
    Downloads
    541 downloads
    File license
    Fair use/fair dealing exception

Reply 23 of 324, by collector

User metadata
Rank l33t
Rank
l33t

Thanks, that works. Not to sound ungrateful, but is there no way to get it to work with the game's unaltered SOUND resources? I have been requested to add MT-32/Munt support into my installers, so I am looking at this from that viewpoint. While I could use the hacked SOUND resources with an installer, I prefer to include as little game data as possible for distribution. The Sierra MTBLAST.DRV was an after market driver file that did not require modification of the SOUND resources.

tikalat wrote:
Note that there could be a problem with the current hacked resource files - the 1st track is always for Adlib. Replacing it with […]
Show full quote

Note that there could be a problem with the current hacked resource files - the 1st track is always for Adlib. Replacing it with MT-32 device ID may accidentally use the Adlib MIDI channels + instrument programs.

I'm not sure though - don't know what happens when the interpreter sees two identical device tracks. 😮

edit3:
It's not a problem - interpreter just uses the first $0c track info. But since each sound resource only holds music or sound effect, there's no conflict.

The way that the SCI interpreter uses resources is to look in its own folder to see if the resource it needs exists there, first. If it does not find it, it will check the MAP file to see where to find it in the RESOURCE.0** archives. The reason for this is so that Sierra could distribute patches that could be simply dropped in the game's folder to override the original. If you notice, many of QfG's resources have multiple copies of its resources as the early SCI games were designed to be able to be played without a hard drive. The resources were spanned over several disks, so some resources were packed in more than one RESOURCE.00* file to minimize disk swapping.

A limitation with SCI0 games is that it can only play one sound resource at a time. This does not seem to be the case with QfG2, but it is an SCI0.1 game. However, a single SOUND file can and often does include MT-32/AdLib variants of the sound effect over the digital sample. The genii laugh in the intro of QfG also includes an MT-32 version of the laugh and empty ones for AdLib and Tandy.

Reply 24 of 324, by tikalat

User metadata
Rank Member
Rank
Member

Okay. I can follow that SCI file lookup logic.

A limitation with SCI0 games is that it can only play one sound resource at a time. This does not seem to be the case with QfG2, but it is an SCI0.1 game. However, a single SOUND file can and often does include MT-32/AdLib variants of the sound effect over the digital sample. The genii laugh in the intro of QfG also includes an MT-32 version of the laugh and empty ones for AdLib and Tandy.

So if the driver can't find the digital track flag, it plays the MIDI synth version. Alright I see where you're going with this.

Thanks, that works. Not to sound ungrateful, but is there no way to get it to work with the game's unaltered SOUND resources? While I could use the hacked SOUND resources with an installer, I prefer to include as little game data as possible for distribution.

You could run an external tool that unpacks. Run another tool that applies the patches. Then move the files to game dir.

The actual patches won't need game data (in this case).

I don't think there's a practical way to trick the game into playing the digital and MT-32 music, given the way all the track ID tags are structured. Hacking / distributing the exe would be worse.

I'll give it some more thought first. I'm looking at the Krondor bit-unpacking algorithm and for me it's a ballbuster.

Reply 25 of 324, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
collector wrote:

The Sierra MTBLAST.DRV was an after market driver file that did not require modification of the SOUND resources.

In which games was only the driver added later? It may be instructive to learn if something different is happening in the case of those particular games. Perhaps the interpreter already had latent ability to internally translate ID 0x06 into music=0x0c sfx=0x00, which seems feasible.

Reply 26 of 324, by tikalat

User metadata
Rank Member
Rank
Member

Note:
Using QFG2 Anthology 1.105, tried both device ID 0c + 06 with untouched sound resources. Game does not call LoadSample, PlaySample, StopSample driver routines. There's no way to force them from the driver side.

Don't see anything else to try other than hacking the exe. 1.102 = 1.105 sciv.exe (and they're both LZ91 compressed requiring a tool for that one).

Reply 27 of 324, by collector

User metadata
Rank l33t
Rank
l33t

I'll have go through my games to come up with a list. Off hand, KQ1SCI and I believe SQ3 come to mind.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 28 of 324, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

The SNDBLAST.DRV and MTBLAST.DRV included with your installers for SQ3 are interesting. It seems unlikely that Sierra would offer drivers using an extra segment register only available on 386 and later, so maybe a fan-made creation? The drivers work in KQ1 SCI, but crash in QFG2 because of incompatible driver function numbering. Perhaps MusicallyInspired will recall the origin of these other drivers, and if source code for them is available. In any case, the MTBLAST.DRV may be doing a runtime hack in the interpreter or some other trick that could be made to work for QFG2.

Reply 29 of 324, by tikalat

User metadata
Rank Member
Rank
Member

In any case, the MTBLAST.DRV may be doing a runtime hack in the interpreter or some other trick that could be made to work for QFG2.

Could be doable. Driver entry - check retf address. Then insert miracle code. Neat idea ripsaw8080. Must check installer driver

Would be useful for Krondor. Uses variant of SCI LZW (not solved). Had to grab run-time driver binaries. Then rebuild sx.ovl after fixing sndblast to work on fast cpus (ex. 60000+ cycles).

Game loads sndblast.drv (audblast) only when sb is picked. Then forces auto-loading of adlib driver.

Replacing adlib with gmidi gives _nothing_. Changing gmidi device to adlib (00) gives sb dma + adlib soundtrack. No extra gmidi polyphony.

Incredible. 😐

Reply 30 of 324, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I should have somewhere a lzw decoder that decompresses sci resources, but you can look at the one of scummvm as well of course.

Water flows down the stream
How to ask questions the smart way!

Reply 32 of 324, by tikalat

User metadata
Rank Member
Rank
Member

Forgot about scummvm. They have a Dynamix version with LZW + RLE compression:
http://wiki.scummvm.org/index.php/DGDS

That looks closer to what I'm seeing. Have to compare them more later. May also hack GoSierra to see what that does too. 😀

Checked out SQ3 driver - it's old SCI0. The same sound resource is passed to each driver. And that resource has digital track flags.
(see func_557 - jumps to 5AB = digital)

So each driver is allowed to process / ignore the PCM stuff. No special SCI1 MIDI track stuff we're seeing in QFG2. Don't see any interpreter hacking.

Note that the driver GetDeviceInfo = patch # + poly #. No device ID. Whoever wrote it though... doesn't look like Sierra stuff I'm used to. ^^

Something else I notice now:
http://sourceforge.net/tracker/?func=detail&a … 116&atid=418823

SQ3 driver is made to play all digital tracks. Including the low-res ones. Would need to hack this driver to only play for the speech sample for best experience.

Reply 33 of 324, by collector

User metadata
Rank l33t
Rank
l33t

The MTBLAST.DRV that is included with my installers came from Sierra's FTP. They had a number of aftermarket audio drivers. The GMBLAST.DRV is a fan made driver modeled after the Sierra MTBLAST.DRV. Maggio took the SB part of the driver and appended it onto the Sierra GENMIDI.DRV. There have been a few other fan made audio drivers, mostly by Ravi Iyengar, though most of his were intended for fan made SCI0 games.

I have a number of the aftermarket drivers here. Most of the official ones were just updated SB drivers to address the SB initialization bug.

Reply 34 of 324, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie
ripsaw8080 wrote:

The SNDBLAST.DRV and MTBLAST.DRV included with your installers for SQ3 are interesting. It seems unlikely that Sierra would offer drivers using an extra segment register only available on 386 and later, so maybe a fan-made creation?

Neither of these drivers came from Sierra's FTP - both were created by NewRisingSun. I take it no-one noticed that the FM output is in stereo (on supported cards)?

Reply 35 of 324, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Sierra targeted 8088/8086 for SCI0 games, so you wouldn't see a driver they made using the FS register. The NRS drivers seem to work well enough on SQ3, but have glitches on KQ1 SCI, such as the first time you open the door of the witch's house there is a couple of seconds of ear-grinding noise at the end of the sample, but every time after the first seems fine.

From what I understand, some of the PCM sfx are low-quality samples of MT-32 sounds, so using them with MTBLAST.DRV is not an improvement over a real MT-32 or MUNT. The QFG2 patch as it is now should probably cherry-pick the "desirable" SOUND.XXX replacement sounds, such as the genie laugh. Would have to go through and listen to all of the samples, but could be a somewhat subjective process of selection...

Reply 36 of 324, by tikalat

User metadata
Rank Member
Rank
Member

Neither of these drivers came from Sierra's FTP - both were created by NewRisingSun. I take it no-one noticed that the FM output is in stereo (on supported cards)?

That would explain why they're so small and optimized. And pristine and clean. With some hard stuff to follow. 🤣
(the techniques do resemble that of his SQ5 drivers) :approving:

Improvement stuff that's out-of-my-league.

Not so sure I'm going to touch his SQ3 work now though - he is around at VOGONS. The driver does use the 'low-res' replacements (debugger confirms SB DMA) but I think it should be his call what he wants to do with his work.

The QFG2 patch as it is now should probably cherry-pick the "desirable" SOUND.XXX replacement sounds, such as the genie laugh. Would have to go through and listen to all of the samples, but could be a somewhat subjective process of selection...

I found the interpreter code that runs through the device ID tracks. Should be able to insert some injection code that lets the driver do all the dirty hacky stuff. Use your idea of patching the Adlib ID for digital-tracks only.

I don't have the QA ears to pick-and-choose though.

Unless of course, NewRisingSun wants to take over or surprise us with some of his coding magic.

Reply 37 of 324, by tikalat

User metadata
Rank Member
Rank
Member

Here's a new version:
1- Generic SCI01 MTBLAST driver
2- QFG2 special driver (plays all digital sounds)

#2 hacks the interpreter to play the SB PCM
#1 no longer includes external sound files. Provided for reference only.

Both have 255 poly, control codes $A0 + $D0 added

We're getting there. 😉

edit:
I'm assuming they didn't change the code much between 1.000 and 1.102? (don't have that version to check sciv.exe)

edit2:
The prescence of any unique MT-32 sounds could give more insight to what's synth vs digital. SQ3 has a good chunk of them - have to use SCI viewer to see how they map up

Attachments

  • Filename
    QFG2_MTBLAST.7z
    File size
    159.97 KiB
    Downloads
    490 downloads
    File license
    Fair use/fair dealing exception
Last edited by tikalat on 2013-07-14, 01:27. Edited 1 time in total.