Skip to content

Atari ST new video modes

update: See the very bottom of the post for more on where this is going.

A while ago there was a discussion on Atari-Forum about what’s known as the “Stefan Nitschke 16MHz mod”. A document from 1996 describing how one can, sort of simply, overclock a regular Atari ST bus from 8MHz to 16MHz, while still keeping video modes backward compatible. It’s done by taking the 32MHz system clock used for the Shifter and re-using it for MMU (instead of 16MHz) as well, and then downclocking downstream instead for some of the other chips.

This mod has been successfully implemented by a few persons over the years, with more or less good results. It’s a tricky mod since you need to upgrade both the RAM and ROM chips with faster versions, as well as switching out your 8MHz CPU for a 16MHZ version.

One of the persons who looked at this mod was exxos, who instead of using the 32MHz clock for the Shifter also for the MMU, put a 64MHz clock on the Shifter and then used the resulting 32MHz output for the MMU. Stefan does mention this in his doc as well, but states that it needs a lot of extra tricky hardware to get useful video output from.

I had a quick look at the image exxos posted and realized it was just perfect. It showed the ST outputting twice the normal horisontal resolution, effectively showing line 0 and 1 (and 2 and 3 etc) after one another on the same horisontal line, and when the video memory ran out half way through it instead showed bus activity (looking beyond available RAM). To me, as a programmer and demo scener, this looked simple to solve. It would enable an effective doubling of the known ST resolutions:

  • 320×200 in 16 colors
  • 640×200 in 4 colors
  • 640×400 in monochrome

… would become:

  • 640×200 in 16 colors
  • 1280×200 in 4 colors
  • 1280×400 in monochrome

… while still using the exact same sync timings for regular TV and monitor use. This got me really excited – a new usage of Atari’s tech from the 80s that would bring something really new, and that in theory could’ve been accomplished already back then.

I looked through the Ataris I have laying around (too many .. ) and decided to use a 1040 STFM of a very late rev (C070859-001 REV 2.0), with surface mounted MMU and GLUE chips. Not just because those chips had a higher likelyhood of being overclockable, but also because the motherboard model is “sane” and compatible with exxos’ 4MB SIMM RAM upgrade. As I wrote above, both RAM and ROM need to be exchanged for faster versions.

This RAM mod took quite some time to do. I used a hot air rework station to remove the old RAM chips, and due to the fact that I have the “big” RF box the new SIMM is tightly snug in place and can never be removed.

After that I installed a fast dual TOS, again from exxos. Sorry, no pictures, that was very straight forward :)

Next up was the CPU. Tedious work, and it felt strange cutting the legs of a trusty old companion like that.

With these components switched out (and the old STFM feeling quite modern with its 4MB RAM and TOS 1.04) it was time to turn to the actual 16MHz mod. I had purchased some 64MHz oscillators, and remembering exxos telling me they might have difficulties driving the Shifter I decided to mount it directly on top of the Shifter with a straight pin connection. I cut the old 32MHz leg right off, and added the osc. The image is from an earlier test, the final version has a decoupling capacitor as well.


Now I needed to sort out the rest of the clocks. Adding 64MHz to the Shifter like this will cause the MMU to get 32MHz instead of 16 (which it gets from the Shifter), and it in turn will output 16 instead of 8, and 8 instead of 4. This starts out fine, we want the 16MHz to the CPU. However, the same clock goes to GLUE/floppy/DMA etc which should still run on 8MHz. Additionally, the MFP needs 4MHz. I tried various configurations of this, using a 74LS74 to downclock, but got stuck on a non working floppy. It wasn’t able to read disk contents correctly, sometimes showing 0 bytes in 0 files, sometimes a few, sometimes all. Loading never worked.

Since I had prepared well by cutting traces both topside and bottom side, effectively severing the MMU from CPU, MMU from GLUE/therest and MMU from MFP, I could try something new.

[legend: red=16MHz, orange=8MHz, cyan=4MHz. Original values]

exxos had pondered whether it wasn’t possible to use a synchronous 4 bit counter, a 74F161, fed with 32MHz and which would then produce synchronized 16,8,4 (and 2) MHz outputs. I ordered one (surface mounted was the only one available as you can see) and connected it up to the already cut traces, fed with the same clock as the MMU got.


Success! First time I switched the computer on it booted the disk right up. The new clocks look really good as you can see from my logic analyzer:


With the mod active and stable, I now finally had the same video output as the image exxos had posted a few years ago, the one that got me interested in this little project to start with. The following image is what mono looks like rendered as 1280×400, and was also the first indication that while I had the new video working something was still off.


RAM speed here should really be 200%. I pondered this for a while, figuring that while the new clocks look really good, it might be wrong for GLUE (8MHz) to only go HI on the falling edge of the CPU (16MHz). As a test, I wired up the CPU to the 16MHz output from the MMU instead – and that did the trick.

However, besides that, the image shows that the Shifter is indeed outputting twice the normal amount of video RAM, and now I went to work on getting GEM/VDI to understand that. I had for a while thought of the fact that this was slightly similar to the old overscan mods, where increased screen resolutions were had by removing the borders using a hardware mod. There was software available for those mods that made GEM/VDI understand the slightly increased resolutions, and I started looking at them.

It turns out that Overscan v1.6 by Bernd Gebauer and Karsten Isakovic from 1989 was just what I needed. I edited the source code to reflect these video modes instead of the overscan ones (and fixed a bug that hadn’t been visible with their modes) and … wow:

What you see above are photos of the new resolutions 1280×400 in monochrome and 640×200 in 16 colors. My ST is connected with an ubeswitch to a Dell 2001FP which has a native resolution enough for these to look well. I’ve also tried with a NEC 1990FXp which does an equally good job at it, maybe even a bit better.

And finally, here’s a run with the latest GEMbench v6 in the new low resolution, 640x200x16. With RAM speed also boosted to 200%, even though GEM is rendering in 16 colors instead of 4, it’s still a lot faster than a stock ST.


Next up I want to look into using the MoCo software I’m already writing for ubeswitch to also help me fool applications that won’t start in low res because they need 640×200 (I’m looking at you, FastCopy III!) to run anyway.

Could Atari possibly have enabled these video modes in the STE, back in 1989? Maybe. I do believe most MMU and Shifters are happy to run at twice the original frequencies. However, RAM and ROM chips at the necessary speed might’ve been a bit too expensive – not to mention sourcing 16MHz CPUs.


addendum: More technical details can be found in my thread on exxos’ forum. That’s also where you will find the latest developments, like “mono, but in color”:

10 Comments leave one →
  1. January 3, 2018 23:10

    Cool stuff, thanks for sharing your findings!

    In the original old thread, where Stefan posted his description, some readers added some fixes for problems like shifter jitters in the screen display:!topic/maus.sys.atari.hardware/9_ojFHer4qc

  2. John H permalink
    April 30, 2018 0:30

    This is kinda amazing work! That’s interesting there is that much margin on the GLUE and Shifter chips.. Is there a way to gain this performance but keep the ‘correct’ atari ST resolutions?

    • Götz permalink
      April 30, 2018 0:31

      Yes, please read the links about the Stefan Nitschke 16MHz mod.

    • May 9, 2018 7:31

      What I haven’t described here, only in the thread on exxos’ forum, is that I’ve gone ahead and implemented this mod in a GAL as well. That has allowed me to have switches connected to the GAL which enables it to drive three different modes:

      1) “doubleST” – Shifter, MMU and CPU running at twice the original frequencies. This allows the new video moves.
      2) “stefan16MHz” – MMU and CPU running at twice the speed. You get the full 200% performance boost, but still with the regular video modes.
      3) stock. Exactly as original.

      (The GLUE is never overclocked but stays at 8MHz, otherwise all video timings would get screwed up)

  3. MarkP permalink
    July 17, 2018 15:32

    OK, now combine this with an overscan mod, and… 768~800×280 in 16 colours, 1440×480 in mono?
    If you can finagle some way of doing interlace, that could be default 640×400 16c and upto 800×560 16c with overscan (equal to what was max rez for a lot of fancy SuperEGA and SVGA PC cards of the STe’s era), and on an LCD TV it wouldn’t even have the horrible interlace flicker, just a slight shimmer around any moving parts.

    Essentially it’d be like what I’ve previously got out of an Amiga when hooked up to a modern TV, but with more horizontal rez (because the pixels are thinner) and without the terrible CPU slowdown that it suffered when running that maxed-out mode… in fact, more than twice the CPU power of that machine even running 640×200 4c …be interesting to see what it could pull off within that expanded screen.

    And, yeah, missed opportunities. I’ve been mulling for a while over what could have been for a while with a fantasy spec list for a less disappointing STe, or at least the MSTe or some other level above the original Megas that would have bridged the gap between them and the TT, and been a better base to build the Falcon from. The 640×200 16c you show off here is pretty much the base mode for any of those, with a variety of higher rez and/or deeper colour modes derived from the same basic clock…

    • MarkP permalink
      July 17, 2018 15:35

      (additionally if you can interlace in mono, and find a monitor that’s still compatible with hi-rez interlace as used for XGA and a variety of SXGA modes before monitor scan rates and VRAM latency managed to catch up with the actual memory size and driver chip sophistication… 1280×800 base, 1440×960 extended? Even the basic one would be pretty sweet if you could get it lined up on a WXGA-2 monitor, ie 1280×800, such as is used in the laptop I’m typing from, or a lot of midrange data projectors… the overscan would be quite a party trick. And imagine if they’d managed to find someone who could manufacture extra-hi-rez monochrome LCDs and then incorporated either mode into a laptop in the early 90s…)

  4. TotO permalink
    March 22, 2019 22:09


    Is possible in the same way to set a new 320×200 resolution with 256 colours???

    • March 23, 2019 11:15

      Well, bandwidth wise, yes. However, the original Atari Shifter is unable to understand either using 8 bitplanes with a 256 color palette, or any form of chunky video mode.

      A replacement Shifter however, and one has been done using an FPGA, could.

      It might be the case that I have such an FPGA Shifter in my DoubleST and just haven’t had the time to get everything working just yet … :/

      • John Heritage permalink
        March 24, 2019 15:02

        Just here to say this is an awesome project! Thanks for all that you do for the ST community!


  1. Atari ST new video modes | it's in my head

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: