exxos's Atari, Amiga & retro forum

well, this is exactly what I wanted to measure when I blown away my CT60e :-( (I fitted my CT60e in his Falcon for a long test run, worked like a charm for more that 24 hours, I wanted to measure the delay, and boom. It would help me to find the error If the schematic of the CT60e power stage was available, but I can't find anything on the web....

AFAIK the CT60 project is closed source aside from people like willy who could update the design under license. I don't know if he is still around on Atari forum or not. But it's a shame he didn't continue with the CT60e :(

Now I think about it, the fact your friends machine doesn't have a clock patch, when I first couldn't get my original CT60 working I sent it to czubatech, I think he put back the original resistors and had a moan about it. I might still have those emails. But my falcon came back in a none functional state because of basically that 47R "termination resistor' killed the sdma clock. It was in part why I started my clock patch investigations....BUT...

Maybe there lies the problem.. the CT60 might have been designed with no clock patch at all. So when people started adding clock patches to fix other issues, maybe that made the CT60 less compatible..

I'll have to open up my original falcon as I'm not sure if it has a clock patch or not.. I think it doesn't.. so I could try the CT60e in that machine and see what happens... I'd assume it would work.. but likely joy demo wouldn't.

But my theory already has a flaw as my test falcon works fine with the CT60e and likely with V2,V3,V4 clock patches. But if my theory is correct, then it would need another new clock patch design to mimic the original clock signal timings but also buffer them.. Which may not be so simple. The original falcon clock is driven from a single source which complicates matters due to reflections from 3 clock traces all being feed back to eachother. So as to what the CT60 expects is anyones guess currently. But it shouldn't be that sensitive to start with. It's also difficult to know if anyone else has run into the same problems already..

My friend’s Falcon is patched, with the Atari rev 1.3 patch, and the CT60e work well.

Swissfalcon wrote: 21 Jul 2024 23:47 My friend’s Falcon is patched, with the Atari rev 1.3 patch, and the CT60e work well.
Image.png

Ah ok.. odd it's linked 2 pads together... Maybe that's a clue... But that could be more clock sync between expansion clock and CPU clock... But IIRC, it's going via the combel which would likely add some delays anyway..

This is this patch

Swissfalcon wrote: 21 Jul 2024 23:55 This is this patch
IMG_7142.jpeg

So it's the FPU and expansion which get the delayed clock... The CPU gets it's clock directly from the combel via a resistor..

So basically the CPU gets a clock slightly advanced over the expansion and FPU clock..

I guess you could drive the CPU clock directly from the clock source from the combel to see what that does...

EDIT:
Oddly Variant 1.5 (author: Petr Stehlík) does the complete opposite.. So I wonder if other clock patches cause problems with the CT60. Assuming it's a CPU clock sync issue...

EDIT2:
I have an idea for a tweaked V4 you could try.. but would take me at least a week to modify a V4 to send to you..

exxos wrote: 22 Jul 2024 00:01
So it's the FPU and expansion which get the delayed clock... The CPU gets it's clock directly from the combel via a resistor..

So basically the CPU gets a clock slightly advanced over the expansion and FPU clock..

and the SDMA too get the delayed clock, so it's in sync with the expansion slot. But my understanding is that it's the case with all Atari patches.

I guess you could drive the CPU clock directly from the clock source from the combel to see what that does...

There is only the resistor on the line, the original one, it's pretty the bar signal that the CPU get in this case. But I think that in 060 mode, this line isn't used, right?

EDIT2:
I have an idea for a tweaked V4 you could try.. but would take me at least a week to modify a V4 to send to you..

Good idea!

What I suggest you do is :
Remove the white wire is shown in the image..
Put back the old R222 resistor (I don't remember the value, may be around 33R ?)
You would still need the black wire on top of R222.

I don't know if this will change anything but it is something relatively simple to try.


I've started to design a revised V4, though currently I'm having to guess at what the problem actually is. It would likely be a couple of weeks before I would get the new boards though.

From what I can really tell, sometimes inverters were used, sometimes they were not. Sometimes the CPU clock was driven directly from the combel, and sometimes not. There seems to be all sorts of combinations going on :roll: I would say there's a bit more to it than the clock patch itself in that the combel to CPU to expansion port timing is very hit-and-miss it seems.

I would guess that there should be no delay whatsoever between the combel and CPU clock going by some of the Atari designs and others. But then the other clocks, expansion, FPU, SDMA get buffered or even inverted. Either way there would be a delay. But maybe those clocks are a lot less critical anyway.

I disconnected the white wire and soldered a 33R for R222.



So even a 33R resistor can skew by about 2ns.

Assuming there is a combel / CPU sync problem.. Then I think it would be better to just wire link over R222 and not drive it from the V4 at all.

Assuming @mikro's Variant 1.1 (author: Atari Corp.) and Variant 1.2 (author: Atari Corp.) and 1.2 was released later.. I would suspect Atari had tried to sync the comble to the CPU, but something was still have been unstable as they later went to inverters, I presumed it was to gain higher drive currents than the "AND gate" they used before. But I would think that while there are several factors going on at once, maybe Atari actually did tried to sync the combel and CPU clock, but found something was still unstable and then went to inverting the signal instead.

So @Swissfalcon you would have to try that on your machine (I guess with your friends CT60e) and see if that helps the problem or not.


The problem is here, that we cannot simply buffer the clock signal if that assumption is correct, as it would inherently add a delay. I don't think it is a good idea to link the Combel to the expansion port clock, but that could be a solution. Buffering would have to be an inverter.. But having a single inverter just on the expansion clock doesn't seem like a good idea. So basically left with having to invert all three clocks as in what Atari did in one of their patches.. But of course the "problem" there is combel is even more out of sync with the CPU, but maybe that's the only solution.

We don't know which signal the CT60 is having issues with. At least my first modification idea will roll out if it is a CPU combel issue, or a sync issue with the combel and expansion port clock.


So to sync the expansion clock and 030 CPU clock to combel..


The Red Crosses indicates wires to be removed.
The yellow lines are new wires.


I am assuming the above image is what may be the original CT60 timings were expecting. As soon as any sort of buffering is introduced it causes problems. The 030 CPU and EXP clock would all be in sync but not buffered at all. The FPU clock and SDMA would still get the buffering, but those are mostly the main issues with clocks anyway. So *maybe* that setup would work best..

This would *almost* be the same as the Variant 1.3 then.. Only the expansion clock would not get buffered. And instead of the expansion and FPU getting the same clock, the 030 CPU and expansion would get the same clock. FPU and SDMA remain buffered.

To illustrate what the hell I am talking about... These are the original Atari 1.3 and my proposed idea..



So combel / 030 CPU / exp remain unbuffered and in sync the combel, this would mimic the timings which I assume the CT60 is expecting. Then the FPU/SDMA get buffered as you really have no choice there anyway.

On the CT60 site it actually says:

- 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 basically it "forbids" any sort of clock patch to be used with the CT60 going by that. It's what I suspected earlier :roll:

I am building this concept into the V4.3 design currently. Though as only @Swissfalcon has this problem, he would have to test the 4.3 design out to see if CT60 behaves better. Hopefully without breaking JOY demo and other related stuff..