Help with bitmaps, VGA, LCD

T Chap · 2012-09-03 08:38

PRI DrawBitmap(pBitmap,  pInfo)|c,i,j,BmpAddress,xPos, yPos, xSize, ySize,bpp,clr
  bpp:=byte[pInfo++]
  xSize:=byte[pInfo++]
  ySize:=byte[pInfo++]
  xPos:=byte[pInfo++]
  yPos:=byte[pInfo++]
  clr:=byte[pInfo++]
  row:=yPos
  col:=xPos
  c:=0
  BmpAddress:=pBitmap
  repeat j from 0 to (ySize-1) step 2
    repeat i from 0 to (xSize-1)
      screen[row * cols + col] := (clr<<1+1) << 10 + BmpAddress>>6 +c
      screen[(row+1) * cols + col] := (clr<<1) << 10 + BmpAddress>>6 +c
      c++
      col++
    row+=2
    col:=xPos

Using Rays NH4 LCD driver, I need to find out if it is possible to position graphics at any position without using fixed areas using tiles. My project uses the LCD flipped 90 degrees, and I can't use PRINT. I need custom graphics and fonts to create buttons, icons. numbers, phrases. Currently, I have 26 phrases that are stored as bmp>dat files and loaded into DAT. Each of the phrases are flipped to work with the LCD. Each phrase is 160 longs. and the memory is getting maxed, with more work to be done.

So the new idea is to try to just convert 26 letters(cap) and 26 letters (non cap) to bmp, rotate, load into DAT. This way the phrases can be created in spin. But, as it is now each font bmp has to be loaded into a tile, so the letters must be spaced out too wide to be usable. I need a method to display the fonts close together, and be able to manage the spacing on a pixel basis, not tile basis. Can this be done? How about making the tiles much smaller, allowing tighter placement? The 4.3 Newhaven screen is using cols = 30 rows = 17.

My last resort is to build a board that uses 2 Props, one for graphics and one for the main program. This will at least let me add the remaining phrases to complete the required user interface, but leaves no room for expansion.

Any suggestions appreciated.

Rayman · 2012-09-03 08:59

You could try using graphics.spin for the text and the bitmaps for the buttons...

You can have several small "graphics" areas around the screen that you can draw text onto...

Another option is to use external flash or SD card or the extra space in your EEPROM to store bitmap data and cycle it in when needed...

T Chap · 2012-09-03 12:58

I am trying to figure out how to do this with eeprom. Here are the steps:

Create 16 x 16 bmp, save to file. Open in Prop1bitmap. Adjust x and y to 1,1, by default it says it is 1x and 2y tiles.

Copy the binary (16 longs) and paste to very bottom of DAT.

Write 64 bytes of data from the .dat file location in DAT to eeprom starting at 0.

Read the 64 bytes back from eeprom, store back to a location in the UserCharStart section of DAT.

Attempt to print the bitmap.

I get echos of the bitmap using x1 and y1 sizes.

DAT
padding LONG 7[16]  'alignment padding for bitmaps
UserCharStart long
graphic00_data long
        file "aa.dat"

Above, aa.dat is the exported bmp>dat file from Prop 1 bit as a 1x1tile. I used 16x16 pixles to create the font.

graphics122_info  byte   1,    1,     1,       24,  15,    0     'A

grr     LONG %11110000_00000000_00000000_00001111
        LONG %11000000_00000000_00000000_00000011
        LONG %00000000_00000000_00000000_00000000
        LONG %00001111_00000000_00000000_00000000
        LONG %00000000_11111100_00000000_00000000
        LONG %00000000_00001111_11110000_00000000
        LONG %00000000_00001100_00001111_11000000
        LONG %00000000_00001100_00000000_00110000
        LONG %00000000_00001100_00000000_00110000
        LONG %00000000_00001100_00001111_11000000
        LONG %00000000_00001111_11110000_00000000
        LONG %00000000_11111100_00000000_00000000
        LONG %00001111_00000000_00000000_00000000
        LONG %00000000_00000000_00000000_00000000
        LONG %11000000_00000000_00000000_00000011
        LONG %11110000_00000000_00000000_00001111

You can see that this is an A with a few pixels on the corners just to see what the borders are doing.

  WritePage(EEPROM1, $0000, @grr, 64)
  ReadPage(EEPROM1, $0000, @graphic00_data, 64)
  'hex(graphic00_data[0], 8)
  'hex(graphic00_data[1], 8)
  'hex(graphic00_data[2], 8)
  'hex(graphic00_data[3], 8)
  w(80_000_000)    pause to 'verify eeprom is what it should be
  DrawBitmap(@graphic00_data, @graphics120_info)

I assumed that if I read in the aa.dat file, then it would park the data in DAT identical to where the eeprom would write back over it.

Is this close to correct? I am seeing what looks like the right 1/4 of A several times overlapped, like echos, but never the full version.

I really just want to get anything to work for a test so I can gauge how slow of a response time the eeprom reads would add to each time a phrase needs to pop up.

Rayman · 2012-09-03 13:11

It sounds like you are doing the right things.
My guess is that you are not righting to the correct starting address...
The tile data starting address has to be aligned to a 16-long address so that the lower 20 bits of it's address are all zeros.
My code does this with the longmove instruction at the beginning of the code...
So, the address you want to copy to is: ( @graphic00_data & $FFC0 )

Also, I would use the upper 32kB of your probably 64kB eeprom for this data so that you can still boot...

T Chap · 2012-09-03 14:12

  WritePage(EEPROM1, $0000, @grr, 64)
  ReadPage(EEPROM1, $0000, @graphic00_data & $FFC0, 64) 

  DrawBitmap(@graphic00_data, @graphics120_info)


graphics120_info  byte   1,    1,     1,       25,  13,    0  
grr     LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF

        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $00FFFFFF
        LONG $0000FFFF
        LONG $000000FF
        LONG $00000000

DAT
padding LONG 7[16]  'alignment padding for bitmaps
UserCharStart long' *********************************************************
        graphic00_data long
                        file "aa.dat"

That helps out, but strangely for some reason the image is showing up as a double. AA.dat is just a character that is 16x16, so I assumed I was replacing it's data with the new data from grr.

Rayman · 2012-09-03 16:03

That "DrawBitmap" function is assuming that bitmaps are a multiple of 2 in height...

You'll have to change the "step 2" to "step 1" and then comment out the second "screen[" line to allow odd heights...

T Chap · 2012-09-03 16:48

Great, that solved the double! The last thing to understand is how to read from the .dat file that is loaded in DAT, write it to EEPROM, read it back from EEPROM and put the same info back into DAT on the fly and use the EEPROM data for display. I am getting garbage with this below, and have tried to & the values you suggested both on the write to eeprom and read from eeprom back to the dat file. If I can get past this, then I can load many .dat bmp files in and park them on some spare eeprom space, read as needed. So far it looks like the read eeprom and display will not be a problem, I just need to understand how to get the dat files into eeprom then back to somewhere that can be used to display the data.

  WritePage(EEPROM1, 64, @graphic39_data, 640)  ' read from the .dat file, store the 640 bytes to eeprom starting at address 64

  PaintKeypad
  repeat
      ReadPage(EEPROM1, 64, @graphic39_data & $FFC0, 640)   'read the 640 bytes back from the eeprom and store the info back to where the original .dat file came from.
      DrawBitmap(@graphic39_data, @graphics39_info)    '  draw the phrase  2 x 10 
      w(10_000_000)   'slow down loop

Rayman · 2012-09-03 17:27

Here's a section of code from an Adafruit RGB matrix driver where I copied some bitmaps into upper eeprom and then back down at run time (maybe you can use these ideas for your code):

OBJ
   matrix : "32x16_Driver3"
   led : "32x16_Graphics3"
    'This second instance is required unless you need to scroll two things at once like we are here
   'led2: "32x16_Graphics3"    'make second instance so we can scroll while showing video...
   eeprom:  "Propeller EEPROM"
   
VAR
 ' long stack[100]  'stack space for cognew (only required when want to scroll two things at once)

DAT 'Test Windows bitmaps to show
    'needs to be 24 or 4 bits per pixel (and maybe have a width that is an even multiple of 4)
WindowsBitmap byte
     'file "MerryXmas3_4bit.bmp"  '5366 bytes        1k..7K
     'file "XmasIcons_4bitB.bmp"  '8950 bytes       7K..16k
     'file "Party_4Bit.bmp"  '9078                  16K..26.1K
     file "HappyNewYear_4bit.bmp"
      'byte 0[9100]  
EndBitmap byte                
PUB Main'|'i, j, k, section, bit,bits, c0, Pin_A, Pin_EN  'Show a 1bpp bitmap
  'Copy bitmap to upper eeprom
  'eeprom.FromRam(@WindowsBitmap,@WindowsBitmap+6000,33000) 'Merry Xmas 
  'eeprom.FromRam(@WindowsBitmap,@WindowsBitmap+9000,32000+7000)  'Xmas icons
  'eeprom.FromRam(@WindowsBitmap,@WindowsBitmap+9100,32000+16000)  'Party
  'eeprom.FromRam(@WindowsBitmap,@WindowsBitmap+5000,32000+26100)  'Party
  'eeprom.ToRam(@WindowsBitmap,@WindowsBitmap+9000,32000+9000)       'test read back

T Chap · 2012-09-03 20:31

I can copy no problem if the data is present like below:

DAT
grr     LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF

        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $FFFFFFFF
        LONG $00FFFFFF
        LONG $0000FFFF
        LONG $000000FF
        LONG $00000000

When I examine the content of memory starting at PADDING long 7[16] using this:

  repeat 256
    row := col := 0
    hex(long[@padding][mmm], 8)
    mmm++
    w(40_000_000)

I can see the padding information as it should appear. But, when trying this to see the content of the .dat file:

  repeat 256
    row := col := 0
    hex(long[@graphic1_data][mmm], 8)
    mmm++
    w(40_000_000)

It does not show the content of the dat file, the dat file is only going to contain 00, ff, 0C, 03, 0F, F0, but I am seeing a lot of other stuff. So in short, I can copy content to the eeprom if I know where exactly something is in DAT, but the externally loaded .dat files are not behaving the same. This means I need a way to either locate them in memory after they are loaded, or I need to just copy and paste from Prop1 bit. But, in looking at the output of the Prop1 bit dat file in the binary view, it seems to be missing a lot of info for larger phrases, but for a single font it looks right, even though the preview is correct. That means I cannot just copy and past the data from Prop1bit into DAT and upload to eeprom, So the options are, either find a way to access already loaded(.dat file) info and copy from there to eeprom, or find a way to copy and paste out of Prop1bit.

Rayman · 2012-09-04 03:58

Maybe you are still seeing the effect of the .dat section being moved into the padding?
Try commenting out the longmove line and repeat what you describe above.

Or, try this: hex(long[@graphic1_data & $FFC0][mmm], 8)
which should give you the right address after the longmove into padding...

T Chap · 2012-09-04 06:09

I got a little app called File Viewer to see the raw dat file. The content doesn't look anything like the binary view. The binary view shows only FF, 0F. F0. FC. 03, but the file viewer shows AA, 05, 80, etc, and none of the binary content. However, the font works when loaded as it should to show a number 1. If it is a padding issue to display the dat file on the LCD or PST, I tried moving the dat file up above the padding so that the padding should not affect it. Strangely, I am seeing the hex values scrolling in reverse order from the file viewer. When I copy and paste binary data from Pro1bit, I can display the font on the LCD, just as well as using the 1.dat file as a font on the LCD. But, when I try to copy the dat file to eeprom it shows all garbage. I thought that the binary must remain in tact for it to show on the LCD as a bipmap. This does not make any sense. If you have a minute, maybe try printing the dat file from PST and see you can see something that makes sense:

  repeat 64
    'row := col := 0
    'hex(long[@graphic1_data][mmm], 8)
    debug.hex(long[@grr][mmm], 8)
    debug.tx($0d)
    debug.tx($0d)
    mmm++
    w(40_000_000)

Rayman · 2012-09-04 09:49

It could be that the text output of my Prop1BitBitmap app is wrong...
I know the .dat file is correct, but I vaguely remember there being a problem with the text output of one of these apps and hoping nobody would notice...

It appears that you have one tile with a sideways "1" and then a blank tile underneath. Because of the way the ROM font-style 1-bit bitmaps are encoded,
I would expect to see a lot of "AA" (binary 10101010) in the real data where the 1's make up your sideways "1" and are interleaved with the 0's for the blank tile.
That text output with all ones probably is just wrong...

I'll try to take a look at that later, but can you try just using the .dat files and not the text?

Rayman · 2012-09-04 11:12

Just took a stab at fixing the text output of Prop1BitBitmap...
If you want, you could try this version and see if it gives the right answer:
Prop1BitBitmap.zip

T Chap · 2012-09-04 11:21

Ray, yes that output looks consistent with the actual file data. Thanks for tweaking that.

The question is now, if I just want to copy and paste the binary view into DAT to view the bitmap directly versus loading the .dat file, do I just discard the char y=0, x =0 type info and put all the longs in a row as copied?

Rayman · 2012-09-04 11:27

Thanks for trying it. Yes, just comment out the "char" lines and it should work the same as the .dat

So now, that text and the .dat file should do the exact same thing... You should be able to use either one interchangeably

T Chap · 2012-09-04 11:46

Ray, I will try this in a few, but I do not know what you are referring to by 'text'. I have been experimenting with putting longs in DAT as well as reading in the .dat file. I assume you mean that if I copy the text file from Prop1bit into DAT, there is no difference. This will be great if I can get this to work, it is also nice to be able to park the data into DAT for future reference since you can sort of see the pixel information and edit it there as well.

T Chap · 2012-09-04 12:51

I tested the new dat copied and pasted and that is working. The other issue I had Dave Hein pointed out was that I was not wrapping around the page correctly on the eeprom writes. This is very close to the goal.

T Chap · 2012-09-04 15:10

Using the pasm_i2c_driver makes the display of a 640 byte bmp seem like the same speed of using the .dat file loaded in DAT. At least it is not really perceivable to be detected. Using the basic i2c driver becomes little noticeable of a delay when navigating around the screen and things need to pop up in response.

Rayman · 2012-09-04 15:51

That sounds pretty good then. I hope you can post an example of what you have working... Somebody may want to copy this idea...

T Chap · 2012-09-04 16:27

Sure, once I get things a little more settled down I will post an example.

Help with bitmaps, VGA, LCD

Comments