VOGONS


Reply 60 of 71, by MobyGamer

User metadata
Rank Member
Rank
Member

So, these games test with perfect CMS sound in a 10 MHz 286 on a real CMS card:

Airball
Bubble Bobble
NY Warriors
Oil's Well
Rastan (although the music stops playing once it plays once through)

...and these have distorted CMS audio on the same hardware:

Budokan (music is fine, but after a while, noise channel starts to creep in)
Jones in the Fast Lane (bad/missed notes)
Prince of Persia (bad/missed notes)
Puzzznic (music is fine, but after a while, noise channel starts to creep in)
Qix (music is fine, noise channel is firing when it shouldn't)
Rambo III (music is fine, but after a while, noise channel starts to creep in)
Times of Lore (lots of noise and missed notes, which is a shame since it's one of the better CMS sountracks)

It's worth reiterating that all of the CMS demo software works 100% on this hardware combination. The simplest explanation is that not all game programmers coded the CMS sound routines correctly. My guess is that they're performing an OUT DX,AX as an optimization when the hardware needs OUT DX,AL, and bus settle time between bytes sent.

Reply 61 of 71, by Scali

User metadata
Rank l33t
Rank
l33t

So, it is confirmed that even the real CMS card has issues with some software, presumably related to the speed and/or 16-bit bus of the 286.
I am not sure about the bus settle time thing though. I thought the OPL2/OPL3 were unique in that. As in, the SN76489 does not have this problem, because it simply doesn't release the bus until it is done processing.
I thought the SAA1099 was the same, and in my own code I didn't add any delays between writes. That did not appear to give any problems on a 20 MHz 286. But perhaps I need to test some more.
Even more important is to study the code of Prince of Persia and other troublesome games.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 62 of 71, by Scali

User metadata
Rank l33t
Rank
l33t

Did a quick check:
Prince of Persia 1.0 does not appear to use out dx, ax, but only out dx, al.
I have consulted the data sheets, and they do say there are two different timings for the chip. Any register write, except for amplitude, takes 4 bus cycles. Amplitude writes take 16 cycles.
The data sheets also claim that the DTACK line should take care of the timing.
So perhaps the DTACK line is not implemented correctly on the card, or not on faster/newer systems.
Either that, or the problem may not be hardware-related at all, and there might just be some kind of corruption going on in the code/data.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 63 of 71, by MobyGamer

User metadata
Rank Member
Rank
Member

Jones' CMS driver (bad) performs all output to the card thusly:

out     dx, al
dec dx
mov al, bl
out dx, al

Oil's Well's routine (good) is slightly different:

out     dx, al
dec dl
mov al, cs:[si]
inc si
out dx, al

I wonder if the cs:[si] memory access is just enough to slow it down to make it work?
Looking at others: Rastan's routine (good) does the typical bus settle:

out dx,al
jmp short $+2
dec dx
mov al,ah
out dx,al

What's confusing is that Qix is almost good; it starts out fine but after about 10 seconds of the title music, the noise channels start firing when they aren't supposed to -- and it uses the same routine as Rastan.

So, what does the official CMS software use? Here's the relevant portion of CMSDRV.COM:

loc_10695:
inc dl
lodsb
out dx, al
dec dl
lodsb
out dx, al
loop loc_10695

So, memory accesses between outputs, possibly slowing it down and giving the CMS card enough time to settle. This is just a guess though.

I wish this were all 100% conclusive, but it's only about 80% conclusive. My firm opinion is that the CMS card, and CT-1320, are not "at fault" or "damaged", but rather that various programmers didn't program for the card correctly. The CMS software works perfectly (I let the demo songs play over 20 minutes, didn't hear a single obvious error) so I think that is the most pertinent evidence -- if the cards were "bad", then they wouldn't sound good with *any* software.

Last edited by MobyGamer on 2018-10-23, 01:48. Edited 7 times in total.

Reply 64 of 71, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Sorry for intruding, I don't mean to disturb this thread. 🙁
Just like to mention that some mainboards seem to have issues with providing an OSC signal on ISA pin B 30.
I don't know the schematics of the CMS well enough to make a statement, but maybe it's worth checking, still.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 66 of 71, by Scali

User metadata
Rank l33t
Rank
l33t
MobyGamer wrote:

I wish this were all 100% conclusive, but it's only about 80% conclusive. My firm opinion is that the CMS card, and CT-1320, are not "at fault" or "damaged", but rather that various programmers didn't program for the card correctly. The CMS software works perfectly (I let the demo songs play over 20 minutes, didn't hear a single obvious error) so I think that is the most pertinent evidence -- if the cards were "bad", then they wouldn't sound good with *any* software.

I suspect the same thing, so I agree with you.
However, I think I have come up with a way to make sure:
I think we can use DOSBox to capture the CMS data (if not the regular DOSBox, I have a version, made by NewRisingSun, which captures VGM, and I'm quite sure it supports CMS captures).
Once we have the raw music data, we can play it back with our own routines, and experiment.
If taking the captured music from a 'bad' game, and playing it through a routine with extra delays fixes it, then we are at least 90% sure that this is the problem (and conversely, if we capture music from a 'good' game, and playing it without delays makes it 'bad', we are even more sure).
What's more: we then know how to fix it: we can just patch some delays into the game's code.

If so, then I think there are two possible explanations:
1) The SAA1099 chips don't handle the DTACK correctly, which means they release the bus before the chip is ready to receive new data (OPL2/OPL3 also have this issue, although in this case we know it is by design. The reason is probably because the FM chips have a very long processing 'cycle', which would lead to hogging the bus and halting the CPU for extended periods of time).
2) The problem is not in the SAA1099 chips, but even the original CMS cards have a dodgy implementation of the bus logic.

In either case, at least we know that even the original CMS card suffers from the problem, so the workaround would have to be applied to all CMS-compatible hardware.

Edit: The VGM-capture patch for DOSBox was made by NewRisingSun:
http://vgmrips.net/forum/viewtopic.php?t=2585
I have also verified that it captures CMS data.

Last edited by Scali on 2018-10-26, 14:00. Edited 1 time in total.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 67 of 71, by Scali

User metadata
Rank l33t
Rank
l33t
Jo22 wrote:

Sorry for intruding, I don't mean to disturb this thread. 🙁
Just like to mention that some mainboards seem to have issues with providing an OSC signal on ISA pin B 30.
I don't know the schematics of the CMS well enough to make a statement, but maybe it's worth checking, still.

The CMS card does not have its own oscillator, it derives its clock from the OSC signal.
Which would imply that when the OSC signal is bad, the pitch of the card will also be affected.
I don't think that is the case here. The pitch seems correct, it seems more like especially amplitude commands are not processed properly, resulting in some channels being silent when they should be playing, and channels generating sound when they should be silent.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 68 of 71, by Scali

User metadata
Rank l33t
Rank
l33t
aquishix wrote:

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.

The original RAM check in the 5150 and 5160 was extremely slow.
I have a late 5160 from 1987, with the last BIOS revision, which is much faster.
Back at Revision 2015, reenigne and I both had our 5160s sitting side-by-side, and he had an old revision BIOS. The difference in memory check was quite interesting.

My guess is that most clones use a fast memory check. And you may have an early BIOS revision. Either that, or even the last revision is still quite slow compared to your clone.

At any rate, there is no direct relation between memory access speed and BIOS memory check. The only way to test memory speed is to run the same routine on both, with a benchmark like TOPBENCH.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 69 of 71, by MobyGamer

User metadata
Rank Member
Rank
Member

I had a thought: I tested a real CMS card on a 286-10. But I have very distinct memories of hearing proper CMS audio with a Sound Blaster on a 386sx-16, from the programs that failed testing earlier in the month. So, I'm going to pull the CMS card back out and put it in a 386sx-16 and re-test this weekend.

Reply 70 of 71, by Scali

User metadata
Rank l33t
Rank
l33t

I did a quick test with Prince of Persia on my CMS clone card. The title screen plays the first note, which then sounds indefinitely. When I start a game, it plays the start jingle correctly, as far as I can tell.
So at the very least there's something fishy going on in the CMS code.
I tried disabling the turbo on my 286, switching it from 20 to 8 MHz, but it made no difference. Perhaps 8 MHz is still too fast for whatever problem the CMS code has.

So on to plan B: make a VGM capture of the title song, and experiment with replaying routines.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 71 of 71, by Scali

User metadata
Rank l33t
Rank
l33t

Quick capture of the Prince of Persia music plays just fine with my own VGM tools.
I use segcs lodsb before each byte I output though, so it is possible that this creates enough delay between the writes by itself.
I will do a lodsw instead, and then output the second byte with a mov al, ah. See what that brings.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/