Plasma wrote:

I'm willing to bet the list of games hard coded to use a SB at 220 only is much smaller than the list of CMS games. But to each his own.

When i made the decision to patch CMS games i had the exact opposite idea. Also, a lot of Sierra adventure games supported CMS, and others like the Sierra games were just a matter of a very easy driver patch. This narrowed the number of games to patch and with the exception of a handful, all others were pretty straightforward. My lack of experience in patching games didn't help as i didn't look thoroughly into game files enough, making me believe that some games were much harder to patch than they actually were. One perfect example of this was Budokan: The Martial Spirit.

In my case, this project was very much worth it, maybe because indeed i'm OCD, and i prefer CMS at 210h & SB at 220h rather than 220h & 240h respectively. For a multi sound card system the 210h-220h approach is better anyway, IMO.

Hey, I have now the Blasterboard and the MUS1099 in the same system and want to patch the Sierra cms.drv for the various Sierra games. The description says:

cms.drv
35 x0 02
37 x1 02

When I do "debug cms.drv" and then "d 135" I see 20 02 21 02. What exactly am I supposed to change this to now?

And one more thing: I found this file here which references a Sierra C/MS driver disk. Which makes sense, as I read in one of the leaflets of my Sierra games that Sierra offered up to date sound drivers via mail-in.

http://cd.textfiles.com/soundsensations/JUKEB … OPM/DRV-DOC.TXT

However that site does NOT have the rest of the driver disk. Quick Google search came up blank. Does anyone have that disk?

carlostex wrote:

My lack of experience in patching games didn't help as i didn't look thoroughly into game files enough, making me believe that some games were much harder to patch than they actually were. One perfect example of this was Budokan: The Martial Spirit.

Yea, a lot of games had very simple code with address 220h hardcoded, so just changing all instances of '220h' to '210h' did the job.
Some games used a variable to store the base address. In which case it took a bit of detective work to see where this variable was being manipulated. In some cases, it turned out that there were undocumented commandline or other configuration settings, so you didn't actually have to patch the game, you just had to reverse-engineer how to configure it.

Budokan and a few others had the problem that the sound code was not in the main part of the game, so you first had to figure out where the code actually came from. Then it turned out that the code was stored in some kind of compressed or encrypted file, so in order to patch it, you would either have to reverse engineer the compression/encryption scheme, or you'd have to patch it in-memory by using some kind of TSR that would hook into some strategic place (eg the DOS FILE API), and make sure it would patch AFTER the proper code was loaded.

Then there were also some 'broken' games. As in: they would have some kind of autodetection scheme, so you couldn't get them to use CMS when an AdLib or SB was installed in the system.
In some cases this was 'by design': apparently the developers figured that if you had multiple sound cards, the one they considered 'the best' would be selected.
In some cases, it really was broken. As in, you could actually configure the soundcard you wanted with an installation tool or commandline option, but the autodetection would still override it.

This would often result in quite a bit of detective work to figure out just where to patch, so the autodetection scheme could be bypassed. This scenario was also extremely common with the Tandy Sound Card. Many games were developed with the assumption that a Tandy machine would ALWAYS use Tandy sound, and any other machine would NEVER use Tandy sound. Worst case scenario was that there were separate binaries for Tandy and regular PCs, so the entire Tandy sound code was simply missing altogether in the binaries for CGA/EGA/VGA graphics.

root42 wrote:

When I do "debug cms.drv" and then "d 135" I see 20 02 21 02. What exactly am I supposed to change this to now?

As you may know, x86 CPUs use Little Endian notation for data. This means that when you use values of 2 or more bytes, the least-significant byte is stored first (lowest address).
This is effectively the reverse of how we normally write down numbers.
So in this case you see:
20 02 -> 220h
21 02 -> 221h

So if you want to change this to eg 210h base address, you do:
210h -> 10 02
211h -> 11 02

Thanks! That actually makes perfect sense.

EDIT: Worked like a charm. I did the following:

1copy cms.drv cms.bak
2debug cms.drv
3e 135 10 02 11 02
4w
5q

Changed the port for Sierra C/MS driver from 220h to 210h.