appiah4 wrote on 2024-05-24, 14:54:

I also initially had similar issues due to my Atmel DSP acting up but reflashing it did the trick for me..

is there anything special you have to do? I just selected the chip from the menu, loaded the hex file and hit program but I've had others in the past that needed certain fuse values set.

also, the DSP doesn't appear to be connected to the SAA chips in anyway. those should be completely independent correct?

snipe3687 wrote on 2024-05-24, 16:20:

also, the DSP doesn't appear to be connected to the SAA chips in anyway. those should be completely independent correct?

If I remember correctly, the SAA chips are quite slow and accessing them is supposed to generate wait-states on the ISA bus using the IOCHRDY line. If your system locks up as soon as you access the SAA chips, I highly suspect the wait-state generation circuit to be the culprit, inserting an infinite number of waitstates.

mkarcher wrote on 2024-05-24, 19:56:

snipe3687 wrote on 2024-05-24, 16:20:

also, the DSP doesn't appear to be connected to the SAA chips in anyway. those should be completely independent correct?

If I remember correctly, the SAA chips are quite slow and accessing them is supposed to generate wait-states on the ISA bus using the IOCHRDY line. If your system locks up as soon as you access the SAA chips, I highly suspect the wait-state generation circuit to be the culprit, inserting an infinite number of waitstates.

So I tested the second chip in there and that one worked so I replaced U15, which was the one that was causing me an issue and that worked so this CMS side is working now the DSP seems to be my only problem. It’s weird when I run the test And I checked the version sometimes I’ll get 1.02 and sometimes I get 2.01 so something funky either with the test or the DSP chip itself but the non-DMA test works just about every time but the DMA test and the digital audio playback test Are pretty hit and miss sometimes they work sometimes they don’t so I’m leaning towards a problem with the DSP chip. I flashed it again but it’s still the same issue. All the solder joints looks fine and I’ve reseated it a couple times so maybe I got a bad ship like some of these other people .

snipe3687 wrote on 2024-05-24, 20:03:

It’s weird when I run the test And I checked the version sometimes I’ll get 1.02 and sometimes I get 2.01 so something funky either with the test or the DSP chip itself

If you sometimes get the wrong version number, the interface between the ISA bus and the DSP is obviously not working reliably, or (of course) the DSP itself might be bad. Reading the DSP version is an operation that reads the major version first and the minor version after that, so the DSP is going to send a 2, wait for it to be read by the computer and then the DSP will send a 1. There is no way the 1 and 2 can be mixed up on the card by "swapping bytes", as the bytes are produced sequentially by the fixed DSP program. If you get 1.02, it seems like you get a spurious extra 1. This can happen if the CPU sees a false "data ready" indication before the major version byte 02 has been sent, reading the 01 from the previous version request again, and only picking up the major version byte when it tries to read the minor version byte. The management of the data ready flag is performed by U22 (keeps the data ready flags for the CPU and the DSP), U27 (decides when to send a ready flag to the CPU) and U21 (actually forwards the ready flag to the ISA bus driver). U2 is involved in passing the output of U27 to the ISA bus, but if U2 had an issue, you will get worse symptoms than just DSP communication issues, as all components on the cards are accessed through U2.

The Snark Barker uses positive logic to indicate "data ready" (i.e. "high" = "there is data"), furthermore, LS-chips tend to interpret "no one drives the input pin" as high. Failure to output any ready signal may generate a false ready signal.That's why I would suggest to start troubleshooting by checking for bad solder joints (or bent pins if inserted in a socket) at U22, U27 and U21.

mkarcher wrote on 2024-05-24, 20:36:

snipe3687 wrote on 2024-05-24, 20:03:

It’s weird when I run the test And I checked the version sometimes I’ll get 1.02 and sometimes I get 2.01 so something funky either with the test or the DSP chip itself

If you sometimes get the wrong version number, the interface between the ISA bus and the DSP is obviously not working reliably, or (of course) the DSP itself might be bad. Reading the DSP version is an operation that reads the major version first and the minor version after that, so the DSP is going to send a 2, wait for it to be read by the computer and then the DSP will send a 1. There is no way the 1 and 2 can be mixed up on the card by "swapping bytes", as the bytes are produced sequentially by the fixed DSP program. If you get 1.02, it seems like you get a spurious extra 1. This can happen if the CPU sees a false "data ready" indication before the major version byte 02 has been sent, reading the 01 from the previous version request again, and only picking up the major version byte when it tries to read the minor version byte. The management of the data ready flag is performed by U22 (keeps the data ready flags for the CPU and the DSP), U27 (decides when to send a ready flag to the CPU) and U21 (actually forwards the ready flag to the ISA bus driver). U2 is involved in passing the output of U27 to the ISA bus, but if U2 had an issue, you will get worse symptoms than just DSP communication issues, as all components on the cards are accessed through U2.

The Snark Barker uses positive logic to indicate "data ready" (i.e. "high" = "there is data"), furthermore, LS-chips tend to interpret "no one drives the input pin" as high. Failure to output any ready signal may generate a false ready signal.That's why I would suggest to start troubleshooting by checking for bad solder joints (or bent pins if inserted in a socket) at U22, U27 and U21.

Checked the chips you mentioned, and all solder joints look good. since they were brand new chips I soldered directly to the board.
Weird thing happens though, when I move the card side to side in the ISA slot it seems to work sometimes. Very strange. I can do the same thing with the adlib and the card does the same thing but adlib works consistently where the DSP chip just locks up completely when I try to do the DMA test. the non-DMA seems to work most of the time but it still seems like maybe my DSP chip has a problem. I've ordered replacements so hopefully that will solve it. Otherwise, I have no idea what to check next.