Deksor wrote on 2022-03-09, 21:17:

"DSP Write Test" is where things seem to fail. I can't see anything there. All I see is the signal being stuck to high. However I can hear in the audio output that something is happening. (A very slight noise when the test runs)

Is my 20MHz oscilloscope too slow to view the signal ? Is there a problem ?

A 20MHz scope is not to slow to view anything ISA related. Yet I guess your scope is part of why you don't see anything. The DSP addressing test continously hammers the DSP chip with read cycles, so your scope gets enough pulses to show stuff. On the other hand, the DSP write test tests for DSP readiness (takes a microsecond) and if that test fails, the program sleeps for a milliscond. So after every relevant event, there is a long gap (1000x the event duration) until the next event happens (in case the DSP readyness test always fails, which might fit your symptoms). Analog scopes are not very good at picking up single events with long gaps between them - but a 1kHz repetition rate should be enough to get a stable display of the pulses - as long as the scope doesn't get "impatient" and displays the flat line in the pause even if there is no trigger event. There is a setting on the scope whether it might get impatient or whether it will wait indefinitely for a triggering event: That's the auto/norm switch. Put it to norm, and you should be able to see 1µs events that happen every ms - if the trigger level is correctly set up and the time base is fast enough to show 1µs events (so you should be at something like 5µs/div or faster.

Well I just received a new digital scope, but I haven't installed it yet, so I guess I have two ways to solve this now 😀 Thanks !

I've built 3 of these now I think? The first one I had lots of trouble with because of a faulty IC, eventually found that probing around voltages for the amp etc while it was powered.

Your one is missing a part, the TXD & RXD jumpers are missing? They should both be connected at the top

Yikes, I thought that was only for debugging, I'll fix that tomorrow and try again, though isn't this only used for Midi ? I guess the DSP problem won't be fixed by that

You might have better luck with a logic probe that can detect short pulses, rather than an analog scope.

Trace the write pulse as far as you can:
1. Pin 11 of U18 (the latch)
2. Pin 9 and pin 10 of U27
3. Pin 12 of U28 (should pulse when the write port is addressed. This is driven by U8 which should be working because the address test worked, but test this signal anyway.)
4. Pin 6 of U16 (should pulse low all the time, it's a buffered ISA bus signal)
5. Pin 4 of U16 (definitely should be pulsing, it's directly off the ISA bus)
6. Pin 5 of U16 (should always be high)

There's a chance the DSP MCU isn't responding for whatever reason.
1. Look for oscillation on pins 18/19 of U13.
2. See if any values get written to the latch U18 by looking at its data outputs before and after running the test.
3. You can check for a pulse on pin 1 of U18 to see if the MCU is trying to read the latch at all.
4. The MCU gets the signal that there is data available in the latch with the flag stored in flip flop U22B. Check pin 9 of U22 to make sure it asserts after a value is written to the port.

Hopefully that's enough to get you started.

Ok so I hooked up my shiny new scope (sorry for the picture quality, taking pictures while probing isn't easy)

Ok so this doesn't look right at all, doesn't it ?

This one looks correct

This one too

This looks really bad

Continuing....

Now this is weird. If I understand properly, this is connected straight to the ISA bus ? Could this mean my motherboard has a bad ISA bus ??

Or is it u16 that's bad ?

That one is ok I think

I don't know what to say for this one

So a lot of these signals don't look healthy at all.
Could this come from just U16 ? The motherboard ? Something else ? Wrong setup ?

MmmmMmmm, signal soup.

How does a fancy schmancy Rigol not have a screenshot/snapshot button?

Hi, sorry for Hijacking this Post. I have the same issue. I soldered 3 of them (some friends wanted one, too) and the issue is the same with all of them. All parts are ordered from mouser, so I don't expect a broken chip. The controller is a AT89S51-24PU. I programmed it with the classic Xgecu T48 and verified the programming, it seems to have worked. Still, on all cards, Adlib mode works but the TEST-SBC-Tool doesent find the card at any address (I tried all jumper settings).
Any ideas? Anybody willing to send/sell me a programmed DSP so I can try if it has a problem with my programmer?

Just to be sure, since it could maybe explain all three cards having issues: all other ICs are oriented to the left, but is the DSP correctly insterted and facing with pin 1 to the right?

Yes it is. That is sadly not the issue.
I can try what @TubeTimeUS suggested and trace signals with an LA, but it feels pretty unlikely that all 3 boards have the same soldering issue 🙁

@Deksor & @Physikant
Maybe both of you bought some rare component from the same seller, and it could be a fake?

I was also thinking of building this card (but ordering from farnell.com , as shipping from Mouser costs the same as the materials, in my case).
But after seeing this, i'm getting kind of scared TBH... 😟

I bought mine on mouser. I haven't touched the card in the past 2 years. I will revisit it someday but I'm busy with other topics 😒

Hello.
I just finished my first Snark Barker and I have exactly the same issue.
I checked every IC with an IC tester, they are ok.
I checked with sbdiag and an oscillo. DSP adressing if running well but DSP Write test doesnt work , there is no signal.
I'm asking if a fake or malfunctionning 89s51 could be possible. I programmed it with a T48. The only point is that I had to disable check id for flashing because of a bad id (FF FF). I checked the ATMEL with oscillo. Tensions are good. The two oscillator pins are ok. DAC ouput are 5v. I already changed all the IC without success.
I will try today to quickly mount another snark barker (only the dsp part, no need for audio amplification , cms or opl) to try if I have the same issue.
I already ordered old 89C51 (not S, this time) for comparison.

More news.
I quickly made a second card.
The issue is exactly the same. So I'm pretty sure that the problem is the dsp. Adlib works, cms is detected and working with sbdiag. Dsp adressing pulses. Dsp writes doesnt pulse at all. The dsp is sleeping.....
So I really suspect 89s51. Maybe the t48 programmation is not well working ?
Will wait for C version and try it.

I have used both the C and S version in a real soundblaster card and both worked fine, I was using the 52 though.

maxtherabbit wrote on 2024-05-01, 16:54:

I have used both the C and S version in a real soundblaster card and both worked fine, I was using the 52 though.

That is going my way.
Orderer also 52 but it "shouldn't" make any difference.

Just had a quick look at what I was using about 5 years ago: those were AT89S51-24PU which came from mouser.

And they're actually still available there:
https://www.mouser.de/ProductDetail/556-A89S51-24PU