Atari TT FAQ compiled by The Paranoid / Paradox
The following file can be found on https://alive.atari.org/alive6/tt.php 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: https://alive.atari.org/alive6/ste.php)
Some minor hints and notes on
___________ ___________
_____/ / _____/ /
/ / _____/ / / _____/
/____/ / / /____/ / /
/_____/ / /_____/ /
/ / / /
/ / / /
/_____/ /_____/
Coding
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.
Paranoia
Think you can handle it ?!
(of the Lunatic Asylum)
Preface.
========
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.
Conventions
===========
Certain names or brands will be used in this documentation to adress
the different Atari computer models that may be mentioned in this
documentation:
- 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
(FPIAR).
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
anything.
=> 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
programmer.
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
TT-RAM.
=> 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
only!
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