• Please review our updated Terms and Rules here

Problem with CMS upgrade on a rev0 CT1350

Chuck(G) said:
Anyone care to post a couple of nice detailed photos of the Rev 1 board that I did the original work with? Since I don't have it to compare with, I'm guessing that they're very close, but let's see...
Click to expand...

Here are photos of the original card I sent:

http://www.symphoniae.com/misc/ct1350b_a.jpg
http://www.symphoniae.com/misc/ct1350b_b.jpg

The "revision" criteria is debatable (that is, the assumption that all unmarked cards are "Rev 0"), considering the fact that all of the cards I own without any revision designation were manufacturered after those that do have some revision marking.
 
Thanks, CS!

Well, comparing the two, my "Rev0" actually has a later manufacturing date(9419) than the one pictured (1192). Not just that, the one pictured has the Creative IC as a CT1336 ©1991, but the "Rev0" that I have has a CT1336A ©1993! However your serial number (336334) comes after the "Rev0" here (329786).

As closely as I can tell, there's no difference in the PCB traces, though I might well have missed something.

Does anyone have any idea of what's going on with these two? :huh:
 
So we might be totally wrong naming those boards "rev0" after all... one would expect that the later models would have revision markings not the other way around LOL
Sadly my other card is a "rev0" too so I can't help with that... I am excited to see what you'll come up with Chuck(G) :)
 
We'll figure it out--but note that about the only thing that can be categorically stated at this point is that Creative was incredibly sloppy. Note that the serial number sticker on both boards identifies them as "Model No. CT 1350A".
 
I want to make sure that I'm doing this right.

Can anyone give me a simple test program (like testsbp) that I can run from a command line that will exercise this facility? If necessary, I want to do some probing while it's running.

Please do not suggest a game. I'm not a game person and have little patience with them.
 
Chuck(G) you don't have to actually play a game...
you can start the Wolfenstein3D demo for example and see that SB won't be recognized or ever Creative's DIAGNOSE.EXE that is part of the CT-1350 driver will fail to find the card
I can't think of a simpler test ATM but I bet someone will suggest something better :confused:

From what I understood you are looking for something that will try and detect the card while you do some readings on it? Like a sound app that you keep making it to try and detect the SB by pressing a test/retry button or something?
 
Is this with new CMS code or with the old one?
If it's with the old one then I guess it's no good and testsbp is an exception , else it's surely an advancement :D what about DIAGNOSE.EXE ? does it work too?
 
You will need two, the TEST-SBC.EXE for the original Sound Blaster 1.0 and the TEST-SBC.EXE for either the Sound Blaster 1.5 or 2.0. The 1.0's test will only test C/MS and the 1.5 and 2.0's test will only test FM.
 
"That comes as close to the original PAL as possible"--that's just the issue; we probe the original PAL, but it's got the security fuses blown, so all we can do is probe it and observe the behavior and extrapolate from that (or didn't you read my blog :) ?).

At any rate, SB test 1.0 and 2.0 pass as well as the SB Pro test (the pro test seems to use water sounds rather than "Hello dere" voices). The SB Pro 16 4-channel FM test doesn't pass, but then I don't know if it should. SB test 1.5 finds the card (IRQ DMA and port) and then hangs. I don't know what that means.

At any rate, this is using a Lattice GAL16V8B compiled using WinCUPL. JED file attached.
 

Attachments

  • SB20GAL2.ZIP
    521 bytes · Views: 1
Chuck(G) can you do a quick test? remove the gals and restore the CMS jumper and see if the same test fail or complete?
That will show if the GAL code has anything to do with the failure IMHO
 
Chuck(G) said:
"That comes as close to the original PAL as possible"--that's just the issue; we probe the original PAL, but it's got the security fuses blown, so all we can do is probe it and observe the behavior and extrapolate from that (or didn't you read my blog :) ?).

At any rate, SB test 1.0 and 2.0 pass as well as the SB Pro test (the pro test seems to use water sounds rather than "Hello dere" voices). The SB Pro 16 4-channel FM test doesn't pass, but then I don't know if it should. SB test 1.5 finds the card (IRQ DMA and port) and then hangs. I don't know what that means.
Click to expand...

It should fail a 4-FM test, because it requires a different FM chip. The SB1.5 test is apparently speed sensitive for whatever reason, so the failure should not be determinative.
 
The board works without a GAL and the CMSOFF setting doesn't seem to matter. It also works with a GAL and with CMSOFF on or off. Which figures, since the CMSOFF pin is connected to GAL pin 7, if I read the PCB correctly. Pin 7 is fed through to pin 13, which is tristated by ISA IO CH RDY.

On the other hand, there's no sense to an open input on the GAL. I wonder if a pullup from pin 7 to Vcc might be just the ticket--nothing big, say 10K. I'll give a try when I get home (very late) tonight, if I get a chance.

...which is why I'm looking for a simple program to test the added CMS portion of the card.
 
Last edited:
Well, you're not going to like this. I did three trials, one with Lattice GAL16V8D supplied and programmed with the card, and a Lattice GAL16V8B that Agent Orange supplied, programmed with the new JEDEC file and a National GAL16V8 programmed with the old one. The board is set for port 22X, DMA 1, IRQ 5, DMACTL on pins 2-3, JYEN and no jumper on CMSOFF (if I put that on, the Paku-paku is silent).

Running Paku-Paku, all three GALs work! (i.e. I get the opening music(?) when I hit return).

FWIW, my system has lots of stuff in it, but the salient stuff is an XTIDE, a DTK Minicmicro FDC and a Tseng VGA card and P+2S card). I also have an Intel Aboveboard 286 with 8MB and an Artisoft AE-2/T NIC, but drivers aren't loaded for those. The board is a no-name "Turbo" clone running a V20 at 4.77MHz for the test.

Any ideas?
 
Yes, I got my rev 0 board working with a Lattice GAL16V8B(like the one that I sent to Chuck(G)) runnning Paku /CMS. Hovever, the sound is choppy, especialy when you start moving the Pak Man and he starts eating the dots. It seems like it can't play the separate voices together but is "Jumping" from one voice to the next and therefore sounds "Choppy". If I completely remove the CMS upgrade and put the jumper back on(CMS OFF) and run PAKU, it sounds a lot better. I would like to hear what a rev 1 or 2 board sounds like running PAKU /CMS. Also, when the CMS upgrade is installed, I thought that I'd be able to force Sound Blaster mode by entering PAKU /ADLIB. But no sound comes out. Does the CMS option force the card to work in "Game Blaster Mode"? However, without the upgrade, PAKU /ADLIB or PAKU without any parameters sounds perfect. Maybe, there is a problem with my board. Maybe, My AST HotShot 286 Accelerater is messing with the timing when the CMS upgrade is used. Next, I'll try removing the Accelerater and trying the CMS option with a stock IBM 5155 with 8088. Any thoughts?
 
Last edited:
Well the original problem with "rev0" cards was that CMS worked fine and SB/Adlib did not when the upgrade was in place, so I am pretty sure ibmapc that your board is fine.
Even with the old chips/code CMS is perfect and is detected every time in more games like Monkey Island or Slipheed... Paku Paku was just a small suggestion to test CMS without much truble. (but I don't remember it being choppy , infact it sounds very very close to the arcade machine)

Chuck(G) I am afraid my friend you need to test some games to see if sb/adlib works there is no escape for you :p CMS has been proven to run fine even with the old code, the sb part gets it...

I am probably just writing BS now but if I understood correctly a GAL pin is pointing to the ISA bus waiting some call to wake up right? (at port 240 IIRC, the standard gameblaster one?) Isn't there a way to make the GAL "turn off" completely until said call is received? From what I guess the problem most likely is that CMS mode is always ON thus "killing" the SB mode whereas it should be 2nd in priority and only activating when CMS is poked... So you basically have a card waiting in a "neutral state" for calls in 220 and 240 and whatever call is made then it either works as a SB@220 or CMS takes control does it's stuff (and killing sb since to do it) and then return to "neutral state" (which is SB mode active until someone activates the 240 port) or is this already implemented? (as I said this prolly bs coming from someone without code understanding but I feel I can speculate a little without being judged hard :D )
 
So if I'm running the SBTEST programs (1.0, 2.0 and Pro), I'm not using the non-CMS features? Those seem to work whether or not I have the CMSOFF jumper set.

So how I test the SB/Adlib part for sure and certain?

Remember that the GAL as used here is plain old combinatorial logic--no memory elements inside.
 
You must log in or register to reply here.
Back
Top