TI-99/4A Memory Map

>0000 Console Rom;
Interrupt vectors, XOP vectors
GPL Interpreter, Floating
POINT routines, XMLINK vectors,
>1FFF Low-level cassette DSR etc.
>2000 Low Memory Expansion Ram;
Varies according to the loader
used (Assembly). Generally
>3FFF not used by XBASIC programs.
>4000 DSR ROM;
Device service routines.
Determined by CRU bit setting
>5FFF Disk Controller, RS232 etc.
>6000 Cartridge Port (ROM & MINI MEM)
12k of XBASIC ROM. Upper 4k
@ >7000 - >7FFF is flipped to page in another 4k for a
>7FFF total of 12k.
>8000 RAM Memory Mapped Devices - VDP,GROM, SOUND, SPEECH.
>8000 Duplication of scratch pad RAM at >8300 - >83FF
>8100 Dup. as above
>8200 again
>8300 Scratch Pad RAM
>8400 Sound Chip
>8800 VDP READ DATA
>8802 VDP STATUS
>8BFF
>8C00 VDP WRITE DATA
>8C02 VDP READ/WRITE ADDRESS
>8FFF
>9000 SPEECH READ
>93FF
>9400 SPEECH WRITE
>97FF
>9800 GRON/GRAM READ DATA
>9802 GROM/GRAM READ ADDRESS
>9BFF
>9C00 GROM/GRAM WRITE DATA
>9C02 GROM/GRAM WRITE ADDRESS
>9FFF
>A000 HIGH MEMORY EXP RAM XBASIC high memory usage, Free space end pointed to by CPU RAM PAD address >8366
Numeric Values
Line Number Table
XBASIC Program Space >FFFF for a total of 24k bytes.
Additional Memory Space not in the CPU address space;
VDP RAM >0000 - >3FFF 16k bytes.
This is the console RAM space, and is separate from the rest of the CPU memory. Without memory expansion, XBASIC and BASIC programs reside here (BASIC does not use expansion memory.) (Assembly language does not use this area.)

BASIC does not use memory expansion at all. Only XBASIC, Assembly, FORTH etc. use it.
Chunks of memory are used by various peripherals as buffers, thus the amount indicated by CALL SIZE is right.

By using CALL FILES(1) followed by NEW, you can get back some, but disables the disk system. If you don't have it installed, but have mem exp. you will have more memory to use automatically.


Original Source as posted on July 8th 1984 by Gene Sampieri

The following is priceless as found in the below address:
http://www.unige.ch/medecine/nouspikel/ti99/tms9918a.htm#Registers

VDP memory
The videoprocessor has 16K of private RAM that it used to store the screen image, the character patterns and colors, and the sprite characteristics. Unless it is used in bit-map mode, only a small portion of this memory is effectively needed. The remaining is therefore available for use by the CPU. However all reading and writing operations must be carried on by the videoprocessor. The CPU passes the required address to the VDP as two bytes at address >8C02, and can then read bytes from >8800 or write bytes at >8C00. The VDP increments an internal pointer after each read/write operation. Contrarily to the GROMs, one cannot retrieve the value of this pointer from the VDP. Instead, address >8802 is used to read the VDP status register. This is definitely a slow way to access RAM, but it probably allowed to market the TI-99/4A at a much lower price, since RAM was fairly expensive in the 80s.


VDP registers
The first eight registers are used by the CPU to control the VDP. Very unfortunately, these are write-only registers, which means there is no way to determine the current display mode, unless it has been saved somewhere in RAM by the program that set it. Registers 0 and 1 contains control bits, registers 2 to 6 contains pointers to various tables in the VDP RAM and register 7 encodes 2 colors.
The VDP also contains a read-only status register that is uses to pass various information to the CPU.
VDP register 0
This register contains two control bits. All other bits must be zero. The register contains >00 after a reset.
Bit 6 (weight >02) selects a bitmap graphics mode when set to 1. VDP register 1 determines which bitmap mode is used.
Bit 7 (weight >01) enables external video input when set to 1.
VDP register 1
This register contains 7 control bits. All are set as 0 after a reset.
Bit 0 (weight >80) selects the memory size. For 4K of memory the bit is 0, for 16K it is 1.
Bit 1 (weight >40) enables the screen. When this bit is 0 the screen is blank.
Bit 2 (weight >20) enables interrupts. When this bit is 1, the VDP issues interrupt signals on the INT* pin each time it resumes refreshing the screen (vertical retrace signal).
Bit 3 (weight >10) selects text mode when set as 1. Bit 7 of register 0 can be set for bitmap text mode.
Bit 4 (weight >08) selects multicolor mode when set as 1. Bit 7 of register 0 can be set for bitmap multicolor mode.
If both bits 3 and 4 are 0, the display is in standard mode (or in bitmap mode, depending on register 0). Bits 3 and 4 should never be set together.
Bit 5 (weight >04) is reserved and should be 0.
Bit 6 (weight >02) selects the sprite size. When 0, sprites are 8x8 pixels. When 1, sprites are 16x16 pixels.
Bit 7 (weight >01) selects sprite magnification. When this bit is 1, each sprite pixel is replaced by a 2x2 pixels box.
VDP register 2
Defines the location of the screen image table. Only the last 4 bits are used, thus possible values for this register are >00 throught> 0F. The value is multiplied by >400 to find the location of the screen image table in the VDP memory. This table contains 1 byte for each character position on the screen (left to right, downwards), this byte contains the character number.
VDP register 3
Defines the location of the color table. Possible values are >00 through >FF and are multiplied by >40 to find the location of the color table. The table is not used in text mode, nor in multicolor mode.
In bitmap mode (i.e. when bit 6 in register 0 is set) the meaning of this register changes: bit 0 (weight >80) is the only one used to determine the address of the color table, which means the table has only two possible locations: >0000 or >2000. The remaining bits are used to define the table size, by the way of an address mask. This is done as follows: the righmost 7 bits are shifted left by 6 positions, filling the rightmost bits with 1s. The result will be a number between> 003F and >1FFF, which is ANDed with the address of a character in the table. As a result, the table can have any size between >40 and> 2000 bytes (however, note that the maximal usable size is >1800: 3 times >800 bytes).
VDP register 4
Defines the location of the character pattern table. Only the last 3 bits are used, thus possible values are >00 through >07. The value is multiplied by >800 to find the location of the character pattern table. Each entry in the table is eight bytes long and define the pattern of a character, in numeric order. Each byte in an entry defines one line of pixels in the character pattern: bits set as 1 result in foreground color pixels, bits set as 0 encode background color pixels.
In text mode (i.e. when bit 3 in register 1 is set) the last two bits of each byte are ignored since characters are only 6-pixel wide.
In bitmap mode (i.e. when bit 6 in register 0 is set) the structure of this register changes: bit 5 (weight >04) is the only one used to determine the address of the color table, which means the table has only two possible locations: >0000 or >2000. The two rightmost bits are used to determine the length of the table, by the way of an address mask. This is done by shifting them 11 positions to the left, filling the righmost bits with 1s. The result will be a number between >07FF and >1FFF that will be used as an address mask. At least, this is what happens in bitmap + text mode (i.e. when bit 3 of register 1 is set). In standard bitmap mode, the righmost bits are not necessarily 1: they are taken from VDP register 3, i.e. the address mask of the color table is used for both the color table and the pattern table addressing.
VDP register 5
Defines the location of the sprite attributes table. Only the last 7 bits are used, thus possible values are >00 through >7F. The value is multiplied by >80 to find the location of the sprite attributes table. Each entry in the table is four bytes long and defines a sprite position and color, in numerical order of sprites. See the chapter on sprites for a detailed description of this table.
VDP register 6
Defines the location of the sprite pattern table. Only the last 3 bits are used, thus possible values are >00 through >07. The value is multiplied by >800 to find the location of the sprite pattern table. Each entry in the table is eight bytes long and defines the pattern of a sprite, one byte per line. Bits that are set as 1 result on a pixel of the color defined for that sprite in the sprite attributes table, bits that are 0 result in a transparent pixel. If the large sprite size is selected (bit 6 in register 1 is set as 1) each entry is 32 bytes long and define a sprite as a set of 4 characters arranged as:
1 3
2 4
VDP register 7
The first nibble of this register defines the color of all characters in text mode. It is not used in the other modes.
The second nibble defines the background color wich is used for all characters in text mode. In all four modes it defines the color of the backdrop plane: this is the color of the screen outside the display area and the color that appears under transparents characters. When this color is set as transparent the external video image appears if it is enabled, black color appears otherwise.
Status register
The first 3 bits of this register are automatically reset as 0 when the register is read or when the VDP is reset. It ensues that the status register should only be read when an interrupt is pending, otherwise an interrupt could be missed.
Bit 0 (weight >80). This bit is set to 1 at the end of the raster scan of the last line of the display area (i.e. before drawing the bottom margin). If interrupts are enabled (by bit 2 in VDP register 1), the INT* pin is low when this bit is 1 and high when it's 0. This is why the status register should be read after each frame, in order to clear the interrupt and be ready to receive the interrupt at the end of the next frame. Also, if bit 2 in VR1 is cleared and set again while status bit 0 is set, an interrupt is issued immediately.
Bit 1 (weight >40) signals that there are 5 or more sprites on a given pixel row. Only the topmost four will be displayed.
Bit 1 (weight >20) is the coincidence bit. It is set when two sprites or more have at least one overlapping "on" pixel. This occurs even if the sprite color is transparent. Note that coincidence is checked only every 1/60th of second (1/50th of a second for the TMS9929A), thus if you change sprite positions during that time a coincidence could be missed.
Bits 3 to 7 contain the number of the 5th sprite on a pixel line, if any. This number is only meaningfull if bit 2 is set as 1 (else it may contain the number of the last displayed sprite, but no guaranty). If such a situation occurs more than once, the 5th sprite listed is the one closest to the top of the screen.
Summary of the VDP registers contents
Bit:
Weight: 0
> 80 1
> 40 2
> 20 3
> 10 4
> 08 5
> 04 6
> 02 7
> 01 VR0 0 0 0 0 0 0 Bitmap Ext vid VR1 16K Blank Int on Multic Text 0 Size 4 Mag 2x VR2 0 0 0 0 Screen image VR3
bitmap Color table Addr Address mask VR4
bitmap 0 0 0 0 0 Char pattern table 0 0 0 0 0 Addr Address mask VR5 0 Sprite attributs table VR6 0 0 0 0 0 Sprites pattern table VR7 Text color (in text mode) Backdrop color Status Int 5+ sp Coinc 5th sprite number

Video modes Standard mode (Graphic I)
This mode is selected by setting all mode bits as 0: bit 7 in register 0 and bits 3 and 4 in register 1. VR0: 0 VR1: 0 0
In this mode, the screen is divided into 24 rows of 32 characters. Each character is 8x8 pixels and has two colors: one for the "on" pixels (foreground color), one for the "off" pixels (background color). If a color is set as 0, the color of the backplane will be used (defined by register 7).
The screen image table is thus >300 bytes long (24x32=768). Each byte in the table contains the number of the character to display at the corresponding position on screen. This number is used to locate the character pattern in the pattern table and to look up its colors in the color table.
The color table is 32 bytes long. Each byte encodes the two colors for a group of 8 consecutive characters in numeric order (i.e. the first byte affects characters 0-7, the second characters 8-15, etc). In each byte, the first nibble encodes the foreground color, the second nibble the background color.
The character pattern table contains 256 entries, one per character in numeric order. Each entry is eight bytes long, each byte defines the pattern of one pixel row in the character: "1" bits set the pixel to the foreground color used for this character group, "0" bits set the pixel to the background color of this character group.

 --------|        |  00000000 = >00|  ***   |  00111000 = >38| *   *  |  01000100 = >42| *   *  |  01000100 = >42|  ***   |  00111000 = >38|   *    |  00010000 = >10|  ***   |  00111000 = >38|   *    |  00010000 = >10 --------

The pattern table entry for the above character would be: >00 38 42 42 38 10 38 10
Sprites can be used in standard mode, see below.
Text mode
This mode is selected by setting bit 3 of VDP register 1 as 1. Bit 4 must be 0, as well as bit 7 of register 0. VR0: 0 VR1: 1 0
In this mode, the screen is devided into 24 rows of 40 characters. Each character is made of 8 rows of 6 pixels. All characters have the same two colors, defined by VDP register 7.
The screen image table is >3C0 bytes long (24x40=960).Each byte in the table contains the number of the character to display at the corresponding position on screen. This number is used to fetch the character pattern from the pattern table.
The color table is not used. The foreground color for each character is taken from the first nibble of VDP register 7, the background color is transparent, which lets the backdrop plane color appears. As the backdrop color is encoded by the second nibble of VDP register 7, one can consider that this register specifies both the foreground and background colors for each character.
The pattern table is organized just as in standard mode, except that the last two bits of each byte are ignored since characters are only 6-pixels wide in text mode.

 ------|      |  000000xx = >00|  *** |  001110xx = >38| *   *|  010001xx = >42| *   *|  010001xx = >42|  *** |  001110xx = >38|   *  |  000100xx = >10|  *** |  001110xx = >38|   *  |  000100xx = >10 ------

Sprites are not available in text mode.
All this makes text mode the least memory-hungry mode: only a maximum of 3008 bytes (>0BC0) of VDP RAM is required in this mode. This can be further reduced by not using all 256 characters and/or by partly overlapping the tables.
Multicolor mode
This mode is selected by setting bit 4 of VDP register 1 as 1. Bit 3 must be 0, as well as bit 7 of register 0. VR0: 0 VR1: 0 1
In this mode, the screen is divided into 48 rows of 64 boxes. Each box is 4x4 pixel and can be independently assigned a color. The screen image table is still >300 bytes long, but each byte now represent a "character" made of 4 boxes. The boxes are arranged as:
0 1
2 3
The color of the boxes are defined in the character pattern table (!). Each entry in the table is 8 bytes long but only 2 bytes are used to define the colors of the 4 boxes that make up a character: >01 >23. To avoid wasting 6 bytes in each entries, the characters on 4 consecutive rows use the same entry, with an offset of 2 bytes:
characters on row 0, 4, 8, 12, 16 and 20 use bytes 0 and 1,
characters on row 1, 5, 9, 13, 17 and 21 used bytes 2 and 3,
characters on row 2, 6, 10, 14, 18 and 22 used bytes 4 and 5,
characters on rows 3, 7, 11, 15, 19 and 23 use bytes 6 and 7.
This reduces the size of this table to 1536 bytes (24 rows x 32 columns x 8 bytes).
The color table is not used in multicolor mode.
Sprites can be used in this mode.
To summarize, the screen organisation is the following:

Column:  0     1   ...   31

Row 0:  a b   q r  ...        c d   s tRow 1:  e f   u v        g h   w xRow 2:  i j   y z        k l   ...Row 3:  m n           o p

The corresponding screen image table could be:

Column:  0     1   ...   31

Row 0:  >00  >01   ...  >1F        Row 1:  >00  >01        >1F           Row 2:  >00  >01        >1F           Row 3:  >00  >01        >1F

Row 4:  >20  >21        >3F

        ...

And the pattern table would look like this (letters a-z represent the color of a given box, i.e. a digit in the range >0-F):

Byte:       0   1    2   3   4   5    6   7Row:          0        1       2        3___

Entry >00: >ab >cd  >ef >gh  >ij >kl  >mn >op

Entry >01: >qr >st  >uv >wx  >yz ...

...

This mode is fairly complicated to use (and does not yield very interesting results). A way to simplify it is to fill the screen with fixed character numbers, as shown in the above example. Drawing is then achieved by changing the color values in the character pattern table. Arranging the character numbers as in the example makes easier to calculate which byte must be changed in the pattern table, but there are other solutions.
Bitmap mode (Graphics II)
I'm sure every TI user had this great idea one day or the other: "Hey, lets fill the screen with all available characters: 0, 1, 2, etc. Then I can draw pixel-by-pixel by just changing definitions in the character pattern table". If you have tried, you must have realised there is a big problem: with 256 characters, we can only cover 1/3 of the screen. Not to mention the fact that the color table defines 8 characters at a time, which makes color drawings almost impossible. Bitmap mode takes care of these problems (sort of).
This mode is selected by setting bit 7 of register 0 as 1. Bits 3 and 4 in register 1 should be 0. VR0: 1 VR1: 0 0
In this mode, the screen is still devided in 24 row of 32 character, just as in standard mode. However, we now have three character pattern tables, one after the other: the first table applies to characters displayed in the top third of the screen (i.e. the first >100 bytes in the screen image table), the second to characters displayed in the middle third (bytes> 100-1FF) and the third to characters displayed in the bottom third of the screen (bytes >200-2FF in the screen image table).
Now we can fully cover the screen with non-redundent characters, by just writing >00, >01, >02 ... >FF three times in the screen image table. As the three pattern tables are consecutive, it is easy to calculate which byte is to be accessed to modify a given pixel.
There are also three color tables, arranged in the same way as pattern tables. Each entry in a table is eight bytes long and defines the colors for one character. Each byte in an entry defines the colors of a row in the character: the first nibble sets the pixel color for bits that are set as 1 in the pattern (foreground), the second sets the pixel color for the 0 bits in the pattern (background). The major drawback of this system is that each line of pixels in the display is chopped into 8-pixels clusters for which there is only a choice of two colors. This forces us to pay a lot of attention when drawing complex images, as 3 colors in a given pixel line must be at least 8 pixels appart.
Sprites are available in bitmap mode and work just as in standard mode.
Not so surprisingly, bitmap mode is extremely memory-hungry: it requires> 3300 bytes, not counting sprite tables.
To summarize, here is an example showing the correspondance between screen, pattern table entry and color table entry:

   Screen             Pattern table         Color table        B 1 B B B B B 1      0 1 0 0 0 0 0 1     1 (black)  B (l.yellow)B B 7 B B B 7 B      0 0 1 0 0 0 1 0     7 (cyan)   BB B B C B C B B      0 0 0 1 0 1 0 0     C (green)  BB B B B E B B B      0 0 0 0 1 0 0 0     E (gray)   BB B B B 8 B B B      0 0 0 0 1 0 0 0     8 (m.red)  BB B B B 5 B B B      0 0 0 0 1 0 0 0     5 (l.blue) BB B B B 6 B B B      0 0 0 0 1 0 0 0     6 (d.red)  B2 2 2 2 D 2 2 2      0 0 0 0 1 0 0 0     D (magenta)2 (m.green)

The VDP register setting could be the following:
VR0 >02 Bitmap mode on
VR1 >C0 16K, screen on
VR2 >08 Screen image at >1800 (we can't have it at >0000 since either the pattern or the color table must be there)
VR3 >FF Color table at >2000, address mask = >1FFF (full size table: 3 times >800 bytes)
VR4 >03 Pattern table at >0000, address mask = >1FFF (full size table: 3 times >800 bytes)
Hybrid bitmap modes
Note that the trick of covering the screen with three repeats of characters 0-255 is just an easy way to calculate which byte corresponds to which pixel, this is by no means an obligation. You could use the tables just the way you do in standard mode: having fixed pattern definitions (and colors) and placing a character number in the screen image table to display it. The address masking trick becomes very handy in this case. Rather than having three copies of the pattern table one after the other, let's just have one and set the address mask to 0: in the example above, VR4 would become >00. The advantage over standard mode is that we can set different colors for each character (rather than for a group of . In fact, we can even set a color pair for each pixel row in a character: this is a nice way to create iridescent characters!
Finally, both solutions can be mixed in the various thirds of the screen: the top two thirds could be arranged for easy bitmap drawing, whereas the bottom third could be arranged for rapid character writing. Some games use this solution to display prompts and scores at the bottom (or top) of the game screen.
You can use the mask bits in register 4 to assign a >800-byte pattern table to each third of the screen:
> 00 (or >04): only one pattern table, identical for each third of the screen.
> 01 (or >05): two pattern tables. One at >0000 (or >2000) for the 1rst and 3rd thirds, one at >0800 (or >2800) for the middle third of the screen.
> 02 (or >06): two pattern tables. One at >0000 (or >2000) for the 1rst and 2nd thirds, one at >1000 (or >3000) for the bottom third of the sceen.
> 03 (or >07): three pattern tables. One at >0000 (or >2000) for the 1rst third, one at >0800 (or >2800) for the 2nd third and one at >1000 (or >3000) for the bottom third of the screen.
Then we could do the same for the color table, using bits 1 and 2 (weight> 40 and >20) to select the number of tables. The remaining bits will affect character grouping within a table. Since they also affect grouping whitin the pattern table, we'd better be carefull with these!
In summary, these would be the addresses of the tables in 8 possible situations:
VR3 VR4 Mask Top 3rd Middle 3rd Bottom 3rd >1F >00 >07FF >0000 >0000 >0000 >9F >04 >07FF >2000 >2000 >2000 >3F >01 >0FFF >0000 >0800 >0000 >BF >05 >0FFF >2000 >2800 >2000 >5F >02 >17FF >0000 >0000 >1000 >DF >06 >17FF >2000 >2000 >3000 >7F >03 >1FFF >0000 >0800 >1000 >FF >07 >1FFF >2000 >2800 >3000

To group characters within a table, we could further alter the color table mask:

• VR3 = >0F results in >400-byte tables. This means that characters> 80-FF will have the same colors and definitions than characters> 00-7F.
• VR3 = >07 results in >200-byte tables. This means that characters> 40-7F, >80-BF and >C0-FF will have the same colors and definitions than characters >00-3F.
• At the extreme, VR3 = >00 results in >40-byte tables. As there are 8 bytes per characters, this means characters are arranged in 8 groups of 32 identical characters: chars 0-7 are identical to chars 8-15, 16-23, etc.
• We could even get weird grouping schemes by using values like> 02,> 04, >55, etc.
  

The table below lists the six most logical values, plus two gooffy ones (just for fun).
VR3 Mask Character grouping Chars Repeats >00 >003F 0=8=16...=248
1=9=17...=249
7=15=23...=255 8 32 >01 >007F 0=16=32...=240
1=17=33...=241
15=31=47..=255 16 16 >03 >00FF 0=32=64...=216
1=33=65...=217
31=63=95...=255 32 8 >07 >01FF 0=64=128=192
1=65=129=193
63=127=191=255 64 4 >0F >03FF 0=128
1=129
127=255 128 2 >1F >07FF Each char is unique 256 1 >02 >00BF 0=8=32=40...
4=12=36=44... 16 16 >04 >013F 0=8=16=24=64...
32=40=48=56=96... 16 16



Bitmap text mode
This is the mode TI forgot to tell us about. It works just like standard bitmap mode, except that the screen is now 40 columns and that only two colors are available.
This mode is selected by setting bit 7 of register 0 as 1. Bit 4 in register 1 should be 1. VR0: 1 VR1: 0 1
The screen is now divided in three, each third is 8 lines high and thus occupies >140 bytes in the screen image table (8*40=320).
The colors are taken from VR7, just like in regular text mode. There is no color table, and the contents of VR3 is irrelevant.
Just like in standard bitmap mode, there can be upto 3 pattern tables, located either at >0000 or at >2000. You can use the address mask bits in VR4 to determine which third of the screen uses which table. The main difference is that the color address mask is not used to fill-in the patten address mask: >07FF is always used instead. No character grouping to worry about, then! This mode comes handy for black-and-white drawings.
Bitmap multicolor mode
Another undocumented mode. It works as a mixture of bitmap and multicolor mode.
This mode is selected by setting bit 7 of register 0 as 1. Bit 3 in register 1 should be 1. VR0: 1 VR1: 1 0
The screen is now divided in three, each third is 8 lines high and thus occupies >100 bytes in the screen image table (8*32=256).
Just like in standard multicolor mode, there is no color table and the contents of VR3 is irrelevant.
The color of the boxes are taken from upto 3 pattern tables, located either at >0000 or at >2000. You can use the address mask bits in VR4 to determine which third of the screen uses which table. Since a single table would be sufficient for this purpose, there is no real point in using this combined mode...

Illegal modes
It is not allowed to set text and multicolor mode together, whether in bitmap mode or not. VR0: x VR1: 1 1
If you try, the VDP will display a fixed image, that is not influenced by the contents of the VDP memory, nor by registers VR2 to VR6 (sprites are not available). The screen is 192 pixel lines and 40 columns. Each column is made of 4 pixels in foreground color, followed by 2 pixels in backgroud color. These two colors are taken from VR7.
Sprites
Sprites are special characters that can be displayed at any position on screen, i.e they are not limited to a grid or rows/column, instead each sprite position can be defined with a precision of one pixel.
Sprites can be either 8x8 pixels or 16x16 pixels depending on the setting of bit 6 in VDP register 1: when this bit is 0 all sprites are 8x8, when it is 1 all sprites are 16x16. In addition, bit 7 in VDP register 1 provides a mgnification feature: when this bit is 1 all sprites are magnified by a factor of two. Concretely this means that each "pixel" becomes a 2x2 pixels box.
Each sprite can have its own foreground color. The background color is always transparent, which lets the underlying image appear under the sprite.
Upto 32 sprites can be displayed at a time. Each one can be seen as an extra image plane on the top of the screen, overlapping each others, with sprite number 0 at the top. Thus the virtual image planes are:
- Black
- External video
- Backdrop plane (color in VDP reg 7)
- Image plane (characters)
- Sprite number 31
- Sprite number 30
- etc upto:
- Sprite number 0
There is one restriction however: the VDP cannot display more than 4 sprites on a given line of pixels. Thus, if 5 sprites or more must be drawn on the same line, only the topmost four (those with the smallest numbers) can be displayed. The number of the 5th one is placed in the status register together with a flag bit and the others are ignored. This occurs whether or not the sprites are actually overlapping: one could be on the left of the screen, the other on the right with the same result.
Coincidence is a different condition: whenever two "on" pixels in different sprites occupy the same screen location, a bit is set in the VDP status register. This comes handy for games programming: an easy way to check whether the bullet hits the target. Note however that the VDP does not tell you which are the overlapping sprites...
Sprites characteristics are defined in two tables pointed by VDP registers 5 and 6: the sprite attributes table and the sprite patterns table.
Sprite attributes table
This table is pointed at by VDP register 6. It contains upto 32 entries for the 32 sprites arranged in numeric order. Each entry is four bytes long, thus the maximum size for this table is >100 bytes. The four bytes define sprite characteristics as follows:
Byte 1 Byte 2 Byte 3 Byte 4 Sprite 0 vertical position -1 horizontal position pattern number clock bit sprite color Sprite 1
"
"
"
"
"

Sprite positions are expressed in pixels relative to the top left corner of the display area. This will be the position of the top leftmost pixel of the sprite (unless the early clock bit is set, see below). Note that the vertical position coordinate in the table is offset by one: therefore the topmost pixel line is >FF, the second is >00, the third is> 01 and the last is >BE. Any sprite whose vertical position is greater than> BE won't be visible on screen, although coordinates close to >FF can result in the bottom of the sprite appearing at the top of the screen. Similarly, row values just under >BE result in partly blending off the bottom of the sprite.
The same thing is true for sprite approaching the right border of the screen (horizontal coordinates close to >FF): the sprite appears to blend-in from the right. However this won't work on the left of the screen: when the horizontal position is 0 the whole sprite is visible, when it's lower than 0 (i.e. >FF, >FE, etc), the sprite appears at the right of the screen. To allow for sprite blend-in from the left of the screen one can set the "early clock" bit (bit 0, value >80) in the color byte: the horizontal coordinate now refers to a point located 32 pixels to the right of the upper left corner of the sprite. This results in shifting the sprite 32 pixels to the left and allows for partial disappearance on the left side (but not any more on the right).
The pattern number refers to the entry containing the sprite pattern in the sprite pattern table.
Finally the sprite color is defined by the right nibble in the byte 4 of the entry.
The sprite attributes table does not need to define all sprites: if the vertical position of a sprite is set as >D0, the sprite won't be displayed (as it's off-screen), but neither will any of the following sprites. This comes handy to quickly erase all sprites by just changing one byte in the attributes table.
Sprite pattern table
This table contains patterns to be used by the various sprites, arranged in ascending order. Each entry is either 8 bytes long or 32 bytes long depending on the sprite size.
If the sprite size is set as 8x8, entries are 8 bytes long. Each byte defines a row in the sprite: "1" bits result in pixels of the color specified for that sprite in the attributes table, "0" bits encode transparent pixels and are ignored for display purposes.
If the sprite size is set as 16x16 (VDP register 1, bit 6 set as 1) each entry is 32 bytes long. These bytes define the sprite pattern as if it were made of four "normal sprites" arranged in a 2x2 formation:
1 3
2 4
Thus, bytes 0-7 define the top left quadrant, one byte per line of 8 pixels. Bytes 8-15 define the bottom left quadrant in a similar fashion. Bytes 16-23 define the top right quadrant, one byte per line of 8 pixels (which now corresponds to pixels 9-15 of the sprite rows 0-7) and bytes 17-23 define the lower right quadrant.
Even wiith a 16x16 pixels size, 32 sprites require at most >400 bytes (32x32). Thus there is room enough for extra sprite patterns and a sprite can be animated by quickly changing its pattern number in the attributes table rather than by modifying the sprite pattern table.

Timing issues
The VDP needs 2 microseconds to read or write a byte to its RAM. In addition, it can only communicate with the CPU at precise moments, when it is not too busy with building the screen. Such moments are known as CPU access windows and may arise at various intervals depending on the video mode. In standard or bitmap mode, a window occurs every 16 memory cycles, each cycle being 372 ns long. This means the VDP may have to wait upto 5.95 us before a CPU access window occurs. Adding the 2 us needed for RAM access gives us a maximum delay time of 8 us. Of course, it can be as fast as 2 us if a window just happens to open (even less for reading operations, thanks to the read-ahead buffer). In text mode, a window opens every three memory cycles, i.e. at intervals of 1.1 us. In multicolor mode, a window opens every four memory cycles, i.e. at 1.5 us intervals.
There are two exceptions to these rules, however:

• When the screen is blank (because bit 1 in register 1 is set as 0) the VDP does not handle the screen and a CPU access window is permanently open. Consequently, there is no wait time.
• When the VDP is done with drawing a frame and enters vertical refresh mode it issues an interrupt (if enabled) and opens a 4.3 milliseconds (4300 us) window for CPU access.
  

Condition Mode RAM access
delay Time waiting
for a window Total delay Building screen Standard
/ Bitmap 2 us 0 - 5.95 us 2 - 8 us Building screen Text 2 us 0 - 1.1 us 2 - 3.1 us Building screen Multicolor 2 us 0 - 1.5 us 2 - 3.5 us Vertical retrace Any 2 us 0 2 us Blank screen Any 2 us 0 2 us

Contrarily to standard memory, the VDP cannot hold the CPU in a wait state until it is ready to accept/send data. This means that the application program must contain appropriate delays to prevent the CPU from going on with the next operation before the VDP has completed the current one. A typical example is passing the two command bytes to the VDP: using two successive MOV instructions is too fast and the second byte won't be read. The program should thus contain another instruction in between the two MOV (such as a NOP or a SWPB).
Programming examples

*------------------------------------------------------------* VDP write to register. * Expects register # in R0 MSB and register content in R0 LSB*------------------------------------------------------------VWREG  ORI   R0,>8000     Set command bits as 1xxx xrrrCMD    SWPB R0            Send a command to the VDP       MOVB R0,@>8C02     Send first byte (least significant)       SWPB R0            Delay       MOVB R0,@>8C02     Send second byte (most significant)       B    *R11*------------------------------------------------------------* VDP set address to write in RAM* Expects address in R0*------------------------------------------------------------VAD2WR ANDI R0,>7FFF     Make sure command bits are 01xx xxxx       ORI   R0,>4000       JMP  CMD          Send command*------------------------------------------------------------* VDP set address to read from RAM* Expects address in R0*------------------------------------------------------------VAD2RD ANDI R0,>3FFF     Make sure command bits are 00xx xxxx          JMP  CMD          Send command*------------------------------------------------------------* VDP write byte to RAM* Expects data byte in R0 MSB and address set by VAD2WR*------------------------------------------------------------VWRBYT MOV  R0,@>8C00    Send data to VDP       B    *R11         Delay*------------------------------------------------------------* VDP read byte from RAM. Assumes address was set by VAD2RD* Result will be in R0 MSB*------------------------------------------------------------VRDBYT MOV  @>8800,R0    Get data byte       B    *R11         Delay*------------------------------------------------------------* VDP read status. Result will be in R0 MSB*------------------------------------------------------------VRDSTA MOV  @>8802,R0    Read status register, resets bits 0-2.       B    *R11         Delay

http://www.unige.ch/medecine/nouspikel/ti99/architec.htm