Shop OBEX P1 Docs P2 Docs Learn Events
Screen pointer problem — Parallax Forums

Screen pointer problem

Nick McClickNick McClick Posts: 1,003
edited 2008-07-26 23:19 in Propeller 1
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;
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

  • Parallel UniverseParallel Universe Posts: 46
    edited 2008-07-26 23:19
    Nope. Your pointer is working fine.
    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:
    PUB main
      new := constant(@my_tile>>6<<6)
      longmove(@tile_start >> 6 << 6, @tile_stare, tile_count * 16)
      tv.start(@tv_params)
     
    DAT
    tile_buffer    long 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 'Fifteen longs you know are zero
     
    tile_start     'tile_count 16 long tiles...
    

    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
Sign In or Register to comment.