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:

320x200 in 16 colors
640x200 in 4 colors
640x400 in monochrome

… would become:

640x200 in 16 colors
1280x200 in 4 colors
1280x400 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. [gallery ids=“561,562,563,564” type=“rectangular”] 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. [gallery ids=“571,570” type=“rectangular”] 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. [gallery ids=“649,650” type=“rectangular”] [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 1280x400, 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: [gallery ids=“609,610” type=“rectangular”] What you see above are photos of the new resolutions 1280x400 in monochrome and 640x200 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 640x200 (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. /Troed 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”: