Explaining the TV driver screen layout

[DrGary]

Here's the comment about the screen memory in the TV driver:

''· tv_screen
''
''··· pointer to words which define screen contents (left-to-right, top-to-bottom)
''····· number of words must be tv_ht * tv_vt
''····· each word has two bitfields: a 6-bit colorset ptr and a 10-bit pixelgroup ptr
''······· bits 15..10: select the colorset* for the associated pixel tile
''······· bits 9..0: select the pixelgroup** address %ppppppppppcccc00 (p=address, c=0..15)
''
''······ * colorsets are longs which each define four 8-bit colors
''
''····· ** pixelgroups are <tileheight> longs which define (left-to-right, top-to-bottom) the 2-bit
''········ (four color) pixels that make up a 16x16 or a 32x32 pixel tile

The screen is laid out in words with each word identifying the tile ("pixelgroup") and the colorset at the given location.

For tiles, you can have 2^10 tiles that you put in the 192 (16x12) screen locations. The tile index the the lower 10 bits of the screen word.

For colorsets, you can have 2^6 colorsets. The colorset index is the upper 6 bits of the screen word. Each colorset can have 4 colors, for a total of 256 colors on screen.

So what does this comment mean?

·············· address %ppppppppppcccc00 (p=address, c=0..15)
······
Why are two highest order bits 0? In the demo code, graphics.spin, the colorset value is bit-anded with $3F, ie, six 1s.

Also, why are the bits drawn in reverse order? Propeller chip words are stored in little-endian order, so if this is showing the in-memory representation, shouldn't it be:

···· pppppppp ccccccpp
····
?

[AndreL]

There is a whole section on this in "Game Programming for the Propeller Powered HYDRA", should be out tommorow or the next day. In fact, I KNEW people would have trouble with this, so we included a free sample of Chapter 16 of the book that has EXACTLY this explanation in 5-10 pages with complete figures, so if you can hold off 24 hours, you can take a look at the free sample of Chapter 16 and hopefully it will answer all your questions about the parallax reference driver.

Andre'

[CJ]

most excellent!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

[Dennis Ferron]

We ought to have a 24" wide color poster that graphically depicts the relationship between where something is in RAM and where it shows up on the TV screen. It could have arrows going from boxes drawn around a hex dump of ram to pointing at boxes on the screen picture, with arrows showing which direction the bits end up and so forth.

Kind of like those posters Microsoft uses to diagram .NET class hierarchies. It would just be a handy source with various examples; i.e., here is a piece of the screen that came from this tile, here is how you set the overscan color, here is a tile that comes from the font in ROM, etc.

I'd buy one. I could put it up on my wall to refer to when I'm working on Propeller code.

[AndreL]

Tommorow you can look at my figures from the sample chapter 16 which depict just that, print them out and there you go!

Andrre'

[DrGary]

Chapter 16 of the Hydra manual is terrific and has detailed explanations about the TV driver. The link is here:

http://www.parallax.com/dl/docs/prod/prop/Hydra-Ch16Sample-v1.0.pdf

I still have the original question, though. How are the 6 colorbits used? The comment (" %ppppppppppcccc00 (p=address, c=0..15)" seems to say that 2 of the 4 bits aren't used. Although the Hydra manual says 6 bits are used to point to a colorset, Figure 16.6 says that _4_ bits point to "a single LONG in the bitmap." So does that mean there are 2^4 or 16 colorsets?

Colorsets are LONGs: 4 bytes, 1 byte per color. So it makes sense to count by fours in memory. But why waste 2 bits in the screen memory? Just ocount colorsets (0,1,2,...), then shift the bits to point to the right long·in memory.

Color me confused... :)

[AndreL]

The 6 bits are an INDEX into each color set, 64 color sets. That's it :)

Andre'
·