exxos's Atari, Amiga & retro forum

So my workings out are :

R222 TOP master clock from combel - (LINK TO EXP CLOCK DIRECT)

(ALL THESE CLOCKS SHOULD BE DRIVEN BY DFB1X NEW CLOCK OUPTU 16MHZ)

R222 BOTTOM CLKB - GAL logic - CPU

R216 TOP CLKC EXP

R221 TOP CLKA DMA / FPU

YELLOW - So we feed combel master 16mhz clock direct to EXP port for DFB1X.

RED - DFB1X then outputs 16MHz which then drives CLKA / CLKB for CPU/SDMA/GAL

So now DFB1X CPU clock is in sync with SDMA and GAL clocks.

So the clock sync is only like 7ns out anyway.


So remove the clock patch and wire as shown. This assumes you have a firmware which outputs the CPU clock on P92. You also need to keep the OPTION jumper closed for 16MHz tests.

This way, the 16MHz system clocks are all exactly in sync with the DFB1X 16mhz clock. As to if it will help or not, no idea. Could make things much worse :)

exxos wrote: 17 Sep 2025 20:21 Maybe even @Badwolf could do tests as well if he can monitor the DFB1 with his LA.

Sorry, I've not really been keeping up with the thread, but I'd need something concrete to measure.

I'm not an audio guy and rarely even have any speakers connected so 'starts crackling' isn't really something I can reliably investigate.

Is there a SCSI dependency here or not in the end? Is Cubase doing something really clever that's pushing the limits of the hardware & is therefore easily tripped up?

I note the problem still exists with no TT-RAM and the OPTION (16MHz mode) jumper enabled. This is crucial information as it rules out a lot of the possible causes.

DFB1X gets its clock from the expansion port, which is on the FPU branch of the clock patch board, IIRC. Ie: it's different to the onboard CPU. Is it worth rearranging the patch wires so that the FPU/Expansion port and the onboard CPU are a single branch?

Also the clock on DFB1X goes into the CPLD and through various logic steps before being reemitted to the CPU. It should be possible to measure the skew input clock. That may of interest.

I wonder if it's as simple as we need *much* more delay on the SDMA branch if DFB1X is in play?

My biggest thought with the whole cutting edge DMA/DSP stuff (Acetracker doesn't work reliably with DFB1 either) was the clock switching and bus arbitration logic. Both of them will alter the timings between events and if something is so bleeding edge that it's relying on rigid intevals beween things happening, then you'll get problems, but with OPTION1 and no TT-RAM declared, you're ruling out much of that.

Bus arbitration (for DMA cycles) and skew would be the obvious remainders, therefore.

BW

@Badwolf The problem only seems to show up with the DFB1X installed, even at 16MHz. So something isn't happy there. Its why I suggested some clock re-work to see if it helps or not. See my previous post about it.

I wonder if it's as simple as we need *much* more delay on the SDMA branch if DFB1X is in play?

The V3 can do that, its been tried, and seems to make things worse. Its like the SDMA data is valid at alternating 10ns time periods. Not saying that's the case, just not sure how else to explain the issue currently.

I am mostly wondering if the GAL logic having a different 16MHz clock than what the DFB1X clock has is part of the problem. I may be barking totally up the wrong tree. But at least it would help rule out a lot of stuff.

I never had problems with ACE tracker, same with others, but IIRC, Some people had to play with the timings on the V3 patch to get it to work. There seemed to be conflicting information as to what did and didn't work. Some people needed the delay, I didn't. @stephen_usher can't get ACE tracker working at all... So what's the difference between all these machines.....

exxos wrote: 18 Sep 2025 13:26 @Badwolf The problem only seems to show up with the DFB1X installed, even at 16MHz. So something isn't happy there. Its why I suggested some clock re-work to see if it helps or not. See my previous post about it.

Yes, I suggested something similar. Our posts crossed.

Badwolf wrote: 18 Sep 2025 13:16 DFB1X gets its clock from the expansion port, which is on the FPU branch of the clock patch board, IIRC. Ie: it's different to the onboard CPU. Is it worth rearranging the patch wires so that the FPU/Expansion port and the onboard CPU are a single branch?

Is SCSI still a factor?

BW

exxos wrote: 18 Sep 2025 13:11 So remove the clock patch and wire as shown. This assumes you have a firmware which outputs the CPU clock on P92.

It might be better to take clock from one of the TUNE resistors just south east of the CPU as P92 will have a CPLD skew from the clock line anyway.

BW

Badwolf wrote: 18 Sep 2025 13:31 Is SCSI still a factor?

I'm not sure, I assume not, but @whomper could clarify.

I assume as a stock machine works , with a V3 delay to SDMA clock, then SCSI can be likely ruled out.

But there is another oddity.. why does the SDMA need a delay even on a stock machine..

It would suggest the Falcon has some inherent problem somewhere and the DFB1X is aggravating it somehow.

Badwolf wrote: 18 Sep 2025 13:34 It might be better to take clock from one of the TUNE resistors just south east of the CPU as P92 will have a CPLD skew from the clock line anyway.

Not sure I follow..

P2 = CPUCLK , and at 16mhz they should be in sync pretty-much.

The CPUCLK on the DFB1X will be 7ns skew from the combel master clock, because of PLD delay. But this is why I am wanting to try outputting that skewed clock back to the Falcon clocks. This way, SDMA,GAL,FPU, DFB1X CPU, all get the same 16MHz clock in sync.

As things stand currently, the DFB1X 16MHz clock is about 7ns behind the SDMA & GAL clocks.

EDIT:

Alternative tests could be removing the clock switching code and see if the compiler will "pass-though" the falcons 16mhz clock directly to the CPU.. Even a couple ns less skew might be enough to tell us something.

EDIT2:
Nope still 6ns.

exxos wrote: 18 Sep 2025 13:40

Badwolf wrote: 18 Sep 2025 13:34 It might be better to take clock from one of the TUNE resistors just south east of the CPU as P92 will have a CPLD skew from the clock line anyway.

Not sure I follow..

P92 = CPUCLK , and at 16mhz they should be in sync pretty-much.

...whereas the TUNE resistor will be 100% in sync as it's the actual signal.

BW

EDIT: looks like it's R19?

Badwolf wrote: 18 Sep 2025 13:53 ...whereas the TUNE resistor will be 100% in sync as it's the actual signal.

Right. I somehow assumed the RAM CLK would be higher than 16MHz somehow.. That's what confused me.

But anyway, I scoped both TUNE resistor and P92, make no odds either way really.

re. SCSI, Cubase Audio works only with SCSI drives so I have a bluescsi with an SD card which is active as part of the setup while working with Cubase, so yes, SCSI is involved.