Falcon Clock Patch V5 series

[exxos]

Does anything changes if you change the STram board ? Can you run ST RAM test on the unstable machine setups ? No idea if your trying to boot from SCSI or IDE ? Maybe experiment as IDE being connected to the bus without buffering isn''t ideal.

Other than the SDMA timings which I don't know if relevant with the blitter on the falcon, I can only suggest patching some 10K SILs across the falcon databus (maybe also address) and see if it helps.

I emailed Mr Zcuba about it all. Basically he says the 030 CPU, CT60 clock timing isn't that important. He suspects the SDMA clock might be timing critical. But he did't look into it more.

As to if that timing can cause CT60 related issues, no idea. I assume it just causes audio drive issues as it does in 030 mode. BUT, with it being a DMA device, maybe floppy polling is enough to cause conflicts with the blitter with it also being a bus master ? I really cannot say and would be a rabbit-hole type problem I think to diagnose.

I tried the new V5 and the SDMA clock is in perfect sync with combel now. BUT, a under-sight was when the CT60 is removed, it changes the timing again. So I have done a new design with a fixed delay rather than syncing to the EXP clock.

Sync can be taken from the SDMA pin directly, but its adding another wire.. which will add another delay anyway. So I think having a fixed timing is likely the best solution. However, as this is all a turned circuit. Every falcon is likely different.. So even with a PLL, obtaining a perfect sync isn't simple. You have a 4ns delay tot he SDMA, so a direct wire may have 2ns for the feedback. So there is no point in trying to compensate for 2 delays which will have random timings anyway.

But even so, I am skeptical the clock sync with the SDMA is the root cause of peoples CT60 issues. I have had various timings on mine and never seen any hard crashing. So I personally would lean more towards bus stability issues.

[mikro]

Good idea with the ST RAM board, however it didn't help (I tried one other 14 MB and the original Atari one). IDE/SCSI doesn't matter as the freeze happens during drawing of the Atari logo (I can bypass this problem with CT60TOS 1.05 which draws the logo without the Blitter but it's easier to test this way).

What I find interesting is that how this behaviour 'deteriorates':
- initially I could run and reboot the Falcon + CT60 for quite some time, it crashed only when accessing Blitter after ~30 minutes of usage
- it took a few minutes to cool off and the Falcon could boot again (if the Atari logo was drawn by Blitter)
- then I mounted your V2 clock patch and it seemed like the cure: I could run and reboot Falcon for whole day
- after 2-3 days it reverted back to the initial behaviour, i.e. freezing on Atari logo again but still being able to boot after cooling off
- and now it never makes it past the Atari logo, even if I don't touch the machine for 24h

If this was happening in 030 mode, too, I would definitely point it to some failing component but this is purely 060 related, and only to this one CT63. Weird.

[Steve]

@mikro This is a CT60? I'm not sure if this problem could also be possible on a CT60, but on the CT60e the IC's have started to have bad connections on the legs. Firstly it happened with mine, then it happened to 'the power of vintage' gent on the forum, and now it's also happened to Frank Lukas.

But I do remember you saying that it's fine in another machine. So probably not that. I've seen quite a few people reporting problems with Centuriontech's CT60 version in the last few years. What version is yours?

[Rustynutt]

I have designed another experimental clock patch. Though I doubt anyone realistically would have any needs for this series. It is more experimental for my own machine for various reasons. Mostly as pointed out in the V4 thread.


FALCON_CLOCK_PATCH_V5.PNG


Overall problem with the clock patches, is that there are so many different designs, it's difficult to figure out why what was done for what reason.

If we stick with the Atari fixes, they seem to go from noninverting (AND) to inverting, back to noninverting according to https://mikrosk.github.io/clockpatch/

Czuba (creator of the CT60) advocates no clock patch whatsoever

Hi Chris, apologies for the long absence. Lot of life issues.

As far as Czuba saying no clock patch is required, recall that debate on the other Atari forum many years ago.
He stated the CT60/CT63 provides it own buffering. As I understand what was discussed, that was true if using the CT optional bus acceleration connection.
Centuriontech clock patch is designed, with a simple IC to split the signals from the CT60 design (e, or whatever it's called now) to the bus.
That conversation evolved into a "heated" debate (you know Czuba ) , where some users were stating their machines wouldn't work without a clock patch.
Don't positively recall, but think the users where the CT didn't work without a separate buffer was they were not using the connections for the CT bus accelerator.
AFAIK, only the CT63 were built with that feature on the board, with later models yet having the connection, sans the required IC's.
So in that case, I'm not sure at what point on the board is the pick off to run a lead from the CT60 to the Centuriontech clock distribution IC.
I'll try to keep up. Not doing all that well.