awesome! thanks for the cheat codes

sadly I can't get either descent games to work...
I have 3 updated game installations: Descent1 at ver1.5 , Descent1 at ver1.4a and Descent2 at rev1.2 (with vertigo expansion)
All games run fine without the midi fixes

If I midi-fix them then all games:
- do the fade effect and the screen stays black , no sign of life on the sc-55s displays and I have to reset my pc
- when setting General Midi /330 on the setup programs and trying to test the music then I get a crash and get dumped back to DOS
- when setting sfx + music to SB16 then the games work OK and there is no crash

I am trying in DOS, with a SB16 + MPU401AT (sb16 mpu jumpered to disabled) and both games are originals...
Maybe someone else can verify this error too?

Bummer.

I'm using Descent CD 1.0 + Descent 2 CD 1.2. No expansions or such. If the HMIMDRV.386 fix by itself works, then it must be the HOG MIDI fix.

I'd have to use a xdelta patcher in that case to cover any different versions.
- Descent.hog = 265609F4 (CRC32)
- Descent2.hog = 2A84C1A3 (CRC32)

I get way different CRC32s... I can't test D1 because I have the floppies stored at my office along with the game boxes, all I got here is archives of already patched 1.4a and 1.5 versions.
But I do have my D2 cd here. It's a UK v1.0 release (officially sold with Greek manual back when d2 was a new game) , here it is along the various crc32s of the .HOG versions:

IMHO xdelta might be needed after all, maybe there are a gazillion releases out there....

edit further testing:
* patched HMIMDRV.386 causes my game to crash with a black screen even with the stock v1.2 .HOG
* stock HMIMDRV.386 with tilakat.hog works OK! though the crc32 is different than yours tilakat...

I believe it's some kind of problem on the midi driver

edit2:
stock driver and tilakat.hog gives this result:

the older sc-55 plays nothing

Don't have a clue yet why the driver fails. But I agree xdelta would be safer method.

the older sc-55 plays nothing

If I understand correctly, non-GM SC-55 should play Descent I+II Fl. Key Click using stock HOG. So if your 2 units play correctly with stock HOG but only 1 fails using Tikalat HOG, then it could be failing CTF (BANK 01 --> BANK 00).

the sc-55s are a mess , both my units are non-gm a you can see but they have different rom versions (v1.10 vs v1.21) and you can't swap them, I tried 🤣
The instrument placement has changed, on top of my head:
the older unit has Fl. Key Click as the main instrument at #122
the newer unit has Breath Noise as the main instrument at #122 and the Fl. Key Click as a variation tone.
I can check all that later back home...

So basically *from what I understand*, the patched .HOG has patched midis? and so it tells the game to play FL. Keyclick at a variation tone position, something that works fine on newer SC-55 but fails on older ones because there is no variation tone at this position... :\

the patched .HOG has patched midis? and so it tells the game to play FL. Keyclick at a variation tone position

Right - patched .HOG has patched MIDI.

Old = plays BANK 00, Fl. Key Click (non-GM) / Breath Noise (GM)
New = plays BANK 01, Fl. Key Click

The part I'm confused about is

something that works fine on newer SC-55 but fails on older ones because there is no variation tone at this position... :\

I thought the older ones have BANK CTF ability, which makes games like World of Xeen work.... eum.. D1stortion? 😀

I haven't read the latest posts completely, but normally Fl. Keyclick should play on non-GM units if you programmed it at PC#122 CC0#1. First time I hear about "No INSTRUMENT" messages on the first SC-55. Could be a mistake with driver patching.

Can't test any of this though - neither do I have the full version of the game, nor the right synth.

On another note, if you haven't done it yet, maybe it should be worth noting in the readme that this cannot work on units like the SC-7/RAP-10/SCB-7 (and also the default MS synth), since all of those only have the regular 128 GM instruments. Just to prevent confusion.

Maybe these photos help?

here is #122 in the units, upper one is v1.10 , lower is v1.21 :

and here is if I press both instrument buttons to browse variation tones:

after pressing instrument-right button:

and here pressing right one more time:

the v1.21 unit goes from breath->click->triangle
the v1.10 goes from click->triangle

I guess there could be 2 ways to apply the patch, just the driver or driver+hog to get the click sound.

I also tested with the click-patched midi tilakat posted before:
- the SCB-7 does not play the click sound, I believe it still plays breath noise
- the v1.21 SC-55 plays click instead of breath as expected
- the MU80 plays click instead of breath as expected

edit: don't know it it is any more help but here is the state of the modules after the click-patched midi is done playing with MFPLAY and part#11 is selected for viewing:

To see if that odd duck unit w/ blank instrument selection supports CTF you need to play a MIDI with variation tones that do not exist on a SC-55. I don't know if you have such MIDIs, I've attached one just in case, play it back and report if all channels play an instrument or not. If all channels play the Descent issue is due to the driver hacking.

I have tested with World of Xeen arrow fx as per GH's instructions and I have tested with the Bloody Tears midi as well, it's a very known tune to me, thanks for uploading it as I had no ctf test midi 😁
It plays the same in both SC-55s , synthy sound overal
On the MU80 I get piano sounds
On the SCB-7 I get the same as the 55s, no piano like the mu80

Thanks guys for clearing that out. Will have to dig into fixing the driver + MIDI again. Should start with the xdelta first.

I gave that "D2 - Music 03" demo a try now... honestly I'm not entirely sure what to think here. The clicks sound very dominant in that part, while you could argue that Echo Drops plays a similarly low-pitched note and matches better with Breath Noise.

On that "D1 - Level 14" example take a look at the panning of Breath Noise/Fl. Keyclick and Gt. Fretnoise. It's identical. I'm not saying it proves anything, but Breath Noise and Gt. Fretnoise could be considered identical in "purpose", so the identical panning would go well with that theory. Although on the other hand Fl. Keyclick does seem to go well with the drums...

Now for my idea... the game supports the Gravis Ultrasound. I don't know if it utilizes the card in a non-GM compliant way or not (and I'm not familiar with it at all, either), but maybe it'd be worth taking a look at what patches it uses on a GUS? Same goes for the AWE actually... at least in Duke3D the AWE mode does yield different results on an AWE card than the GM mode (i.e. direct access vs. going through MPU-401 emulation), so the arrangement might be different. Again, this will not prove anything (nothing 'cept for contacting the composer will, or equivalent direct sources of information), but all of that could give hints as to what the composer actually had in mind. As in, if he wanted to have click percussion on the AWE (which has only Breath Noise at that position) maybe he would have used something on the drum channel instead, to give an example.

But on a further note, maybe I'm thinking way too much into this and they didn't give a flying f*ck about how it all sounds... after all, in Blood all you get is Pianos when starting the game on Yamaha.

d1stortion wrote:

[...]
But on a further note, maybe I'm thinking way too much into this and they didn't give a flying f*ck about how it all sounds... after all, in Blood all you get is Pianos when starting the game on Yamaha.

I genuinely believe that is the case. The composer makes some music with all the bells and whistles, then it goes to the programmers and the sound driver person, he tries to adapts it... during that adaption the original score could be butchered and altered. Or maybe the sound driver simply lacks exotic features to fully support/replay it.
Does it make a sound? nice move along 🤣 🤣 🤣

keropi wrote:

I genuinely believe that is the case. The composer makes some music with all the bells and whistles, then it goes to the programmers and the sound driver person, he tries to adapts it... during that adaption the original score could be butchered and altered. Or maybe the sound driver simply lacks exotic features to fully support/replay it.
Does it make a sound? nice move along

It is probably more like this... the composer is told to make an GM soundtrack but does an SC-55 soundtrack instead wich then fails when used with the sound drivers that are ment for GM standard becuase the sound programmers did not fail to follow the GM standard.

Probably going to have to make my own patcher. xdelta is too rigid - exact hashsums - and others don't allow flexibility that I'd like.

I don't remember Descent GUS having custom percussion samples. But we could check anyway. Didn't know that System Shock uses a few custom patches.

Feels like ages have gone bye. Doing Descent I+II in piece-meal as I get time.

Copy patcher tool to <install>. Run and it will patch MIDIs only to be Fl. Keyclick friendly. Be sure to make backups of your DESCENT.HOG / DESCENT2.HOG files first.

^ thanks tilakat, will give it a shot and report back

tested in both games, Fl. Key Click is selected fine in the newer SC-55/MU80 and works perfect.
As expected the older unit plays nothing on channel #11 with the patched .hog files.
The SCB-7 also plays nothing with the patched .hog files. I guess it's either breath noise or nothing on it.

Thanks for the patch tilakat!

tikalat wrote:

Star Trek: Judgment Rites (1993)

Title: Driver fixes
Date: August 26, 2013

Thank you for the STJR fix!

I had some problems with the patched trekjr.exe under DOSBox 0.73, however: Beside the MT-32 for music, I chose Sound Blaster for sound output. When running the game, it would either

• hang right after the Interplay title screen or
• if I pressed Escape during the title screen, the game would continue with music, but speech and sound effects would be missing.

I therefore propose a slightly modified patch of trekjr.exe (see the attachment) -- it seems to run fine on my setup. Maybe you can take a look at it ...

1credit: DenizOezmen
2
3
4dseg:1261A 33 C0                             xor     ax, ax
5dseg:1261C 89 46 FA                          mov     [bp-6], ax
6dseg:1261F 89 46 FC                          mov     [bp-4], ax
7dseg:12622 89 46 FE                          mov     [bp-2], ax
8
9
10dseg:12625 C7 46 DE 0F 18                    mov     word ptr [bp-22h], 180Fh
11dseg:1262A C7 46 E2 14 18                    mov     word ptr [bp-1Eh], 1814h
12dseg:1262F C7 46 DC 09 00                    mov     word ptr [bp-24h], 9
13dseg:12634 C7 46 E4 0A 00                    mov     word ptr [bp-1Ch], 0Ah
14dseg:12639 C7 46 E6 19 18                    mov     word ptr [bp-1Ah], 1819h
15dseg:1263E C7 46 E8 06 00                    mov     word ptr [bp-18h], 6
16dseg:12643 C7 46 EA 1E 18                    mov     word ptr [bp-16h], 181Eh
17
18
19; assumption: ah = 0
20; old code: ah = random
21dseg:12648 B0 04                             mov     al, 4
22
23
24dseg:1264A 89 46 E0                          mov     [bp-20h], ax
25dseg:1264D 89 46 EC                          mov     [bp-14h], ax
26dseg:12650 C7 46 EE 23 18                    mov     word ptr [bp-12h], 1823h
27dseg:12655 C7 46 F0 07 00                    mov     word ptr [bp-10h], 7
28dseg:1265A C7 46 F2 28 18                    mov     word ptr [bp-0Eh], 1828h
29dseg:1265F C7 46 F4 03 00                    mov     word ptr [bp-0Ch], 3
30dseg:12664 C7 46 F6 2D 18                    mov     word ptr [bp-0Ah], 182Dh
31dseg:12669 C7 46 F8 05 00                    mov     word ptr [bp-8], 5

You caught an interesting bug. Your version is correct.

I did it to save a byte but goofed. You fixed it up. Thanks! 😉
(driver updated)