F18A programming, info, and resources

[Tursi]

Holy crap! Even seeing it in bits before, that still looks really sweet with the full smooth scroll.

 

I wonder if it would save you some hassle if the GPU program didn't scroll the first character row - is it safe to say that should remain static on all screens?

[matthew180]

Looks really great!

Not scrolling the first row is a very easy modification, however it will still be affected by the pixel scrolling. If you are going to mask the left and right edges with TL2 (tile layer 2), you can also use TL2 for the top line score and such.

 

Setting up TL2 is easy and works just like TL1. Each tile layer has its own set of table base address, i.e. Name and Color, as well as their own scroll registers:

Tile Layer 1:
VR2: NTBA
VR3: CTBA
VR27: Horz Scroll
VR28: Vert Scroll

Tile Layer 2:
VR10: NTBA
VR11: CTBA
VR25: Horz Scroll
VR26: Vert Scroll

Just set VR10 to point to VRAM for the TL2 name table. If you want to use the same colors at TL1, the TL2 CTBA can point to the same color table as TL1. Nothing stops both tile layer from pointing to the same locations in VRAM. However, for masking I suggest you set up TL2 with its own color table where the bg color is set to black (or some other color that you want) instead of transparent. Although you need at least one character color set to have a transparent bg color, otherwise you will never see TL1.

 

To enable TL2, set bit >80 in VR49. That's it, just set tiles on TL2 and they will appear on top of TL1. If patterns on TL2 have any transparent fg or bg color, TL1 will show through. To mask TL1, write tiles on TL2 that have a bg color other than transparent. If you set up a non-transparent color table for TL2, for the top row you can just duplicate what you are already writing on TL1.

 

TL2 is always on top of TL1, and by default it is also on top of sprites. However, TL2 vs sprite priority can be changed so that sprites are on top of TL2 (but you need to be using on of the enhanced color modes to use this feature).

[digress]

Does it use the same tile_pattern table? I got the name table loaded into tl2 and I can see it's the correct table. Everything is in the correct 32x24 tile positions but the tile patterns are corrupted or at least not what should be there.

 

Perhaps my f18a is not installed completely correctly.

[Omega-TI]

 

Does it use the same tile_pattern table? I got the name table loaded into tl2 and I can see it's the correct table. Everything is in the correct 32x24 tile positions but the tile patterns are corrupted or at least not what should be there.

 

Perhaps my f18a is not installed completely correctly.

 

 

What version are you running? 1.5, 1.6, 1.7 or 1.8... it might make a difference if it's an earlier version. Possibly an update might be in order.

[digress]

1.8

 

>edit>>> I'm getting there. I didn't understand the addressing. Had some normal tiles show up but still not right. I'll figure it out.

[matthew180]

Both TL1 and TL2 use the same pattern table. Only the name table, color table, and horz/vert scroll registers are unique to each tile layer. Make sure the TL2 name table is pointing to VRAM where you think it is. Suppose you have this setup:

VR2  = >00 - TL1 name table at VRAM  >0000
VR3  = >0C - TL1 color table at VRAM >0300 (768)
VR10 = >01 - TL2 name table at VRAM  >0400 (1024)
VR11 = >1C - TL2 color table at VRAM >0700 (1792)

(I like to tuck the color table in VRAM right after the name table)

 

In this example, if you write to VRAM from addresses 0..767 you are putting tiles on TL1, and writing to addresses 1024..1791 you are putting tiles on TL2.

 

 

Perhaps my f18a is not installed completely correctly.

 

The F18A either works or it does not, there is no in-between. V1.8 is the latest firmware.

[matthew180]

I'm getting there. I didn't understand the addressing. Had some normal tiles show up but still not right. I'll figure it out.

 

The registers that control the location of the various tables in VRAM are used to make up part of the 14-bit address of where the table resides. No name table has a full 14-bits to specify its location, and the more bits used for the table's base address, the more flexibility you have to locating the table. The color table is the more flexible with 8-bits of address available, but the name table only has 4-bits which make up the upper 4-bits of the 14-bit address for the table's location in VRAM. If you look in the 9918A datasheet starting on pg. 2-7 you will see tables that show the table's location in VRAM for a given value in the VR.

 

The name table is formed like this:

7  6  5  4   3  2  1  0  VR2-bits
-----------|-----------
0  0  0  0 | A  A  A  A
             |  |  |  |
             13 12 11 10   9 8 7 6 5 4 3 2 1 0  Name table address formation
             ------------|--------------------
             A  A  A  A  |   8-bit tile name

.

This means that a value of >01 in VR2 has a "weight" of >0400 or 1024, i.e. 1K. So the name table can only ever be placed in VRAM at 1K offsets:

VR2 | Address
 00 | 0000
 01 | 0400
 02 | 0800
 03 | 0C00
 04 | 1000
 05 | 1400
 06 | 1800
 07 | 1C00
 08 | 2000
 09 | 2400
 0A | 2800
 0B | 2C00
 0C | 3000
 0D | 3400
 0E | 3800
 0F | 3C00

.

VR10 has the same location restrictions as VR2.

Edited October 6, 2016 by matthew180

[digress]

almost there. The gpu code in 3F00 was not a safe spot afterall as it was overwriting part of the sprite patterns . So for a while there I had some flying gpu code that I could shoot down.

 

I got the addressing figured out now and can place it where there's opening. I moved it to 0x3700 and the tile layer 2 & tile layer name tab to 0x2800 & 0x2b00 respectively and mostly working.

 

The table is in the correct areas with blanking lines on x=0 and x=31 to cut off the redraw just the colour is still not quite right. I got black down 1/3, then green middle 3rd, then black again bottom 1/3.

 

So pretty close now.

[matthew180]

I sounds like the TL2 color is not set correctly. Character sets are in groups of eight tiles. You can create a "masking character set" by setting the fg and bg color to black, the setting tiles from that charset in the areas you want to mask. Setting the fg/ bg color the same means it does not matter how the tiles in that charset are defined, just use 1 of the 8 tiles from that set. Then pick another character set to be the visible set, and set the fg / bg colors to transparent. Or, you can overlap with the normal tiles that define the standard printable characters from 32 to 127 and use the space character.

[digress]

Doin a ECM3 sprite test, I got the 3 layer patterns working but wrong palette colours. Trying to load the custome palettes: Not sure where or how to do it. here was first attempt: Any ideas?

vdp_out(47, 0xC0);//VDP_SET_REGISTER(47, 0xC0); data port mode

for ( i = 0 ; i < 8 ; i++ )

{

//address, array, how many bytes

fill_vram (0xff00,palettes,16);

}

vdp_out(47, 0x00);//VDP_SET_REGISTER(47, 0x00); data port mode off

convert to data>>>

const byte palettes[] = {

0x00,0x00,0x09,0xF6,0x00,0xE2,0x00,0x86

,0x0C,0x55,0x0F,0x55,0x02,0xA3,0x0F,0xFF

,0x0F,0x55,0x0F,0x77,0x09,0x03,0x0E,0x00

,0x0C,0x60,0x0C,0x5B,0x00,0x00,0x0F,0xFF

,0x0C,0xEF,0x00,0x00,0x02,0xC4,0x06,0xD7

,0x05,0x5E,0x07,0x7F,0x0C,0x55,0x04,0xEE

,0x0F,0x55,0x0F,0x77,0x0C,0xB5,0x0E,0xC8

,0x02,0xA3,0x0C,0x5B,0x0C,0xCC,0x0F,0xFF

,0x0C,0xEF,0x00,0x00,0x02,0xC4,0x06,0xD7

,0x05,0x5E,0x07,0x7F,0x0C,0x55,0x04,0xEE

,0x0F,0x55,0x0F,0x77,0x0C,0xB5,0x0E,0xC8

,0x02,0xA3,0x0C,0x5B,0x0C,0xCC,0x0F,0xFF

,0x0C,0xEF,0x00,0x00,0x02,0xC4,0x06,0xD7

,0x05,0x5E,0x07,0x7F,0x0C,0x55,0x04,0xEE

,0x0F,0x55,0x0F,0x77,0x0C,0xB5,0x0E,0xC8

,0x02,0xA3,0x0C,0x5B,0x0C,0xCC,0x0F,0xFF

};

original output>>>>

****************************************

* Colorset Definitions

****************************************

PAL0 DATA >0CEF,>0000,>02C4,>06D7 ;

DATA >055E,>077F,>0C55,>04EE ;

PAL1 DATA >0F55,>0F77,>0CB5,>0EC8 ;

DATA >02A3,>0C5B,>0CCC,>0FFF ;

PAL2 DATA >0CEF,>0000,>02C4,>06D7 ;

DATA >055E,>077F,>0C55,>04EE ;

PAL3 DATA >0F55,>0F77,>0CB5,>0EC8 ;

DATA >02A3,>0C5B,>0CCC,>0FFF ;

PAL4 DATA >0CEF,>0000,>02C4,>06D7 ;

DATA >055E,>077F,>0C55,>04EE ;

PAL5 DATA >0F55,>0F77,>0CB5,>0EC8 ;

DATA >02A3,>0C5B,>0CCC,>0FFF ;

PAL6 DATA >0CEF,>0000,>02C4,>06D7 ;

DATA >055E,>077F,>0C55,>04EE ;

PAL7 DATA >0F55,>0F77,>0CB5,>0EC8 ;

DATA >02A3,>0C5B,>0CCC,>0FFF

[Tursi]

You're close on the palette...

 

First, set register 47 (decimal) to 0xc0 - this specifies DPM=1, Auto increment = 1, and palette register 0

Then you need to just write directly to the data port, without setting any VDP address (register 47 has overridden the destination). Write your palette data as you are, but you need a function or a loop that writes without setting an address first. (You could just out directly).

Finally, set register 47 (decimal) to 0x00 to turn off DPM and restore normal operation. (If you wrote all 64 palette registers, it will turn off automatically). DPM also turns off automatically if you access the status register, so as always, inhibit interrupts.

 

I don't have the library code handy, but make sure that vdp_out permits registers greater than 7 without masking (and that it actually sets registers). Then I'd just replace the fill_vram with my own loop that writes to the VDP data port. Something like this would work (based on my lib):

// Write Address/Register
volatile __sfr __at 0xbf VDPWA;
// Write Data
volatile __sfr __at 0xbe VDPWD;

inline void VDP_SAFE_DELAY() { 
__asm
nop
nop
nop
nop
nop
__endasm;
}

inline void VDP_SET_ADDRESS(unsigned int x) { VDPWA=((x)&0xff); VDPWA=((x)>>; VDP_SAFE_DELAY(); }

---------------------------
 
void load_palette(const byte *pal, unsigned char count) {
  unsigned char i;
 
  VDP_SET_ADDRESS(0xafc0);  // dpm, auto-inc=1, palette 0
  for (i=0; i<count; i++) {
    VDPWD = pal[i*2];
    VDPWD = pal[i*2+1];  // two bytes per palette entry
  }
  VDP_SET_ADDRESS(0xaf00); // dpm off
}
 
(... in the appropriate spot...)
 
load_palette(palettes, 64);

The set address macros are handling the register set, I pre-built the bit masking. The most significant byte has bit 0x80 set to indicate a register set, and the six least significant bits are which register. (47 = 0x2f, 0x2f+0x80 = 0xaf). the least significant byte is the data to set the register to.

(edit: sorry, several passes at getting the code right )

Edited October 11, 2016 by Tursi

[digress]

That worked. cool!

 

but now I have even more questions!

 

It affected my tiles. I wasn't expecting that. They're all weird colours. does that mean I have to use these 8 palettes for all my tiles?

 

 

 

You're close on the palette...

 

First, set register 47 (decimal) to 0xc0 - this specifies DPM=1, Auto increment = 1, and palette register 0

Then you need to just write directly to the data port, without setting any VDP address (register 47 has overridden the destination). Write your palette data as you are, but you need a function or a loop that writes without setting an address first. (You could just out directly).

Finally, set register 47 (decimal) to 0x00 to turn off DPM and restore normal operation. (If you wrote all 64 palette registers, it will turn off automatically). DPM also turns off automatically if you access the status register, so as always, inhibit interrupts.

 

I don't have the library code handy, but make sure that vdp_out permits registers greater than 7 without masking (and that it actually sets registers). Then I'd just replace the fill_vram with my own loop that writes to the VDP data port. Something like this would work (based on my lib):

// Write Address/Register
volatile __sfr __at 0xbf VDPWA;
// Write Data
volatile __sfr __at 0xbe VDPWD;

inline void VDP_SAFE_DELAY() { 
__asm
nop
nop
nop
nop
nop
__endasm;
}

inline void VDP_SET_ADDRESS(unsigned int x) { VDPWA=((x)&0xff); VDPWA=((x)>>; VDP_SAFE_DELAY(); }

---------------------------
 
void load_palette(const byte *pal, unsigned char count) {
  unsigned char i;
 
  VDP_SET_ADDRESS(0xafc0);  // dpm, auto-inc=1, palette 0
  for (i=0; i<count; i++) {
    VDPWD = pal[i*2];
    VDPWD = pal[i*2+1];  // two bytes per palette entry
  }
  VDP_SET_ADDRESS(0xaf00); // dpm off
}
 
(... in the appropriate spot...)
 
load_palette(palettes, 64);

The set address macros are handling the register set, I pre-built the bit masking. The most significant byte has bit 0x80 set to indicate a register set, and the six least significant bits are which register. (47 = 0x2f, 0x2f+0x80 = 0xaf). the least significant byte is the data to set the register to.

(edit: sorry, several passes at getting the code right )

 

[matthew180]

There are 64 palette registers (PR0..PR63). Depending on how many bits of color you are using, it will affect how those 64 registers are grouped. To select one of the PRs you need 6-bits total, and those bits come from multiple places depending on the ECM you are using (tiles and sprites are separate, but still reference the same 64 PRs).

In ECM3, you have 3-bits to specify the color of a single pixel, so you have 8 possible values: 0..7. Thus, in ECM3 you have 8 palette-groups of 8 colors in each group. The 3-bits from the pattern decide the color in a group, and 3-bits from the sprite attribute table decide the group itself:

In ECM, each sprite attribute byte has extra values:

  7      6       5      4       3   2   1   0
ECLK | FLIPX | FLIPY | SIZE  | PS0 PS1 PS2 PS3
                                |   |   |
                                |   |   |
                                5   4   3   2   1   0
                               PS0 PS1 PS2 PT3 PT2 PT1 -> 6-bits that select the final pixel color

Pattern Tables make up the bit "planes".

1 : 0 0 0 0 1 0 1 - a byte from pattern plane 1, LSbit of color
    |
2 : 0 0 0 0 0 0 0 - a byte from pattern plane 2
    |
3 : 1 0 0 1 1 0 1 - a byte from pattern plane 3, MSbit of color
    |
   PT3 PT2 PT1
    1   0   0

.
There are also two bits that can come from VR24 that contribute extra bits depending the ECM. There are bits for sprites and each of the tile layers:

        7  6     5    4      3     2       1     0
VR24: | 0  0 | SPS0 SPS1 | T2PS0 T2PS1 | T1PS0 T1PS1 |

.
So the 6-bits to select a palette register for sprites, for each ECM are selected like this:

ps  = palette select from VR24
cs  = color value from sprite attribute
px0 = pixel from byte from pattern table 0 (original mode and EMC1)
px1 = pixel from byte from pattern table 1 (ECM2)
px2 = pixel from byte from pattern table 2 (ECM3)

original: ps0 ps1 cs0 cs1 cs2 cs3
ECM1    : ps0 cs0 cs1 cs2 cs3 px0
ECM2    : cs0 cs1 cs2 cs3 px1 px0
ECM3    : cs0 cs1 cs2 px2 px1 px0

.
For tiles it is similar, except 4-bits of color come from the color table (sprites get 4-bits from the sprite attribute table). In ECM1..3 the color table expands to 256 bytes, so each tile can have its own enhanced attributes:

Normal color table:
  7   6   5   4     3   2   1   0
 FG0 FG1 FG2 FG3 | BG0 BG1 BG2 BG3

ECM1..3, color table attribute byte per tile (256 bytes)
  7      6       5       4      3   2   1   0
 PRI | FLIPX | FLIPY | TRANS | PS0 PS1 PS2 PS3

ps  = palette select from VR24
cs  = color value from color table (256 bytes for ECM1..3)
px0 = pixel from byte from pattern table 0 (original mode and EMC1)
px1 = pixel from byte from pattern table 1 (ECM2)
px2 = pixel from byte from pattern table 2 (ECM3)

original: ps0 ps1 cs0 cs1 cs2 cs3
ECM1    : ps0 cs0 cs1 cs2 cs3 px0
ECM2    : cs0 cs1 cs2 cs3 px1 px0
ECM3    : cs0 cs1 cs2 px2 px1 px0

.
In summary, the grouping and color selection of the 64 PRs can be described like this (the 4-bits of "attribute" come from either the color table or sprite attribute table depending on if you are considering tiles or sprites):

 

Normal (original) color: 4 groups of 16 colors each: 2-bits from VR24 select 1-of-4 groups. Tile color table or sprite attribute table provides 4-bits of foreground and 4-bits of background to select 1-of-16 colors within the group. 1-bit from pattern selects between FG or BG bits to use to select the color from the group, or for sprites 1-bit provides a visible pixel or transparent.

 

ECM1: 32 groups of 2 colors each: 1-bit from VR24 + 4-bits from tile/sprite attribute select 1-of-32 groups. 1-bit from pattern selects color0..1 from the group.

 

ECM2: 16 groups of 4 colors each: 4-bits from tile/sprite attribute select 1-of-16 groups. 2-bits from pattern selects color0..3 from the group.

 

ECM3: 8 groups of 8 colors each: 3-bits from tile/sprite attribute select 1-of-8 groups. 3-bits from pattern selects color0..7 from the group.

 

Edited October 11, 2016 by matthew180

[digress]

I got it. I shouldn've touched the initial palettes and restored them and used further down palettes for the sprites instead. You can see the resulting ecm3 sprites over here if you want.

 

http://atariage.com/forums/topic/257913-f18a-enhanced-sprites-on-colecovision/

[digress]

I got the tile layer 2 to work. However I had to triplicate the colour table to do so 2Kb + 2Kb + 2kb = 6kb for 1/3 +1/3 +1/3 of the screen so.

 

This is just using standard tile patterns from the default colecovision colour mode. Is this necessary?

 

The tile layer 1 only needed the pattern table (which is triplicated too) 0x00 +0x800 & 0x1000. so 6KB again.

 

At least it only needed the 1 colour table of 2KB.

 

I'm sure I'm doing this wrong.

 

Can't I just reused the same pattern & the same colour once for the whole screen? What I want is :

 

0x00-0x7fff the tile patterns = 2kb (why does this need to be tripled? down to 0x17ff)

0x1800 the tile 1 table

0x1c00 the hidden tile table for getting the scroll data from

0x2000-0x27FF the colour table for tile layer 1

 

0x2800 the tile 2 llayer table

0x3800-0x3fff the sprites table 1 colour

 

Is there more memory available above 3FFF?

 

what's happening right now is

6kb for the tile patterns (2kb tripled)

768kb for tile layer1

90kb for the gpu code

768kb for tile layer (hidden) (0x1c00) (this layer is pletter compressed and needed to be expanded into the hidden area before I can grab sections of it to redraw at the screen edge)

6kb for the colour table(tripled 2kb)

2kb for sprte patterns

 

15962bytes out of 16384 bytes so I don't have enough for another name table or additiional sprite colour layers.

 

I am reworking the graphics for ecm3 so that will probably fit and look better anyways.

[matthew180]

I got the tile layer 2 to work. However I had to triplicate the colour table to do so 2Kb + 2Kb + 2kb = 6kb for 1/3 +1/3 +1/3 of the screen so.

Are you talking about the *color* table or the *pattern* table? The color table is never 2K in GM1, it is either 32-bytes for original color, and 256-bytes for ECM1..3. Are you using GM1? While they will work in other modes, the scrolling and ECM1..3 enhancements were really designed for GM1.

 

This is just using standard tile patterns from the default colecovision colour mode. Is this necessary?

Not for normal GM1.

 

The tile layer 1 only needed the pattern table (which is triplicated too) 0x00 +0x800 & 0x1000. so 6KB again.

Again, unless you are trying to implement GM2, or "half-bitmap", I don't know why you are making triple tables. You *would* need this for ECM3 though. One pattern table for EMC1, two pattern tables for ECM2, and thee pattern tables for ECM3. But the *color* table is always 256-bytes.

 

At least it only needed the 1 colour table of 2KB.

 

I'm sure I'm doing this wrong.

I'm not sure either, I'm confused.

 

Can't I just reused the same pattern & the same colour once for the whole screen?

Yes, you can use the same color and pattern tables for both TL1 and TL2, however, I recommend you use a color table (256 bytes) for each tile layer.

 

What I want is :

 

0x00-0x7fff the tile patterns = 2kb (why does this need to be tripled? down to 0x17ff)

I think you meant 0x07FF. Tile patterns only require 2K unless you are using ECM2 or EMC3, as described above.

 

0x1800 the tile 1 table

0x1c00 the hidden tile table for getting the scroll data from

0x2000-0x27FF the colour table for tile layer 1

The color table is only 32-bytes for original color, and 256-bytes (one byte per tile) in ECM1..3.

 

0x2800 the tile 2 llayer table

0x3800-0x3fff the sprites table 1 colour

 

Is there more memory available above 3FFF?

No, there is no VRAM over >3FFF. The GPU has an additional 2K of RAM available for program or data storage, but it is *only* available via the GPU.

 

what's happening right now is

6kb for the tile patterns (2kb tripled)

768kb for tile layer1

90kb for the gpu code

768kb for tile layer (hidden) (0x1c00) (this layer is pletter compressed and needed to be expanded into the hidden area before I can grab sections of it to redraw at the screen edge)

6kb for the colour table(tripled 2kb)

2kb for sprte patterns

 

15962bytes out of 16384 bytes so I don't have enough for another name table or additiional sprite colour layers.

 

I am reworking the graphics for ecm3 so that will probably fit and look better anyways.

Ok, assuming GM1 and ECM3 for tiles and sprites, you need:

 

256 bytes for TL1 color/attribute table

 

256 bytes for TL2 color/attribute table

 

768 bytes for name table 1

 

768 bytes for name table 2

 

6K for all 256 tile patterns

 

6K for all 256 sprite patterns

 

128 bytes for sprite attribute table

 

Now, for the tile and sprite patterns you have some options. If you use the same patterns for tiles and sprites, then the tile and sprite pattern tables can be the same, i.e. you only need 6K total. Also, if you don't use the full 256 patterns for tiles or sprites, then you don't need the full 2K tables. In this case (you need fewer than all 256 unique tiles) the F18A offers the ability to modify the distance between the bytes that make up the additional color "planes", so the total memory needed for the ECM2 and ECM3 pattern tables is reduced.

 

Of all the tables, the color tables have the most flexibility for where they are located in memory, followed by the sprite attribute table, then the tile name tables, followed by the tile and sprite pattern tables:

 

Color tables: located on any 64-byte boundary, 256 possible locations in VRAM.

Sprite attribute table: located on any 128-byte boundary, 128 possible locations in VRAM.

Name tables: located on any 1024-byte boundary, 16 possible locations in VRAM.

Pattern tables: located on any 2048-byte boundary, 8 possible locations in VRAM.

 

If you are going to have ECM3 for both tiles and sprites, and use all 256 patterns, then you will chew up 12K for patterns alone. You can overlap them if you are sharing patterns between tiles and sprites. I like to put the patterns at the end of VRAM, but you have patterns first, so this is one way to set everything up (remember, in ECM1..3 the pattern *is* the color):

>0000 .. >07FF - tile patterns, ECM3 bit plane 0 (LSbit)
>0800 .. >0FFF - tile patterns, ECM3 bit plane 1
>1000 .. >17FF - tile patterns, ECM3 bit plane 2 (MSbit)

>1800 .. >1FFF - sprite patterns, ECM3 bit plane 0 (LSbit)
>2000 .. >27FF - sprite patterns, ECM3 bit plane 1
>2800 .. >2FFF - sprite patterns, ECM3 bit plane 2 (MSbit)

>3000 .. >32FF - name table 1 (768 bytes, 1K boundary)
>3300 .. >33FF - color/attribute table 1 (256 bytes, 1 attribute byte per tile)

>3400 .. >36FF - name table 2 (768 bytes, 1K boundary)
>3700 .. >37FF - color/attribute table 2 (256 bytes, 1 attribute byte per tile)

>3800 .. >387F - sprite attribute table (128 bytes, 4 bytes per sprite)

>3880 .. >3FFF - 1920 bytes free space for GPU code, staging, etc.

.

I like to tuck the color tables right up at the end of the name table since it uses the full 1K without wasting any VRAM.

 

If you want to use the 2K of GPU-RAM for the GPU code, then you need a two-stage process to get the code into the GPU-RAM:

 

1. Load a GPU copy routine into VRAM, as well as the GPU utility code you want loaded into GPU-RAM.

2. Execute the GPU copy routine to move the utility code to the GPU-RAM.

 

Once the utility code is in GPU-RAM, the copy routine and utility code in VRAM can be overwritten since they are no longer used. The GPU-RAM is addressable by the GPU as memory from >4000 to >47FF (2K).

Edited October 14, 2016 by matthew180

[digress]

thanks very much. This is the info i needed. Apparently I've been using bitmap mode all along. The reason I didn't realize is because the screen was automatically copying the tiles three times over in the coleco library initialialzation where as if I was displaying a full screen bitmap i had to have 3 tables , 1 for each 1/3 of the screen.

 

So that could be very useful info for a coleco only project if I'm looking for more vram.

 

>>(remember, in ECM1..3 the pattern *is* the color)

 

This is what i needed.

 

so I'm most likely just going to go ecm3 for tiles & patterns or dial it back if I can't quite fit. I'll figure it out today.

 

 

Are you talking about the *color* table or the *pattern* table? The color table is never 2K in GM1, it is either 32-bytes for original color, and 256-bytes for ECM1..3. Are you using GM1? While they will work in other modes, the scrolling and ECM1..3 enhancements were really designed for GM1.

Not for normal GM1.

[Asmusr]

Just for information, what does the F18A do if you enable ECM in bitmap mode (mode 2)? Will the ECM setting be ignored or will it result in some weird hybrid mode?

[matthew180]

When I said:

 

"remember, in ECM1..3 the pattern *is* the color"

 

Let me clarify that a little, since it is not correct in the sense that the patterns define the color like modern systems actually do using 16, 24, or 32-bit color values per pixel. Since on these older systems we have limited memory, we can't code the actual color value of the pixel in the patterns (that would take too much memory), so we use indexes and palettes. In ECM1..3 the bits from the pattern are used to form the index into the palette. So, for example, in ECM3 the 3-bits of pattern data form a color selection of 0..7 in the palette group defined for the tile (which comes from the tile's attribute byte).

 

This is actually the same as the original color mode (OCM or ECM0) of the 9918A, the '0' or '1' bit in the pattern byte selects either the background or foreground color. However, with a single bit (two possible colors), you tend to look at the bits in the patterns as the actual bitmap pixel, and indeed they are an actual bitmap. But, in ECM2..3 the patterns are no longer a bitmap, they are used to form the index of the color to use. So in this sense the bits form a color "index" or "value", but using the term "color value" is what might lead to confusion, since it is not the actual result color. The final 12-bit RGB "color value" comes from the palette register indexed by the pattern bits.

 

Hopefully that makes my previous statement a little more clear.

[matthew180]

Just for information, what does the F18A do if you enable ECM in bitmap mode (mode 2)? Will the ECM setting be ignored or will it result in some weird hybrid mode?

 

It will do what GM2 normally does I suppose, but there will probably certainly be some side effects. When I was implementing ECM1..3, scrolling, and TL2, I was focused on making it work for GM1 without any regard as to what might happen in the other modes. I don't try to detect or restrict ECM1..3 in any other mode, so you can set it up and you might get something usable. However, I do not recommend relying on any functionality that might currently result in enabling ECM1..3 in any modes other than GM1, or where specifically documented.

 

Scrolling is supported in the text modes, T40 and T80, but only for a single column, i.e. the multiple name tables won't work correctly in the text modes. TL2 should work normally in the text modes though, as well as the documented enhanced colors, tile attributes, sprites, and the BML.

[digress]

how does one set GM1 and be sure that it's currently set.

 

I've got the ecm3 sprites working. The tiles & all the memory setup to ecm3 tiles. But's only displaying them in the first plane of colour

 

should look like this

vdp_out(0,0);

vdp_out(1,0xe0); //mode 2

// vdp_out(0,0);

// vdp_out(1,8 ) ; //mode 2

// vdp_out(0,0); // gm1 //VDP_SET_REGISTER( 0, 0x00);

// vdp_out(1,0); // gm1 //VDP_SET_REGISTER( 1, 0x00);

vdp_out(2,0x06); // set name table to 0x1800

vdp_out(3,0x80); // set colour table to 0x2000

vdp_out(4,0); // set tiles table to 0x0000

vdp_out(5,54); // 0x1b00 temp dem 54 = 6912 sprites ecm 3 sprites data to 0x2800 = 10K 5*2K

vdp_out(6,5); // sprites ecm 3 sprites data to 0x2800 = 10K 5*2K

vdp_out(7,0x40); //VDP_SET_REGISTER( 7, 0x00); // Black border

vdp_out(49,0x33); // tiles ecm3/sprites ecm 3

[Asmusr]

 

how does one set GM1 and be sure that it's currently set.

 

I've got the ecm3 sprites working. The tiles & all the memory setup to ecm3 tiles. But's only displaying them in the first plane of colour

 

I can't see anything wrong with your register values. Do you see multicolor sprites with this configuration?

[digress]

I do have 3 bit 8 colour sprites. The funny thing is for 1 frame the colour looks right during init then goes to mud that you see. don't mind the 8x8 sprite at the start i was switching video modes on the fly to see if I could get it to work.

 

it goes by real quick but here is the still:

 

https://www.youtube.com/watch?v=HNekiNWRM0c&feature=youtu.be

here is the ecm3 sprites working with the regular coleco tiles. so you can see what it should look like more or less. I have upgraded the colours a bit.

https://www.youtube.com/watch?v=0VCXbFpiaHY

so if it looks like i'm in the correct video mode then it's something else i'm doing wrong. it shows up correct for that 1 instant and that is the 3 layer ecm3 coloured tiles too.

 

 

 

 

 

I can't see anything wrong with your register values. Do you see multicolor sprites with this configuration?

[Asmusr]

Hmm, are you writing to register 49 again, for instance to enable tile layer 2?

[digress]

nope, I tested that as well. I put the tile layer 2 on off to a button so I could turn it on and off to confirm.

 

I tried rearrangeing the video layers and got to see the different layers were working but never more than 1 at a time.

 

I'll try messing with the palette next.

 

What I was wondering is there a setting that tells in to keep going beyond the first 2 kb of tile data into the 4kb & 6kb. It seems like it stops at the first 2kb.

Hmm, are you writing to register 49 again, for instance to enable tile layer 2?