I played the 1.0 floppy. Hit a bug towards the end of ch3 that locked me out from finishing it.

Spoilers:
-Couldn't talk to the priest about mortification
-Couldn't find the girl after the 1st talk to learn about the book(

Wasted days before switching to the CD and starting over. That version is very good regarding bugs (only hit 2, with narrative text not pausing before I could read them).

As a side-note, ch8 BGM uses 2 GS (SC-55) percussion instruments that I'm reasonably sure the MT-32 didn't include in its SysEx patch banks. It's pretty minor though - the MT-32 mapped some other drum replacement I think.

I thought the same thing - hoping to make a unified SBMIDI driver. Being a rookie, I'm pretty sure that the sx.ovl (where I suspect the driver code sits) is compressed. Ugh. But otherwise it looks to be standard Sierra stuff (RAM disasm).

I'm actually interested in QFG2 'MTBLAST' also. Having torn apart a few Sierra MIDI sound files, I've got a decent idea how those drivers work. Hoping to start a merger soon since I've got my tools + time ready.

Not to get too off-topic, but:

I had come across a dummy SCI0 driver assembly source code (QfG2 is actually SCI01 though which may be slightly different).

I was also looking at disassembly of one of the QfG2 drivers (SB or MT-32, don't remember which). It generally works by having a jump table that allows the game to call different functions (like initialize, play a sound, etc.). I was hoping to basically replace the OPL init and OPL music playback code of the SB driver with the code from the MT-32 driver, but I had only gotten as far as locating most of the functions and annotating a little here and there when I could tell what was going on.

I wonder if it would be better to find an SC0 or SC1 MTBLAST driver and try to adapt it to work with QfG2?

I was looking into it too, after you brought it up on SHP. You can't approach it the same way Maggio did for his GMBLAST.DRV, which was to pull the SB part of the Sierra MTBLAST.DRV to append it onto the Sierra GM.DRV. The SNDBLAST.DRV driver that it was based on will lockup QfG2 on initialization. You would probably need to start with the MT32.DRV and SNDBLAST.DRV drivers that shipped with the game and do it from scratch.

Speaking of which, tikalat was messing around with some of the Sierra sound drivers, but has since deleted a lot of the post. Sierra sound driver hacking

collector wrote:

I was looking into it too, after you brought it up on SHP. You can't approach it the same way Maggio did for his GMBLAST.DRV, which was to pull the SB part of the Sierra MTBLAST.DRV to append it onto the Sierra GM.DRV. The SNDBLAST.DRV driver that it was based on will lockup QfG2 on initialization. You would probably need to start with the MT32.DRV and SNDBLAST.DRV drivers that shipped with the game and do it from scratch.

Figures. That was my original plan though.

Speaking of which, tikalat was messing around with some of the Sierra sound drivers, but has since deleted a lot of the post. Sierra sound driver hacking

Ah, I saw that a while back but didn't realize it was tikalat. He PM'd me today to say he was going to look at the QfG2 drivers, so I offered moral support 😀

HunterZ wrote:

he was going to look at the QfG2 drivers, so I offered moral support 😀

Great! This is something I would be very interested in, too. Let me know if he gets somewhere. Maggio's information may prove somewhat useful to him.

Talked a good deal with NewRisingSun about Sierra drivers in general. I messed everything up and made some poor assumptions.

Felt like I had to delete that info - misleading people. 🙁

He did give me a -new- package though which fixes up some sound problems I've never heard of (lol). But it only works on a real SC-55 (not mkII or higher) - SQ5 uses capital tone fallback.

I didn't ask whether I could openly distribute his new files though. When I have the 1st QFG2 draft ready (broken or working), HunterZ can check it over. And it will later be public released with full source + notes. 😉

I've seen Krondor driver use Sierra Roland MPU 1.08 - there's my thread tie-in. :p

I noticed that MT32.DRV in QFG2 and SQ4 are very similar, so after finding the important differences I was able to modify the SQ4 driver to work in QFG2. This told me what changes need to be made in the MTBLAST.DRV from SQ4 to make it work in QFG2.

The init subroutine of the SCI sound drivers return what I call a "device resource" value in the CH register. MTBLAST.DRV has 0x06 for this value, and it produces no sound at all in QFG2. If I change the value to 0x0c like MT32.DRV then MTBLAST.DRV plays the music correctly on the MT-32 but with sfx also from the MT-32. If I change the value to 0x00 like SNDBLAST.DRV then MTBLAST.DRV plays the music INcorrectly (wrong instruments, missing notes) but the SB sfx are played correctly. I think the music is messed up with 0x00 because SB music resource data is being played as if it was MT-32 music resource data.

I can't draw any firm conclusions from this tinkering, because I don't fully understand how the interpreter feeds sound resource data to the sound driver, but it suggests that sfx cues are embedded in device-specific resource data. If that's true, you'd have to create separate device resource data (number 0x06) representing the MT-32 music sequences with SB sfx cues instead of MT-32 sfx cues.

Starting to make sense now. 😀

I've been using this to extract the non-SCI0 MIDI files from the resource files (WIP stuff)
http://www.sendspace.com/file/uua882
- Place your QFG2 resource files with programs
- Run batch file
- Run midi_parse

It looks something like this:

1sound.012.txt
2
3Track 0 = Adlib / Soundblaster
4- Play parts = 3
5
6Track 9 = CMS Gameblaster
7- Play parts = 1
8
9Track 12 = MT-32
10- Play parts = 1
11
12Track 19 = Tandy
13- Play parts = 2
14
15..
16..
17
18
19Play part 5
20- Soundblaster (Adlib doesn't have PlaySample)
21- Tandy
22
23
24Header bytes
25[0003D1]  FE 00 
26- Frequency = 5000
27- *** Digital PCM!!

The rest is basically what ripsaw8080 said. 😉
- We (community) could create a tool to add new $06 MTBLAST info to all affected tracks. Then load them externally like NRS's patches.
(at least I think so)

The Adlib patch data is different from the MT-32. And the drivers are written to account for them. So that may be where the messed up notes come from.

ripsaw8080 is right about modifying the sound resource. Made a merged QFG2 MT-32 + Soundblaster MTBLAST driver (needs fixing).

Hacked sound.754 to play genie laugh on MT-32 (and not Soundblaster). I get MT-32 music. Then MT-32 sound effects. Then the 'digital' laugh (kinda muted compared to MT-32 volume) (debugger confirms SB DMA). Then the driver breaks. 😀

Here's the modified MTBLAST.DRV from SQ4. Testing with QFG2 version 1.102 it doesn't lock up or crash, but as described in my previous comment, it won't produce any sound unless you modify the CH register value in the "identify" subroutine at the end of the file from 0x06 to 0x0c or 0x00. Might work if sound resource (track) 0x06 is provided through patching or hacking.

BTW, I noticed that the interpreter tries to open a "patch.001" file after loading the driver. The patch file isn't there, but it doesn't seem to cause a problem. If you change the AL register value in the driver's "identify" subroutine from 1 to 2, the interpreter instead tries to open "patch.002" causing a file not found error. Maybe this mechanism can be useful for something...?

Edit: on second thought, the patch.xxx resources are probably for custom instrument patches, so not that useful.

Great! Going to have fun poking around with the driver. 😉

Instrument data (compressed inside the resources files):
patch.001 = MT-32 sysex data
patch.003 = Adlib
patch.101 = ....? (don't recognize device)

For SQ5 though (instrument data)
- 0.pat = Adlib
- 1.pat = MT-32
- 4.pat = General Midi

edit:
This is the genie laugh hacked to play with ripsaw8080's MTBLAST ($06 device ID)
http://www.sendspace.com/file/psh7vp

You will only hear the laugh. Nice job merging the drivers together!
(If I can break apart Krondor, I might ask for your help on that one) 😉

Checklist:
- B0 + 01,07,0A,40 = okay!
- E0 = okay!

There might be a problem with the reverb: SQ4 is reading the data from $81 and QFG2 wants it from $48. Used in sysex data.

GlobalVolume also: SQ4 uses $77 and QFG2 is $3E.

Here's my version of MTBLAST w/ hacked genie laugh ($0c device ID)
http://www.sendspace.com/file/l4tje3
(edit2: MTBLAST is ripsaw8080's version. Please recompile to get QFG2 version)

It'll crash when stopping the sample.

edit3:
Since I have the decompressor done, I'll try making a tool this weekend to detect / expand any digital sound files to add in $06 MTBLAST support (copy MT-32, add digital). It's just a bunch of header tags and reshuffling the data / ptrs around.

I didn't merge drivers together, I modified the MTBLAST.DRV from SQ4 to use some slightly reordered logic I learned about from analysis of MT32.DRV between SQ4 and QFG2.

I changed the 3rd byte of your sound.754 resource from 0x06 to 0x0c, and changed the SQ4 driver to device ID 0x0c, then music plays correctly and the genie laugh is heard as the only SB sfx, no crash. 😉

The best tool for accessing the resources in SCI games is the Sierra Resource Viewer..

I am currently working on a GUI to work with SCI0 SOUND resources, using some of Ravi Iyengar's command line tools. This is for use with SCI Studio and SCI Companion. Currently, the GUI can dump MIDI files from SCI0 SOUND resources, convert AdLib BNK files to SCI0 PATCH and the other way, MT-32 SysEx files to PATCH and a number of other features.

The reason that I bring this up is that It can also add digital audio samples to the SCI0 SOUND files, which is how the genii laugh in QfG as well as the "Where am I?" in SQ3 is added to the games. I am in the process of adding batch processing capabilities to it. And I will be adding the ability to extract WAV files extracted from the SOUND and or RESOURCE.* files. So I find this is relevant to me with what I am currently working on.

ripsaw8080 wrote:

Edit: on second thought, the patch.xxx resources are probably for custom instrument patches, so not that useful.

Yes. It is the SOUND.* files that have the MIDI, AdLib, MT-32 audio resources. Before Sierra added separate digital audio samples to the games packed in the RESOURCE.AUD/*.AUD files with a separate audioDrv driver, they started to introduce WAV data by appending it onto the SOUND files so it could be accessed with the hybrid soundDrv, MT32.DRV/SNDBLAST.DRV. Opening a game in the Sierra Resource Viewer is a great way to browse the the game data.

I didn't merge drivers together, I modified the MTBLAST.DRV from SQ4 to use some slightly reordered logic I learned about from analysis of MT32.DRV between SQ4 and QFG2.

Okay. I understand now.

The reason that I bring this up is that It can also add digital audio samples to the SCI0 SOUND files, which is how the genii laugh in QfG as well as the "Where am I?" in SQ3 is added to the games. I am in the process of adding batch processing capabilities to it. And I will be adding the ability to extract WAV files extracted from the SOUND and or RESOURCE.* files. So I find this is relevant to me with what I am currently working on.

Aha! Didn't know that trick. Batch processing would also be stellar.

With everyone's great findings, guess I can hold back working on QFG2 now.

Not too eager to look at Krondor atm so.. I just relax. 😀

For some reason, the Sierra SB driver initialization speed bug has crept into the modified driver. I get no sound, MT-32 or WAV with any of these drivers, either with Munt or my MT-32. Both work just fine with the MT32.DRV that shipped with the game.

Some information on Maggio's work on his GMBLAST.DRV can be found on his page here: http://sierra.voyd.net/

I feel that it would have to use the MT32.DRV and SBLAST.DRV that shipped with the game. I am afraid that I am not capable of dealing with assembly, so it will have to wait for someone else that can append the SBLAST.DRV onto the SBLAST.DRV.

Are you using DOSBox where you can control the cycles? Low enough cycles should render system speed issues moot. I hear MT-32 music or SB sfx when the device ID of the driver is changed to 0x0c or 0x00, respectively. Have you changed the device ID in the driver?

As I mentioned previously, none of the sound resources in QFG2 are marked as device 0x06, so you either have to change the device ID of my modified SQ4 driver or modify the sound resources to device 0x06. It is expected that nothing will be heard if you just drop the driver in and don't modify anything, but you should still see the MT-32 LCD messages.

In the middle of a move to a new house, so I may not be much help for a few days.

My MIDI synths are also packed away, although I did install a DOSBox SVN with munt built in.

ripsaw8080 wrote:

Are you using DOSBox where you can control the cycles? Low enough cycles should render system speed issues moot.

Of course, but my default cycles for SCI0 to SCI1.1 is 10000, which is high enough to trigger the SB initialization bug. This is nearly non-existent in games earlier that SCI1. Even though it is easy enough to work around, I am thinking about supporting it in one of my installers. I have to look at it from the lowest common denominator of the end user.

ripsaw8080 wrote:

I hear MT-32 music or SB sfx when the device ID of the driver is changed to 0x0c or 0x00, respectively. Have you changed the device ID in the driver? As I mentioned previously, none of the sound resources in QFG2 are marked as device 0x06, so you either have to change the device ID of my modified SQ4 driver or modify the sound resources to device 0x06. It is expected that nothing will be heard if you just drop the driver in and don't modify anything, but you should still see the MT-32 LCD messages.

I misunderstood. I assumed that you had already done that to the driver. I did get the opening LCD message.