SCI music patch formats

[commodorejohn]

Okay, there's already converters to create patch resources from MT-32 SysEx files and Adlib banks, but I'm curious if anybody knows anything about some of the other supported drivers. The IBM Music Feature Card is just a Yamaha FB-01 with a MIDI interface; there's plenty of editors for FB-01 and other Yamaha 4-op FM synths out there, but is there any information on the patch format for the MFC driver that would allow conversion from an FB-01 bank? What about the Casio CSM-1/MT-540? As near as I can tell it doesn't even have editable patches; does the patch file just map MIDI instrument changes to the built-in voices?

[MusicallyInspired]

I honestly don't know about those other cards. It's possible it remaps, or contains a standard map. I really don't know. This is an instance where someone from the Quest Studios forums would be of much more help. NewRisingSun helped me a lot with the patch bank information and programs for the MT-32 and Adlib. No idea if he's active anymore at all, though.

[Collector]

There are a number of different synth/audio devices that are supported by SCI. Most of them are useless these days as SCI game are generally played using DOSBox. The development tools we have are mostly limited to SCI0. This limits the available devices to AdLib/SoundBlaster, MT-32, PC speaker and to a lesser extent, GM. The SCI documentation does not have anything that I am aware of out side of that.

[MusicallyInspired]

SCI0 does indeed support the devices he mentioned, though. We just have no tools or information for them. Even SoundBox has flags for them.

[commodorejohn]

Most of them are useless these days as SCI game are generally played using DOSBox.

Maybe so, but DOSBox itself supports routing emulated MIDI out to a real MIDI port, and FB-01s can be had pretty cheaply; it'd be fun to support them. (Well-programmed 4-op FM can even sound better than an MT-32 in some instances!)

(Hmm...wonder if my V50 is backwards-compatible with the SysEx format for the FB-01...? Probably not. My TX81Z might've been, though.)

[Collector]

SCI0 does indeed support the devices he mentioned, though. We just have no tools or information for them. Even SoundBox has flags for them.

It is not just what SCI0 supports, but also what DOSBox supports. That narrows the field considerably. That leaves AdLib/SB, Tandy, GM. DOSBox also supports GUS, but this is only available to later SCI games via after market patches.

Yes, you can set tracks for the mentioned devices, but you cannot play them through DOSBox directly. While you could use the MIDI out from DOSBox, unless you are talking about a device that is a separate module, you have the problem of dealing with an ISA device. That starts to get fairly absurd and/or expensive.

That is not to say your inquiry is silly, just that from the view point of creating new SCI0 games there is not much motivation to be working with these other devices. As MI indicated, people on the Quest Studios forums would probably be able to provide more information.

[commodorejohn]

While you could use the MIDI out from DOSBox, unless you are talking about a device that is a separate module, you have the problem of dealing with an ISA device. That starts to get fairly absurd and/or expensive.

A fair point; but then, while the IBM MFC is indeed an ISA card, it's just a MIDI interface glued to the innards of an existing Yamaha MIDI module (the FB-01) which can be had for about the same price as an MT-32, so it doesn't really seem that ridiculous, certainly not for the nice quality music you can get from it. (The Casio MT-540 and compatibles are also separate modules or keyboards, but I doubt their sound quality is all that good; Casio only ever made a few keyboards that sounded that interesting.)

As MI indicated, people on the Quest Studios forums would probably be able to provide more information.

Yeah, I'd ask there, but they've had registration disabled every single time I've visited...

[Collector]

All true, but again, from the stand point of new SCI games, the lowest common denominator is what developers will have in mind. Most have trouble with adding just AdLib. From the point of view of playing the Sierra SCI0 games, most sound tracks were written primarily with the MT-32 in mind. I can't say how good the tracks were for the mentioned devices as I have never heard them. As you noted, DOSBox works very nicely with external modules, but outside of the hard core Sierra Fans not that many Sierra retro players have an MT-32. MUNT is also a solution for Roland sound.

The later is a subject that is of particular interest to me, but with the twist of what I can do with my new Sierra installers. I could easily have the games configured for Roland sound with MUNT, but the legal status of the required ROMs is problematic for distribution with my installers. This is why I try to use GM with the game that support it or use one of the hacked drivers for enhanced sound, if available.

I can't tell you what is currently going on with Quest Studios' registration. If they closed it to stop spam, there are very easy ways to deal with it. Perhaps Tom does not know how to setup effective bot filters. You could try to email Tom. Beyond that, I cannot say. I have not bothered with those forums in literally years. I can do without the attitude that some there showed me. I used to be registered there, but my account has probably been deleted for inactivity long ago.

Another option for information may be VOGONS. It is a very active community of retro gamers. It includes the official forums for DOSBox. NRS and several other very knowledgeable people frequent it. It is where the MT-32 emulation that became MUNT was started and is where its forum resides.

[commodorejohn]

All true enough, I guess, but I'm mostly interested in it for the neatness factor, not for practical concerns.

As for how good the renditions on supported games were, there's a few recordings around the 'net - here and here, for example. They're not as good as they could be (the 4-op FM synths are capable of some great sounds,) but they're pretty good; they may or may not just be mapping to ROM presets, I dunno.

(Though someone should really make an MFC emulator like Munt does for the MT-32; emulation of the 4-op FM chips is quite good, more accurate than Munt most of the time...and you wouldn't even have to use ROM dumps, since there's no PCM and the FB-01 presets have already been around in SysEx format for forever.)

Anyway, I figured out the Quest Studios thing; you have to use the main site contact form to register, it just doesn't say that on the "registration blocked!" page for the forum...

[commodorejohn]

Oh, and for the Casios, here's a page with demo tracks (No Sierra tunes, though.) Limited and cheap, but surprisingly not bad. I'd love to know how it came about that Sierra decided to support it, though...what a random choice!

[Collector]

I'd love to know how it came about that Sierra decided to support it, though...what a random choice!

Remember that this is the beginning of the sound card era. How many sound card and modules were available, then? Sierra was one of the first to support the MT-32. Whatever extra modules were supported may have been on the recommendation of Mark Seibert the other musicians. Anyway, I suspect that these other tracks were not as well done as the Roland tracks.

[MusicallyInspired]

All true enough, I guess, but I'm mostly interested in it for the neatness factor, not for practical concerns.

This. The moment we stop doing things because we are fascinated by it and start doing it for the LCD only is the moment when it stops being fun. This whole community was started because of the "how cool would it be..." factor. I mean, if you look at it that way, people wouldn't even mess with DOSBox if there was a simple AGS game they could snag easily.

I'm all for looking into these kinds of things and experimenting. I still have an old 486 that I use for old DOS games. Not many do but I do and that's all I care about. That's why I was going to program KQ2SCI to support Adlib, the MT-32, PC Speaker, and Tandy 3-voice/PCjr because it was awesome. Maybe nobody would take advantage of it, maybe they would. I don't care about that.

Keep me updated if you find anything out about support for those other devices! If anything comes of it I'd love to make plans for supporting them in KQ2SCI as well (if I ever get around to finishing it).

[commodorejohn]

This. The moment we stop doing things because we are fascinated by it and start doing it for the LCD only is the moment when it stops being fun. This whole community was started because of the "how cool would it be..." factor.

Right on

That's why I was going to program KQ2SCI to support Adlib, the MT-32, PC Speaker, and Tandy 3-voice/PCjr because it was awesome. Maybe nobody would take advantage of it, maybe they would. I don't care about that.

Well I sure would - I've got all of those on-hand! No sense letting 'em go to waste

Keep me updated if you find anything out about support for those other devices! If anything comes of it I'd love to make plans for supporting them in KQ2SCI as well (if I ever get around to finishing it).

I will. Crossing my fingers that the Quest Studios folks will have some more information...

[commodorejohn]

Okay, I dumped the patch resources for MFC, FB-01, and CSM-1 from the SCI Companion test game to dig around in with a hex editor. The MFC patch resource (patch 002) is almost completely straightforward - it's mostly a bunch of 64-byte blocks with names at the beginning, which look to exactly match the FB-01's internal voice format as documented in its manual. (The internal representation, not the SysEx representation, which is awkwardly chopped up into nybble values!) The only part I'm not clear on is a couple of 2-byte sections at the beginning and middle of the file. The first is "89 00" (hex,) which (if I'm reading the available information correctly) is just the type ID for a patch resource. The second (which occurs after the first 48 voices - the size of one FB-01 bank - out of 96 total) is "AB CD," which isn't found in the other two but does show up close to the end of the MT-32 patch resource (and nowhere else in either the MFC resource or the MT-32 resource.) Anybody know what this signifies? The ScummVM wiki seems to think it's merely a separator, since the MFC patch file can contain either one or two banks. If this is true, then it should be trivial to create a new set of patches from FB-01 banks. I've got an FB-01 in the mail, so I'll give it a shot when I get a chance.

Interestingly, however, the resource SCI Companion labels as "FM-01" (I presume they mean FB-01?,) patch 004, is completely different - it's only 235 bytes long, has no FB-01 patch blocks in it, and looks a heck of a lot like the CSM-1 patch resource, patch 007. Both files have the "89 00" ID followed by fourteen zero bytes, and then have what look to be a series of two-byte pairs in which the second byte is almost always zero, and then end with the exact same last 46 bytes. I have no idea what this is. For the CSM-1, I presume that it must contain some sort of instrument map, since the CSM-1 doesn't have custom patch capability and only has about thirty presets, but I'm not sure why the FB-01 would need a similar file...anybody know anything about this?

Edit: the ScummVM Wiki says that patch 004 is used by the GM driver, and gives a file format, only the file format doesn't at all match the resource with the SCI Companion test game - for starters, the test game's patch 004 is much too short! Oy...

Further edit: the ScummVM Wiki also claims that the FB-01 driver uses patch 002 as well, which makes more sense (though it means SCI Companion doesn't know what it's talking about.) Still no idea how the CSM-1 patch 007 works, though...

[gumby]

I can help with the first part:  Yes the 89 00 is the 'patch header' that indicates that this is a sound resource.  If you were to look at the resource in a resource.xxx file it would not have the 89 00 at the beginning.