The Atari TT was based on the earlier ST line of computers but with a 32 MHz 68030 instead of an 8 or 16 MHz 68000. There were a number of extensions made (e.g. new video modes) and the memory architecture had some differences as well. Though largely backwards-compatible, some earlier software reportedly would not run on it. What specifically caused some ST software to fail to run on the TT?

2 Answers 2


Beyond the usual TOS compatibility issues which affected all Atari STs, the TT add the following twists:

  • its faster CPU meant that some programs (games) ran too fast; this wasn’t as much of a problem as on the PC since most games used the vertical blank interrupt for timing;
  • its 32-bit address bus meant that programs which used the top eight bits of addresses suddenly stopped working, as detailed in Brian H’s answer (the unofficial 24bit.prg, available here, will program the MMU so those bits are ignored, so that games such as Ultima III will work);
  • it dropped the blitter, emulating it in software instead (which turned out to be faster, using the 32MHz CPU, than the 8MHz blitter anyway); programs which address the blitter directly instead of using the TOS routines fail to work (so some STE-specific games won’t work);
  • its list of supported resolutions doesn’t quite match the ST’s, which affects some programs.

The Atari wiki has a list of TT-compatible games which gives a good idea of what to expect. This Atari forum thread also contains a lot of useful information for people trying to run games on the TT (it gives the impression that lots of games need patches, but many of those patches aren’t required, they allow the games to run from the TT’s hard drive).

  • I can't see how the extra supported resolutions would affect compatibility. Unless you're talking about e.g. starting a program needing 16 colors (and which assumes it will get ST Low) from 16 color 640x480 (TT medium IIRC?) - I seem to recall that would sometimes yield interesting results. I could be totally mis-remembering though. I'll have to track down my old documentation and see how resolution/color depth checks were done. Commented Jun 5, 2018 at 14:00
  • Yes, that’s what I remember too, programs expecting ST Low and getting TT Med. Commented Jun 5, 2018 at 14:16
  • For sake of completeness, some programs designed to run on a bare 68000 and using self-modifying code would crash because of the instruction cache of the 68030. (However, this mainly applies to demos, that are very likely to crash way before that on a TT anyway.)
    – Arnauld
    Commented Dec 9, 2018 at 0:52

The question is sort of broad, since there are many ways to write software that targets the specifics of ST hardware, and which leads to programmer assumptions that break when the hardware changes even slightly. That said, you identified one of the main issues for games: the faster CPU. Not being able to slow the CPU down to the expected speed of the ST would be an issue for any games that relied on precise instruction execution speed.

Another likely culprit, which also affected lots of Amiga and Macintosh software in the transition from 68000 to 68020/030, was the programmer "abuse" of using the upper 8-bits of addresses to store additional data. Addresses on the 68000 are 32-bit, just like with the 020/030. But the 68000's address bus is only 24-bits (16M maximum memory). So it was very common for programmers to conserve some memory space by using the upper 8-bits of address data for purposes other than addressing memory. On the 68000, the extra bits were ignored by the hardware, but not so on the 020/030. This led to many unexpected crashes on the 32-bit machines, especially since the OS for these machines didn't include memory protection from user applications. On the Macintosh, the early system software had used this means of conserving memory, and that was one of the contributors to the lengthy push to get "32-bit clean" ROMs for 32-bit Macintoshes so that they could actually support >8M of RAM.

  • 1
    The 24/32 bit change rings a bell. There's not much that can be done to fix that from a hardware standpoint. One would think the OS could have had a compatibility mode that used the MMU to remap high memory to low though (presuming that the '030 MMU could support such a scheme). Can't recall whether TOS 3.x had such an ST compatibility mode (I mostly ran MagiC on the TT which was it's own kettle of worms compatibility-wise). Commented Jun 5, 2018 at 12:54
  • 3
    There’s a nice little program aptly called “24bit.prg” which programs the TT’s MMU so that the top eight bits of addresses are ignored, thus allowing misbehaved programs which use the top eight bits for other purposes to work on a TT (e.g. Ultima III). Commented Jun 5, 2018 at 13:00
  • @StephenKitt Another faint bell rings. Do you recall if that program was officially from Atari or from a third-party? Commented Jun 5, 2018 at 13:03
  • Especially on 68k Macs this was a problem, as the OS designers decided they could use the upper 8 address bits for something more useful than zeroes.... On other systems, it was only applications that did that.
    – tofro
    Commented Jul 8, 2018 at 19:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .