F18A MK2

[Asmusr]

19 hours ago, matthew180 said:

I'm trying to think if this would need to stay compatible with the 12-bit palette for any reason (i.e. with the original F18A).  Since the MK2 has a digital output at 8bpp, even the 12bpp palette has to be scaled.  So, 8bpp as the typical RRRGGGBB, and scale each color component to an 8-bit red, green, and blue value, respectively?

Wouldn't it be possible to extend the F18A palette from 64 to 256 colors? If not then a fixed palette would also be fine. It would be compatible with V9938 mode 7.

If any of this is implemented, would it be as an extension of the F18A bitmap layer with an optional transparent index 0?

[Tursi]

On 9/15/2019 at 10:37 AM, wierd_w said:

1) Do not overwrite transparent color

2) DO overwrite transparent/background color

3) Hmirror char on placement

4) Vmirror char on placement

There's always more that we can ask for, but just for interest's sake, most of that already exists in the F18A. You can set up a dual-tile layer with attributes that give you mirroring per character plus the overlay, and the palette of the F18A is already 64 user-definable colors. If you're willing to work with character restrictions anyway, that's pretty good. That said, you are going to need to learn some code to use any of these features - existing or future - since there's no other interface built for them.

 

[matthew180]

1 hour ago, Asmusr said:

Wouldn't it be possible to extend the F18A palette from 64 to 256 colors? If not then a fixed palette would also be fine. It would be compatible with V9938 mode 7.

If any of this is implemented, would it be as an extension of the F18A bitmap layer with an optional transparent index 0?

The 9938 only has sixteen 9-bit palette registers.  Mode 7 does not use the palette either, from the manual:

 

"The color palette is set as shown in the table when a RESET is done. This table has no meaning in G7 mode since the color palette is not used."

 

The pattern table becomes the pixel color, with 1-byte per pixel.   The color is also specified as GGGRRRBB, which makes me sad since it will just make confusion with the normal RGB order used everywhere else these days.

 

If I expand the MK2 palette to 256 entries, there would be two more bits to deal with for all the other modes.  I'm not sure where those would be set.

 

I don't know if this would change the existing BML or just be something separate.  I'll have to see how the scan-line timing works out.

[Asmusr]

Another idea would be to make it a 64 color BML instead, and use the remaining two bits in the byte to set the degree of transparency (0, 25, 50, or 100%). That could generate some cool lighting effects.

[matthew180]

I have thought about that.  So 2-bits of alpha and 6-bits of palette?  Is that acceptable?  Keep in mind the palette would have to be shared with any tile layers and sprites.

76 543210
AA|PPPPPP

Alpha blending would have to come at pixel scan-out time though, which may complicate matters.  I'll have to think about it a little.  Also, alpha-blending might be *cool*, but is it as useful as having a full 256-color bitmap?  I'm not a big fan of effects at the expense of usefulness.

 

Palette expansion might be a possible option, but working out how to make it usable to the other parts of the VDP other than just the bitmap would take some thinking and effort.

[wierd_w]

16 minutes ago, matthew180 said:

I have thought about that.  So 2-bits of alpha and 6-bits of palette?  Is that acceptable?  Keep in mind the palette would have to be shared with any tile layers and sprites.

76 543210
AA|PPPPPP

Alpha blending would have to come at pixel scan-out time though, which may complicate matters.  I'll have to think about it a little.  Also, alpha-blending might be *cool*, but is it as useful as having a full 256-color bitmap?  I'm not a big fan of effects at the expense of usefulness.

 

Palette expansion might be a possible option, but working out how to make it usable to the other parts of the VDP other than just the bitmap would take some thinking and effort.

Used right, it could be very useful.  If you are updating lots of pixels, that is going to slow a lot of things down. Its faster to poke at some registers and get similar results. This kind of thing was done to do palette effects on VGA cards in the DOS days. Fade to Black, Fade-in, etc-- can be used creatively to cover up slowly drawn areas.  It can add a lot of polish.  

 

One such condition: Simple drop shadow under a sprite.  By making it 25% black, the layer underneath shows through. To do the same effect, you would have to be pushing many more pixels to dynamically update the drop shadow. Having to dynamically update the screen like that just for a sprite to move 1 pixel, is what really put me off from qbasic's graphics routines. Sure, it has a fully addressable 256 color mode with fully definable colors, but no easy way to handle sprites as distinct from the background; You end up blasting so much data in and out of the framebuffer that the whole thing comes to a crawl. TI basic gives you that for free, just with fewer colors and more restrictions in other areas.

 

As regards the color palette density-- I can do a whole lot with 64 colors, if I get to choose what those colors are. Most of my images only need 8 to 20 colors. The headache comes with pre-defined indexed colors that were picked for their mathematics, not their optical perception.  (THAT is when you end up with situations where "I dont have enough greens!" and pals. When you dont need 2 colors of cyan, 2 colors of pink, etc.. and you can redefine the palette entry to get those extra two shades of green you really need-- it makes all the difference in the world.  You just have to plan what your global color space for the full image is going to be in advance to know what ones you can reassign)

Edited September 16, 2019 by wierd_w

[Tursi]

I don't think a 256 color mode is that useful. I know we have practically infinite ROM but by any other loading mechanism it still takes time to get the data into the VDP.

 

Also Weird_W, you have to remember that features added to the bitmap layers don't automatically become sprite features, those are handled by different circuitry.

 

The palette is definable - I added a mode to my Convert9918 program that changes the palette every scanline to give over 2000 colors onscreen with zero CPU cost (so, 15 colors per scanline - all the work is done on the GPU). I intended it for backdrops - there's enough VDP RAM left on the stock 9918 (barely) for a sprite table, and 2 of the four palettes are untouched and can be used for sprites.

 

 

(Attached file can be viewed on hardware with my slideshow program - you can also see a sample video by Omega here:

 

But of course, that's the extreme and runs in bitmap mode. A program doesn't do as good a job with tile-based pixel art, for that we need artists like you.  

 

TursiHawaii.zip

[Asmusr]

8 hours ago, matthew180 said:

I have thought about that.  So 2-bits of alpha and 6-bits of palette?  Is that acceptable?  Keep in mind the palette would have to be shared with any tile layers and sprites.

76 543210
AA|PPPPPP

 

Yes I think that would be great. But maybe we should park the idea until we know more about how the memory management is going to work? Knowing that will help to inform the decision.

[Tighe]

On 9/8/2019 at 11:24 PM, OLD CS1 said:

Woah!  I never knew Baby Pac-Man uses a 9928!

Yeah, the one in my game was bad and I "borrowed" a replacement from a Colecovision I had to get mine working.

https://forums.arcade-museum.com/showthread.php?t=380222

 

 

Edited September 17, 2019 by Tighe

[+FarmerPotato]

On 9/16/2019 at 4:03 PM, wierd_w said:

 

As regards the color palette density-- I can do a whole lot with 64 colors, if I get to choose what those colors are. Most of my images only need 8 to 20 colors. The headache comes with pre-defined indexed colors that were picked for their mathematics, not their optical perception.  (THAT is when you end up with situations where "I dont have enough greens!" and pals. When you dont need 2 colors of cyan, 2 colors of pink, etc.. and you can redefine the palette entry to get those extra two shades of green you really need-- it makes all the difference in the world.  You just have to plan what your global color space for the full image is going to be in advance to know what ones you can reassign)

 

I've been imagining what Tursi's HAM could do on a tile based screen (not bitmap. Perhaps EC2). If the palette changed for every line, you still don't get "enough greens" on every row, but maybe every other row. Would this be sufficient to create awesome textures for a game tileset? Like granite, metal with specular highlights, green monster parts... the goodies of early 90s VGA games.

 

If the screen were divided into horizontal zones, that would open up possibilities, but my imagination is going in the direction of a platformer that scrolls in horizontal and vertical.

[wierd_w]

3 hours ago, FarmerPotato said:

 

I've been imagining what Tursi's HAM could do on a tile based screen (not bitmap. Perhaps EC2). If the palette changed for every line, you still don't get "enough greens" on every row, but maybe every other row. Would this be sufficient to create awesome textures for a game tileset? Like granite, metal with specular highlights, green monster parts... the goodies of early 90s VGA games.

 

If the screen were divided into horizontal zones, that would open up possibilities, but my imagination is going in the direction of a platformer that scrolls in horizontal and vertical.

There was an interesting vga dither routine that was used in wizardry 7 (msdos). It was used to generate the larger inventory screen portraits, from the smaller in-game thumbnails.  Literally, the large portraits are produced from the smaller ones. (I think they were 16x16 pixels for source image, and nearly 64x64 for final image. ) it was pretry complicated, but it judged what new pixels and patterns to add, based on its neighbors.  I remember this because I spenthink ages looking for the higher resolution portrait data in the games files, but could only find the thumbnails.  

 

Something similar in concept could be used to tile-ize a smaller bitmap, that obeys the row-by-row color attribute restrictions, and uses less program memory.  At least for backgrounds.  They would be dithered, but it could be neat to look at and unique.

 

Here's some images to help you understand.

 

This is the normal play screen.  See the character portrait for bolor.

 

Now, look at the inventory screen for that character.

 

 

The second image is generated from the first one, by the dithering routine.

 

We could do something similar, grabbing 4x4 areas in the source, and expounding them into 8x8 areas that obey Ti color conventions. 

 

This specific ditherer came to mind,  because if you look closely at the large portrait, you will see the local palette is different every other line. The dither routine selects colors that are appropriate, based on the source pixels, but with a different palette.

 

Designing images for such a routine is challenging, but not impossible. 

Edited September 18, 2019 by wierd_w

[Tursi]

4 hours ago, FarmerPotato said:

 

I've been imagining what Tursi's HAM could do on a tile based screen (not bitmap. Perhaps EC2). If the palette changed for every line, you still don't get "enough greens" on every row, but maybe every other row. Would this be sufficient to create awesome textures for a game tileset? Like granite, metal with specular highlights, green monster parts... the goodies of early 90s VGA games.

 

If the screen were divided into horizontal zones, that would open up possibilities, but my imagination is going in the direction of a platformer that scrolls in horizontal and vertical.

The GPU is fast enough to change a color register roughly every 8-9 pixels, although timing it gets tricky (it's easier than when I tested it since h-interrupts exist now). So you can do mid-scanline palette color changes - the main trick is coming up with enough RAM.  MK2 may open some of those tricks up as well.

 

 

[matthew180]

On 9/16/2019 at 2:03 PM, wierd_w said:

I can do a whole lot with 64 colors, if I get to choose what those colors are.

The F18A has 64 12-bit fully programmable palette registers.

 

6 hours ago, FarmerPotato said:

I've been imagining what Tursi's HAM could do on a tile based screen (not bitmap. Perhaps EC2). If the palette changed for every line, you still don't get "enough greens" on every row, but maybe every other row. Would this be sufficient to create awesome textures for a game tileset? Like granite, metal with specular highlights, green monster parts... the goodies of early 90s VGA games.

(the following is not a rant or a complaint, just thoughts as I read the various posts about possible features, etc.)

 

The F18A and MK2 features are kept to the era of the machines they are going into.  More simultaneous on-screen colors mean more bits per pixel, which means pushing more data, storing more data, etc.  There comes a point where what you can do, and what you should do, deviate and the features no longer align with the host computer.  I *could* very easily just provide a full 24-bit or 32-bit per pixel, 640x480 frame buffer, but the 99/4A (or other systems that used the 9918A family VDP) could never hope to manage such a display.

 

There are also no less than 10-billion options and arrangements of the various possibilities, and keeping the requirements and capabilities sensible is very important.

 

I have discussions with Tursi about this often, and I feel like I'm always running in a circle, since no matter what features the F18A has, someone is looking to find ways to get more out of it.  Maybe that is just human nature?  I'm ok with that, and watching the discussions can be interesting, but my goal would be to provide the features people want without having to resort to tricks; and just let everyone get on with making the cool programs they are trying to do in the first place.

 

For example, everyone always wanted pixel scrolling on the 9918A, and it was achieved in various ways.  But it is so CPU intensive that it does not leave much CPU to run the rest of a game.  The feature is cool, but at the expense of not being able to do much more.  The F18A provides a hardware feature to solve that with a single VDP register update, although it is rarely used.

 

For the color capability, I would like to create a solution that provides the features people are trying to achieve, so everyone can focus on using those features to make software, instead of making feature demos.

 

[wierd_w]

[Already does assignable 64 color mode]

Sounds like I need to order an F18A then... 

 

Right now I just have a stock unit. 

[+9640News]

I would be happy if the F18A could support all 9938 or potentially 9958 capabilities.

 

Beery

 

[+FarmerPotato]

10 hours ago, matthew180 said:

The F18A has 64 12-bit fully programmable palette registers.

 

(the following is not a rant or a complaint, just thoughts as I read the various posts about possible features, etc.)

 

The F18A and MK2 features are kept to the era of the machines they are going into.  More simultaneous on-screen colors mean more bits per pixel, which means pushing more data, storing more data, etc.  There comes a point where what you can do, and what you should do, deviate and the features no longer align with the host computer.  I *could* very easily just provide a full 24-bit or 32-bit per pixel, 640x480 frame buffer, but the 99/4A (or other systems that used the 9918A family VDP) could never hope to manage such a display.

 

I hear you. My post was trying to get at how to make pretty pixel art on the F18A as it is. Combined with scrolling registers.

 

I studied the ECM3 mode. I will explore choosing 8 colors to build a tile out of. As I understand it, the 64 palette registers will make 8 different 8-color palettes. In ECM3, there are 3 bits per pixel of a tile, and the 3 attribute bits per tile select which 8-color palette the tile uses.

 

In the 9918 color group scheme, each 8 tiles in 32 color groups are assigned a FG and BG color. ECM modes end up kind of like color groups but any tile can pick its group? 

 

Suppose ECM3 mode. The palette is 8 groups (3 tile attribute bits) of 8 colors (3 bits of pattern data.)

(I'm not using Color0=Transparent attribute.)

Imagine filling the 8 8-color palettes like so for a game:

0 Text. Black, Red, Orange, Yellow, Green, Blue, Magenta, White.
1 Rocks. Black, Grey1, Grey2, Brown, Copper, Gold, Purple, White.
2 Lava. Black, Red1, Red2, Orange1, Orange2, Yellow1, Yellow2, White. 
3 Metal. Black, Grey1, Grey2, Grey3, Bley, Blue1, Blue2, White. 
4 Ice. Black, Grey1, Grey2, Blue1, Blue2, Blue3, Cyan, White
5 Organic. Black, Green1, Green2, Green3, Yellow, Red1, Brown, White.
6 Metal with lights. Black, Grey1, Grey2, Blue1, Cyan, Red, Yellow, White. 
7 Blood. Black, Purple1, Purple2, Purple3, Red1, Red2, Grey, White

Each tile would be designed using one 8-color palette.

I just made these up without much thought about optimizing.

Here's what I think I did there:

0 Primary colors
1 Metallic
2 Warm colors
3 Cool blues and greys
4 Pretty much 3 with less saturation?
5 Greens plus brownish
6 Greys plus primary colors
7 Purples and reds

 

 

[Asmusr]

I think no matter what hardware you design, not matter which features you provide, chances are that only a handful developers will ever use it for anything. I hope that's enough to make it worthwhile, but if not that's understandable.

 

[Omega-TI]

13 minutes ago, Asmusr said:

I think no matter what hardware you design, not matter which features you provide, chances are that only a handful developers will ever use it for anything. I hope that's enough to make it worthwhile, but if not that's understandable.

Sad, but probably true.  I'm of the school that if you are going to make something NEW that gives one NEW capabilities, why artificially limit it's capabilities?  To me, I agree with him, it's human nature to always want more, and in the computer world more has always been the holy grail.  Take it to the bleeding edge of the console capabilities! ?  Now in reality, I'll be dang happy to get whatever he comes up with, because knowing him, it'll be a good rock-solid product that has good capabilities.  

[Tursi]

I think you have more than enough features already.

 

The point of my scanline palette trick /was/ the trick. I don't want a true-color 12-bit graphics mode. I wanted to see what I could do in 16 colors, now that I finally had scanline detection and palettes. I'd always been jealous of other machines that had that ability.

 

To Omega, I'd argue that it's not an "artificial" limitation. You're still in the same host computer. What's the good of a 24-bit color mode? People will look at it two or three times, say "that's impressive", ask when it will be in the emulators, and never use it again. Features take time to implement and to test, and then to retest to make sure they didn't break anything else. What's in the F18A right now is roughly between the 8-bit and 16-bit console era, with better capabilities than the NES and approaching the power of the Genesis. It has barely been tapped. Rasmus has done a few demonstrations/games on the TI and Digress has released a couple of games with F18A graphics modes for the ColecoVision. I'd argue the only feature it /needed/ was 80 column support, cause it's nice to finally have a cheap solution for that.

 

Even if he did take it to the bleeding edge - who's going to write the software to demonstrate it? And will that be the only software, ever? It'll be in there, but you won't be able to see it. Maybe it's in there now, how would you know?  

 

I'd further argue that now that it's shipping in the Phoenix, any MK2-specific features are eventually going to get begging for backporting. More work. To that same note, the more different the feature set of the MK2 is, the more existing F18As will become useless as new software is released that can't run on them. Expand the RAM, sure, we can account for that in software. But completely new features need a better reason than "we want it".

 

Alternately, you will just get what we see today where people won't use the new features to avoid locking out the existing install base.

 

But then, I always tell Matt to leave it at where it is, feature-wise.  I want to see the install base grow to a viable point, not keep fragmenting it.

 

[matthew180]

14 hours ago, wierd_w said:

[Already does assignable 64 color mode]

Sounds like I need to order an F18A then...

As soon as the MK2 is done, you will be able to do just that.

 

8 hours ago, FarmerPotato said:

I studied the ECM3 mode. I will explore choosing 8 colors to build a tile out of. As I understand it, the 64 palette registers will make 8 different 8-color palettes. In ECM3, there are 3 bits per pixel of a tile, and the 3 attribute bits per tile select which 8-color palette the tile uses.

So, the documentation is lacking for the F18A, and I really do want to write them... one day it will happen.

 

Color selection depends on a lot of factors with the F18A.  As soon as you enable the any ECM (enhanced color mode) on the F18A, every pixel has to ultimately reference one of the 64 palette registers.  As you have pointed out, you need 6-bits to select one of the 64 palette registers, and those 6-bits have to come from somewhere related to each pixel.  Using ECM1..3 also expands the color table to 1-byte per tile, so it goes from 32-byte to 768-bytes.  This provides each on-screen tile with its own priority over sprites, h/v flip, transparency flag, and 4-bits of palette select.  VDP Register (VR) 24 has extra global palette select bits to help make up the final selection.

 

In ECM1, you have 1-bit of color that comes from the tile pattern.  Another 4-bits from the tile's attribute byte, and the last bit come from VR24.  The index is formed from the global VR24, to the attribute, and finally to the pattern:

|  5   |  4 3 2 1  |  0   | 6-bit palette index
---------------------------
| VR24 | tile attr | ptrn | source of bits to
| >02  | ps3..0    | bit  | make index

So, VR24 selects either the first-32 (0..31) or second-32 (32..63) group of palette registers, 4-bits from the tile's attribute byte select one of 16 2-color groups from the first or second half, and the pattern bit selects between one of the two colors in the group.  The transparency bit in the tile's attribute determines if *index* 0 in the group (i.e. if the pattern bit is 0) means that the pixel is transparent.

 

This system adjusts as the number of patten bits changes for each ECM.  More bits from the pattern mean less bits are taken from the tile's attribute byte.  It breaks down like this for each mode:

|  5   |  4 3 2 1  |  0   | 6-bit palette index
---------------------------
| VR24 | tile attr | ptrn | ECM1
| >02  | ps3..0    | bit  |

|  5 4 3 2  |  1 0   | 6-bit palette index
----------------------
| tile attr | 2 ptrn | ECM2, 16-color groups
| ps3..0    | bits   | pattern selects 1 of 4 colors

|   5 4 3   | 2 1 0  | 6-bit palette index
----------------------
| tile attr | 3 ptrn | ECM3, 8-color groups
| ps3..1    | bits   | pattern select 1 of 8 colors

So, depending on how many bits you get from the pattern data, the 64 palette registers appear as different groups of colors.  VR24 has two bits of palette select to support the original color mode, i.e. where you only have 4-bits to select a color, and the color table is the normal 32-bytes and tiles are in groups of 8.  There still needs to be 6-bits to index a palette, so in that case VR24 provides those bits, which is essentially 4-groups of 16-colors.

 

Each tile-layer (there are two, TL1 and TL2) and the sprites all have their own palette select bits in VR24, and each tile-layer has its own color-table base address and ECM mode.  Sprites are also independent and have their own want to specify the extra palette index.  So, you can have TL1 in ECM2, TL2 in ECM1, and sprites in ECM3.  However you want to slice it up.

 

The extra bits in ECM2 and ECM3 come from the extra pattern data and create a bit-plane.  It is kind of a pain to make patterns with this arrangement, but it makes more efficient use of memory and Magellan will let you create ECM2 and ECM3 tile patterns.  Each additional patten bit means the pattern table increases by 2K, so ECM3 uses 6K of VRAM for patterns.  If you don't need all 256 tiles, the F18A can also be set to limit the pattern table size (holy crap I can't believe it does all this... feature creep!)  The VRAM use looks like this (ECM0 is the 9918A "original color mode):

Usable  Memory use in bytes
Tiles   ECM0/1  ECM2  ECM3
--------------------------
0..31   256     512   768
0..63   512     1K    1536
0..127  1K      2K    3K
0..255  2K      4K    6K

This is specified in VR29 for the sprite patterns and tile (both TL1 and TL2 are the same) patterns separately.

 

Also, all of this applies only the GM1 and GM2.  The text modes set things up differently.

[+FarmerPotato]

20 hours ago, wierd_w said:

There was an interesting vga dither routine that was used in wizardry 7 (msdos). It was used to generate the larger inventory screen portraits, from the smaller in-game thumbnails.  Literally, the large portraits are produced from the smaller ones. (I think they were 16x16 pixels for source image, and nearly 64x64 for final image. ) it was pretry complicated, but it judged what new pixels and patterns to add, based on its neighbors.  I remember this because I spenthink ages looking for the higher resolution portrait data in the games files, but could only find the thumbnails.  

 

Something similar in concept could be used to tile-ize a smaller bitmap, that obeys the row-by-row color attribute restrictions, and uses less program memory.  At least for backgrounds.  They would be dithered, but it could be neat to look at and unique.

 

Here's some images to help you understand.

 

This is the normal play screen.  See the character portrait for bolor.

 

Now, look at the inventory screen for that character.

 

 

The second image is generated from the first one, by the dithering routine.

 

We could do something similar, grabbing 4x4 areas in the source, and expounding them into 8x8 areas that obey Ti color conventions. 

 

This specific ditherer came to mind,  because if you look closely at the large portrait, you will see the local palette is different every other line. The dither routine selects colors that are appropriate, based on the source pixels, but with a different palette.

 

Designing images for such a routine is challenging, but not impossible. 

I can see  those Wizardry images are algorithmically scaled up. Nice.

 

I tried to think of ways to use that (changing the palette after each scanline) to get more colors for dithering. This would  mean 16 colors on even lines and 16 for odd lines. It broke my brain a little the way Apple II high res mode did.
 

Suppose I set 2 8-color palettes, with evenly distributed saturation values:

0 2 4 6 8 A C E   palette for even rows
 1 3 5 7 9 B D F  palette for odd rows

If the original image was limited to palette 1, then the scaled up version could make smoother gradients in between rows. But not inside rows. It will look stretched. So extra wizardry is needed to add noise or something.

 

What I came up with is that these people are probably smarter than me. So I'm going to let dithering be. Thinking of an 8-color custom palette is giving me happier ideas.

 

 

[+FarmerPotato]

54 minutes ago, matthew180 said:

 

So, the documentation is lacking for the F18A, and I really do want to write them... one day it will happen.

 

Thanks Matthew! I know you covered this in F18A programming, info, and resources   , but it's clearer the second time through. Also I hadn't read about TL2. 

 

 

[wierd_w]

The wizardry ditherer expands in both directions; yes.

 

However, the attribute cutoff is at 8 horizontal pixel demarcations.  (At least with the original VDP anyway-- At least that's what I get from cursory reading.) You will have less statistical likelihood of needing the same exact palette over a space of 4 pixels horizontally. Even if every single pixel was different, the max colors you are using is 4.  You don't need more.  Instead, the ditherer interjects new colors at every other column, bringing the full image size up, and selecting additional colors, based on the colors AND PATTERN used by the pixels in the source row. Instead of defining 8x8 tiles, you are defining 4x4 tiles, which are less complex, and cannot realistically house the higher color density anyway per row. You generate the higher color density on the fly, by evaluating the colors and pattern of the source tile.

 

Like I said-- designing images for use by the ditherer is "Challenging", but not impossible.  Rather than selecting colors and patterns based on intuition, you have to select them based on the rules of the upscaling/dithering algo. However, results will be consistent, and if color selections are sane-- visually pleasing.

[matthew180]

20 minutes ago, FarmerPotato said:

Also I hadn't read about TL2.

TL2 was added, along with a lot of other changes and fixes, in the V1.6 firmware (2015).  You can thank Rasmus for a lot of that.  You can see a demo of TL2 in the Flappy Bird demo that Rasmus wrote (probably the fastest / easiest way to see it is to just fire up js99er and choose the demo).  TL2 is literally a second tile layer with its own name table, pattern table, color / attribute table, and scroll registers.  TL2 sits on top of TL1.  Transparency in TL2 will allow TL1 tiles to show.  Also, since tiles in TL1 and TL2 can, on a per-tile basis, have priority over sprites, you can do some interesting layering and/or masking of sprites.

 

Then if you still need more, you can drop the bitmap-layer (BML) on top of all of that.  And another random feature, sprite size (8x8 or 16x16) can be specified on a per-sprite basis.

 

Currently, until I get the docs written, the Register Use Spreadsheet is pretty much the feature play book for the F18A.  I always update the spreadsheet before making the HDL changes.  Oh, and note that I use TI bit numbering in the spreadsheet (which will probably change for the MK2 to possibly implement some of the memory enhancements in a 9938-compatible way if possible (the 9938/58 use industry-standard bit numbering in the documentation)).

 

[Asmusr]

5 hours ago, FarmerPotato said:

Thanks Matthew! I know you covered this in F18A programming, info, and resources   , but it's clearer the second time through. Also I hadn't read about TL2. 

 

 

If you want to try what you can do with the F18A, Magellan has support for ECM2 and ECM3 colors modes for both sprites and tiles.