Clocking

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

Clocking

Post by ijor » Wed Jun 05, 2019 8:05 pm

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: 1505
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: Clocking

Post by terriblefire » Wed Jun 05, 2019 8:17 pm

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?
———
I get cranky when asked to repeat myself.

User avatar
exxos
Site Admin
Site Admin
Posts: 8630
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Clocking

Post by exxos » Wed Jun 05, 2019 9:12 pm

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)
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
exxos
Site Admin
Site Admin
Posts: 8630
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Clocking

Post by exxos » Wed Jun 05, 2019 9:21 pm

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... viewtopic.php?f=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.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

ijor
Posts: 92
Joined: Fri Nov 30, 2018 8:45 pm

Re: Clocking

Post by ijor » Thu Jun 06, 2019 2:23 pm

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: 8630
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Clocking

Post by exxos » Thu Jun 06, 2019 2:29 pm

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.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

ijor
Posts: 92
Joined: Fri Nov 30, 2018 8:45 pm

Re: Clocking

Post by ijor » Thu Jun 06, 2019 2:53 pm

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 “MONGREL EDITION DEVELOPMENT & INFO”