Atari TT FAQ compiled by The Paranoid / Paradox

From Atari Wiki
Revision as of 08:39, 7 December 2023 by Mikro (talk | contribs) (Created page with "The following file can be found on but perhaps it has been distributed around the net the same way as the Atari STE FAQ compiled by The Paranoid / Paradox was (which happens to be available in the same Alive issue: <pre> Some minor hints and notes on ___________ ___________ _____/ / _____/ / / /...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The following file can be found on but perhaps it has been distributed around the net the same way as the Atari STE FAQ compiled by The Paranoid / Paradox was (which happens to be available in the same Alive issue:

Some minor hints and notes on

                           ___________       ___________
                     _____/          / _____/          /
                    /    /     _____/ /    /     _____/
                   /____/     / /    /____/     / /
                       /_____/ /         /_____/ /
                        /     /           /     /
                       /     /           /     /
                      /_____/           /_____/


           assembled mainly from the Profibook ST-STE-TT from
           Julian F.Reschke, Hans-Dieter Jankowski and Dietmar
           Rabich (Sybex Verlag 1991) and various other sources
           including magazines by The Paranoid.

           For Ray of .tSCc.

                        Think you can handle it ?!

                         (of the Lunatic Asylum)


The Atari TT or TT030 is a powerful workstation initially planned to approach
the Unix-market in competition to SUN Microsystems and Hewlett-Packard, which
were producing professional Unix-workstations based on Motorola 68000 and
Motorola 68020 processors in the eighties.

The Atari TT was initially designed to feature a Motorola MC68020, clocked at
16 MHz, a Motorola MC68882 FPU, also clocked at 16 MHz, and to run on a
version of System V by AT&T. A TOS-compatible operating systems was initially
only thought of either as a nice extension or as a last resort if everything
else failed.

The Atari TT that was commonly available in the stores looked slightly
different after all: Instead of an 68020 as planned, it featured the even
more powerful MC68030, which was also not clocked at 16 MHz anymore but
ran at a full 32 MHz, just like its companion, an MC68882 at 32 MHz.
Instead of System V, the computer was sold with a version of TOS,
initially named TOS030, later on renamed to TOS 3.0x.

However, hardly any software for the Atari ST ran on this system, even
though the hardware was "similar" and the operating system compatible.
Atari finally decided to release an awful lot of programmer's documentation
on how to handle BIOS, XBIOS, GEMDOS, VDI and AES in a way to ensure
maximum compatibility.

Which was a good idea just as well.

Games and demos usually refuse to run on the Atari TT. Reasons are
numerous, but in some respect, parts of games or demos could have
easily been designed in a way that they do run on a TT. Then again,
certain aspects of game- or demo-writing would require a lot of
reprogramming to make them TT-compliant.

This little documentation is meant to introduce all of the TT-hardware
that's relevant for games- or demo-programmers, i.e. graphics, timing
and sound-hardware as well as certain approaches to make ST- and STE-
programs TT-compatible.

It will also feature certain TT-only aspects, in what way they could
be used as an enhancement without losing ST-compatibility as well as
the problems you might encounter when trying to use them.


Certain names or brands will be used in this documentation to adress
the different Atari computer models that may be mentioned in this
- Atari TT
  This will refer to the Atari TT or Atari TT030 as it was sold in
  large amounts, meaning a 32 MHz 68030 CPU, a 32 MHz 68882 FPU,
  at least 2 MB of ST-RAM, optional TT-RAM, equipped with a
  TT-Shifter. None of this documentation will actually apply to a TT
  using a graphics card.
- Atari STE
  This usually refers to a computer of the Atari STE series, equipped
  with an 8 MHz 68000 CPU, the STE-shifter and a random amount of RAM.
  If required, the Atari MegaSTE series, equipped with a 16 MHz 68000
  and a 16KB 2nd level cache will be adressed explicitely since it
  also features certain aspects of the TT hardware (VME-related).
- Atari ST
  Means one of the ordinary Atari ST series computer, including Atari
  260, 520, 1040 ST, STf, STm and STfm as well as the Mega 1, Mega 2,
  Mega 4 series, sometimes officially named Mega ST 1, 2 or 4.
- Atari Falcon
  Refers to an Atari Falcon030. This machine is much more similar to
  an Atari STE than to an Atari TT, however, the graphic chip of the
  Falcon, the VIDEL, is capable of "emulating" certain resolutions of
  the Atari TT and it also has an 68030 CPU that can be equipped with
  an 68882 FPU.

1. The Atari TT hardware

  The MC68030 CPU
  The MC68030 in the Atari TT is a real 32-bit processor which is
  mainly 68000 compatible. The biggest advantage is the on-chip Data
  and Instruction caches of 256 byte length each.
  The caches can be manipulated by the Cache-Control-Register (CCAR)
  which is a part of the MC68030 itself (hiword is always zero!):

   15 .......................................................... 0
    0   0   WA  DBE CD  CED FD  ED  0   0   IBE CI  CEI FI  EI

   WA  = Write allocate                IBE = Instruction Burst enable
   DBE = Data Burst Enable             CI  = Clear Instruction Cache
   CD  = Clear Data Cache              CEI = Clear entry in Inst.cache
   CED = Clear Entry in Data cache
   FD  = Freeze Data cache             FI  = Freeze Instruction cache
   ED  = Enable Data cache             EI  = Enable Instruction cache

   To completely disable one of the caches, you have to set the
   "Enable cache" bit to zero. "Freezing" the cache makes it work
   almost as a ROM - All Reads will be applied to the cache, but its
   contents will not be overwritten. To clear one whole cache, use
   the CD- or CI-bits. To clear a certain cache-entry, you will have
   to use the CEI- or CED-bits in conjunction with the
   Cache-Address-Register (CAAR) - also on chip - which contains the
   address of the cache entry. However, only bits 7 to 2 are being
   used currently in the CAAR, so only these bits have to be set.
   Burst mode enables extremely quick update of the cache which allows
   128-bit to be read more or less at once.

   The MC68030 PMMU
   The "paged memory management unit" of the MC68030 inside the Atari
   TT is capable of converting "virtual" adresses used by programs
   into "physical" adresses used by the hardware. This easily allows
   memory protection, mostly used by multitasking systems like Unix
   and MiNT or virtual memory that is actually on a harddisk.
   This device is usually not being used by games- or demo-programmers
   so it will not be discussed here in any way.

   The MC68882 FPU
   The MC68030 was designed to cooperate with an MC68882 without any
   additional hardware- or software modification. The duo MC68030 and
   MC68882 work almost like they were on one chip, which makes it
   extremely easy for the programmer to handle the duo.
   The FPU features 8 floating point registers (FP0 to FP7) of 80 bits
   length each, it has its own Control Register (FPCR) and Status
   Register (FPSR) as well as its own Instruction adress register
   The MC68882 communitcates with the MC68030 over the so-called LineF
   emulation (all instructions of the MC68030 that adress the FPU have
   "F" as the first hexadecimal digit).
   The FPU itself bears 64 instructions and 5 new instruction-width
   indices (Integer, Single Real, Double Real, Extended Real and
   Packed Decimal Real Data Format).

   The details on FPU-programming will not be discussed in detail in
   this documentation. Please refer to an MC68882 Programmer's Manual
   by Motorola.

  Compatibilities and incompatibilities
  => In comparison to the Atari ST and Atari STE:
     These series only bear an MC68000 which has a few "disadvantages"
     in comparison to the MC68030 of the Atari TT.
     First, the external data bus is only 16-bits wide which makes
     reading and writing of a longword slower than of a word. In the
     Atari TT, reading or writing 16-bits at once makes absolutely no
     difference to reading or writing 32-bits.
     The 68000 does not have adress line 0, which makes it impossible
     for the MC68000 to read 16- or 32-bits from odd addresses
     (reading bytes is possible since the 68000 reads a 16-bit-word in
     fact and only leads through the required 8 bits) - The attempt to
     do this will lead to an error on the ST. The TT can read words
     and longwords from any given address.
     The 68000 has no cache. Attempting to set the caches will either
     crash the machine or have no affect at all (untested).
     The condition code register of the MC68030 and 68000 are
     identical. The other bits of the Status Register (8 to 31) are
     NOT identical. Handle with care.
     The 680x0-instructions MOVE from/to SR are allowed in USER-mode
     on the 68000, on the MC68030, they are NOT. The TOS of the TT has
     a patch for that by executing an exception, but in case the
     desired program shall not require or refer to TOS routines, this
     will have to be acknowledged.
     Furthermore, the MC68030 has additional ways of adressing and can
     multiply/divide longword operands. These instructions will
     generate an error on the MC68000.

  => In comparison to the Atari Falcon030:
     Both computers have an MC68030 with its caches and both have a
     PMMU. If equipped with an MC68882, the Falcon can also operate
     FPU-instructions just like the TT, if the FPU misses, they will
     generate an error.
     The bus-system of the Falcon does not allow burst-mode in
     memory-access. Setting this bit in the CCAR will not change

  => What to look out for when writing ST-programs:
     The MC68030 is a 32-bit processor and has - basically - a 32 bit
     adress bus. The MC68030 will not work well if being fed 24-bit
     adresses only, which works on the ST.
     Also make sure to access the Condition Code Register instead of
     the whole Status Register if not in Supervisor mode. These
     instructions on the MC68030 are only allowed as Supervisor.
     Also, clockcycle-based effects will never work correctly on ST
     and TT. First, instruction timing on the 68030 is not only
     different to that on 68000, but also more flexible due to cache
     and RAM-usage. Besides that, the clockspeed of the TT is not
     controlable and always runs at 32 MHz - In contrast to the Falcon
     which is switchable to 8 MHz.

2.  Two kinds of RAM in the TT

    The TT sports two kinds of RAM - So called "dual purpose RAM",
    commonly known as ST-RAM, and "single purpose RAM", also known as
    TT-RAM. The ST-RAM is, as seen by the programmer, identical to the
    RAM in the ST and is being shared by CPU and all the custom-chips.
    It appears in the RAM-space of the 68030 at adress

      $00000008 to $009FFFFF

    The most significant difference to the RAM in the ST is the way it
    is internally organised since it allows the TT-Shifter to access
    64 bits at once. This, however, is of no concern for the
    The ST-RAM is, in theory, expandable from $00A00000 to $00DFFFFF.

    The other kind of RAM maps the remaining adress space of the
    MC68030. It (commonly) supports burst-mode access for lightning
    fast fills of the 68030-cache and cannot be accessed by any other
    device of the TT. Hence, it only supports 32-bit wide accesses,
    which is however sufficient for the CPU.

  For the programmer:
    For sensible support of multitasking or advanced systems, a
    program should always "start" with an MSHRINK GEMDOS-command to
    "free" the RAM that the program does not require. TOS memory
    management is somewhat simple, so each program is being given the
    whole free RAM of the computer and it is being relied on that the
    program returns the unused RAM.
    If the program requires additional RAM, this should be done via
    either a MALLOC, or better yet, an MXALLOC GEMDOS-command.
    Please refer to the GEMDOS documentation for the usage of MSHRINK
    to reduce the memory usage of your program.

    The important difference between MALLOC and MXALLOC is that MALLOC
    will always allocate the RAM-type specified in the file-flags.
    However, if file-flags are set to allocate TT-RAM via MALLOC and
    this certain program uses MALLOC to request screen memory, the
    program will not work since screen memory has to be in ST-RAM.
    MXALLOC allows to specify which RAM to allocate within the command
    itself. The usage is as follows:
      move.w   mode,-(sp)   ;which RAM to allocate
      move.l   amount,-(sp)   ;number of byte to allocate
      move.w   #$44,-(sp)   ;GEMDOS function number
      trap #1         ;execute GEMDOS
      addq.l #8,sp      ;clean up stack

    amount contains the number of bytes to request, mode allows the
    following settings:
      mode = 0   allocate ST-RAM only, error if not enough ST-RAM free
      mode = 1   allocate TT-RAM only, error if not enough TT-RAM free
      mode = 2  allocate what is free, preference on ST-RAM
      mode = 3   allocate what is free, preference on TT-RAM
    Using MXALLOC allows the programmer to both allocate ST- and
    TT-RAM specifically for all purposes.
    Please note that ALL memory-areas that customchips need to access,
    like video memory (Shifter), sampled sound data (DMA-sound chip),
    I/O-buffers (DMA in general) need to be in ST-RAM.

    It is unwise to use MALLOC and restrict the program to use ST-RAM
    via the fileflags, even if the program is prefered to run on an ST
    and only meant to be TT-compatible. TT-RAM is lightning fast in
    comparison to ST-RAM and will result in a tremendous speedup in
    all CPU-intense tasks.

  Compatibilities and incompatibilities
  => In comparison to the Atari ST and Atari STE:
     This computer series does not feature TT-RAM in general. There
     are some expansions that have TT-RAM, but the number is too small
     to list them in detail here. An MXALLOC-call that requires TT-RAM
     will fail to work on these machines, but an MXALLOC-call that
     just prefers TT-RAM will allocate ST-RAM (if free).

  => In comparison to the Atari Falcon030:
     The Falcon030 also has, in general, no TT-RAM. Certain
     accelerator cards (FX card, Centurbo 2, etc.) do have TT-RAM
     though, some even allow burst-mode access, just like the TT does.
     In these cases, it's also sensible to write TT-RAM compatible
     software by using MXALLOC that prefers but does not require

  => What to look for when writing ST-Programs:
     Already dealt with in the chapter "for the programmer".

3. TT Graphics subsystem

   The TT bears a set of 6 fixed resolutions of which 5 are accessible
   with an ordinary VGA-compatible monitor while the sixth requires a
   special Atari 19" b/w monochrome monitor to be accessed.
   The set of resolutions is separated into 3 "ST-compatible" ones, 2
   "TT-resolutions" in colour and the last monochrome one.
   The registers to control the graphics subsystem are:

     Video Base Register:

       $FFFF 8201   X X X X X X X X            Adress High Byte
       $FFFF 8203   X X X X X X X X            Adress Mid Byte
       $FFFF 820D   X X X X X 0 0 0            Adress Low Byte

       The Video Base Register can only contain multiples of 8. The
       TT-Shifter can, due to ST-RAM memory logic, access 64 bits at
       once which are interleaved over the ST-RAM memory modules. Hence,
       the adress always has to be a multiple of 8 to allow this 64-bit
       access. Only the TT-Shifter can access ST-RAM in 64 bits width.
       The register works as a default adress which is being used after
       each VBL interrupt as base adress for the screen memory.

     Video Count Register:

       $FFFF 8205   X X X X X X X X            Counter High Byte
       $FFFF 8207   X X X X X X X X            Counter Mid Byte
       $FFFF 8209   X X X X X X X X            Counter Low Byte

       This register displays the adress that the Shifter is currently
       fetching its data from. It can be read AND written, at least in
       ST-compatible and TT-colour resolutions (Thanks to Ray/.tSCc.).
       It should maybe not be touched in TT-high resolution which
       features a pixel-clock of 95 MHz, which is almost 3 times the
       TT-CPU speed and 6 times the speed of the TT-bus.
       Hence, this register should be handled with care. Besides this,
       according to certain documentation, these registers are read

     Sync-Mode Register:

       $FFFF 820A  0 0 0 0 0 0 0 0 X         ST-Sync mode

       This register is mainly there for compatibility reasons,
       however, it is NOT ST-compatible. Only Bit 0 is being used. On
       the ST, setting bit 0 to 1 switched to EXTERNAL synchronisation
       of the video timing, on the TT, setting this bit to 0 switches
       the TT to external synchronisation.

    ST Palette registers:

      $FFFF 8240  0 0 0 0 r R R R g G G G b B B B    Colour 0
      $FFFF 8242  0 0 0 0 r R R R g G G G b B B B    Colour 1
        ...                  . . . . . .
        ...                  . . . . . .
        ...                  . . . . . .
      $FFFF 825E  0 0 0 0 r R R R g G G G b B B B    Colour 15

      These palette registers are STE-compatible and allow to set 16
      colours. Each entry consists of 12 bytes for the according RGB
      values. Bit 3 of each nibble for either red, green or blue,
      features the least significant value (1), while bits 0, 1 and 2
      contain the values 2, 4 and 8. This results in 16 values for
      each red, green and blue share, giving 4096 colours in total.

      However, the TT always works with a 256 colour palette. The
      palette registers from adress $FFFF8240 to $FFFF825F contain
      just a selected subset of colours - a so-called bank - of the
      256 TT-palette registers.
      This will be dealt with in detail further on.

    ST Shift mode register:

      $FFFF 8260  0 0 0 0 0 0 X X  0 0 0 0 0 0 0 0   ST Shift mode

      This register selects one of the 3 ST-compatible graphic modes
      in the following way. The 2-bit combination and the modes are:
        0  0  -  ST-Low  mode (320x200 pixels in 16 of 4096 colours)
        0  1  -  ST-Mid  mode (640x200 pixels in  4 of 4096 colours)
        1  0  -  ST-High mode (640x400 pixels in  2 of 4096 colours)
        1  1  -  reserved

      Once again, this register is not fully ST-compatible though. If
      a TT-specific mode is selected (dealt with in detail further
      on), this ST-Shift mode register ALSO contains all bits of the
      TT-Shift mode register. Therefore, handle with care.

    TT Shift mode register:

      $FFFF 8262  S 0 0 M 0 X X X  0 0 0 0 P P P P   TT Shift mode

      This register contains basically any setting the TT-Shifter
      allows. The "middle" bits, named X X X above, contain the
      desired video mode in the following order:
        0 0 0  -  ST Low  mode (320x200 pixels in 16 of 4096 colours)
        0 0 1  -  ST Mid  mode (640x200 pixels in  4 of 4096 colours)
        0 1 0  -  ST High mode (640x400 pixels in  2 of 4096 colours)
        0 1 1  -  reserved
        1 0 0  -  TT Mid  mode (640x480 pixels in 16 of 4096 colours)
        1 0 1  -  reserved
        1 1 0  -  TT High mode (1280x960 pixels monochrome)
        1 1 1  -  TT Low  mode (320x480 pixels in 256 of 4096 colours)
      The TT-High mode is not switchable and will automatically be set
      if a TT-High-compatible monitor is detected, similarly to the
      monochrome signal detection on the Atari ST to enable monochrome
      hires mode. In contrast to the ST, the ST-High mode does NOT
      require a special monitor on the TT and allows to select the 2
      colours displayed freely from the palette.
      Bit 15, named "S" above enables "Sample & Hold", nicknamed
      "smear"-mode. In this mode, the TT-Shifter will draw all pixels
      of colour "0" in the colour of the first pixel to the left with
      a different colour than "0". This means, a pixel of a certain
      colour in a line will "smear" to the right as far as there are
      pixels of colour "0" following. Intended to work as "hardware
      polygon fill" for line-vector 3D routines.
      Bit 12, named "M", enables "Hyper-mono mode", a superior
      greyscale mode in which 256 greyscales can be displayed at once.
      The 4096 colours palette is replaced by 256 greyscales. The
      nibble containing the "red" value in the palette registers are
      being ignored, the "green" and "blue" nibbles are combined to
      contain an 8-bit number of which greyscale to display.
      Finally, bit 0 to 3, named "P" above contain the number of the
      palette-"bank" from the TT-palette that is being used as
      ST-compatible palette. Values can be anything between 0 and 15.
      A value of "1" means, the colour 16 to 31 of the TT-palette are
      being used for the "ST-compatible Palette".

    TT Palette registers:

      $FFFF 8400  0 0 0 0 r R R R  g G G G b B B B   Colour 0
      $FFFF 8402  0 0 0 0 r R R R  g G G G b B B B   Colour 1
          ...                   . . .
          ...                   . . .
          ...                   . . .
      $FFFF 85FE  0 0 0 0 r R R R  g G G G b B B B   Colour 255

      Same function and structure like the STE-palette registers, just
      that there are 256 instead of 16.

  For the programmer:
    While the TT-Shifter seems to be highly ST-compatible first, it
    must be noted that it is not. First, the three so-called
    "ST-Compatible"-resolutions work at a line-frequency of 31.5 KHz,
    and not, like in the ST, with 15. ST-Low- and ST-Mid-resolution
    even require the TT to "doubly paint" all lines, just like the
    Falcon allows to. This may be invisible to the programmer (a HBL
    interrupt is only executed after each line has been drawn twice),
    yet again it means a totally different timing within each
    rasterline than on the ST.
    Besides that, the TT delivers a VGA compatible signal, meaning a
    vertical refresh of 60 Hz in all cases, while the ST allows both
    50 and 60 Hz. Also, all coloured ST-resolutions use the TT's
    256 palette registers basically, just that only a 16-colour subset
    of it is being used at once.
    Finally, the ST-Highres-mode is also being displayed with a
    refresh of 60 Hz (in comparison to 71 Hz on the ST) and allows to
    select the 2 colours on display (which is why it's called
    Duochrome mode).
    The 2 colour TT-modes, TT-Low and TT-mid allow higher resolutions
    and more colours.
    Hardware scrolling is being done the same way as on the STE (please
    refer to the STE-FAQ for that), just that adresses on the TT have
    to be multiples of 8. This makes horizontal fine-scrolling require
    at least 8 bytes per set of bitplanes (meaning ST-Low, TT-Mid or
    TT-Low. No other mode on the TT can be used in conjunction with
    horizontal fine-scrolling).

  Compatibilities and incompatibilities
  => In comparison to the Atari ST and Atari STE:
     The biggest difference is the fact that the timing of the
     ST-compatible resolutions on the TT is totally different than on
     the real ST. Additionally, note that the Sync-mode register works
     different than on the ST.
     Depending on the environment your program runs in, it might be
     possible that the ST-palette registers do not resemble colour 0
     to 15 of the TT-palette, so always access the ST-palette. If your
     program is also supposed to run in a TT-compatible resolution,
     bear in mind that the shift-mode register on the TT has
     additional bits that you might not want to change.
     As a conclusion one should note that when it comes to just write
     data to the screen memory to bring it on screen, the TT works
     just as the ST-does. "Old-school effects" like Overscan,
     Sync-Scrolling etc. would not work on the TT anyway since both
     CPU- as well as Shifter-timing differs vastly from the ST.

  => In comparison to the Atari Falcon030
     The Atari Falcon030 can be programmed to emulate the
     TT-compatible resolutions, by programming the VIDEL to display
     either 320x480 or 640x480 in either 256- or 16 of 4096 colours
     (by setting the ST(E)-compatibility-bit). However, the Falcon
     does not display a border on VGA (which the TT unfortunately
     does) and can also be programmed to display 320x480 or 640x480
     pixels on RGB using a refresh of 50 Hz, while the TT is fixed to
     refresh 60 times a second in any way.
     Besides that, the Falcon is not really capable of displaying the
     TT-High resolution. The part of the TT-Shifter that displays
     TT-High is not an Atari customchip anyway but an off-the-shelf
     circuitry by National Semiconductors. The Falcon can be "forced"
     to display 1280x960 in 2 colours by certain hard- or software
     expansions though.

  => What to look for when writing ST programs:
     Mind the Sync-mode register as well as the fact that screen
     adresses have to be multiples of 8 when trying to use
     STE-features on the TT. Also mind that screen memory has to
     reside in ST-RAM in all cases for the shifter to access.

4.  Blitter

    The Blitter, introduced in 1988 by Atari to massively speed up VDI
    copy and move operations, is NOT present in the TT.
    The TT does not have a Blitter.
    This makes sense in some way, as the CPU in the TT is a lot
    faster when it comes to copying blocks around the memory than the
    CPU in the ST is. If source and/or destination are even located in
    TT-RAM, which the Blitter could not access anyway, the speed gain
    is even more massive.
    TOS 3.0x therefore does not offer Blitter-based VDI-routines. All
    attempts to access the Blitter will crash the TT.

  Compatibilities and incompatibilities
  => In comparison to the Atari ST and Atari STE:
     The ordinary ST usually does not have a Blitter (only the Mega ST
     series has a Blitter), the STE does have a Blitter. In the ST
     (where present) or STE, the Blitter does mean quite a speed-up.
     However, if you are trying to program the ST or STE in a
     TT-compatible way, you may not use the Blitter.

  => In comparison to the Atari Falcon030:
     The Atari Falcon030 does have a Blitter, and for most copy
     operations, the Falcon-Blitter, even though it's operating at 16
     Mhz, is a factor of 3 to 4 slower than the CPU is on the same
     operations. Therefore, it is usually not adviseable to use the
     Blitter in the Falcon anyway. To program the Falcon in a
     TT-compatible and efficient way, you may not use the Blitter.

  => What to look for when writing ST programs:
     No Blitter in the TT. That's all to mind.

5.  DMA-Sound

    The TT-DMA sound is, as seen by the programmer, 100% identical to
    the DMA-sound of the STE. It offers:
      -> 6.25, 12.5, 25 or 50 KHz replay rate
      -> stereo or mono
      -> 8 bit samples
      -> National LMC 1992 soundchip to enhance bass/treble etc.
      -> Microwire interface to connect to the LMC1992
    All adresses and registers are identical to the ones in the STE,
    hence i recommend to refer to the STE-FAQ for details on the
    DMA-sound subsystem.

    Hardware-wise, the TT DMA-sound system is totally different. Since
    the STE-Shifter also houses the largest parts of the STE-DMA-sound
    system and since the TT does not have the STE-Shifter, the whole
    adress generation logic as well as the DMA-sound replay system had
    to be put into its own set of chips.
    This is, however, invisible to the programmer.

6.  Other specifications of the TT to mind about:

  -> The Atari TT does not have the advanced joystick ports that the STE
     (not MegaSTE) and Falcon030 have. Any program requiring user
     interaction using these ports will not work on the TT.

  -> The Atari TT does not have simple SIMM-slots for upgrading the
     ST-RAM. This is due to the special logic needed by the TT-Shifter
     to access ST-RAM with 64 bits width. There are, however, ST-RAM
     expansion cards that allow to connect SIMMs of a certain type.

  -> The Atari TT has neither the Megabus nor an 68000 on a DIL-socket
     for ST-compatible expansions. The TT was meant to drive VME-bus
     expansions. Besides that, due to the fact that the TT has an
     68030, expansions that work on the Megabus or 68000-socket would
     not have worked anyway.

7. Epilogue:

  In 1990, the TT seemed a very very powerful machine. And it did
  quite well for some time, being sold as DTP- and Layout computer in
  conjunction with Calamus and Digital Arts' software.
  Nevertheless, the TT never conquered the homes like the ST did. It
  didn't play any ST-games and there were hardly any TT-compatible
  games. Besides a few 3D- or 256-colour demos, the TT never saw any
  demos either. Besides "Sweety" by DHS, the TT does not run many ST
  demos until now.

  By this little documentation i hope however that this situation can
  be improved. It is not very hard to write games or demos in a
  TT-compatible way if you mind the aspects discussed in this little
  documentation. Old-school demo-effects will never work on the TT -
  on the Falcon, there is at least the option to switch the CPU and
  Blitter to 8 MHz and when also switching all caches off, the Falcon
  can behave very ST-like. The TT can't. The CPU always runs at 32
  MHz, the bus always at 16 MHz. The video-timing is totally different
  because the TT only supports VGA. Additionally, there's the
  separation between TT- and ST-RAM to mind.

  However, new-school effects can easily be done in a TT-compatible
  way. Chunky-2-planar conversion works on the TT similarly to the ST
  and Ray of .tSCc. even found quick ways of doing 256-colour-c2p
  (thanks to the Amiga community) - and when doing new-school effects,
  the additional power of the TT's CPU along with the TT-RAM can
  achieve a stunning performance.
  Frankly, the less your program relies on hardware-accesses, the more
  ST-compatible the TT will behave.

Back to Atari ST FAQ