Falcon clock patch V4 series

[exxos]

Thanks for the images. But did you try the V4 without the 47pf cap before doing the other changes ?

Currently we don't know if the rounded nature of the signal was the cause of the low logic level issues or DC offset, or a combination of both. The 10k is a bias resistor and it's known on some falcons to cause issues without it.

I always find it very peculiar that others are never seeing any significant ringing on signals. I assume you have bandwidth limit disabled ?

As for audio quality, probably best opening up a new topic on that as I've never read about such issues. But that could be anything to do with software or hardware, likely on the analogue side. Such issues are likely outside of the clock patch itself.

EDIT:
IIRC I had issues with falcamp when it was "stuck" in mono mode it sounded terrible..

[leonk]

@exxos I had bandwidth limit set to 20M. I turned it off and this is what it looks like now. You can see the channel settings in this picture. Anything wrong with these settings?

IMG_8040.JPG (358.28 KiB) Viewed 647 times

[exxos]

@exxos I had bandwidth limit set to 20M. I turned it off and this is what it looks like now. You can see the channel settings in this picture. Anything wrong with these settings?

That's how I expect the waveform to look with the spikes. That is the reason the 62R and 47pF capacitor are there to limit the spikes. But it seems on some machines the values are to high.

This is where it gets tricky to solve now unfortunately... As you would need to also add the 62R back in series with the capacitor which will help with the spikes.. but this is now somewhat new territory in this configuration.. The problem is finding optimum values so that it reduces the spikes without distorting the waveform to much again.. 62R is likely still fine to start with.. Higher than 100R may well see to much signal distortion, similar that adding the 47pF reduces the ringing but it's difficult to tell at this point if it's needed or not or if the values suits your machine. A little experimentation with values is likely needed..

So I suggest trying to add the 62R in series with the 100pf cap and see where that ends up.. It might be enough in just doing that..

[leonk]

Here's some more plots for you. It shows how unique each Falcon is and that trying to find a universal solution is really an uphill battle.

V4 fix with no components around SDMA: (no SDMA errors on this Falcom)

IMG_8046.JPG (343.9 KiB) Viewed 632 times

V4 fix + 68 ohm resistor + 47pf cap / recommended install: (SDMA errors on this Falcon)

IMG_8047.JPG (323.81 KiB) Viewed 632 times

V4 fix + 68 ohm resistor: (no SDMA errors on this Falcon)

IMG_8048.JPG (328.02 KiB) Viewed 632 times

At this point I realized what the purpose of the 47pF cap was. It's to smooth out the overshoot but on this falcon it was over doing it, causing the front of the wave to dip below where it has to be. So I went into 0603 components binder and replaced the 47pF ceramic cap with a 22pF ceramic cap (one end going to 0V) and now getting this:

IMG_8049.JPG (322.95 KiB) Viewed 632 times

I think this is as good as it's going to get, and I'm getting no errors and all demos play. I do have noise in the analog output but I think that's a different problem.

Hope this helps.

FWIW .. I did try to inline a 100nF ceramic cap as well as add the 10K ohm resistor to 0V and these 2 changes had no effect on the curve.

[exxos]

Thanks, that is good information.

Looking as the rise and fall it looks twice as long as before. I wonder if you bridge the 68R and just use 22pF if the spikes come back. It's all a tradeoff unfortunately.

The capacitor only changes the minimum and maximum voltages on the sdma. So the logic low is what to look for there. It looks like you hitting zero basically on all your tests anyway.

[exxos]

At this point I realized what the purpose of the 47pF cap was. It's to smooth out the overshoot but on this falcon it was over doing it, causing the front of the wave to dip below where it has to be. So I went into 0603 components binder and replaced the 47pF ceramic cap with a 22pF ceramic cap (one end going to 0V) and now getting this:

I wonder if you would mind try a lower resistor value, say 33R ?

I did wonder a few pages back about changing to a lower cap value. I think for some reason, some falcons just seem "heavier to drive" for some reason. I mean I get signals similar looking to yours on my Falcon with 47pF. So its like your falcon has a "extra" 22pF on the signal somewhere. But there could be a million different things as to why that could be including the scope.

[exxos]

@Swissfalcon I just quickly installed the V5.

In actual fact now, the expansion port clock is 4ns leading the combel clock Though I kind of suspected this would happen because of the output buffer and the slowdown of the signal with the series resistor. This by itself was I think make a interesting experiment anyway.

This way, regardless of what is placed on the expansion port clock, the PLL will always "track the loading" and adjust the sync to the combel automatically. So if a higher resistor value is used, and it slows down the signal (skew), the PLL will compensate automatically. This "method" can be undone with a simple track cut and bodge wire to bypass the output buffer on the V5 if needs be anyway.

The "4ns clock advance" may help with the sync with the SDMA as that clock seems to lag a bit anyway.

I haven't done any other tests other than measuring the clock and the falcon boots to desktop with the DFB1X... Though one of them no longer boots, so not sure if that's related or something iffy on my other DFB1X.

IMG_2639.JPG (309.12 KiB) Viewed 601 times

IMG_2638.JPG (294.27 KiB) Viewed 601 times

[Swissfalcon]

I'm not sure to understand the difference now against what I got with the V4, I had a similar offset. Or do you mean that it's now possible to correct it automatically?

[exxos]

I'm not sure to understand the difference now against what I got with the V4, I had a similar offset. Or do you mean that it's now possible to correct it automatically?

I think you have missed a lot of posts talking about this project...

The V5 uses a PLL chip to synchronise to the combel clock. This means there is zero delay between all the clocks. The "delay" you are seeing in the image is a clock advance not a delay. Where as all the clocks would have a delay with any patch, maybe around +4ns, or alot more if inverters are used, then zero delay would of course be zero, The V5 has a 4ns advance so -4ns from zero. As you saw in your results, even resistors can add skew, so a -4ns delay should counteract all that. So what the system sees, would be "almost" all clocks in perfect sync.

As it has a PLL, it has feedback, so regardless of the timing or load on the clocks, it will always be -4ns clock advance. This advance can even be bypassed with a little work so all clocks are in sync. The -4ns clock is the default setup on the V5. No other clock patches do this.

I did not receive a response about the loan of your CT60, so I am unable to do any more testing, but if you have lost interest in this project then there is no point in sending you a V5 to try out to see if it solves your problem. I cannot really spend much more time on this project now anyway.

[exxos]

I just want to clarify some things here, because the scope reading you posted earlier were actually in sync, it is the slow rise and fall times due to the SDMA series resistor and capacitor on the V4 which skews the signal making it look/act like its out of sync... All 3 clocks are driven from the same combel clock source. There still can be skew, but thats down to other factors..

The V3 still has 33R on the V3 board itself, but does not have the same termination as the V4. So likely the V4 in your case (and some others) the 47pF is likely resulting in poor logic level drives. Which was discussed and experimented in the previous few booths with the other guy.

But I don't think your scope results are taking into account the V3 is using inverters, so its 180deg out of sync with the combel clock. This is how the majority of patches work.

However, Cuba states removing those..

- The machine is not stable.

WORK AROUND :

- Verify you see no 74F08 soldered (added) on the clock trace near the SDMA chip. If yes, you must remove this 74F08 and connect again the clock trace (that was cutted for this 74F08).

- On the GAL U63 (left of the NVRAM) : - If you see a component 74F08 or 74F04 with some wires connected on the resistor places R216, R217, R221 & R222, you must remove this component and the wires. Solder the three 33 ohms SMT resistors (furnished) on R216, R221 & R222 places. - If you have no 74F08 or 04 on U63, you have to verify all the three resistors R216, R221 & R222 are well 33 ohms marked 330 or 33R). On some motherboards, one of them can be a 0 ohm (marked 0 or 0R0) : replace it with a 33 ohms.

So he strongly advocates no clock patch whatsoever and advocates the use of series resistors. So basically, the EXP and SDMA clock will still likely be a tiny bit out of sync due to the long trace lengths/loading on the SDMA clock line... I also posted about it here viewtopic.php?p=117501#p117501 "So even a 33R resistor can skew by about 2ns."

Though it is somewhat conflicting because he also states..

Compatibilité

The CT63 should run fine without solders with the 20 or 25 MHz motherboard boosters.

But it is depending of how the booster is managing the motherboard clock, especially the SDMA clock patch.

But does not go into precise details and what he actually means there..

So the V5 goes with the first methodology of "no clock patch whatsoever". So no delays (as in the V4) and no inversions (as in the V3) . Though this isn't technically 100% true as the V5 advances the clock by about -4ns in relation to the combel clock (which is what I am measuring). Again this is going by the first text of, that all clocks should be totally synchronised without delay... with the combel clock.. The SDMA clock sync is otherwise a unknown at this point other than the text suggesting they all must be in sync, hence no clock patches.

Also looking back to the Atari path you mentioned worked better. viewtopic.php?p=117480#p117480

The CPU is ran without delay to the combel clock. The SDMA ,FPU,EXP clock are actually delayed via the 74F08... So that's another oddity and another clock patch variation in the mix.. On that basis, having the delay on the SDMA clock like on the V4 should match more like what the Atari patch did.. but that doesn't seem to be the case..as you stated the V4 doesn't work as well. It's why (again) I advocated having the 3 clock patch outputs in sync with the combel clock on the V5 as its what Czuba seems to be suggesting by what he has written.

With that variant 1.3. We know that no clock patch (advocated by Czuba) must work best with the CT60. Plus you advocating the Atari 1.3 works well also. It suggests that the delay on the SDMA clock is not so much important. The 74F08 delay is about 5ns. So if we rule out SDMA clock timing being an issue, it only leaves the clock sync with the CPU with the combel.

The next problem there is the V4 will have about 4ns lag behind the combel. You say that works worse. BUT, the V3 which you say works better, has the CPU clock inverted in relation to the combel.. So there is conflicting information there in the results obtained as "no delay" and "inverted" clocks can't both work better. Same problem with the SDMA clock...

Its why I went back to basics on the V5 to buffer the clocks without losing the sync to the combel. This way, it basically does the same as the variant 1.3 but doesn't have the delays introduced by the 74F08. Czcuba says don't use the F08, so the V5 should be the best of all methods now..

But there is still the overall nagging problem of why your CT60/Falcon even needs all this doing in the first place when , from what I have seen, the CT60 doesn't really seem to care about clock patches at all and its always worked fine with all my current clock patch revisions.