F18A

[matthew180]

The PIX instruction seems to be very powerful. What I don't get is what you mean with writing a 2 ("10") pixel or a 3 ("11") pixel.

As we are talking bitmap layer I expected a 1 (pixel on) and 0 (pixel off) ?

Can you give some details on that? What about pixel colors?

 

I'm a bitmap rookie

 

Well, I'm technically using the term "bitmap" incorrectly. A bitmap, when used to describe the idea of a picture, really is what you were thinking, i.e. 1 bit per pixel, black and white, '1' or '0'. Of course a bitmap can be used for other things besides graphics, but it is being used here in scope of images and screen data.

 

I guess I used "bitmap" in the sense that each "pixel" is changeable (or "addressable", which is also an incorrect term to use here, but is generally creates the right idea in people's minds) without affecting its neighbor, unlike the GM2 mode we are used to.

 

A real bitmap does not really contain color data since the information only indicates if a pixel is visible or not. Color is defined somewhere else. This is also how the 9918A defines tile patterns, i.e. as bitmap map data with the color defined separately.

 

A bitmap is fine for two colors, but as soon as you need more color you lose the simplicity of consecutive bits directly correlating to pixels on the screen. When you go beyond a bitmap's 1-bit per pixel, the bits actually describe the color data itself. In modern computers with available memory, the color data *is* the color, i.e. a 24-bit display uses 1-byte per Red, Green, and Blue component, and sometimes a 4th byte to represent 256 levels of opacity.

 

In older systems where you don't have enough memory to store the color data *as* pixels, a scheme called "indexed color" was used. This is what the F18A does, and many other systems like coin-op games and such.

 

With indexed color, you have a certain number of "palette address" or "palette registers" which hold the actual color data. Each palette register is some fixed number of bits, like 8-bit, 12-bits, etc. and can thus represent a certain number of colors. An 8-bit palette registers can hold 1 of 256 possible colors. The F18A has 12-bit palette registers and thus can display a possible range of 4069 colors.

 

The key here is, the pixel data stores a palette "address" or "index", and the color at that palette index is then used to display the pixel. The savings comes because the number of palette indexes is smaller than the number of color bits in each palette register. So you can display a select number of colors from a wide range of colors, yet store pixel data more efficiently.

 

The F18A has 64 programmable palette registers, and each register can hold any of 4096 colors. The "indexes" of the palette registers are 0 to 63 ("000000" to "111111" binary) which requires 6-bits of data to represent (2^6 = 64).

 

In the F18A, the bitmap layer (BML) uses 2-bits for each pixel, so 1-byte in VRAM holds 4-pixels. That means the bits for each pixel can identify 4 possible colors: "00", "01", "10", and "11" in binary or 0, 1, 2, and 3 in decimal.

| PX0-0 PX0-1 | PX1-0 PX1-1 | PX2-0 PX2-1 | PX3-0 PX3-1 |

 

But you need 6-bits to identify one of the 64 palette registers to use, so the extra 4-bits come from a new VDP Register related to the BML and are called the "palette select" bits. So taken together, 4-bits come from the new register, and 2-bits come from each pixel:

32  16   8   4   2   1  (binary place value)
0   1   2   3   4   5  (bit number)
PS0 PS1 PS2 PS3 PX0 PX1 (bit source)

6-bits --> PR0 --> 12-bits of color --> RGB output
          PR1 --> 12-bits of color --> RGB output
          .
          .
          .
          PR63 --> 12-bits of color --> RGB output

Since the top 4-bits come from the Palette Select, they can select 1-of-16 groups of 4-colors in the total range of 64 palette registers. The pixel data selects 1 of 4 colors in that group. This is exactly how the "color groups" of the 9918A work for each group of 8 tiles in the color table, only here we are dealing with pixels and groups of 4 instead of groups of 8.

 

The BML also has an option to use pixel value "00" as transparent instead of an index into a palette register, which gives you 3 colors and transparency (either background or the tile layer) instead of 4-colors. It all depends on what you want to do.

 

If you look back on post #634 you can see the BML in each mode (GM1, GM2, T40, T80, and MCM).

Edited July 31, 2012 by matthew180

[moulinaie]

Helllo,

 

Something about the F18A installation.

I have an accelerator in the TI 99 (a switch to toggle between the original quartz and a faster one)

In the fast mode, the TI doesn't boot anymore with the F18A. The beep at start nevers stops BEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEPPPP

and the display never comes.

 

Guillaume.

[matthew180]

Power on, then insert a cartridge which will force a real hardware reset. Do you have a schematic for the modification?

 

Vorticon has used the F18A in an 99/4A with the faster crystal, and I believe Willsy has too. The F18A should not be affected, or have any affect on the system clock. However, the fact that you have the beep means the F18A is working, since the GROMCLK comes from the VDP. Also, if you have an orange light on the F18A, it is configured and up and running.

Edited August 6, 2012 by matthew180

[+retroclouds]

Hi Matthew,

 

can you give some details on how the scrolling feature of the F18A works? Is it possible to scroll part of the screen?

Or do you have to use the bitmap layer for static stuff (game score, num# of lives, etc) ?

[moulinaie]

Power on, then insert a cartridge which will force a real hardware reset. Do you have a schematic for the modification?

 

Vorticon has used the F18A in an 99/4A with the faster crystal, and I believe Willsy has too. The F18A should not be affected, or have any affect on the system clock. However, the fact that you have the beep means the F18A is working, since the GROMCLK comes from the VDP. Also, if you have an orange light on the F18A, it is configured and up and running.

 

I used the guide on this page: http://www.mainbyte.com/ti99/speedup/speedup.html

 

If some accelerated TI work, I suspect that I broke something when disassembling the console to insert the F18A in the crystal cables.

But, I thought I made everything softly...

If someday I open it again, I will try to see what's happening.

 

Guillaume.

[matthew180]

Hi Matthew,

 

can you give some details on how the scrolling feature of the F18A works? Is it possible to scroll part of the screen?

Or do you have to use the bitmap layer for static stuff (game score, num# of lives, etc) ?

Scrolling is one of the areas that I ended up spending a lot of time on, and subsequently there are a *lot* of options. So, let me start with the basics and build up from there.

 

*Note1* The term "pixel" here refers to what I call a "fat pixel", which is made up of a 2x2 block of VGA pixels, and represents the 9918A's pixel resolution of 256x192.

 

*Note2* Let me say right now that when I was implementing the scrolling, I was not considering the text modes because they use a special pixel counter that is not a multiple of 8 (and that is critical to the scrolling hardware). Scrolling will do *something* in the text modes, but it won't be what you expect. Everything here assumes GM1 for the most part.

 

The guts of the scrolling are the horizontal and vertical scroll registers. These are a full 8-bits each and cause the display to be adjusted in 1-pixel increments.

 

When you start scrolling, you immediately become aware of several problems, the first being what should display on the left or right (or top and bottom) as you start to scroll. This is where the idea of "pages" comes in to play.

 

There are two "page" bits that control how big the display is horizontally and vertically. With a "0" horizontal page size, if you scroll left or right the display wraps at the edges. With a "1" horizontal page bit, you now have two name tables in VRAM that make a virtual display size of 64x24 tiles, of which you can see a 32x24 window:

 

virtual screen  |0<--------------->63|
physical screen |0<---->31|

So, as you increase the horizontal scroll register, instead of the display wrapping, you start to see what is in the second name table. In memory, the name tables are 1K each and are consecutive. The name table base address can still be used to locate the name tables, but the size grows 1K for each additional "page" (of which there can be 1, 2, or 4).

 

VRAM Name Table address example
>0000 start 1st name table, page 0
>02FF end 1st name table, page 0 (767 bytes)

>0300 256 bytes unused
>03FF ...

>0400 start 2nd name table, page 1
>06FF end 2nd name table, page 1

01234-----------31-32-------------63|
+-----//...//-----+-----//...//-----|
0|0,1,2...........|1024,1025,1026...|
1|
2|......page 0....|......page 1.....|
.
.
.
21|
22|
23|............767|.............1791|
+-----//...//-----+-----//...//-----+

Also, in a 1-page setup, you would normally have to mask-off the left-most and right-most columns (0 and 31) and constantly provide new display information to "scroll in" or "scroll out". With the extra horizontal page, you still need to do updates to provide the appearance of endless scrolling, but you don't have to mask the edge columns and you have at least 16 columns of buffer space to work with on either side, or a full screen depending on how you set things up.

 

The vertical page size works the same way except page-2 is used instead of the page-1 name table, and it would show up below page-0 as you start to scroll vertically:

 

01234-----------31|
+-----//...//-----|
0|0,1,2...........|
1|
2|.....page 0.....|
.
.
.
21|
22|
23|............767|
+-----//...//-----+
24|2048,2049,2050.|
25|
26|.....page 2....|
.
.
.
45|
46|
47|...........3071|
+-----//...//-----+

The final configuration would be a "1" for both the horizontal and vertical page size, in which case there are now four name tables:

 

VRAM Name Table address example
>0000 start 1st name table, page 0
>02FF end 1st name table, page 0 (767 bytes)

>0300 256 bytes unused
>03FF ...

>0400 start 2nd name table, page 1
>06FF end 2nd name table, page 1

>0700 256 bytes unused
>07FF ...

>0800 start 3rd name table, page 2
>0AFF end 3rd name table, page 2

>0B00 256 bytes unused
>0BFF ...

>0C00 start 3rd name table, page 3
>0EFF end 3rd name table, page 3

01234-----------31-32-------------63|
+-----//...//-----+-----//...//-----|
0|0,1,2...........|1024,1025,1026...|
1|
2|.....page 0.....|......page 1.....|
.
.
.
21|
22|
23|............767|.............1791|
+-----//...//-----+-----//...//-----+
24|2048,2049,2050.|3072,3073,3074...|
25|
26|....page 2.....|......page 3.....|
.
.
.
45|
46|
47|...........2815|.............3839|
+-----//...//-----+-----//...//-----+

The 4-page mode gives you the ability to scroll around a 32x24 window on a virtual 64x48 tile field. Also, with the ROW30 bit, the 24 rows expands to 30 rows, so your display becomes a 32x30 window on a 64x60 tile field. Also with the ROW30 bit set, the name tables go from 768 bytes (32*24) to 960 bytes (32*30) with only 64 bytes of unused memory between the pages. This was one of the main reasons for placing the pages on 1K boundaries (not to mention the technical reasons).

 

The page layout scheme was inspired by the NES, which has a very similar setup.

 

hsize|vsize|hscroll|vscroll|name tables
-----+-----+-------+-------+-----------
  0  |  0  | wraps | wraps | 1 (page 0)
  1  |  0  | pg0/1 | wraps | 2 (page 0 and 1)
  0  |  1  | wraps | pg0/2 | 2 (page 0 and 2)
  1  |  1  | pg0/1 | pg2/3 | 4 (page 0, 1, 2, 3)

There are also two more bits associated with the horizontal and vertical size bits, and those are the horizontal and vertical "page start" bits. These control which page is the "starting" page when the horizontal or vertical size is "1".

 

Think about when you scroll to the right a little (increase the horizontal scroll register) with a horizontal size of "0". If the horizontal scroll is at 16, for example, as the display is drawn the left of the screen starts with data for column 2. But, when you get to column 31 in VRAM you still have 2 columns on the screen to display. So the F18A uses the data from columns 0 and 1 to finish the row. This is the wrapping in a single page setup.

 

Now, if you have a horizontal size of "1", then the 2 columns of data to finish off the row (using the example above) would come from columns 0 and 1 of the second page.

 

Here is where the "start page" settings come in to play. In the example above, say you have the horizontal scroll register set to 255 (max). This means you are displaying one *pixel* of data from the first page (page 0) before you start using data from page 1, which is entirely displayed except for 1 pixel. At this point, if you wanted to continue scrolling, you need to be able to "start" on page 1 and use data from page 0 as you continue to scroll. This is what the "start page" bit does.

 

After all that I came to the realization that you would probably want to keep part of the display still while you scrolled, like for scores and such. So I added a "top border" register that would let you specify a line above which scrolling would not affect the display. So, you could set the top-border to 8 to keep the first row still while the remaining rows would scroll around.

 

Of course the top-border soon expanded into a bottom border, then a left and right border. Therefore, you also have four registers that can define a "scroll window" on a pixel level. Inside the window the tiles scroll, outside the window the tiles are fixed.

 

The top-border was originally called the top "banner" (because I was only going to have that one additional register), and I realized you might want to have only what is on the first name table (page 0) display at the top while having a horizontal size of "1" (two pages wide). So there is also a setting to control how "wide" the top border is, i.e. 1 page or 2 pages. It can really make for some strange effects and was really designed with side-scrolling games in mind, but I tried not to do that though, i.e. create features for specific purposes.

 

On top of all of that, I thought it would be nice to have control over how each tile is affected by the scroll registers. Thus the "fixed map" was created. The fixed map is a bitmap of the 32x24 (or 32x30) tile display, each each bit determines if that tile will be affected by the scrolling or not, i.e. "fixed" in place. The fixed table has a new base-address register and can be located on 128-byte boundaries (I think, I can't remember right off hand). Each byte controls 8 tiles on the screen:

 

 .........byte 0......... ...  .........byte 3.........
|t0|t1|t2|t3|t4|t5|t6|t7| ... |t24|t25|t26|t27|t28|t29|t30|t31|

Each row requires four bytes (4*8=32), and there are 24 rows, so a total of 96 bytes for a 32x24 name table and 120 bytes for a 32x30 name table (ROW30 set).

 

The sprites and the bitmap layer (BML) are *not* affected by the scroll registers. However, the BML can be moved around at a pixel level via is own xy location registers, and can be set above or below the tiles (have priority over tiles or not). So, with the scrolling, scroll borders, fixed map, BML, and sprites you can probably come up with some pretty nice effects.

Edited December 27, 2013 by matthew180

[+retroclouds]

Thanks for the update Matthew. The way I say it, it should be pretty easy to implement horizontal pixel scrollng in Tutankham.

Would probably take some more effort to keep the "static" stuff on screen as that would need to go on the BML.

 

By the way I received my F18A last Thursday. Did not install it yet (unfortunately). Planning on doing that soon.

I'd like to add F18A support to Tutankham, but currently considering how to get the Tutankham 64K image to run on the TI-99/4A without having to burn EPROMS for every cycle, which will be totally cumbersome.

Perhaps I could do something with a SAMS card (if I can get my hands on one, but then I also need a way to transfer the stuff to the TI-99/4A as I'll be using the PEB box, so no CF7+)

[moulinaie]

Hello again Matthew,

 

Someday you'll write a manual to stop our questions...

 

What about the 80-columns mode?

Is it totally 9938 compatible?

 

I read the 9938 manual and here's what they say (I don't care about the 80x26.5 display):

- 80*24 tiles (so a memory of 1920 bytes)

- 256 patterns (as usual 2048 bytes)

- 240 bytes for the blinking bits (240 bytes = 1920 bits)

 

Is it the same with the F18A? Are sprites allowed in this mode (normally not..)

 

Guillaume.

[Willsy]

Blinking is not implemented. But you can have different colour characters. All 32 sprites are available. And smooth scrolling IIRC.

 

I can't remember how you do different colour characters. I can't remember if it uses 8 character sets like 32 character mode, or if it is a different system. I can't remember seeing any example code for colours in 80 column mode. I would love to see it myself! I'll be taking my TI out of storage soon - I can't wait!

[Gazoo]

Blinking is not implemented. But you can have different colour characters. All 32 sprites are available. And smooth scrolling IIRC.

 

I can't remember how you do different colour characters. I can't remember if it uses 8 character sets like 32 character mode, or if it is a different system. I can't remember seeing any example code for colours in 80 column mode. I would love to see it myself! I'll be taking my TI out of storage soon - I can't wait!

 

 

80 column color.

[matthew180]

Someday you'll write a manual to stop our questions...

 

I don't mind, I'm using the posts as a starting point for the docs. I'd rather provide the information people are looking for first. This also helps with awareness of the F18A, and having people like you working on projects and support for the new features are critical for wide-spread support and adoption.

 

What about the 80-columns mode?

Is it totally 9938 compatible?

 

No, it is not totally 9938 compatible. As Willsy said, the "blink" support was not implemented, but that was by choice. The memory use for the name table and such is the same though, and ROW30 can be set in the T40 and T80 modes, which gives you 40x30 and 80x30 respectively.

 

Tiles are still 6x8 pixels of the 8x8 pattern data, nothing changed there.

 

As I mentioned in my scrolling post above, the text modes probably won't do well with the scrolling. This is primarily due to the text modes not falling on bit-boundaries that are powers of 2, i.e. 40 and 80. It is actually not something I even tried (scrolling in the text modes), but the more I think about it, the more I think it will probably work up to a point, and vertical scrolling should work better than horizontal scrolling. Multiple page support certainly won't work in T80 mode because the name table is almost 2K, and the pages are designed to expect 1K name tables. T40 might work, but only with 24 rows.

 

Colors are available in T40 and T80 with ECM1 to ECM3 enabled. In ECM0 the T40 and T80 modes function as the original, i.e. two colors. The BML is always available if enabled, and is not affected by the graphic mode.

 

Is it the same with the F18A? Are sprites allowed in this mode (normally not..)

 

Sprites are available with ECM1 to ECM3.

 

[matthew180]

I can't remember how you do different colour characters. I can't remember if it uses 8 character sets like 32 character mode, or if it is a different system.

 

Color depends on the ECM (enhanced color mode). There are 4 ECMs:

 

ECM = enhanced color mode
BPP = bits per pixel
CTS = color table size
PTS = pattern table size

ECM|BPP|CTS|PTS|Colors
0   1   32  2K  2 per group of 8 tiles (the original 9918A grouping)
1   1  256  2K  2 per tile
2   2  256  4K  4 per tile
3   3  256  6K  8 per tile

 

ECM1 is essentially the same as ECM0 (original color), but ECM1 enables the per-tile attributes which is where each tile can specify its own palette, flip x, flip y, and priority over sprites. The other primary difference between ECM0 and ECM1 is that ECM1 changes the role of the pattern data. In ECM1 to ECM3, the pattern data becomes a color selection in the specified palette. In ECM0 the pattern data selects if the pixel is fg or bg, but the color palette index comes from the original 32-byte color table.

 

ECM2 and ECM3 expand the pattern requirements to support more colors per pixel.

 

I can't remember seeing any example code for colours in 80 column mode. I would love to see it myself!

 

Look on page 26 of this thread:

 

http://www.atariage.com/forums/topic/168968-f18a/page__st__625#entry2554368

 

I don't know if I have a code example anywhere yet, but it would the same as T40 or T80 modes with the addition of setting up the expanded color table, which is just initializing the 256 per-tile attribute bytes instead of the original 32 color bytes.

 

[moulinaie]

Color depends on the ECM (enhanced color mode). There are 4 ECMs:

 

ECM = enhanced color mode
BPP = bits per pixel
CTS = color table size
PTS = pattern table size

ECM|BPP|CTS|PTS|Colors
0 1 32 2K 2 per group of 8 tiles (the original 9918A grouping)
1 1 256 2K 2 per tile
2 2 256 4K 4 per tile
3 3 256 6K 8 per tile

 

 

Hello Matthew,

 

ECM0 and ECM1 are easy and interesting modes.

is it always VDP R3 that sets the COLOR TABLE address (by >40 step) even if it is 256 bytes long?

Is it always the same encoding (high nibble for foreground and low for background) ?

 

Something else I don't understand...

If I set the display in 40 colums, VDP R7 is the color for the whole character set. How is this distinguished from ECM0 wich uses a 32 bytes color table?

What's the use of FIXED_TILE_ENABLE in R49 ?

 

THat's all for today!

 

Guillaume.

[moulinaie]

Hello again,

 

Here is what I've been able to do with MLC for now, three new instructions:

 

TEXT32 for standard mode
TEXT40 for 40 columns (every TI99)
TEXT80 for 80 columns (F18A only)

 

http://www.youtube.com/watch?v=DSfj9s6cxGY

 

When I'll get all informations from Matthwe, I'll add the 40x30 and 80x30 text modes (instead of 40x24 and 80x24)

and finally colors in text modes.

 

Guillaume.

Edited August 9, 2012 by moulinaie

[Willsy]

Love it!

 

When you being to look at colours in 80 column mode please share the info! I'll build a library for TurboForth!

 

Mark

[matthew180]

ECM0 and ECM1 are easy and interesting modes.

 

Actually, ECM or "Enhanced Color Mode" is a poor choice of words on my part. They are not really "modes", but rather "settings" which work in all "modes". The modes of the F18A are: GM1, GM2, MCM, T40, and T80. Most of the enhancements are available in all the modes, i.e. the BML can be enabled in every mode, but the BML itself is not a "mode" of operation. The ECM for tiles and sprites can also be set no matter what mode is currently being used.

 

is it always VDP R3 that sets the COLOR TABLE address (by >40 step) even if it is 256 bytes long?

 

Yes, VR3 always sets the color table base address no matter the ECM. In ECM0 it is the original 32-bytes long. In ECM1 to ECM3 the color table is 256-bytes long, and changes to what I call the "per-tile attribute table", which is why it is 256-byte long (one attribute byte per tile).

 

Is it always the same encoding (high nibble for foreground and low for background) ?

 

No. The color table is only fg/bg for ECM0. In ECM1 to ECM3 each byte is a per-tile "attribute" byte. At the bottom of the register user spreadsheet you will see the format of the attribute byte:

 

|PRI|FLIP X|FLIP Y|TRANS|PS0|PS1|PS2|PS3|

PRI . . . when '1', this tile has priority over sprites
FLIP X  . flip this tile's pattern data in the X direction: 11001100 would become 00110011
FLIP Y  . flip this tile's pattern data in the Y direction
TRANS . . when '1', a 0-pixel index ('0', '00', or '000') is transparent instead of a color
PS0:PS3 . the palette select for this tile, the color index comes from the pattern data

 

Something else I don't understand...

If I set the display in 40 colums, VDP R7 is the color for the whole character set. How is this distinguished from ECM0 wich uses a 32 bytes color table?

 

In normal 40-column mode (ECM0), the color table is not used and the only colors for text come from VR7. This is how the 9918A works and how the F18A works in T40 and T80 with ECM0. In T40 and T80 modes with ECM1 to ECM3, the per-tile attribute table is used as shown above.

 

What's the use of FIXED_TILE_ENABLE in R49 ?

 

It enables the use of the "fixed tile" table. When '0', the fixed-table is not used. Please see my post above (#656) on scrolling. If you still have questions about it, let me know.

Edited August 9, 2012 by matthew180

[matthew180]

When you being to look at colours in 80 column mode please share the info!

 

What is it you want to know? To get color in T80 mode you only need to set the location of the per-tile attribute table via VR3 (i.e. the color table register), and initialize it with a default palette index. I set some default palettes in the F18A to help get up and running with ECM1. Initialize the 256-bytes of the attribute table to: >08, which will index the palette registers 16 and 17 (PS0:PS3 from the attribute table form the middle 4-bits of the 6-bit palette index).

 

Then you only need to set T80 by setting the new M4 (which I know you already know how to do), and set ECM1 in VR49.

 

[moulinaie]

 

In normal 40-column mode (ECM0), the color table is not used and the only colors for text come from VR7. This is how the 9918A works and how the F18A works in T40 and T80 with ECM0. In T40 and T80 modes with ECM1 to ECM3, the per-tile attribute table is used as shown above.

 

So I can't have the T40/80 with one color per group of 8 tiles... Too bad! That was easy ! But no matter, I will have a look at the color mode...

 

guillaume

[matthew180]

Color Selection Detail

 

The F18A has 64 12-bit programmable color registers. Depending on the ECM selected for tiles and sprites (which can be independently set), the final color index is derived differently. Below is the part of the actual HDL used to set the index:

 

tile_ps & pix_colr when ecm = 0 else            -- Original color mode
tile_ps(0) & pal_sel & pix0 when ecm = 1 else   -- 1-bit color
pal_sel & pix1 & pix0 when ecm = 2 else         -- 2-bit color
pal_sel(0 to 2) & pix2 & pix1 & pix0;           -- 3-bit color

 

If that does not mean anything to you, read on...

 

To reference any of the 64 palette registers you need a 6-bit number (2^6 = 64) which is "000000" to "111111" or >00 to >3F hex. Based on the ECM, a certain number of bits come from the pattern data, and the rest come from the per-tile attribute table and the global "tile palette select" bits from VR24.

 

ECM0:

 

In ECM0 the pattern data is not used directly in color selection, and this is the main difference between ECM0 and ECM1. Just like in the original 9918A, in ECM0 a '1' bit from the pattern specifies that the pixel will be the foreground color, and the actual 4-bit color index comes from that tile's color group byte. Since the 9918A has 16 colors indexed with 4-bits, you still need two additional bits to specify the 6-bit index in the F18A. These two additional bits come from the two Tile Palette Select bits in VR24:

 

TPS0:TPS1 | COL0:COL1:COL2:COL3

 

COL0:COL3 come from the high-nybble or low-nybble of the color byte for each group of eight tiles. Thus, the 64 palette registers are sectioned into four groups of sixteen color each. You can change the set of sixteen palette registers used for ECM0 by simply changing the TPS bits in VR24.

 

 

ECM1:

 

In ECM1 (and ECM2 and ECM3) the pattern data becomes color information directly used to select one of two colors from the palette. The color table changes to the per-tile attribute table which contains 4-bits of palette selection data for the tile. Thus, the tile's attribute byte provides 4-bits, and the pattern data provides 1-bit, so only 1-bit is used from the global TPS bits in VR24:

 

TPS0 | COL0:COL1:COL2:COL3 | PATTERN-BIT

 

COL0:COL3 are from the per-tile attribute entry for the tile. This sections the 64 palette registers into 32 2-color palettes, and the pattern bit, '0' or '1', selects which of the two colors to use. This is also where the transparent bit from the tile attribute tables comes in to play. If the transparent bit is enabled, a '0' pattern bit will be displayed at transparent instead of the color at the index palette register. This is no different than the special color "0" in the 9918A being transparent instead of black. This is really just a way to specify the difference between black and transparent.

 

 

ECM2:

 

ECM2 works just like ECM1 but picks up a additional color bit from the expanded pattern data. ECM2 makes the pattern table 4K-bytes long instead of 2K-bytes. With 2-bits per pixel, the global TPS bits from VR24 are no longer used:

 

COL0:COL1:COL2:COL3 | PB0:PB1

 

PB = pattern-bit

 

COL0:COL3 are from the per-tile attribute entry for the tile. This sections the 64 palette registers into 16 4-color palettes, and the pattern bits, '00', '01', '10, and '11', select which of the four colors to use. The transparent bit from the attribute table is used to determine if index '00' (from the pattern data) is transparent or the color at that index.

 

 

ECM3:

 

ECM3 adds a final bit and expands the pattern table out to 6K-bytes. There are now 3-bits per pixel for a total of 8 possible colors for any given pixel in any of the 256 tiles. Only 3-bits are used from the per-tile color bits:

 

COL0:COL1:COL2 | PB0:PB1:PB2

 

COL0:COL2 are from the per-tile attribute entry for the tile. This sections the 64 palette registers into 8 8-color palettes, and the pattern bits, '000', '001', '010, '011', '100', '101', '110, and '111', select which of the eight colors to use. The transparent bit from the attribute table is used to determine if index '000' (from the pattern data) is transparent or the color at that index.

 

 

The pattern tables expand consecutively in VRAM directly following the original 2K pattern table. Each new 2K pattern table are configured as "bit-planes" and add 1-bit of color data per table (or plane):

 

Bytes in VRAM, offset from the Name Table Base Address from VR2:

NTBA + 0 . . . .  NTBA + 1
|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7| Pattern Plane 1 LSbit (ECM1,ECM2,EM3)
1 0 1 0 1 1 1 1   0 0 0 0 0 1 1 0

NTBA + 2048 . . . NTBA + 2049
|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7| Pattern Plane 2 (ECM2,ECM3)
0 0 0 0 1 1 1 1   1 0 0 0 1 0 0 1

NTBA + 4096 . . . NTBA + 4097
|0|1|2|3|4|5|6|7| |0|1|2|3|4|5|6|7| Pattern Plane 3 MSbit (ECM3)
1 1 1 1 0 0 0 1   0 1 0 1 0 1 0 1

Pixel index values.  Pattern Plane 0 is the LSbit:

1 0 1 0 1 1 1 1   0 0 0 0 0 1 1 0  ECM1 color indexes (same as pattern plane 1)

1 0 1 0 3 3 3 3   2 0 0 0 2 1 1 2  ECM2 color indexes, pattern planes 2+1

5 4 5 4 3 3 3 7   2 4 0 4 2 5 1 6  ECM3 color indexes, pattern planes 3+2+1

For example, the first "4" index above is formed by taking 1-bit from each plane
and forming a binary value that becomes the color index:

P3 P2 P1 - pattern plane
4  2  1 - binary place value
--------
1  0  0 - data from each plane

 

Every 8-bytes in each pattern plane describes one tile, just like the 9918A. Shown here, the tables are defining the color indexes for the first two rows of tile 0.

 

I set up the data in planes, vs. packed consecutively in bytes, for a few reasons:

 

First, with 3-bits per pixel in ECM3, color data for a pixel would cross byte boundaries and this would seriously complicate things on the hardware side and for the programmer.

 

Second, using pattern planes like this means you can use your existing pattern data in ECM2 and ECM3 and just add additional pattern data as necessary to get the extra colors.

 

However, it does make it harder to define the pattern data, and I'm hoping to produce a dedicated editor for this. In the mean time, sometimers99er has graciously expanded his Flash-based sprite editor to support the 8 color possibility of ECM3.

 

[matthew180]

So I can't have the T40/80 with one color per group of 8 tiles... Too bad! That was easy ! But no matter, I will have a look at the color mode...

 

Nope. With flexibility and options comes complexity. ECM0 is the default and was designed to provide original functionality. ECM1 to ECM3 enabled the extra color features and making them all the same was essential to me not going insane.

 

However, if you really want a fg/bg color per group of 8 tiles, you can set that up really easily in ECM1. Just define every 8-bytes in the 256-byte attribute table to point to the same palette index. To change a "color group" you have to change 8-bytes instead of 1-byte, but that is really the only difference if you want to look at it that way.

 

Or, you can set each group of 8 tiles to point to each of the 32 2-color palettes of ECM1, and then change the palette register colors. That gives you the possibility to have 64 on-screen colors for the text from a possible 4096 colors.

 

It really depends on what you want to do. There are too many ways to accomplish something to try and describe them all. Better to understand the tool so you know how to use it best in a specific situation.

 

[Tursi]

I'm loving these descriptions and so I say keep the questions coming. it helps my own understanding which I'll eventually need to update Classic99.

[moulinaie]

hello,

 

just one idea if an update will come some day. An option to freeze the display while working on the screen image would be great!

 

:-))

 

Guillaume.

[Willsy]

That's very good, and much more flexible than the old 8 colours per char set thing. I *always* thought that was crap!

[Willsy]

Or, you can set each group of 8 tiles to point to each of the 32 2-color palettes of ECM1, and then change the palette register colors. That gives you the possibility to have 64 on-screen colors for the text from a possible 4096 colors.

 

YYYYYYYYYYYYYYYYYYYYYEEEEEEEEEEEEEEEEEEOOOOOOOOOOOOOOOOOWWWWWWWWWWWWWWWWWsers!

[+Lee Stewart]

Or, you can set each group of 8 tiles to point to each of the 32 2-color palettes of ECM1, and then change the palette register colors. That gives you the possibility to have 64 on-screen colors for the text from a possible 4096 colors.

 

YYYYYYYYYYYYYYYYYYYYYEEEEEEEEEEEEEEEEEEOOOOOOOOOOOOOOOOOWWWWWWWWWWWWWWWWWsers!

 

You're so melodramatic, Mark! I suppose, though, I should think about getting one ere long.

 

...lee