Screen pointer problem
Nick McClick
Posts: 1,003
I spent a week trying to figure out how the TV driver worked on my demoboard. Andre's book explains it in about one page. Still having a little problem;
I'm storing 16 longs @ tile, If I put those 16 longs straight to the display, they fill a tile and it works fine. My problem is with changing the screen pointer for each tile to point to the longs;
I would expect it to load the tile address and assign the color palette at index 11. The color palette works fine. But it looks like half the tile is filled with random data. (and the other half is filled with the right data).
My DAT section only consists of two parts. the Tile pattern and the tile. It's strange that if I put put data in front of the tile data entry, I see changes to the tile displayed. I'm pretty sure my pointer is screwed up. Here's my DAT section
What's the right way to change the screen pointer?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Concentrate on understanding the problem, not applying the tool
Post Edited (Nick McClick) : 7/26/2008 7:17:28 PM GMT
I'm storing 16 longs @ tile, If I put those 16 longs straight to the display, they fill a tile and it works fine. My problem is with changing the screen pointer for each tile to point to the longs;
repeat i from 3 to 50 screen[noparse][[/noparse]i ] := (@tile >>6) + 11 << 10
I would expect it to load the tile address and assign the color palette at index 11. The color palette works fine. But it looks like half the tile is filled with random data. (and the other half is filled with the right data).
My DAT section only consists of two parts. the Tile pattern and the tile. It's strange that if I put put data in front of the tile data entry, I see changes to the tile displayed. I'm pretty sure my pointer is screwed up. Here's my DAT section
DAT Smile LONG $FFFFFFFF LONG $FFFFFFFF LONG $FFFFFFFF LONG $FFFFFFFF Tile LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 LONG %0101_0101_0101_0101_0101_0101_0101_0101 TVparams LONG 0,1,%011_0000,%0000,0,0,x_tiles,y_tiles,10,1,0,0,55_250_000,0
What's the right way to change the screen pointer?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Concentrate on understanding the problem, not applying the tool
Post Edited (Nick McClick) : 7/26/2008 7:17:28 PM GMT
Comments
The problem is that the 6-bit right shift you have to do to the pointer to make it work with the TV driver. As it stands, the start of your tile is on a long boundary. The 2 LSB's of that pointer will always be zero, since each byte has its own·address. The complier will always make sure that "long" data will start at an address where the last 2 bits are zero. (See page 209 in the propeller manual.) When you shift the point six bits to the right, you basically set the last 6 bits to zero. When the·TV driver reads the pointer, it shifts the data six bits to the left, and the 6 lowest bits are set to zero.
So... Your tile has to start at an address where the last six bits are zero. Unfortunately, there isn't any way to make this happen at compile-time; it has to happen at runtime.
You have to do something like this:
Hope this helps.
Also, you can enter four color tiles more easily using quaternary numbers (e. g. %%0123). Each digit is two bits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·</Parallel Universe>
Post Edited (Parallel Universe) : 7/26/2008 11:24:27 PM GMT