STE documentation

 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.

<Previous> [1][2][3][4][5][6] <Next>