exxos's Atari, Amiga & retro forum

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.

One small observation @Badwolf

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


U44..


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

exxos wrote: 29 Sep 2025 20:41 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

Badwolf wrote: 30 Sep 2025 15:44 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 :shrug: It may at least gain a bit of information..

exxos wrote: 30 Sep 2025 16:57 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 :shrug: 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

exxos wrote: 29 Sep 2025 12:55 Use this pinout .. .@Badwolf I suggest doing 12-13 link first ! :lol:

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

Thanks @exxos!

(DISABLE set)


Now I have a machine gun DSP loopback adapter too!

Ho ho ho.

BW

Badwolf wrote: 30 Sep 2025 21:03 Now I have a machine gun DSP loopback adapter too!

:bravo:

Hi All,

Reviving this thread to see if anybody managed to find a way to work with DFB1X and DSP in audio application scenario.

It's still on our to do list, myself and @Badwolf have that many ongoing projects demanding our attention, that we simply haven't gotten around to looking into much yet all yet sorry.

@dml recently wrote us some test tools to help diagnose the issues, but that's about as far as things have progressed so far. I'm not sure I remember what the tests reported unless you can @Badwolf or @dml .

whomper wrote: 27 Apr 2026 15:25 Hi All,

Reviving this thread to see if anybody managed to find a way to work with DFB1X and DSP in audio application scenario.

You can use the DSP with DFB1X perfectly well. Just not as fast as you can without it. Whether that difference in bandwidth causes a problem is entirely down to the circumstances, I'm afraid.

Ultimately it's a limitation of the Falcon chipset. Specifically the GALs. Even CT60 has the same problem.

When an expansion card is accessing the DSP it takes longer for the DSP to be activated than it does when the onboard CPU is accessing it. What that means is if you have a task that really works the DSP host port hard, there are fewer cycles left for the CPU to do everything else.

Why don't we see the same problems with CT60 if it has the same limitation? Good question. Only theories so far but 1) CT60 has been around a long time, it's possible software has been written to realise it's on a CT60 and adapt accordingly; 2) the CPU execution, which has less *real* time to run than the onboard 030 normally would, is so overwhelming faster than that baseline configuration that the same or more instructions are occurring in that reduced time, so you never hit a problem.

I tend to lean towards theory 2), but it's kind a moot point and only someone with the specific software and hardware skills to be able to measure it would be able to tell us for sure.

However thanks to some brilliant work by @pakman, all is not lost. Unfortunately I haven't *any* time to work on my 'real' Falcon since Christmas, but pakman's provided me with some test GAL builds and next time I have the case open I'm going to send him back some timing information. This is primarily of academic interest so we can attempt to completely describe the GAL equations (which have been shown to be not quite correct in the GALS.ZIP that's done the rounds), but it could lead the way to a simple fix where the user can substitute in a new GAL and have 100% DSP host port speed.

I have actually achieved this with a slightly modified DFB1 firmware and a slightly modified GAL, but that wasn't a rigorous analysis: viewtopic.php?p=136438#p136438

Cheers,

BW