Clocking

Related information and WIP etc
Post Reply
ijor
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Clocking

Post by ijor »

Quoting from a different subforum, but probably better to follow up here:
exxos wrote: Mon Jun 03, 2019 9:13 pm In terms of clock distribution and division, on the remake board, we simply just used a LS161 synchronous binary counter. So we can feed in 32MHz and get 16,8,4,2 MHz output all in phase.
I can't see this in the H1 schematics, or are there newer schematics? Using a binary counter as quoted might have some problems, but thought I should better ask if and how it is used before elaborating.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
terriblefire
Moderator Team
Moderator Team
Posts: 5368
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK

Re: Clocking

Post by terriblefire »

my 2 pence worth...

On the TF330, TF360 and TF536 I sample and recreate the 8MHz clock with a 100Mhz Clock (i.e. much faster clock)

I then use this to produce a 50Mhz or 16/8Mhz as required (depending on the address being accessed) in the 100Mhz clock domain. The resulting stability is incredible. Could you do something like this with the ST and use a multiple of 8 instead... i.e a 128Mhz or 64Mhz Clock and divide down to 32Mhz/16/8 as required?
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
User avatar
exxos
Site Admin
Site Admin
Posts: 23504
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Clocking

Post by exxos »

terriblefire wrote: Wed Jun 05, 2019 8:17 pm I then use this to produce a 50Mhz or 16/8Mhz as required (depending on the address being accessed) in the 100Mhz clock domain. The resulting stability is incredible. Could you do something like this with the ST and use a multiple of 8 instead... i.e a 128Mhz or 64Mhz Clock and divide down to 32Mhz/16/8 as required?
This isn't exactly clock switching, we are running the 8MHz clock at 16MHz kinda thing (of course its a bit more complicated, but its just basic overclocking)
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23504
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Clocking

Post by exxos »

ijor wrote: Wed Jun 05, 2019 8:05 pm I can't see this in the H1 schematics, or are there newer schematics? Using a binary counter as quoted might have some problems, but thought I should better ask if and how it is used before elaborating.
Its not on the H1 as its not been tested and proven yet. We are doing a hack job on the Alpha board first... https://www.exxosforum.co.uk/forum/viewt ... =73&t=1916

Of course we need to check back on 8MHz (stock speeds) but we haven't got that far yet. I need to check everything is in sync with the MMU outputs etc yet.

The 161 starts with 32MHz, into the shifter (MEGA ST does this) . The 16MHz out from the shifter gets replaced with 32MHz and feeds the MMU.

The MMU clock outputs get bypassed (not used) and are re-generated from the 161. GLUE, 1772,DMA etc gets 8MHz from the 161. The CPU & blitter gets 16MHz from the 161.

So all that really happens is the CPU,MMU,Blitter gets double clocked. Of course the MMU clock outputs are double speed, so we don't use them.. in fact the outputs seem to slow in rise and fall times and cause to much skew... So we just re-generate the clocks totally from the 161.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
ijor
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Re: Clocking

Post by ijor »

I see. A few comments.

Using a sync counter like that is not the best way to avoid clock skew. You still has the Tco (clock to ouput) delay from 32 MHz. That is equivalent to a clock division and will produce a significant skew. Although it certainly won't be as bad as the chain of divisions that the standard ST has.

A better way would be to feed the counter with a x2 clock, 64 MHz in this case, and never use that master clock. You use the counter outputs only, including the 32 MHz one. You would still have some skew. Those counters are not designed for very low skew between pins, and that skew is even not specified in the datasheet. But it is expected to be small.

This probably doesn't matter too much for a stock system. But once you start to increase the frequency (as we talked in the other thread), the clock skew becomes more critical. Also FPGA devices are more sensible to clock skew. At some point you might need to use a true clock generator. It might be possible to use the FPGA as a clock generator. FPGAs have special circuit to compensate clock skew.

Personally, I would like to be able to select a clock frequency among the 3 or 4 frequencies used at the ST. This might need a configurable clock synthesizer to be precise. But not sure if most people would care about something like that.

Another small issue. Bypassing chipset clock division might introduce subtle wakeup issues.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
User avatar
exxos
Site Admin
Site Admin
Posts: 23504
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Clocking

Post by exxos »

The problem with 64MHz clock is lack of decimal accuracy on them. I mean we use 32.08 so we get the 8.02Mhz clock ( as we deemed it most compatible with my talks with Troed) but if we jump to 64MHz, it will throw us out unless there is a 64.16MHz osc, which I doubt there is. As we want to keep the 8MHz clock as something compatible, we can't really use 64MHz. 8.00 MHz isn't a standard ST clock and will likely break a lot of demos. I do understand your point though, but I think it would result in more issues in doing that.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
ijor
Posts: 428
Joined: Fri Nov 30, 2018 8:45 pm

Re: Clocking

Post by ijor »

I've read that thread where Troed discussed the issue, and I don't agree with him 100%. IMHO very few demos would be affected. But yes, it is not very good to have a squared 8 MHz frequency. I was mostly thinking in loud voice. This would probably become more critical when (and if) the frequency is increased even more.

The problem that there is no oscillator available with the exact frequency can be solved with a clock synthesizer. Or, again, it might be possible to use a FPGA (or even a CPLD).
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
Post Reply

Return to “H4 MONGREL EDITION DEVELOPMENT & INFO”