Falcon + CUBASE AUDIO + SCSI - Experiences?

[exxos]

Reply from Czuba.

The SDMA clock is the peak of the iceberg : around that there is a timing problem on some SDMA chips (yes you could try to replace the SDMA chip !) and the ST-ram accesses ...--> DRAM chips and timings with different behaviours... Same, we can say that combel, that is addressing the DRAM is too a part of the problem some times ... and some motherboards have more bad PCB route giving different clock timings ....So many factors to consider.

There are so many clock patch because nobody really did a complete logic analyse of the SDMA cycles with SDMA transfers ! My poor 16 channels logic analyser was not enough to do that...

A big pro laboratory logic analyser with 48 probes should do the job to really see what happen on the Data bus between SDMA and DRAM...

I can just tell that ST60 SDMA clock patch (see the CT60 fitting manual) was perfect for 99% of falcons I have touched...

So, good luck...

I'm not sure this is even a clock patch problem as the stock machines all work fine.

[exxos]

One small observation @Badwolf

With and without DFB1X, DSP_DS seems to glitch with the booster enabled.

IMG_3743.JPG (61.24 KiB) Viewed 201 times

IMG_3744.JPG (62.89 KiB) Viewed 201 times

U44..

dsp.PNG (175.39 KiB) Viewed 201 times

DSP_CS does stay low double the time with DFB1X enabled as well.

IMG_3746.JPG (66.1 KiB) Viewed 199 times

IMG_3745.JPG (62.85 KiB) Viewed 199 times

[Badwolf]

One small observation @Badwolf

With and without DFB1X, DSP_DS seems to glitch with the booster enabled.

Yes, that's odd. That DSP selection logic is convoluted. I wonder if we need to hold something off longer to avoid that?

Mind you, I doubt that's the problem, but it's certainly worth noting.

DSP_CS does stay low double the time with DFB1X enabled as well.

I seem to vaguely recall that from my endless DSP-related probing a few years ago. I think it was just down to timing with the GAL translation kind of working in reverse. I don't think there was anything wrong in relation to the DSP spec, but if something's cycle counting, perhaps it all adds up?

[viewtopic.php?p=74671#p74671]

BW

[exxos]

Yes, that's odd. That DSP selection logic is convoluted. I wonder if we need to hold something off longer to avoid that?

I seem to vaguely recall that from my endless DSP-related probing a few years ago. I think it was just down to timing with the GAL translation kind of working in reverse. I don't think there was anything wrong in relation to the DSP spec, but if something's cycle counting, perhaps it all adds up?

My only idea is I could rework my PLL clock patch and have the DFB1X 16mhz clock in sync with the MB 16mhz clock.. It may improve some things.. But I don't think it would solve the problem at hand It may at least gain a bit of information..

[Badwolf]

My only idea is I could rework my PLL clock patch and have the DFB1X 16mhz clock in sync with the MB 16mhz clock.. It may improve some things.. But I don't think it would solve the problem at hand It may at least gain a bit of information..

From memory, I don't think it's clock related at all. The GALs which do the DSP selection (and it's at least three of them) are working in a different mode when being driven by the expansion port versus the onboard CPU. I think that's where the offset is.

I can always been proven wrong, but I'd be surprised if the length of the pulse is a problem. The glitch is more interesting.

I'm fiddling with the diagnostic source to see if I can extract anythign useful from it.

BW

[Badwolf]

Use this pinout .. .@Badwolf I suggest doing 12-13 link first !

1 - 26
2 -( 1k )- 21
3 - 22
4 - 19
6 -( 1k )- 21
11 - 24
12 - 13
15 - 23

Thanks @exxos!

loopback1.png (642.54 KiB) Viewed 125 times

IMG_9326.jpeg (150.02 KiB) Viewed 125 times

loopback2.png (404.88 KiB) Viewed 125 times

(DISABLE set)


Now I have a machine gun DSP loopback adapter too!

Ho ho ho.

BW

[exxos]

Now I have a machine gun DSP loopback adapter too!