Yes, I know some people don't like posting to old threads, but I'd rather do that in this case than create a new one.

I have some interesting news to report.

I have two very old Sound Blaster cards: a Sound Blaster 1.5 (CT1320C) and a Sound Blaster 2.0 (CT1350B). Both have the C/MS upgrade chips installed, and both have the OPL2 chips removed. (I removed the FM1312 chip but left the FM1314 chip installed in the SB 1.5, but I don't know if it matters or not.)

When playing on the SB 2.0, the C/MS music in Prince of Persia messes up for me very similarly to how people on here have described it(and recorded it), but not *exactly*. Close enough, though.

When playing it on the SB 1.5, it sounds AMAZING! I'll try to record it tonight and post the recording on this thread so people can hear what it's supposed to sound like. It's unmistakably the way it's supposed to sound, and sounds nothing like the Adlib music. The digital effects come through in the game itself and sound very similar if not identical to the Sound Blaster sound effects.

All of this is being done on an original XT -- an IBM 5160 with a "new style" CGA card, I believe. I have 2 or 3 different CGA cards and I'll confirm that tonight.

Something else of note, which I thought was pretty amusing. This XT has a dual monitor setup because I also have a Hercules card installed, with the output going to an amber monochrome Hercules monitor. The CGA card is feeding a Gorilla green monochrome monitor identical to the one I had as a child. When the flashing effects happen in the game, the flashes occur on the CGA monitor, not the Hercules monitor, even when the game is running in Hercules mode and all the normal graphics are going to the Hercules monitor. That happens in the intro, and in the game when picking up the sword.

I'd also like to mention that I tried several other games using C/MS sound and music options, and almost all of them screwed up using the SB 2.0. I think Budokan and Conquests of Camelot were the only ones that had even remotely pleasing C/MS sound with the SB 2.0, and as I discovered when trying those two with the SB 1.5, it wasn't complete on the SB 2.0. I can make detailed recordings of all this and post them later.

aquishix wrote:

When the flashing effects happen in the game, the flashes occur on the CGA monitor, not the Hercules monitor, even when the game is running in Hercules mode and all the normal graphics are going to the Hercules monitor.

The game uses the same basic graphics code for CGA and Hercules (the Hercules output is scaled CGA graphics data), and performs the flashes by changing the color select register (3d9h). There is no MDA/Hercules equivalent, so the coder either forgot a conditional jump to avoid it, or (more likely) got lazy and figured nobody would notice (hardly anyone had dual-monitor setups).

Stiletto wrote:

The fact that I don't see more use of TOPBENCH in DOSBox circles is dismaying. 🙁

Agreed.

MobyGamer wrote:

aquishix wrote:

When the flashing effects happen in the game, the flashes occur on the CGA monitor, not the Hercules monitor, even when the game is running in Hercules mode and all the normal graphics are going to the Hercules monitor.

The game uses the same basic graphics code for CGA and Hercules (the Hercules output is scaled CGA graphics data), and performs the flashes by changing the color select register (3d9h). There is no MDA/Hercules equivalent, so the coder either forgot a conditional jump to avoid it, or (more likely) got lazy and figured nobody would notice (hardly anyone had dual-monitor setups).

...as I never did, back in the day. 😉

Well, that certainly explains why the Hercules mode for the game looks squished / like it has the wrong aspect ratio. That's disappointing. There's really no point in using that mode, then, except to have the graphics look a little sharper(perhaps) because that monitor is of such high quality.

I also discovered that Prince of Persia does indeed use CGA composite NTSC artifacting, but it's really subtle and limited compared to Sierra games, which use it all-out. In Prince of Persia, the tips of the spikes on the gates(and maybe the spikes coming up from the floor) look red, like they're blood-stained. It baffles me why they didn't make the torch flames on the walls look red instead of pink/purple, but alas...

It sounds like from what you're saying that even if I remove the CGA card and run it with Hercules only, that that flashing will just be absent. That's also a little disappointing. But great information!

Your avatar looks like the one that Trixter has used on other forums; are you Trixter?

aquishix wrote:

Your avatar looks like the one that Trixter has used on other forums; are you Trixter?

He is, Trixter is also the co-founder of Mobygames, hence his Mobygamer name here. I guess Trixter name was already taken.

Could this be because the pal code we use on ct1350b cards is not 100% correct (and also why one needs the 1366a controller to use it without breaking the sb part?)

keropi wrote:

Could this be because the pal code we use on ct1350b cards is not 100% correct (and also why one needs the 1366a controller to use it without breaking the sb part?)

One thing that I haven't mentioned yet is that my CT1350B card has a 1336, NOT a 1336A, which was quite intentional on my part because I had consulted this post: http://nerdlypleasures.blogspot.com/2013/06/t … ms-upgrade.html

(I assume you meant 1336, not 1366.)

^ yes ofcourse you are correct I messed it up. Now I see the blog post and I stand corrected. I also use a CT1336 card successfully with the CMS upgrade

I blame old old age 🤣 🤣 🤣

Does anyone know what the PAL/GAL chips contain exactly, and why they are different between revisions?
I have built a clone CMS card myself (using the design from veovis), and there is no PAL/GAL used at all. So I take it the PAL/GAL is merely used for some basic TTL logic, related to the address decoding. I don't believe they even implement the simple flip-flop of the original CMS card, which my clone does. This flip-flop enables you to write data to the card and read it back, as a rudimentary way to detect the card. From what I understood, these detection routines fail on SB cards with CMS chips (but not on my clone).

Scali wrote:

Does anyone know what the PAL/GAL chips contain exactly, and why they are different between revisions?
I have built a clone CMS card myself (using the design from veovis), and there is no PAL/GAL used at all. So I take it the PAL/GAL is merely used for some basic TTL logic, related to the address decoding. I don't believe they even implement the simple flip-flop of the original CMS card, which my clone does. This flip-flop enables you to write data to the card and read it back, as a rudimentary way to detect the card. From what I understood, these detection routines fail on SB cards with CMS chips (but not on my clone).

I'll confirm soon, but I think the following statements are true:

A) My SB 1.5 card does not have a GAL chip on it.

B) My SB 1.5 card with the FM1312 chip removed gets auto-detected as C/MS in several DOS games.

aquishix wrote:

A) My SB 1.5 card does not have a GAL chip on it.

Hum, yes that could be. Perhaps they only added the GAL on the SB 2.0 design?
The original CMS/Game Blaster also didn't have a separate GAL chip, but it does have a big chip (CT1302A) on there that is not on my clone. Not sure what that does exactly. According to Wiki, it is used for the detection routine, but it would be a huge overkill for that. My clone does it with simple TTL logic.

aquishix wrote:

B) My SB 1.5 card with the FM1312 chip removed gets auto-detected as C/MS in several DOS games.

That could also be true... I know that a number of games 'prefer' Adlib/SB music over CMS, Tandy or other sound options because of limitations in their auto-detection and/or commandline handling.
So perhaps the games that don't work in CMS mode on an SB are suffering from this, rather than the detection routine itself failing.
I suppose we'd have to investigate that on a per-game basis.

Here you go.

The way it's supposed to sound:

( tried my other pair of C/MS chips I used to upgrade my CT1350B: )

The way it's NOT supposed to sound:

( ...and just to be sure that it wasn't the C/MS chips causing the problem... )

And removing the GAL chip, this is how it's REALLY not supposed to sound!:

Just to show that it's not merely system *speed* that's the issue, observe these recordings:

..and these.

So as you can hear, only the CT1320C while plugged into the IBM 5160 actually sounds perfect. All of the rest of these are varying degrees of garbage. I'd be willing to bet that the guy who handled the C/MS support on Prince of Persia for DOS decided to use an original IBM PC or XT and assumed it would work on other machines.

Exactly why the CT1320C sounds great and the CT1350B doesn't is the real mystery to me. I eliminated the possibility of it being the C/MS "upgrade" chips by swapping them, as you can see/hear in my first post tonight. It sounds like some of the channels are missing, but it would take a bit of work to prove that.

I'm fairly confident that Prince of Persia is the only game I've tried so far that had to have the Yamaha FM chip removed in order for C/MS / Game Blaster support to work as intended. Since I'm satisfied with never playing Prince of Persia with the C/MS option again, I think I'm going to put my Yamaha FM chips back in these two cards and move on with my life.

What specific version of POP did you run for your tests? I have a true CMS card (not a sound blaster) that I can use to test on a 10 MHz 286 and see if I'm hearing the same missed notes you're hearing with your CT1320C.

I'll check the Prince of Persia code to see if there is an obvious WTF coding error and see if it can be patched. Your recordings illustrate that, clearly, there is data not making it to the chips, resulting in lost note and volume changes. The programmer might have been trying a dumb optimization like sending words instead of bytes, or not waiting for the bus to settle.

Have you tried other versions? The last version of POP (v1.3) had additional sound support and a setup program, might be worth checking that one.

MobyGamer wrote:

What specific version of POP did you run for your tests? I have a true CMS card (not a sound blaster) that I can use to test on a 10 MHz 286 and see if I'm hearing the same missed notes you're hearing with your CT1320C.

I'll check the Prince of Persia code to see if there is an obvious WTF coding error and see if it can be patched. Your recordings illustrate that, clearly, there is data not making it to the chips, resulting in lost note and volume changes. The programmer might have been trying a dumb optimization like sending words instead of bytes, or not waiting for the bus to settle.

Have you tried other versions? The last version of POP (v1.3) had additional sound support and a setup program, might be worth checking that one.

I have not tried multiple versions; I (perhaps erroneously) assumed that the C/MS support would be constant across them.

I'm pretty sure I was using v1.0 on those 3 machines, but I'll double check them all tonight when I get home. If there's a discrepancy, I'll re-test and post new recordings if I hear any differences.

One thing that's interesting is that my XT Turbo clone with turbo off (I.e., with the clock tamped back down to 4.77MHz) performs its POST RAM count up to 640KiB much faster than my true blue IBM 5160 does. Makes me think there's something going on with the RAM timing...or perhaps my XT Turbo clone is one of those machines that doesn't REALLY change the clock with turbo off -- it performs some other trick to simulate a lowered clock rate. I'd gladly run some kind of test to elucidate that. Would TOPBENCH help in that regard? 😉

Also, technically speaking, v1.4 was the last release of the classic Prince of Persia game for DOS. I don't think I've ever used it, but it was a significant departure from the previous versions. In particular, most of the command line options were stripped out and I believe the MT-32 support was dropped entirely.

See: https://popuw.com/parameters.html

I've never seen 1.4. 1.3 has the SETUP program so it's definitely different than the others. When you retest with 1.3/1.4, let us know if things improve in the bad situations; if they don't, I'll get to checking the code.

Your clone XT might count faster simply because the BIOS routine does a less stringent test of the memory. The 5160 BIOS tests each 64K segment with a write/read pattern of AA55, 55AA, FFFF, 0101, and 0000 so it takes a bit of time.

You can definitely run TOPBENCH's realtime benchmarking screen and pop the turbo button on and off, and see the immediate results of doing so. (It was one of the design goals, actually, as I also have turbo buttons over here 😉 Or, add both turbo and non-turbo to the database, then use the database compare function to directly see both (one on top, one on bottom) and you can inspect what changed and how much.

MobyGamer wrote:

What specific version of POP did you run for your tests? I have a true CMS card (not a sound blaster) that I can use to test on a 10 MHz 286 and see if I'm hearing the same missed notes you're hearing with your CT1320C.

I confirmed today that I tested with Prince of Persia 1.0 on all three systems.

MobyGamer wrote:

I've never seen 1.4. 1.3 has the SETUP program so it's definitely different than the others. When you retest with 1.3/1.4, let us know if things improve in the bad situations; if they don't, I'll get to checking the code.

It looks like the Game Blaster / C/MS support was entirely dropped in Prince of Persia v1.3. So 1.0 is the only game in town for this, no pun intended.

Okay, I'll use a PS/2 Model 30 (10 MHz 286) with a real CMS card. If the sound support is broken in the game, it will sound wrong on the CMS card too. If the Sound Blaster's CMS support is faulty, it will sound fine. I'll report back with results.

CMS card running CMS demo software is working 100% perfectly. Will test a few games as well as PoP.