Gentle overclocking possible?

[6BQ5]

Is it possible to gently overclock a ST(e)/TT/Falcon machine? For example, could I bump my 8 MHz STe clock to something like 8.5 or 9 MHz? I understand the potential speed boost is negligible.

 

Or ... are the design / speed tolerances extremely tight? Would some other hardware, like video circuitry, freak out over any clock rate higher than 8 MHz?

 

Thanks!

[ParanoidLittleMan]

Not really, even if most of CPUs could work stable even at 12 MHz. The reason is that CPU and video + practically everything what is on CPU bus must be syncronized . Main problem is video - you can not raise it's clock because then video will be too fast, and out of standard frequencies. Of course, there are some components which getting no clock signal, but will not work well with higher frequencies - RAM and ROM.

But 'gentle' overclock is actually done, very long time ago. Back in 80-es. Gentle would mean here small performance gain - about 20-30% max. That needs replacing of CPU in most cases to 16 MHz one.

And drawing it with 16 MHz only during internal operations. When bus access is active, then clock must be set to 8 MHz. You can find schematic for it online.

 

So, problem is not "video circuitry, freak out" , but that produced video will be out of standards, and TVs, monitors will not sync.

[TornadoTJ]

I forget the brand of the 16mhz upgrade I had in my 1040STfm or the one I had in my STacy, but it was almost a 100% gain. Some of the 16mhz upgrades did not have onboard cache, the ones that did though were very fast.

Edited January 30, 2019 by TornadoTJ

[+DarkLord]

Jo Even did an upgrade on his STacy one time that involved modifying the motherboard

'n stuff. I think he would up at around 12 mhz.

 

Still, I'd agree with Tornado - if you can find an AdSpeed or T series accelerator board

in good shape, with onboard cache, and have the soldering skills to socket it, then that

would be your best option.

 

Otherwise, contact Exxos (Chris) at his online Atari store - he has lots of options for

accelerating ST's and will fall over backwards to help you.

[kool kitty89]

On 1/23/2019 at 12:32 AM, ParanoidLittleMan said:

Not really, even if most of CPUs could work stable even at 12 MHz. The reason is that CPU and video + practically everything what is on CPU bus must be syncronized . Main problem is video - you can not raise it's clock because then video will be too fast, and out of standard frequencies. Of course, there are some components which getting no clock signal, but will not work well with higher frequencies - RAM and ROM.

But 'gentle' overclock is actually done, very long time ago. Back in 80-es. Gentle would mean here small performance gain - about 20-30% max. That needs replacing of CPU in most cases to 16 MHz one.

And drawing it with 16 MHz only during internal operations. When bus access is active, then clock must be set to 8 MHz. You can find schematic for it online.

 

So, problem is not "video circuitry, freak out" , but that produced video will be out of standards, and TVs, monitors will not sync.

The GLUE (GLU) chip provides video sync and blanking (and I think border/DE display-enable signaling) in the ST, so you need to keep that close to the stock 8 MHz and also synchronous to any overclock. Overclocking the SHIFTER increases the horizontal resolution, but you need modified software to take advantage of this, plus vertical overscan handler to extend the screen size beyond 32kB. This was done recently to a full double resolution of all modes (16 MHz CPU, 32 MHz MMU, 64 MHz SHIFTER) but hypothetically you should be able to do 40/48/56 MHz SHIFTER speeds for 1.25/1.5/1.75x resolution modes (ie lowres = 400x200/480x200/560x200 4-bitplanes 16 colors) but I also haven't seen people try that. Possibly even more intermediate speeds like 36/38/38.4/44/51.2/54/60 (18/19/19.2/22 /25.6/28/30 MMU clock) but I'm not sure how that would work for cases with non-multiple of 16 pixels per line or non-integer SHIFTER clocks per line. 51.2 MHz is interesting though as it would provide 256 bytes per line (512 pixels with 4 bitplanes) so each scanline would be 1 256 byte SHIFTER address, so you could have smooth vertical scrolling in hardware.

Also, if you could get the GLUE to output the hires mode sync signals while the SHIFTER output low/midres modes at 64 MHz, you should get VGA/SVGA monitor compatible 640x480 and 320x480 ~35.8 kHz ~71.5 Hz 2 and 4 bitplane modes for 4 and 16 colors. (hypothetically if you did this with a 56.4 MHz SHIFTER clock and reduced the GLUE to 1/8x that at 7.05 MHz, you'd get VGA standard 31.47 kHz S-sync at ~63 Hz or very, very close to 1987 VGA standard 640x480 60 Hz mode and should work on 100% of VGA monitors, even really limited/inflexible ones as they all supported at least 60-70 Hz v-sync)

The more common overclock is to double the MMU and CPU speeds, leave SHIFTER alone, and synthesize synchronous 8 MHz GLUE clock (or use the 4 MHz clock output from the MMU which is now 8 MHz). For async interface chips you can also just switch to a separate 2 or 4 MHz oscillator. (though STF models already use a separate 4 MHz oscillator for the keyboard controller since it's no longer on the motherboard and I think that's the only thing that needs a 4 MHz clock signal). In this arrangement, the SHIFTER just uses half of its available DMA slots and wastes the other half. I think you might be able to feed a 32 MHz SHIFTER with intermediate speed MMU, too and it would sync up OK, but not sure. ie it may be possible to do 12 MHz 68k + 24 MHz MMU + 32 MHz SHIFTER without issues. I think some people have tried this (I think even before the 16 MHz overclock) and possibly did it even late in the ST's lifetime, but I'm not positive. That's the max speed you could probably get with suitable 100 ns DRAM (already used on some STFs and a lot of MEGA STs by 1988/89) and also a more likely speed for 8 MHz 68ks to overclock too. (moreso for any cases where CMOS 68HC000 chips were used, especially Hitachi or Toshiba ones)
A 20 MHz MMU might also be able to feed a 32 MHz SHIFTER properly, but again, I haven't seen details on this. (if it does work, that would imply the SHIFTER has a fairly wide/flexible access period between address sent and data received for its DMA ... it needs to have 4 16-bit words fed to it every 500 ns, so the bandwidth is there, but it needs at least 4 DMA slots available per 500 ns as well, every 500 ns, though depending exactly how the MMU handles it, it may be able to switch between even vs odd cycles to feed the DMA and make the 68k wait to re-allign access vs being fully fixed to even/odd split between 68k and SHIFTER/refresh cycles)
A 38 MHz SHIFTER clock has been used successfully, but then that's still at least 2 full SHIFTER DMA slots per 500 ns).

The ST MMU in general is extremely overclockable per all testing/anecdotal accounts, the issue is getting RAM fast enough to tolerate it and added work to generate the proper slower clock speeds needed for other parts of hardware. (albeit by 1991, 70 ns DRAM was pretty cheap/common and you'll see it on a lot of Amiga 500/500+ systems from that era ... incidentally those Amigas were literally running at 1/2 the speed their RAM was comfortably rated for as the entire chipset could have been working at 14.31818 MHz with 139 ns memory cycles rather than 279 ns ones ... also enough bandwidth for all the AGA graphics modes or just all the ECS ones at 2x the horizontal res).

Not sure how tolerant the blitter is at overclocks or DMA chip for that matter, and you'd definitely need to keep the floppy controller at its stock speed. (or speed ranges if it's a DD/HD compatible model)

See:

https://exxosforum.co.uk/atari/last/16mhz/index.htm
https://blog.troed.se/projects/atari-st-new-video-modes/


Note:
70 ns DRAM (sometimes 80ns) tends to be required for the 16 MHz CPU + 32 MHz MMU combo. Bear in mind different DRAM chips have different specs at given RAS/RAC ratings and some have more room to overclock as well, plus there's NMOS vs CMOS DRAMs (the latter generally being of the Fast Page Mode type) and CMOS ones generally need shorter precharge time, some more dramatically so than others. IIRC, the ST MMU uses a 2-phase clock (effectively working at 2x the speed internally, so 16 MHz MMU works on 32 MHz ~31.25 ns pulses) with RAS timing being 5 clock ticks and RP (precharge) being 3 ticks. (or looking at external clocking, that would be 2.5 and 1.5 ticks) Standard ST uses ~156.25 ns RAS and ~93.75 ns precharge, the latter being a bit fast for most 150 ns DRAMs (the minimum/standard speed grade Atari used) which is how they managed to get 250 ns cycle times and thus 1 CPU and 1 video access in 500 ns. (or 1 CPU + hidden refresh cycle while SHIFTER is idle)
2x speed overclock produces ~125 ns (or exactly 125 ns using 32.000 MHz MMU) DRAM cycles which is faster than the official 130 ns rating of most 70 ns FPM DRAM and moreso compared to the 150 ns of most 80 ns FPM DRAM, but the former tolerates that fine and the latter seems to as well per anecdotal evidence. (there's also the odd case of most/all 64kx16-bit FPM DRAMs where 80 ns parts ate rated for 135 ns RC cycles and just 45 ns RP precharge though that's 128kB 16-bits wide and not generally what you'd use even on an external expansion module mod)

 

For STe the same method isn't possible due to the GST MCU combining the GLUE and MMU. You might be able to overclock it if you could enable external sync and synthesize aproriate H/V sync signals externally (maybe even using an ST GLUE chip to do so), but I haven't seen anyone try this.

The STe's genlocking provisions also allow it to not only accept external video sync, but also an external system clock, which in theory could make a multi-speed switching overclock mod easier to implement, but would still need external sync generation.



Edit:
Video from 2015 detailing a rather nicely kit fabricated 16 MHz RAM+CPU mod with 16 MHz blitter as well. Though in this case using some sort of embedded 68000 or FPGA clone on a socketed PCB. Not sure if that's a vanilla 68k core or CPU32 or something else in there, but bone standard 16 Mhz 68000s work fine in a similar configuration.

 

Edited June 30, 2023 by kool kitty89

[+DarkLord]

Hmm, 4 years later...