Explaining the TV driver screen layout
DrGary
Posts: 7
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
····
?
''· 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
····
?
Comments
Andre'
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?
I've killed a fly with my bare mind.
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.
Andrre'
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... [noparse]:)[/noparse]
Andre'
·