Atari STE FAQ compiled by The Paranoid / Paradox

From AtariForumWiki
Jump to navigation Jump to search

The following file can be found on the net so I (Simon Sunnyboy/Paradize) assume it can be distributed here:


                        Some minor hints and notes on
                        
                  ___________      ___________  ___________
                 /          /_____/          / /          /
                /     _____//    /     _____/ /     _____/
               /     /____ /____/     / /  __/     /
              /_____/    /     /_____/ /  / /_____/
             _____/     /       /     /  /      /_____
            /          /       /     /  /            /
           /__________/       /_____/  /____________/
           
                                 Coding
                                 
       assembled after depressing hours of experiments and tests
       that did usually not work out as planned by The Paranoid.
       
                                 Paranoia
                        Think you can handle it ?!
                        
                         (of the Lunatic Asylum)
                         
                         

Preface:
--------
The Atari STE is, without a doubt, a nice machine. It has so many
features the Atari ST lacked:
- 4096 instead of 512 colours
- Horizontal and Vertical hardware scrolling
  (also called hardware windowing of large virtual screens)
- Blitter
- 8 Bit DMA stereo sound
  (Up to 50 KHz replay rate)
- National LMC 1992 soundchip, connected over Microwire serial port
  Treble, Bass, Left/Right/Main Volume Control
- 256KB EPROM containing the TOS, socketed
- 4 30-pin SIMM-slots, up to 4 MB RAM
- Extended and analogue capable joystick ports

Unfortunately, you will pretty soon find out that the STE also
contains a lot - and i mean a lot - of pitfalls.
Whatever feature of the STE you want to use, it will either
not work as planned or require special treatment. If it works
as planned and does not require special treatment, it will
definetly not work on the TT or the Falcon.
So this documentation is just a little compilation of the usual
traps especially programming beginners might step in and how
to dodge these traps.

This documentation is given on an "as is" basis. Paranoia does
not give any warranties about correctness about the given
information here. We can not be held responsible for any loss
of data, damage to your hardware or whatever might happen to
you, your software or your hardware after reading this 
document.
Every chapter will describe the special registers for a certain
feature and afterwards list the traps you should look out for.
In the bitset tables, "0" means this bit cannot be set and is
automatically assumed "0", "1" means this bit cannot be set and
is automatically read as "1", "X" means it can be read/written
and can feature "0" or "1".
In the Tables, "yes" means this register exists in the model
mentioned while "no" means that this register does not exist.
"ro" means "read only" and refers to a register that cannot be
written to, "rw" means "read/write" and declares a register
that can be read as well as written to.


1.) The Hardware Scrolling
--------------------------
The Registers:
  Video Base Address:                             ST     STE
    $FFFF8201    0 0 X X X X X X   High Byte      yes    yes
    $FFFF8203    X X X X X X X X   Mid Byte       yes    yes
    $FFFF820D    X X X X X X X 0   Low Byte       no     yes

    The first two registers are identical with those of the ST and
    can be read and written to. The last one (low byte) did not
    exist on the ST. While on the ST this meant that a Video Base
    address had to be even on a 256-byte basis (lowbyte was
    assumed #$00 then), on the STE it only has to be even since
    bit 0 is automatically assumed #0.
  
  Video Address Counter:
    $FFFF8205    0 0 X X X X X X   High Byte      ro     rw  
    $FFFF8207    X X X X X X X X   Mid Byte       ro     rw
    $FFFF8209    X X X X X X X 0   Low Byte       ro     rw

    This set of registers already existed on the ST but could not
    be written to. The Shifter uses this actually for counting
    through the whole screen it is building up. Write access
    has of course immediate effect.
  
  Line-Offset Register
    $FFFF820F  X X X X X X X X X                  no     yes
    
    This register contains the value how many WORDS (not BYTES!)
    the Shifter is supposed to skip after each Rasterline. This
    register enables virtual screens that are (horizontally)
    larger than the displayed screen by making the Shifter skip
    the set number of words when a line has been drawn on screen.
    
  Video Base Address Pixel Offset
    $FFFF8265  0 0 0 0 X X X X                   no      yes
  
    This register allows to skip from a single to 15 pixels at
    the start of each rasterline to allow horizontal fine-
    scrolling.
    
The registers are easy to understand. So why didn't it work ?

? Writing to the Video Base Address registers seems to have no direct
  affect on the screen contents.
! No. These registers only contain the "reset" value for the Shifter
  after a whole screen has been drawn. It does not affect the current
  screen, but the one for the next VBL. To make immediate changes on
  the screen, use the Video Address Counter.

? There's only junk on the screen. It looks like the STE reads the
  screen content from a totally wrong address.
! For compatibility reasons, the low-byte of the Video Base Address
  is ALWAYS set to 0 when the mid- or high-byte of the Video Base
  Address are set. This is easy to understand, seeing that the ST
  did not have this register - hence ST software that never sets
  the low-byte might have problems setting the correct Video Base
  Address. The solution on the STE is simple: Always set the
  Low-Byte last. First set High and Mid-Byte (in no special order),
  then do the low-byte.

? Scrolling in 16-pixels blocks works, but fine-scrolling totally
  screws up the screen contents.
! The Line Offset Register is very critical. Make sure it contains the
  correct value at any time. If the Pixel Offset Register contains a
  zero, the Line Offset Register contains the exact number of words
  to skip after each line. But if you set the Pixel Offset Register to
  "X", the Shifter will still display 320 (640) pixels a line and 
  therefore has to read "X" pixels from the NEXT word which it would
  have skipped if the Pixel offset Register contained a "0".
  Hence, for any Pixel Offset Value > 0, please note that the Shifter
  has to read (a few bits) more each rasterline and these bits
  must NOT be skipped using the Line Offset Register.

? Tried. Screen content is still screwed up.
! Please also note that in Low-Resolution (4 Bitplanes), the Video-
  Shifter reads 4 words at once. In Low-Res, the Line Offset therefore
  always has to be a multiple of 4, otherwise the Shifter will not
  display the bitplanes correctly next rasterline.

? In Hires (Monochrome 640x400), my scrolling does not work on the
  Falcon
! On the STE, the Video Base Address only has to be a multiple of 2
  since bit 0 is always "0". On the Falcon, the least significant 2
  bits of the Base Address are "0", hence, on the Falcon, you can
  horizontally scroll a minimum of 2 words, which, in monochrome
  mode, is not sufficient for fine-scrolling.
  There is no way to do horizontal-fine scrolling on the Falcon in
  a monochrome mode. Midres (640x200 2 bitplanes) will already
  work since every address has to be a multiple of 4 then.

? Gah! On the TT neither hires nor midres works.
! It's even worse on the TT since the TT-Shifter lacks the 3 least
  significant bits of the Video Base Address, hence all Video Base
  Addresses have to be a multiple of 8. In hi- and midres however,
  any "sound" Base Address is a multiple of 2 or 4.
  There is no way to horizontally fine-scroll on the TT in these
  resolutions.

? It scrolls, but the screen-content seems to jump sometimes.
! The Atari STE shifter has a slight timing problem regarding the
  Pixel Skip Register. Whenever this registers "jumps" from a value
  >"0" to "0", the STE might display the wrong screen address.
  This is a known problem and Atari affirms it.
  Atari officially suggests to NOT set the Pixel Skip register in
  the VBL as this causes the problem. Since changes on this
  register have immediate effect, Atari suggests to use a HBL
  routine that sets all registers connected to Video hardware
  not in the VBL but in (for example) a HBL interrupt after the
  VBL.

? On the Falcon and TT, fine-scrolling seems to work without
  the jumping in low-res, even when the registers are set in the
  VBL-interrupt.
! Affirmed. Both TT and Falcon do not suffer "visibly" from this
  bug. However, in case there are other bus-timing critical jobs
  running (like MOD-replay routines or heavily loaded interupt
  routines that occur more often than the VBL), this bug MIGHT
  become visible as well. Besides, if you are coding Falcon or
  TT for STE compatibility, you should follow Atari's suggestion
  and not use VBL to set the registers.
  You will learn later on that the STE behaves very very critical
  to anything done in the VBL anyway.
  
? I tried to write a screen splitting routine that changes a lot
  of Video-related parameters after a certain rasterline. But it
  is highly fragile and does not work very well.
! The STE with an 8 MHz CPU is not very fast and timing becomes
  critical when trying to change Video-registers on the fly
  during the screen build-up. There is no general solution for
  this, just that you should, during screen build-up, never
  change too many registers or at least not in a way that it
  costs too much time. If you do need to change many registers,
  make a table with all the values long before they are used
  (for example in the VBL) and try to write these values as
  quickly as possible.
  Sometimes, an empty line in exactly that HBL you change all
  the registers, can help a lot.

? So now i fixed it and it works fine on the STE, but often enough,
  bitplanes are screwed up on the Falcon. Why ?
! Remember that the Falcon only allows screen addresses as multiples
  of 4, which is not as flexible as on the STE, where it only has to
  be a multiple of 2. This is also the case for the Video Counter
  Registerts, not only for the Video Base Address.
  Make sure that your screen data is stored on an address that is
  a multiple of 4 and it will work.

? My screen splitting routine now works fine on the STE and
  on the Falcon, but not on the TT.
! On the TT, it's even worse and each Video Base Address has to
  be a multiple of 8. According to Ray/tSCc, the TT allows write
  access to the Video Counter - in contrast to what some books
  say. However, officially, the TT does not allow to change
  video address on the fly by writing to the address counter.
  

2.) 4096 Colours
----------------
Registers:

  Palette Register:                                 ST     STE
    $FFFF8240  0 0 0 0 x X X X x X X X x X X X       X     x+X
    $FFFF8242  0 0 0 0 x X X X x X X X x X X X ...
    ...
    $FFFF825E  0 0 0 0 x X X X x X X X x X X X    (16 in total)
                       ---_--- ---_--- ---_---
                         red    green    blue
    
    These 16 registers serve exactly the same purpose as in the
    ST. The only difference is that each Nibble for Red, Green
    or Blue consists of 4 bits instead of 3 on the ST.
    
This time, Atari did good work (almost). So what are the pitfalls:

? I tried to program a fade and it works in general, but flashes
  during the fade, why ?
! For compatibility reasons, each nibble encoding the Red, Green or
  Blue values is not ordered "8 4 2 1", meaning the least significant
  bit represents the value "1" while the most significant one 
  represents the value "8" - This would make the STE rather 
  incompatible with the ST and only display dark colours.
  The sequence of Bits is "0 3 2 1" encoding the values
  "1 8 4 2". Therefore to fade from black to white, the sequence
  of colours would be $000, $888, $111, $999, $222, $AAA, ...
  
? My program sets the palette correctly on the STE in lowres
  (320x200 16 colours). Will it also work on the TT in TT midres 
  (640x480 16 colours) ?
! Yes, it will. Even though the TT uses its own palette registers,
  256 in total, it can "mask in" a set of 16 colours in the ST
  palette registers, which are of course at the same address as
  on your STE. Meaning: Whatever values you write in the ST
  palette registers on the TT, in TT midres, they will be used.
  Your program will even work correctly in TT Low (320 x 480
  256 colours), if the TT Shiftmode register is set accordingly.

? So it does work on the TT alright. But i have a Falcon and not
  a TT. Now what ?
! The Falcon can be switched to "ST compatible mode". This is not
  a 100% term since it does not - in contrast to the TT - mean
  either 320x200, 640x200 or 640x400 pixels in 16,4 or 2 colours
  but only means that the ST palette registers are being used,
  hence this flag can only be used when displaying 16, 4 or 2
  colours. If you do not set this flag, the Falcon will NOT
  - in contrast to the TT - read the ST palette registers.
  This change has been necessary since the Falcon has 18 bits
  per colour in bitplane mode while the TT only has 12, just
  like the STE has. The Falcon RGB format for a palette mode
  is: 00RRRRRR 00000000 00GGGGGG 00BBBBBB (VGA compatible).
  

3.) The Blitter
---------------
(The Blitter in the STE is, at least from the programmers view,
 identical to the Blitter in the Mega ST. Hardware-wise, it is
 not)

Registers:
  
  Halftone RAM:                            
    $FFFF8A00  Halftone RAM, Word 0    (16 Words in total)
    ...
    $FFFF8A1E  Halftone RAM, Word 15
    
  Halftone RAM is a 32 Byte zero-waitstate Blitter-exclusive RAM
  that can be used for lightning-quick manipulations of copied
  data. Its main purpose was to combine monochrome picture data
  with (16 x 16 pixel) patterns, usually to make them a bit
  darker or brighter (halftone).
  
  Source X Increment Register:
    $FFFF8A20  X X X X X X X X X X X X X X X 0
  Source Y Increment Register:
    $FFFF8A22  X X X X X X X X X X X X X X X X
    
    These registers encode how many bytes the Blitter increments the
    counter after each copied word ($FFFF8A20) or after each line
    ($FFFF8A22). Source Y Inc has to be even since the Blitter only
    works on a Word-basis and can not access single Bytes.
  
  Source Address Register:
    $FFFF8A24  XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXX0
    
    The 32-Bit address of the source, meaning the Blitter will start
    reading from this address. This address has to be even as the
    Blitter cannot access single Bytes. The Blitter actually accepts
    real 32-Bit addresses, but the MMU filters the upper 10 bytes
    out.

  Endmask Registers
    $FFFF8A28  X X X X X X X X X X X X X X X X  Endmask 1
    $FFFF82AA  X X X X X X X X X X X X X X X X  Endmask 2
    $FFFF82AC  X X X X X X X X X X X X X X X X  Endmask 3
    
    The Endmask is a Bitmask that can be applied upon the copied
    data in a blockwise way. Endmask 1 is being applied on every
    first word copied in a row, Endmask 2 for all other words
    in this row except for the last one, which is combined with
    Endmask 3. Clever usage of these registers allow to start
    copies from basically every bit in memory.
    
  Destination X Increment Register:
    $FFFF8A2E  X X X X X X X X X X X X X X X X
  Destination Y Increment Register:
    $FFFF8A30  X X X X X X X X X X X X X X X X
    
    Similar to the Source X/Y Increment Register. These two denote
    how many Bytes after each copied word/line the Blitter proceeds.
    
  Destination Address Register:
    $FFFF8A32  XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXX0
    
    This contains the address where the Blitter copies all the
    data to that it computes. A real 32 Bit word that has to be even.
    
  X Count Register:
    $FFFF8A36  X X X X X X X X X X X X X X X X
  Y Count Register:
    $FFFF8A38  X X X X X X X X X X X X X X X X
    
    These two registers contain the information about how the 2D
    bitblock the Blitter copies are shaped. The X Count Register
    contains how many words a line of this rectangular block has,
    the Y-Count how many lines the bitblock has in total.
    This does not include the skipped words, only those the
    Blitter really copies (hence the name count).
  
  Blit HOP (Halftone OPeration) Register:
    $FFFF8A3A  0 0 0 0 0 0 X X
    
    How to combine Halftone-Data and copied data is given here.
    A "00" means all copied bits will be set to "1" (blind copy),
    "01" means ONLY halftone content will be copied, "10" implies
    that ONLY source content will be copied (1:1 copy). "11" makes
    the halftone-pattern work as supposed and does a copy 
    "Halftone AND source".
  
  Blit OP (logical OPeration) Register:
    $FFFF8A3B  0 0 0 0 X X X X
    
    The Blitter can carry out 0-cycles logical operations with
    source and target. The table of possible values follow:
    0 0 0 0    - Target will be zeroed out (blind copy)
    0 0 0 1    - Source AND Target         (inverse copy)
    0 0 1 0    - Source AND NOT Target     (mask copy)
    0 0 1 1    - Source only               (replace copy)
    0 1 0 0    - NOT Source AND Target     (mask copy)
    0 1 0 1    - Target unchanged          (null copy)
    0 1 1 0    - Source XOR Target         (xor copy)
    0 1 1 1    - Source OR Target          (combine copy)
    1 0 0 0    - NOT Source AND NOT Target (complex mask copy)
    1 0 0 1    - NOT Source XOR Target     (complex combine copy)
    1 0 1 0    - NOT Target                (reverse, no copy)
    1 0 1 1    - Source OR NOT Target      (mask copy)
    1 1 0 0    - NOT Source                (reverse direct copy)
    1 1 0 1    - NOT Source OR Target      (reverse combine)
    1 1 1 0    - NOT Source OR NOT Target  (complex reverse copy)
    1 1 1 1    - Target is set to "1"      (blind copy)
    
  Blitter Control Register:
    $FFFF8A3C  X X X 0 X X X X
    
    This register serves multiple purposes.
    The lowest 4 bit represents the number of the line in the
    Halftone pattern to start with.
    The upper 3 bits feature extended options of the Blitter.
    Bit 5  -  Smudge-mode
              Which line of the halftone pattern to start with is
              read from the first source word when the copy starts
    Bit 6  -  Blit-Mode Register
              Decides wether to copy in BLIT Mode (0) or in 
              HOG Mode (1). In Blit Mode (also known as cooperative),
              CPU and Blitter get 64 clockcycles in turns, in Hog 
              Mode, the Blitter reserves and hogs the bus for as long
              as the copy takes, CPU and DMA get no Bus access.
    Bit 7  -  Busy Bit
              Turns on the Blitter activity and stays "1" until the
              copy is finished
              
  Blitter Skew Register:
    $FFFF8A3D  X X 0 0 X X X X
    
    The lowest 4 bit of this register allow to shift the data while
    copying by up to 15 bits to the right. The upper 2 bits are
    Bit 6  -  NFSR (No final source read)
    Bit 7  -  FXSR (Force extra Source Read).
    NFSR means the last word of course is not being read anymore.
    This is only sensible with certain Endmask and skew values.
    FXSR is the opposite and forces the Blitter to read one more
    word. Also only sensible with certain Endmask/Skew combinations.


So much for the theory. Unfortunately, the Blitter is a lovely but
also pretty stubborn little chip. What went wrong this time ?

? After feeding the Blitter values and activating it, the STE
  totally crashes.
! All the address-related auxilary registers such as X-Count/Y-Count,
  X/Y-Increments etc. are signed values. In other words, the Blitter
  can go backwards in memory as well as forward. Please check if your
  values are correct.

? I am trying a simple and direct copy and set all the important
  registers, but it does not work as i planned.
! The Blitter is a chip and not a software, meaning it does not know
  any default values. Especially when starting to learn "Blitter" it
  is important to ALWAYS set EVERY Register correctly.
  Especially Endmask, Smudge, Skew and OP-Register can lead to very
  funny results if not set correctly. So set ALL the registers at
  least once, for all subsequent copies you do not need to set them
  ALL anymore.

? The copy appears at the right spot, but is scrambled.
! Make sure your X/Y-Increments are correct for both Source and
  Destination. Especially if you are copying a "tight" block
  (like a 32x32 pixel compact block) to a larger area (like the
  screen) you definetly need to watch the increment registers.

? Now the first copy works, but even though i am copying blocks of
  identical size, just setting addresses does not work.
! No, the Blitter uses a few of the registers accessible by the CPU
  for its own counting. Set Addresses, X and Y-Count Registers
  every time you do a copy in any case. 
  
? So i set all the registers, but the copies are incomplete when
  i do multiple copies.
! Before feeding the Blitter new values, make sure it has finished
  its task already by checking the Busy-Bit.
  Do not write new values into the Blitter's registers as long as
  it is still operating.

? It looks like the copy itself works, but it flickers. And i was
  using the Blitter to speed things up, not to make them flicker.
! After feeding the Blitter all the values and activating it, the
  CPU is done and can do other tasks, the Blitter however has just
  started. If the Blitter does critical things in your program make
  sure the "Blit Busy" has returned from "1" to "0" before your CPU
  proceeds when using the Blitter in Blit-mode.
  
? To make it even faster, i turned the Blitter into Hog-mode.
  But now my program crashes almost at random.
! The Hog-Mode of the Blitter does not allow the CPU to access to
  bus while the Blitter is active - Not even for interrupts. Make
  sure that your software does not require the CPU to react to
  an interrupt immediatelly - Otherwise, the STE will crash.

? Is there a way to make the Blitter faster in Blit-mode ?
! Yes, there is. Atari used this to speed up the Blitter in GEM
  without risking to use Hog-mode:
  Check the Busy-Bit. The CPU cannot access the bus and therefore
  not the Busy-Bit if the Blitter is "active". If the CPU can finally
  check the Busy-Bit the Blitter has "paused" and will wait for 64
  clockcycles. Now if the Busy-Bit is 0, the Blitter is done and
  you can leave. If not, set it to "1" manually and do a NOP.
  Writing the Busy-Register will relaunch the Blitter immediatelly,
  but the Blitter needs a few clockcycles to reserve the bus
  (around 7), so the NOP is carried out in any case.
  This gives about 90% the speed of the HOG-mode without losing
  the option to execute interrupts within the next 64 clockcycles.
  Here's an extract from the ST Profibook:
     Loop:    bset.b #7,$FFFF8A3B  ;test and set Busy-Bit
              nop                  ;do a NOP in any case
              bne.s Loop           ;if Busy-Bit was "1", go to Loop

? Huh ? My program does not work on the TT ?
! No, it does not. The TT does not have a Blitter.

? I am coding the Blitter on the Falcon to reduce CPU usage a bit
  but the program has slowed down even more.
! Unfortunately, the Falcon Blitter is rather useless since the
  68030 is, when doing a simple 1:1 copy, about a factor of 4 to 5
  faster than the Blitter in the Falcon is, even though the Falcon
  Blitter is running at 16 MHz.
  On the Falcon, the Blitter can become useful if you plan to 
  heavily use Halftone-pattern, bitwise-shifts and logical operations.
  Otherwise, use the CPU instead.

? I was trying to use the shift-operations of the Blitter to have
  my objects on screen (ST Lowres) move pixelwise, but instead,
  Bitplanes are being screwed up.
! Please bear in mind the interleaved bitplane structure of the
  ST Low resolution. Trying to copy and shift all bitplanes at
  once will make the Blitter shift single bits from bitplane X
  to bitplane Y. Copy bitplane by bitplane and it will work.

? Copying and shifting blocks with the Blitter works now, but
  sometimes, a few bits get lost.
! In some cases, depending on the Endmask- and the Skew-registers,
  the Blitter requires to read a word more than planned. Try
  the FXSR-Register in these certain conditions.

? I copy around large chunks of memory in one go, but i can't
  really say it has gotten very fast on the Mega STE.
! The Blitter in the STE does nearly 2 MB/sec. Per frame this
  is roughly 40 KB/sec. The CPU in the STE comes nowhere near
  that, but the CPU of the Mega STE (16 MHz, cache on) can
  almost compete when it comes to direct 1:1 copies.

? I heard somewhere, that the Blitter can be used for generating
  software sprites all by itself. Is that true ?
! Yes, you can have software sprites using the Blitter, that
  can be freely positioned (pixel-perfect) without any other
  interference of the CPU than just feeding values into the
  Blitter registers. However, the Blitter cannot produce a
  4 bitplane software-sprite in 1 go.
  The simplest solution is to copy bitplane by bitplane,
  and each bitplane twice: First NOT Source AND Target, then
  Source OR Target. Since the shifts do not need any additional
  time for the Blitter to carry out, this will, on the STE,
  result in lightning fast sprites since the 68000 is very slow
  doing the shifts.

? I program the Falcon in true-colour mode and i would like to
  take advantage of the Blitter.
! Even though of course the Blitter works well in TC-mode, its
  special features, bitwise shifts, extremely fast logical
  operations, masks for bitwise copy and the halftone pattern,
  are basically useless and for a direct copy, the CPU is a lot
  faster.
  
? Is it just my imagination or is the Blitter in the Mega ST
  really a bit faster than the Blitter in the STE ?
! Actually, this is true. Due to the fact that the Blitter is
  a sole chip in the Mega ST and has been combined in a chip
  named COMBEL in the STE, it is really very slightly slower
  in the STE than it was in the Mega ST.
  This however is almost invisible.
  

4. DMA-Sound - the simple way to make music
-------------------------------------------
Registers:
  DMA-Sound Control Register:
    $FFFF8900  0 0 0 0 0 0 0 0 0 0 0 0 0 0 X X
    
    Writing a "00" to the last 2 bits terminate DMA sound replay.
    Bit 0 controls Replay off/on, Bit 1 controls Loop off/on
    (0=off, 1=on).
  
  DMA-Sound Start Address Register:
    $FFFF8902  0 0 X X X X X X X X X X X X X X   Hibyte
    $FFFF8904  X X X X X X X X X X X X X X X X   Midbyte
    $FFFF8906  X X X X X X X X X X X X X X X 0   Lowbyte
    
    These three registers contain the 24-bit address of the sample
    to play. Even though the samples are built on a byte-base, the
    DMA chip also only allows even addresses
  
  DMA-Sound Count Register:
    $FFFF8908  0 0 X X X X X X X X X X X X X X   Hibyte  (ro)
    $FFFF890A  X X X X X X X X X X X X X X X X   Midbyte (ro)
    $FFFF890C  X X X X X X X X X X X X X X X 0   Lowbyte (ro)
    
    Used internally for the DMA-soundchip to count from start- to
    end-address. No write access.
  
  DMA-Sound End Register:
    $FFFF890E  0 0 X X X X X X X X X X X X X X   Hibyte
    $FFFF8910  X X X X X X X X X X X X X X X X   Midbyte
    $FFFF8912  X X X X X X X X X X X X X X X 0   Lowbyte
    
    The address that the sample ends at. When the count registers
    have reached this address, the DMA-sound system will either
    stop or loop.
    
  DMA-Soundmode Register:
    $FFFF8920  0 0 0 0 0 0 0 0 X 0 0 0 X X X X
    
    Allows to toggle between several replay methods.
    Bit 7 switches Mono/Stereo (1 = Mono, 0 = Stereo),
    Bit 0 and 1 encode the replay rate:
      0 0  -  6258 Hz
      0 1  - 12517 Hz
      1 0  - 25033 Hz
      1 1  - 50066 Hz
      
Sounds fairly easy, right ? Unfortunately, it's not.

? I set all the registers, but there is no sound at all.
! The DMA-Soundsystem expects you to write the high-byte of the
  Start- and Endaddress first. Even though this serves no
  purpose at all, writing the highbyte clears the others. Hence
  it must be written first.
  
? I can't hear anything on my Falcon when trying to replay a
  6 KHz sample.
! The Falcon DMA-soundsystem does not support 6 KHz. The value
  "00" in the Soundmode-register means "OFF" on the Falcon.

? The sound is awful. This does not sound like my sample.
! On the STE, the DMA-soundsystem only works with signed sample
  files, featuring values from -128 over 0 to +127. Some sample
  programs use unsigned formats, ranging from 0 to 255 with
  128 representing zero-line of the sample. Those samples need
  to be converted first.

? I want to replay stereo samples. How can i know which sample
  will be played on which channel ?
! Stereo Samples have to be organized wordwise like
  Lowbyte -> right channel
  Hibyte  -> left channel
  
? My STE program to replay samples does not work very well on the
  Falcon.
! No, the Falcon's soundsystem is way more complex and can without
  any major programming interfere very well with the parts of the
  STE-soundsystem, especially since identical addresses are used for
  some purposes. If you want Falcon-compatibility of your STE-code,
  do not use "move"-instructions to set/unset bits of $FFFF8900
  and $FFFF8920 as this might override Falcon-specific registers.
  Best, leave them as they are and use AND to unset and OR to set
  certain bits.

? Will my STE code work on the TT ?
! Yes, it will. The TT's DMA-sound subsystem is identical to the
  one of the STE.
  
? I am trying to change the addresses of the sample while the
  DMA-sound plays, but it does not work.
! No, the DMA-Soundsystem latches the Start- and End-Register
  internally, so writing to these values only takes influence
  when the values are re-read, which happens when the sample
  has been played, even if the DMA-soundsystem is switched to
  loop.

? Argh, i have now implemented DMA-sound to my program and now
  my whole screen-management goes wild
! This easily happens. The DMA-sound subsystem of the STE houses
  the "shifting logic" in the STE-Shifter. When starting the DMA
  sound to play a sample, you should not try to access the Shifter's
  registers directly afterwards but "wait" a few cycles.
  The simplest solution is to wait a single VBL after starting
  the DMA-sound before proceeding with your program.
  Once the DMA-sound plays, you can change DMA-sound registers
  without risking to screw up screen management.

? Can i get a "notice" from the DMA-soundsystem when it finished
  playing a sample ?
! Yes, you can use TIMER A as event counter which will be notified
  when a sample has been played completely.
  
? I want to replay a sample backwards.
! Does not work on the STE. The sample-counter can only be
  increased, not decreased.


5. The National LMC 1992 and the Microwire
------------------------------------------

Preface:
  There's a little, but common mistake of minor importance when it
  comes to this combo that allows manipulation of the DMA sound to
  enhance trebble and bass as well as left, right and main volume.
  It is not the Microwire interface that manipulates the sound, it
  is a chip named National LMC 1992.
  This chip however has not been integrated into the Atari STE
  hardware directly but can only be communicated with using a 3-bit
  serial interface, the so-called Microwire.
  It is a bit hard to handle for a beginner, but luckily, it is also
  hard to crash the STE using this register.
  And since the Microwire can basically connect more than just one
  device, it needs a 2 bit address to which device to transfer data
  to. The LMC1992 is at "address" 2 (binary 10). Each address-data-pack
  written to the LMC1992 therefore consists of an 11 bit package.
  The communication is a bit similar to communicating with the YM2149
  since the Microwire also requires to encode data in a certain way.
  
National LMC 1992
  Adress and Data register
    $FFFF8922  x x x x  x x x x  x x x x  x x x x
    
    This address is being used to feed the National LMC both
    address and data bits for a certain setting.
    The choice which bits are being read are being described
    in the mask register at $FFFF8924.
    As described above, the first two bits of the 11 bit
    package need to be a "10" to address the LMC1992.
    Then there are 3 more "address" and 6 more data bits.
    The address bits are 3 in total and are being used as
    follows:
      0 1 1  -  Master Volume (followed by 6 bits of data)
      1 0 1  -  Left channel volume (followed by 6 bits of data)
      1 0 0  -  Right channel volume (followed by 6 bits of data)
      0 1 0  -  Trebble control (followed by 6 bits of data)
      0 0 1  -  Bass control (followed by 6 bits of data)
      0 0 0  -  Mixer (followed by 6 bits of data).
      
    However, not all bits of the 6 general data bits are being
    used. It is necessary to have a multiple of 6 though since
    the Microwire is a 3-bit serial interface.
    The explanation of the 6 data bits are
      (d means necessary data bit, x means bit is ignored)
    
      Master Volume: d d d  d d d  (all 6 bits used)
                     0 0 0  0 0 0  = -80 db volume
                     0 1 0  1 0 0  = -40 db volume
                     1 0 1  x x x  =   0 db volume (max)
      Each increment represents 2 db. If the 3 left bit encode "101",
      the last 3 bits are being ignored.

      Left channel:  x d d  d d d  (left bit ignored)
                       0 0  0 0 0  = -40 db volume
                       0 1  0 1 0  = -20 db volume
                       1 0  1 x x  =   0 db volume (max)
      Each increment represents 2 db. If the 3 left bit carry "101",
      the last 2 bits are being ignored.
      
      Right channel: x d d  d d d  (left bit ignored)
                       0 0  0 0 0  = -40 db volume
                       0 1  0 1 0  = -20 db volume
                       1 0  1 x x  =   0 db volume (max)
      Each increment represents 2 db. If the left 3 bit are "101",
      the last 2 bits are being ignored.
      
      Trebble:       x x d  d d d  (left 2 bits are ignored)
                         0  0 0 0  = -12 db (min)
                         0  1 1 0  =   0 db (linear)
                         1  1 0 0  =  12 db (max)
      Each increment represents 2 db, normalized at 15 KHz.
      
      Bass:          x x d  d d d  (left 2 bits are ignored)
                         0  0 0 0  = -12 db (min)
                         0  1 1 0  =   0 db (linear)
                         1  1 0 0  =  12 db (max)
      Each increment represents 2 db, normalized at 50 Hz.
      
      Mixer control: x x x  x d d  (left 4 bits are ignored)
                              0 0  = DMA + (YM2149 - 12 db)
                              0 1  = DMA + YM2149
                              1 0  = DMA only
                              1 1  = reserved
     Setting "00" mixes the output of the YM2149 and the output
     of the DMA-sound, but the YM2149 sound is being downsized by
     12 db. "01" mixes DMA and YM2149 linearly, "00" means DMA
     sound output only.
     
  Mask Register
    $FFFF8924  x x x x  x x x x  x x x x  x x x x
    
    This contains in a bitfield which bits of the Address+Data
    Register are explicetely used. Since the Microwire, as it
    is being used in the STE, requires 11 bits of data (in general,
    the Microwire can transport 14 bits), it is essential to let
    the Microwire know WHICH of the 16 bits of this register are
    to be taken into account.
    As being used in the STE, this register will always feature
    11 "1"s and 5 "0"s.
    
  Example:
    Let's say we want to feed the LMC the data "011101000",
    we would need to write a "10 011101000" to the address+data
    register. We can use whatever bits we like of the 16 bits
    of this register, so we use the mask register to mask out
    the unused bits, which might look like:
      $FFFF8924  0 0 0 0  0 1 1 1  1 1 1 1  1 1 1 1
      $FFFF8922  0 0 0 0  0 1 0 0  1 1 1 0  1 0 0 0
    or
      $FFFF8924  0 1 1 0  0 1 1 1  1 1 1 0  1 1 0 1
      $FFFF8922  0 1 0 0  0 0 1 1  1 0 1 0  0 0 0 0
    both have the same effect.
    
Sounds complicated enough but can boost the DMA-sound output of
the STE quite a lot. When programming it first time however you
might easily see that it did not work as planned. Why ?

? Can't hear any changes on my Falcon ...
! Unfortunately, the Falcon does neither have a Microwire interface
  nor the National Semiconductors LMC1992. The Falcon cannot 
  manipulate bass, treble, main, left and right volume as easily as
  the STE can. The Falcon will not report an error either though.
  The TT does have the Microwire interface as well as the LMC1992.

? I write both address+data and the mask register correctly, still
  it doesn't have the expected effect.
! You need to write the mask before you write address and data.
  As soon as address+data register has been written to, the 
  Microwire starts to operate (which means shifting to the left).
  Writing the mask register after writing the address+data register
  is therefore useless.

? I write data into the mask-register, then address and data but
  it still doesn't do what i wanted to.
! Always make sure you have a total of "11" bits, and always
  make sure, the leading bits on the left side are a "10".
  Otherwise, the Microwire will try to access other peripherals
  that the STE does not have - which will not lead to an error,
  but result in no changes at all.
  
? I tried to achieve sound manipulation effects by writing a lot
  of values to the LMC1992 to change DMA sound output. It does
  seem to ignore a lot of my values.
! The LMC1992 is connected to the Microwire and is being fed
  data in a serial way. The Microwire is more or less a parallel
  to serial converter and it does that by shifting the 16 bit
  value (along with the mask) to the left 16 times and passing
  each bit for that the mask-bit is "1" to the LMC.
  That takes some time and during its operational state, the
  Microwire cannot be written to.
  
? How can i find out wether the Microwire interface is done ?
! Simply check the value in the address+data register after you
  wrote your value into it. If the value at $FFFF8922 is identical
  with the value you wrote into it, the Microwire is done shifting
  and can once again be written to. In all other cases, the
  Microwire is still shifting and cannot be written to.

? I successfully wrote to the LMC1992, but now YM2149 sound output
  is pure torture. What happened ?
! Well, the LMC1992 is not a chip that controls the DMA-sound in
  its digital form but manipulates the analogue sound that comes out
  of the DMA chip. If you now put the mixer to mix YM2149 and DMA
  sound, the LMC1992 will also manipulate the YM sound output.
  However, the YM2149 as a soundchip is not really meant to have
  Bass and Trebble enhanced. This might result in a very ugly
  sound.

? My program works fine and also exits cleanly, but then any
  subsequent sound output is awful. How come ?
! You should save the contents of the LMC1992 right at the
  start of your program and when exiting, you should restore
  the original value - and the easiest way is to save both
  mask and address+data register.
  Restoring can be done by just writing mask and address+data
  registers. The Microwire does not need any further software
  support once you wrote the values, so it does not harm if
  your program terminates in the meantime.
  Programs you launch when your program is terminated that do
  use DMA or YM2149 sound might be affected by your LMC1992
  settings otherwise.

? How come the Falcon does not have this feature ?
! When the Falcon was initially planned (and named Sparrow),
  it had a chip that was supposed to bear similar features
  named RASCAL. It is probable that this chip was supposed to
  "simulate" a Microwire + LMC 1992 duo as well as give
  enhanced possibilites towards the 16-bit stereo sound of
  the Falcon (Sparrow) as well as the DSP.
  Either Atari did not finish this chip in time, it was too
  expensive or too complex, we don't know. It appeared in
  the first Sparrow prototypes as well as the first few
  Falcon (exhibitors) boards. However, it is so far unknown
  wether this chip is compatible to the Microwire+LMC1992 duo
  or not and why it has been canned.

? Why is the handling of the LMC1992 so complicated ?
  Wouldn't there have been an easier way to give the STE these
  features ?
! Yes, of course, but the LMC1992 was very cheap. The LMC1992
  was never meant to serve in a computer but was commonly used
  in TV sets, Radios etc. and any other Audio-device that had
  the option to control volumes, bass and trebble electronically,
  and those preferred a "1-bit serial" implementation.
  The Microwire is just the connection of the STE's architecture
  to the LMC1992.

6. Advanced Joystick, Paddle and Lightpen ports
-----------------------------------------------
Registers:
  Fire-Buttons for 4 Joysticks:
    $FFFF9200  - - - -  - - - -  - - - -  X X X X
    
    This address features the fire buttons of 4 joysticks that
    can be connected to these ports. Bit 0 represents joystick
    0, bit 1 joystick 2, bit 2 joystick 1 and bit 3 joystick 3.
    This register is "low active", meaning that a "0" implies
    "active" (button pressed) and a "1" means "inactive"
    (button not pressed).
    
  Joysticks:
    $FFFF9202  X X X X  X X X X  X X X X  X X X X
    
    Read this address to get the directions of 4 digital
    joysticks connected. The lowest 4 bits (0-3) represent
    joystick 0, the middle low 4 bits (4-7) represent
    joystick 2, the next 4 bits (8-11) joystick 1 and
    the highest 4 bits (12-15) joystick 3.
    The lowest bit encodes "right", the next bit "left",
    the next bit means "down" and the highest bit "up".
    This whole register is low-active as well.
  
  Paddles:
    $FFFF9210  - - - -  - - - -  X X X X  X X X X  Paddle 0 X
    $FFFF9212  - - - -  - - - -  X X X X  X X X X  Paddle 0 Y
    $FFFF9214  - - - -  - - - -  X X X X  X X X X  Paddle 1 X
    $FFFF9216  - - - -  - - - -  X X X X  X X X X  Paddle 1 Y
    
    The advanced joystick ports allow analogue devices such as
    paddles. Two paddles usually connect to one port, meaning
    the connection of 4 paddles are possible. Instead of 
    "paddle X/Y coordinate", you might also read this as
    "paddle 1/2 coordinate".
    The fire buttons of each paddle can be read at the same
    address as for the joysticks, $FFFF9200
    
  Lightpen:
    $FFFF9220  - - - -  - - X X  X X X X  X X X X  X-Position
    $FFFF9222  - - - -  - - X X  X X X X  X X X X  Y-Position
    
    Connection of a light-pen is only possible at port 0. It
    has a precision of 4 pixels in ST Low, 8 pixels in ST Mid
    and 16 pixels in ST High resolution (horizontally).
    Vertically, the light-pen is pixel-perfect. The values
    read in this register always refer to ST Low. For usage
    in midres, you need to multiply by 2, for usage in hires,
    you need to multiply by 4.
    
These interfaces allow a lot of connections. What do you need
to watch out for ?

? Can't read out these registers. Why ?
! In contrast to any joystick/mouse/keyboard function on the
  ordinary ST, these interfaces are _not_ being maintained and
  supervised by the IKBD subsystem of the ST keyboard but are
  directly accessible by hardware. You need to be in supervisor
  mode to access these registers.

? The paddles i have from my good old 800XL can't be connected
  since the plug doesn't fit. Can i connect and use them on the
  ordinary joystick port of the ST ?
! No, unfortunately, the IKBD does not have the hardware that
  is necessary to drive paddles. Paddles are very "dumb" devices
  that need quite a bit of hardware logic to work in a "digital"
  environment. You will need to built yourself an adapter.

? I want to build myself a 4-player adapter so i can connect 4
  joysticks to these ports. What pins do i need to connect ?
! The hardware layout of each of these joystick ports is
  (seen from the outside of each connector):
    _______________________________  1 - Joystick 0 "up"
    \   5   4    3    2    1      /  2 - Joystick 0 "down"
     \     10   9    8    7   6  /   3 - Joystick 0 "left"
      \ 15  14   13  12   11    /    4 - Joystick 0 "right"
       \_______________________/     5 - Paddle 0 Y coord
     6 - Joystick 0 "fire"          11 - Joystick 2 "up"
     7 - VCC                        12 - Joystick 2 "down"
     8 - NC                         13 - Joystick 2 "left"
     9 - Mass                       14 - Joystick 2 "right"
    10 - Joystick 2 "fire"          15 - Paddle 0 X coord
  
  The ordinary 9 pin socket for an ordinary digital joystick
  look like this:
     ___________________           1 - Up     5 - reserved
     \  1  2  3  4  5  /           2 - Down   6 - fire
      \  6  7   8  9  /            3 - Left   7 - +5V
       \_____________/             4 - Right  8 - Mass
                       (9 is officially unused, might be 2nd "fire")
  This should be sufficient to build an adapter.
  
? Which models have the extended joystick ports ? Is it sensible
  to use them at all ?
! Depends on what you are planning to do. Only the 1040 STE and the
  Falcon have these additional ports. Neither the Mega STE nor the
  TT have these. Games/Programs that can only use joysticks/paddles
  connected to these ports cannot be played on Mega STE/TT computers.

? How can i write a program that uses paddle controllers for the
  Mega STE and TT then ?
! You cannot. Both these computers lack the logic required to drive
  paddle controllers.

? But isn't the mouse a paddle controller, too ?
! No, surprisingly, it is not. The mouse is using an internal
  logic to convert "analogue" movement into digital impulses,
  similar to rapidly moving a joystick in a direction and letting
  it go again. The mouse is, unlike a paddle, not being read "by
  position", but like a joystick "by movement".
  For games however, you might use the mouse as a paddle.
  GEM programs can use an AES routine to read mouse position,
  otherwise you can use the IKBD to read the mouse.

? My light pen doesn't work at all.
! The light pen is only supported on connector 0. Connector 1
  cannot be used to drive a light pen.

? I want to connect jaguar powerpads, which can connect directly
  to the advanced joystick ports. How do i read those ?
! The directional pad and the 3 action buttons can be read
  relatively easily. The D-pad represents one joystick connected
  to the port, the 3 fire buttons and the Option button the
  other joystick. The Pause-Button is the firebutton of one
  joystick. Reading the numerical pad of the powerpad is more
  difficult however.
  
7. Hardware related questions
-----------------------------
Here come some typical questions and answers concerning the 1040
STE's hardware, not seen by the programmer but for upgrades and
installations.

? I want to upgrade my STE to 4 MB. What shall i do ?
! The 1040 STE uses 30 pin SIMMs and the 1040 STE is not really
  picky about the SIMMs you use. By using 4 x 1 MB SIMM you
  will achieve 4 MB in total.

? I only have 2 1 MB SIMMs. Can i use them ?
! All 4 SIMM-slots (2 banks) need to be filled by SIMMs, otherwise
  the STE won't boot at all. You might try to replace 2 of the
  SIMMs in your 1040 STE to have either 2.5 MB (2 x 256KB +
  2 x 1 MB) or 3 MB (2 x 512 KB + 2 x 1 MB), but unfortunately,
  both only work with restrictions: There is a program that
  "reserves 1.5 MB" while booting which are exactly those 1.5MB
  that a 2.5 MB STE lacks to the 4 MB. The STE then "believes"
  to have 4 MB with 1.5 MB permanently used.
  This is not a wise choice however since it will require you
  to always run this program. Most games will crash.
  
? I want to upgrade my STE to TOS 2.06. Do i need a TOS-card ?
! No, you don't. The 1040 STE has 2 EPROM-sockets for 2 128KB
  EPROMs, exactly the size of TOS 2.0x. Simply purchase the
  TOS-ROMs, open your 1040 STE and replace chip by chip. They
  are marked "E" for "Even" and "O" for "Odd".
  Make sure the "O" chip you take out is replaced by the "O"
  chip of your TOS 2.06. The same goes for the "E" chips.
  TOS-cards were only necessary for ST computers that had
  6 x 32 KB EPROMs and could not handle 2 x 128KB.
  
? Is it possible to have an internal IDE harddisk in the 1040
  STE ?
! Yes, it definetly is. There is room for a 2.5" IDE-harddisk
  just above the memory on the metal shielding and it is even
  easy to mount the harddisk there. The PSU of the STE is also
  powerful enough to drive a 2.5" IDE harddisk usually.
  Then you need an IDE interface and a cable.

? The IDE interface i bought doesn't fit anywhere. Help!
! Well, the 1040 STE uses a PLCC-socketed 68000 while all ST
  computers had a DIL-version of the 68000. IDE interfaces
  either connect to the Megabus of the Mega ST series directly
  or to the CPU and usually that implies a DIL CPU.
  Mario Becroft, T.U.S. and Gellermann & Felmuth produced IDE
  interfaces especially for the 1040 STE. So before you order,
  make sure the IDE interface can be used on a PLCC 68000.
  GE Soft produced a simple adapter called "speed-bridge",
  which connected to the PLCC-socket of the STE and had a
  DIL-like socket on the top. This allowed to use ST expansions
  on the STE, too, but please note that this means additional
  space being occupied by the adapter - Speed bridge + IDE
  interface might not fit anymore into your 1040 STE.
  
? The IDE interface is mounted, it works and the IDE harddisk
  is identified correctly and installed by my software. Yet
  my STE can't boot from it.
! A common problem. To boot from an IDE device, you need
  TOS 2.06 in your STE. Otherwise, you will need a boot-disk
  that features your harddisk driver.

? Help! I just removed my IDE interface and now my 1040 STE
  doesn't work anymore at all, i only get a black screen!
! The pins of the socket and the 68000 have been bent a little
  when you had the IDE interface mounted. Now that you removed
  it, the pins of the socket do not connect 100% anymore to the
  pins of your CPU. Now all you need is patience and a needle.
  Open the STE, carefully pull out the CPU by using the needle
  as a lever. Now carefully bent the pins on the socket towards
  the middle. Do not push them hard since they break relatively
  easily. When done with this, carefully bent the pins of the 
  68000 a little to the outside. Then push the CPU in gently
  and try to switch on your STE.


8. Miscelleanous questions and other STE compatible computers
-------------------------------------------------------------
This section simply features a few questions about what
compatibility problems you might expect when coding STE or
what to do when you want to use additional features of
certain models like the TT, the MegaSTE, the Falcon without
abandoning STE compatibility totally.

? How compatible is the STE with the Mega STE, TT and Falcon ?
! Here's a small chart of the additional features of the 1040
  STE and their existance on the other models (including the
  Mega ST and ST for completeness):
  
                     ST MegaST    STE    MegaSTE      TT  Falcon Note:
  --------------------------------------------------------------------
  4096 colours       no     no    yes        yes     yes     yes  (1)
  Blitter            no    yes    yes        yes      no     yes  
  Hardware scroll    no     no    yes        yes     yes     yes  (2)
  screen splitting   no     no    yes        yes      no     yes  (3)
  DMA sound          no     no    yes        yes     yes     yes  (4)
  LMC1992/Microwire  no     no    yes        yes     yes      no
  Adv.Joystick port  no     no    yes         no      no     yes
  
  Notes:
  (1) The Falcon has to be in an ST compatible resolution for this.
      On the ST, programs that try to use 4096 will not crash, but
      still be limited to 512 colours.
  (2) Both Base Address and Counter have to be multiples of 4 on
      the Falcon and multiples of 8 on the TT.
  (3) On the Falcon, the Video Counter can only contain values
      that are multiples of 4.
  (4) There is no 6.125KHz DMA sound on the Falcon.
  
The Mega STE and its features:
  ? The TT features quite a complex SCSI subsystem but i cannot
    find any information of the Mega STE's SCSI subsystem ?
  ! That is simply because the Mega STE does not have a SCSI
    subsystem. If your Mega STE is equipped with an internal
    SCSI harddisk, it has an internal SCSI hostadapter that is
    mounted on an internal ACSI-bus. Hence, the Mega STE sees
    your harddisk as ACSI, not as SCSI and can also not directly
    access the SCSI controller on it.
    
  ? I see the Mega STE has a socket for a math coprocessor.
    Which types can i connect ?
  ! The Mega STE was intended to drive a 16 MHz MC68881, but
    it should (!) also work with a 16 MHz MC68882 if it fits.
    The coprocessor will be driven with 16 MHz.
    
  ? How do i program the Mega STE's MC68881 if present ?
  ! That's unfortunately more complicated than for the Falcon
    and the TT since the 68030 used in TT and Falcon can operate
    an MC68882 directly while the 68000 in the ST, STE and
    Mega STE cannot. The Mega STE has a coprocessor interface
    register from $FFFFFA40 to $FFFFFA5C, but it also requires
    a so-called "coprocessor protocol" to communicate with the
    MC68881. This is rather complex and too much to list here.
    The operation of the MC68881 in the Mega STE is identical
    to the operation of the FPU-cards for the Mega ST, so
    i recommend the documentation of these.
    
  ? I want to make sure that my software uses the Mega STE in
    "high speed", but when i boot the Mega STE "cleanly", it
    always is in "8 MHz cache off" mode. How do i switch it
    into 16 MHz cache on ?
  ! The Mega STE has a register to control speed and cache
    status:
     $FFFF8E21  - - - -  - - X X
     
     Bit 0 controls the clockspeed (0 = 8 MHz, 1 = 16 MHz),
     the upper bit controls the cache (0 = Cache off, 1 = cache on).
     Some docs say that all upper 15 bits of $FFFF8E20 need to
     be set to "1" to turn the cache on.
     Writing to this register in anything but a Mega STE will
     most probably lead to a crash, so be sure to check the
     Cookie Jar for _MCH to estimate wether this is a Mega STE
     or not (Upper word is 1 for STE, lower word is 0x0010 for
     Mega STE, 0x0000 for anything else).
     
  ? How come the Controlfield only allows 16 MHz Cache On, 16
    MHz Cache off and 8 MHz Cache off when the hardware also
    allows 8 MHz Cache on ?
  ! Because the setting "8 MHz Cache On" is senseless. The
    cache operates at 16 MHz and is meant to reduce real 
    memory accesses for the 16 MHz CPU since the bus and
    therefore the memory only runs at 8 MHz.
    When you run the CPU in 8 MHz, the cache will operate at
    8 MHz, too, and hence be as quick as the bus - giving no
    more speedup.
    
  ? Can the Cache of the Mega STE lead to problems with demo
    effects since it does not influence memory directly ?
  ! Yes and no. From the docs i have - and they are not really
    very detailed about the Cache of the Mega STE - any
    hardware register access is not being cached but carried
    out directly. If your "demo" just does a lot of hardware
    register accesses, the cache should not really be a problem.
    However, screen memory and other buffers are in the main
    memory and therefore cached. If timing is critical for
    accesses on these parts of the memory, better turn the
    cache off.
  
  ? How fast is the Mega STE at 16 MHz without the cache ?
  ! Unfortunately, not very much faster than an ordinary 8 MHz
    STE. The cache might seem small according to todays
    standard (16 KBytes), but for a system like the Mega STE,
    it reduces memory accesses dramatically. If you turn off
    the cache, the 68000 has to fetch everything directly
    over the 8 MHz bus. Only operations that completely work
    in the 68000's registers will gain performance.
    
The Atari TT and its features:
  ? Urghs. The TT also has this ugly internal speaker that
    sounds awful. How can i turn it off ?
  ! The internal speaker is being controlled by the YM2149
    directly over port IOA6. The settings are
       OnGIbit: ($40) - switch internal speaker off
      OffGIbit: ($BF) - switch internal speaker on
  
  ? Say, is the 8-bit resolution of the TT a chunky resolution ?
    That would be cool for demos and games.
  ! Unfortunately, it has the same interleaved bitplane structure
    like the ST and STE have. Screen memory is organized:
      Word 0   X X X X  X X X X  X X X X  X X X X  pixel  0-15 plane 0
      Word 1   X X X X  X X X X  X X X X  X X X X  pixel  0-15 plane 1
      ...
      Word 7   X X X X  X X X X  X X X X  X X X X  pixel  0-15 plane 7
      Word 8   X X X X  X X X X  X X X X  X X X X  pixel 16-31 plane 0
      etc.
  
  ? I read somewhere that the Falcon can be switched to an
    STE compatible mode. Is there something similar for the TT ?
  ! No. STE compatibility for the Falcon also only refers to
    STE compatible resolutions (ST Low, Mid, Hi) and STE 
    compatible DMA-sound (8 bit). The TT has the ST(E) resolutions
    anyway and the DMA-sound is identical to the one of the STE
    as well. But, the TT lacks the Blitter, cannot change
    screen addresses in the middle of a screen and does not
    have the enhaced joystick ports.
    So, since the TT lacks important hardware specs of the STE,
    a compatibility mode would be rather useless anyway.
  
  ? Why does the TT lack the feature to change Video Counter
    during a screen build anyway ?
  ! At least according to Ray/tSCc, it actually allows
    write accesses. However, the official documentation states
    this register as read/only. In the monochrome hires mode
    it is not advisable to write to these registers since the
    TT shifter does 95 MHz (74 Khz at 1280x960), which is
    almost 3 times the speed of the TT's CPU and 6 times the
    speed of the TT's bus. So be careful in this mode.
    
  ? I toyed around with the SYNC-Mode register but it behaves
    odd on the TT. Why ?
  ! Even though this register is called "ST Sync Mode" officially,
    it's the direct opposite. Only Bit 0 is used and if it is "0",
    screen is off, otherwise screen is on (On the ST, "0" was on).
  
  ? What's the difference between the ST Shift Mode Register
    and the TT Shift Mode Register ?
  ! The ST Shift mode register is supposed to be only 2 bits wide
    and contain a "00" for ST Low, "01" for ST Mid and "10" for
    ST High. However, the ST Shift Mode Register on the TT also
    contains ALL other bits of the TT Shift Mode Register as well.
    The ST Shift Mode Register is more or less a mirror of the TT
    Shift Mode Register. Hence, be careful when writing to this
    register for STE compatibility, you might turn on/off TT
    specific features.  
    
  ? What is that funky greyscale mode of the TT i read about ?
    Is it any useful ?
  ! The so called "Hper Mono"-mode is a mode in which each
    pixel can have 1 of 256 greyscales. To enable this mode,
    you need to set bit 12 of the TT Shift Mode register:
      $FFFF8262  X - - X  - X X X  - - - -  X X X X
    
    This mode will combine the green and blue channel (=8 bits)
    to gather 256 greyscales. Obviously, it is not a chunky
    but still a palette mode, however, not using the original
    TT palette (4096 colours can only feature 16 greyscales).
    It is not a chunky mode either but still uses the same
    interleaved bitplane format. Then again, it seems that this
    mode can be engaged not only in the 256 colours resolution.
    But, this mode _only_ exists on the TT. This mode is _not_
    available on the ST, the STE or the Falcon.
    Please note that using this mode will limit your software
    to run solely on the TT.
    
  ? Then i read about a smear mode on the TT. What is that ?
  ! The so called "Hold & Sample" mode of the TT an be engaged
    by switching bit 13 of the TT Shift mode Register:
      $FFFF8262  X - - X  - X X X  - - - -  X X X X
      
    In this mode, every pixel with a colour different from 0
    will "smear", meaning that all pixels with colour 0 to the
    right of a pixel with colour X will be drawn in colour X.
    Only the left border resets the smear mode and really draws
    colour 0 as colour 0 until a pixel with colour<>0 follows.
    This mode was meant to make programming of filled-vector
    3D graphics about as easy as programming wireframe vectors.
    Unfortunately, it stayed widely unused.
    Please note that this mode _only_ exists on the TT and is
    _not_ available on the ST, STE or the Falcon.
  
  ? What TOS does the TT have ? If i use routines from TOS 1.0x
    or 2.0x directly, will it work on the TT, too ?
  ! Unfortunately, there are 5 series of TOS for the TT, TOS
    3.01 to 3.06, not counting the very first TT-TOS called
    TOS030. So please, if using TOS routines, program as cleanly
    as possible to ensure compatibility.
    
  ? How come that the TT only uses 2/3 of the width of my VGA
    monitor but displays a stupid white border ?
  ! When Atari designed the TT and especially the TT shifter
    which has VGA-compatible elements, IBM decided to change
    the specs of the VGA standard (at least some docs say so,
    there are no official affirmations for this).
    This is why the TT displays a rather pointless border and
    also only uses 2/3 of the screen width.
    The simplest solution to go around this is an OverScan TT
    which simply uses up the whole space the TT reserves for
    the border, giving up to 896 x 496 pixels in TT Mid and
    448 x 496 in TT Low.
    
The Falcon030 and its features:
  ? How compatible is the Falcon to the STE ? Will my STE code
    work flawlessly on the Falcon ?
  ! Yes, the Falcon was meant to be an (68000-based) successor
    to the 1040 STE, therefore it is easy to code Falcon-
    compatible STE-code. The only exceptions are:
      - The Falcon does not allow 6.125 KHz DMA sound
      - The Falcon's screen base address has to be a multiple
        of 4
      - The Falcon does not have the so-called "Shadow"
        registers of the YM2149
    To also make sure that the timing of the CPU is (almost)
    correct, switch the processor caches off and the CPU and
    the Blitter down to 8 MHz.
    Now, the only obstacle is the DMA-sound matrix of the Falcon
    which might be setup wrongly.
    
  ? I migrated from a 1040 STE to a Falcon030. But how can I
    connect my external Floppy disk drive or connect my good old
    ACSI-harddisk drive ?
  ! You cannot. The Falcon does not have any kind of interface
    for an external disk drive - even though the TOS 4.0x still
    checks for Drive B: on boot-up. Additionally, the Falcon
    does not have an ACSI port. You cannot connect any ACSI-
    devices such as harddisks or Laser printers.

9. Epilogue
-----------
  Without a doubt, the 1040 STE and the Mega STE are nice pieces
  of hardware. In 1989, the 1040 STE offered quite a lot a home
  computer could offer and you got a computer with excellent
  sound capabilities for the price of a sound-card for your PC
  alone. In 1991, the professional STE was released with the
  introduction of the Mega STE. 16 MHz clockspeed, 16 KB cache,
  VMU interface and internal harddisk at a price for which other
  companies gave you an update of their operating system and a
  new harddisk.
  But the STE didn't make it. The 1040 STE's features stayed
  widely unused until the release of games such as Obsession or
  Stardust, of Demos such as Brain Damage by Aggression or
  Omega's Grotesque or of tools such as the ProTracker STE.
  The Mega STE did not increase the sales of STE computers a lot
  either, being limited to STE graphics and sound.
  
  This documentation is for people that, like me, like the STE
  for what it is: A fun machine with quite impressive specs.
  I assembled this documentation in case you want to program
  the STE's features such as the Blitter, the hardware scroll
  or DMA sound and would like to avoid stumbling over the
  little traps in the STE design. So i hope you find this
  documentation useful and keep on programming the STE to
  push this little machine to the maximum.
  
                                 Best wishes,
                                      The Paranoid
                                  Paranoia -- Lunatic Asylum
                                  Think you can handle it ?!
  
10. Final words
---------------
  This FAQ has been collected and assembled using various
  sources:
    - Atari ST/STE/TT Profibuch,
        Jankowski, Rabich, Reschke, Sybex Verlag 1991
    - Das TOS 1.4 Update Buch,
        Pauly, Data Becker 1989
    - Chips'n Chips 6.0
        Ruge, AG Computertechnik 1998
  and many many experiments on a 1040 STE using TOS 2.06,
  a Mega STE using TOS 2.06 and a Falcon030.
  
  This documentation is far from complete and is not given
  with any warranties about correctness. Any kind of damage
  done to yourself, your hard- or software after, while or
  before reading this documentation is not being covered in
  any way by the author.
  If you copy this documentation, please do not alter, add
  or subtract any content. This documentation is free to
  copy as long as it is copied completely and without
  additionals.
  If you spot mistakes or have proposals on what to add,
  feel free to mail the author at paranoid@atari.org
  
  




Back to Atari ST FAQ