Pages: [1] 2 3 4   Go Down
  Print  
Author Topic: SAA1099 (CMS) Chips on a Sound Blaster 2.0  (Read 22359 times)
0 Members and 1 Guest are viewing this topic.
Salient
Senior Member
*
Offline Offline

Posts: 248


There is no final truth


View Profile WWW
« on: June 10, 2008, 07:22:49 PM »

Hi,

I'm new here and I hope you all don't mind the question i'm about to ask (It might have been asked a million times before so I hope noone get's agitated).
I have an old Sound Blaster 2.0 here and would like to 'upgrade' it with the CMS soundchips. Now I already found the chips themselves on eBay (thanks to this forum) but I am confused about the 3rd empty socket on the card. What is supposed to fit in there and is it neccesary for the CMS option to function correctly?

Thanks in advance,
Marnix.
Logged

My sound stuff: << here >>
For sale: << here >>
New MIDI comparison website: << wavetable.nl >>
mace
Senior Member
*
Offline Offline

Posts: 396



View Profile
« Reply #1 on: June 10, 2008, 07:27:13 PM »

What is supposed to fit in there and is it neccesary for the CMS option to function correctly?

It is supposed to fit a custom chip and yes it is necessary, you are sh*t out of luck.

That socket is supposed to contain the specialty chip which basically hooked the chips up to the ISA bus.
It was a PAL chip, programmed in the factory, and as of yet it has not been reverse-engineered.
They are extremely rare and I think you'll have lots of trouble finding it.
« Last Edit: June 10, 2008, 07:28:52 PM by mace » Logged


Using in/on my rig now:
MT-32 first gen, CM-64, SC-155, NEC DB60XG, Yamaha FB-01, AWE64 Gold, MPU-IPC-T
Salient
Senior Member
*
Offline Offline

Posts: 248


There is no final truth


View Profile WWW
« Reply #2 on: June 10, 2008, 07:34:14 PM »

It is supposed to fit a custom chip and yes it is necessary, you are sh*t out of luck.
...
They are extremely rare and I think you'll have lots of trouble finding it.

Okay, not what i wanted to hear  Grin but at least I know what I'm up to.
It's probably easier to find myself a Sound Blaster 1.5 then, since I already ordered the CMS chips I don't want them to go collect dust.
Logged

My sound stuff: << here >>
For sale: << here >>
New MIDI comparison website: << wavetable.nl >>
BlueMax
Senior Member
*
Offline Offline

Posts: 922



View Profile WWW
« Reply #3 on: June 11, 2008, 12:08:46 AM »

Cool choice of avatar at least!  Smiley
Logged

AAAAAAAAUUGHH!!!! - Charlie Brown
Salient
Senior Member
*
Offline Offline

Posts: 248


There is no final truth


View Profile WWW
« Reply #4 on: June 11, 2008, 11:02:15 AM »

Cool choice of avatar at least!  Smiley

Thanks Smiley
LSL1 was the first adventure I ever played on the PC so it has to do with nostalgia.
Logged

My sound stuff: << here >>
For sale: << here >>
New MIDI comparison website: << wavetable.nl >>
Laust
Senior Member
*
Offline Offline

Posts: 722


View Profile
« Reply #5 on: June 11, 2008, 10:14:21 PM »


That socket is supposed to contain the specialty chip which basically hooked the chips up to the ISA bus.
It was a PAL chip, programmed in the factory, and as of yet it has not been reverse-engineered.
They are extremely rare and I think you'll have lots of trouble finding it.

Why is that, I wonder? presumably because no one tried...  The PAL16L8 used on the SB is pure combinatorial logic (no hidden state information inside) and would be trivial to reverse engineer.
Logged
Cloudschatze
Moderator
Senior Member
*
Offline Offline

Posts: 1,948



View Profile
« Reply #6 on: June 11, 2008, 11:00:24 PM »


That socket is supposed to contain the specialty chip which basically hooked the chips up to the ISA bus.
It was a PAL chip, programmed in the factory, and as of yet it has not been reverse-engineered.
They are extremely rare and I think you'll have lots of trouble finding it.

Why is that, I wonder? presumably because no one tried...  The PAL16L8 used on the SB is pure combinatorial logic (no hidden state information inside) and would be trivial to reverse engineer.

I'll let you borrow mine, if you want to figure it out. Smiley

I never did buy a programmer...
Logged
mace
Senior Member
*
Offline Offline

Posts: 396



View Profile
« Reply #7 on: June 12, 2008, 07:18:55 AM »

The datasheet says the following:

"Once the PAL device is programmed and verified, an additional connection may be opened to prevent pattern readout. This feature secures proprietary circuits."

and:

"Security Fuse"
"After programming and verification, a PAL16R8 Family design can be secured by programming the security fuse. Once programmed, this fuse defeats readback of the internal programmed pattern by a device programmer, securing proprietary designs from competitors. When the security fuse is programmed, the array will read as if every fuse is programmed."

So there you go.   Wink
« Last Edit: June 12, 2008, 07:24:08 AM by mace » Logged


Using in/on my rig now:
MT-32 first gen, CM-64, SC-155, NEC DB60XG, Yamaha FB-01, AWE64 Gold, MPU-IPC-T
Laust
Senior Member
*
Offline Offline

Posts: 722


View Profile
« Reply #8 on: June 12, 2008, 02:25:32 PM »

That's the datasheet for the PAL16R8, however as indicated in one of Cloudschatze's older posts (too lazy to find the link), the SB uses an PAL16L8 and that makes a world of difference. The R-variant has internal memory (flip flops), which means you can't see what happens inside the chip and how it affects the output. However, the L model is purely combinatorial. The output is always (and only) depent on the input. For a given input, you always get the same output.

That means you can essentially map the chip out, by trying every binary input combination and making a note of what the output is. Once you have the output, you run it through a boolean algebra optimizer and hopefully end up with boolean expressions you can put into a new chip Smiley
Logged
mace
Senior Member
*
Offline Offline

Posts: 396



View Profile
« Reply #9 on: June 12, 2008, 06:41:33 PM »

That's the datasheet for the PAL16R8, however as indicated in one of Cloudschatze's older posts (too lazy to find the link), the SB uses an PAL16L8 and that makes a world of difference. The R-variant has internal memory (flip flops), which means you can't see what happens inside the chip and how it affects the output. However, the L model is purely combinatorial. The output is always (and only) depent on the input. For a given input, you always get the same output.

That means you can essentially map the chip out, by trying every binary input combination and making a note of what the output is. Once you have the output, you run it through a boolean algebra optimizer and hopefully end up with boolean expressions you can put into a new chip Smiley

Right, no flip flops means no memory, meaning that a previous input has no ability to affect the output, meaning you only have to bruteforce 10 inputs and 6 I/O ports.
I thought it had the flip-flops, and when you have to take in account that previous states can influence future ones it suddenly becomes infinitely more complex

So at worst 16 bits, meaning 65536 possible combinations. You could theoretically get the info needed in seconds or less.
Optimizing it will take longer I guess because of all the redundant data, combinations of input that will never happen.
Also knowing the specs for the CMS chips and the ISA bus can be useful to root out all the unused stuff.

The problem is probably finding people with the skill to do this, but also willing to work on such a "niche" hack.

I would work on it, but I'm no expert on any of this, I just know the basics of PALs and boolean algebra and such.
« Last Edit: June 12, 2008, 06:43:32 PM by mace » Logged


Using in/on my rig now:
MT-32 first gen, CM-64, SC-155, NEC DB60XG, Yamaha FB-01, AWE64 Gold, MPU-IPC-T
Laust
Senior Member
*
Offline Offline

Posts: 722


View Profile
« Reply #10 on: June 12, 2008, 09:10:05 PM »

Fortuately there are programs for optimizing boolean equations and fitting them into a PAL. Doing it by hand would be a huge task indeed Smiley

Actually I wonder if the L-series even has a security fuse as the datasheets don't mention it at all (in relation to PAL16Lxx) and it doesn't really add any security. Without the security fuse you don't even have to use brute force, you can simply read out the original programming. Time will tell...

Cloudschatze, let me get back to you (I'll see if I can't find some other equipment with PALs to experiment on first!)
Logged
mace
Senior Member
*
Offline Offline

Posts: 396



View Profile
« Reply #11 on: June 12, 2008, 09:24:36 PM »

This seems to be interesting as well:
http://www.eettaiwan.com/ARTICLES/2002SEP/A/2002SEP05_PL_AN.PDF?SOURCES=DOWNLOAD

It talks about programmers programming GAL devices emulating PAL devices, calling them RAL devices.
It mentions using a "master PAL" to read and then program.
Logged


Using in/on my rig now:
MT-32 first gen, CM-64, SC-155, NEC DB60XG, Yamaha FB-01, AWE64 Gold, MPU-IPC-T
Salient
Senior Member
*
Offline Offline

Posts: 248


There is no final truth


View Profile WWW
« Reply #12 on: June 15, 2008, 10:28:55 AM »

It seems near to impossible to find such a PAL chip but it also seems very hard to find a soundblaster 1.5 for sale, on ebay they won't show up (or I am searching the wrong way).
If there is anybody here that is willing to sell an sb 1.5 (I'm willing to trade my sb 2.0 and some cash from my side ofcourse too) please let me know. Smiley
Logged

My sound stuff: << here >>
For sale: << here >>
New MIDI comparison website: << wavetable.nl >>
mace
Senior Member
*
Offline Offline

Posts: 396



View Profile
« Reply #13 on: June 15, 2008, 10:03:46 PM »

I did some more research and asked around on some forums.

What it basically boils down to is this:

The programmers for PAL devices are expensive, too expensive for a project like this if you ask me.
The problem is that the programming algorithms for these devices are secret, and only available after sigining a NDA.
This is probably why there aren't any homebrew programmers.
Also, you have a big risk of the programming fuses being blown and not being able to read the PAL out.

The best way to do this is first looking at the circuit board and drawing up a simple schematic.
Then you can see what ports are input and what are output.
The next step is using a using a ISA I/O card, something based on a 82C55 or something and a simple program to send the different possible combinations of data to the PAL and reading out the output.
This data then needs to be compiled in a truth table, and have redundancies removed.

Using this truth table one could program a GAL16V8 using a homebrew galblast programmer, of which the schematics and software are freely available.

The GAL can be used as a direct replacement of the PAL.

This should all be possible.

« Last Edit: June 15, 2008, 10:04:25 PM by mace » Logged


Using in/on my rig now:
MT-32 first gen, CM-64, SC-155, NEC DB60XG, Yamaha FB-01, AWE64 Gold, MPU-IPC-T
Cloudschatze
Moderator
Senior Member
*
Offline Offline

Posts: 1,948



View Profile
« Reply #14 on: June 16, 2008, 03:07:41 AM »

It seems near to impossible to find such a PAL chip but it also seems very hard to find a soundblaster 1.5 for sale, on ebay they won't show up (or I am searching the wrong way).
If there is anybody here that is willing to sell an sb 1.5 (I'm willing to trade my sb 2.0 and some cash from my side ofcourse too) please let me know. Smiley


http://www.a1usedcomputers.com.au/shop/prodView.asp?idproduct=311
Logged
Salient
Senior Member
*
Offline Offline

Posts: 248


There is no final truth


View Profile WWW
« Reply #15 on: June 16, 2008, 06:54:31 AM »

Tnx! I'm going to order it. Smiley

Update: I ordered it. With the shippingcosts it's not exactly called cheap but I guess it was the only option not to let the CMS chips go to waste. Smiley AND i get to keep my SB 2.0 Cheesy

Update2: I received the SAA1099P chips so now I'm waiting for the SB 1.5 to arrive Smiley
« Last Edit: June 17, 2008, 05:33:35 PM by Salient » Logged

My sound stuff: << here >>
For sale: << here >>
New MIDI comparison website: << wavetable.nl >>
Laust
Senior Member
*
Offline Offline

Posts: 722


View Profile
« Reply #16 on: June 17, 2008, 09:02:45 PM »

I did some more research and asked around on some forums.

What it basically boils down to is this:

The programmers for PAL devices are expensive, too expensive for a project like this if you ask me.
The problem is that the programming algorithms for these devices are secret, and only available after sigining a NDA.

Nah, old databooks have the algorithms and TI has them on their website (as glorious "fax" quality scans), maybe others too.

Quote
This is probably why there aren't any homebrew programmers.

Try magazines like Elektor 15-20 years ago Smiley

No one in their right mind would use a PAL today when GALs are available, which probably goes a long way towards explaining the lack of info on the subject.

Quote
The best way to do this is first looking at the circuit board and drawing up a simple schematic.
Then you can see what ports are input and what are output.
The next step is using a using a ISA I/O card, something based on a 82C55 or something and a simple program to send the different possible combinations of data to the PAL and reading out the output.
This data then needs to be compiled in a truth table, and have redundancies removed.

This was basically what I had in mind, except for the cumbersome part involving ISA cards. Any (EP)ROM reader can read out the PAL with a simple adapter.

Logged
mace
Senior Member
*
Offline Offline

Posts: 396



View Profile
« Reply #17 on: June 17, 2008, 09:35:34 PM »

The best way to do this is first looking at the circuit board and drawing up a simple schematic.
Then you can see what ports are input and what are output.
The next step is using a using a ISA I/O card, something based on a 82C55 or something and a simple program to send the different possible combinations of data to the PAL and reading out the output.
This data then needs to be compiled in a truth table, and have redundancies removed.

This was basically what I had in mind, except for the cumbersome part involving ISA cards. Any (EP)ROM reader can read out the PAL with a simple adapter.

Okay, but can the EPROM reader do the bruteforce thing?
« Last Edit: June 17, 2008, 09:36:01 PM by mace » Logged


Using in/on my rig now:
MT-32 first gen, CM-64, SC-155, NEC DB60XG, Yamaha FB-01, AWE64 Gold, MPU-IPC-T
Laust
Senior Member
*
Offline Offline

Posts: 722


View Profile
« Reply #18 on: June 18, 2008, 04:53:42 AM »

Map PAL inputs to address-lines, outputs to data-lines. The reader can't tell the difference Smiley

It would even be possible to use an EPROM as a replacement for the PAL (you don't even need to optimize the logixc, the EPROM can store all possible combinations), but EPROMs are much slower so it's not guaranteed to work.
Logged
mace
Senior Member
*
Offline Offline

Posts: 396



View Profile
« Reply #19 on: June 18, 2008, 06:54:00 AM »

Map PAL inputs to address-lines, outputs to data-lines. The reader can't tell the difference Smiley

It would even be possible to use an EPROM as a replacement for the PAL (you don't even need to optimize the logixc, the EPROM can store all possible combinations), but EPROMs are much slower so it's not guaranteed to work.
Yeah, I read that somewehere.
The propagation delay for that particular PAL is 4 or 5 ns I think
Logged


Using in/on my rig now:
MT-32 first gen, CM-64, SC-155, NEC DB60XG, Yamaha FB-01, AWE64 Gold, MPU-IPC-T
Pages: [1] 2 3 4   Go Up
  Print  
 
Jump to: