graphics driver question

Erik Friesen

I would like to use the graphics driver for my 128x64 lcd driver.· I have a 1024 main memory byte array that the lcd updates from.· The bytes are layed out horizontally, 16 bytes per row, by 64 rows high.· The graphics driver updates a 16 x 16 tile if I understand it correctly.· How are the longs or bytes written to in a 16 x 16 tile?·

Ken Peterson

I believe the graphics driver arranges the words for the tiles in vertical fashion. This means the upper left tile has 16 longs consecutively in memory, then the tile below it has the next 16 longs, then the next one below that to the bottom of the first column. Then on to the next column....

I'm just recalling this from memory and I haven't looked closely at the graphics driver in a while. Someone hit me over the head if I'm wrong.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

stevenmess2004

Inside the tiles the memory is arranged left to right, top to bottom with two bits per pixel. The tiles are arranged top to bottom, left to right. Which is just like Ken said. Because of the tile system its a bit of a pain to find the pixel that you want.

Ken Peterson

Also, aren't the character definitions backwards, with the LSB being the left side of the character and the MSB being the right? That could make things even more confusing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Timothy D. Swieter

Erik -

I suggest picking up the Hydra book. It covers this topic in a good detail with diagrams which are more helpful in this case than words. I have attached the graphics.spin object to a couple of different LCD screens. One was a monochrome screen and the other was a uOLED-96-PROP screen. Once you get the core concept of graphics.spin down it is easy to do.

Let see if I can do this right in words:
-Graphics.spin is tile based
-each tile is 16 pixels by 16 pixels
-in memory, each tile is one long wide by 16 longs tall (maybe not the best description words)
-the tiles are column major, meaning the upper left tile is first in memory, than the tile below it, then the tile below, when you get to the bottom you wrap around to the top of the next colum
-As previously said, each tile is 16 pixels by 16 pixels so therefore each long (32 bits) is 16 pixels meaning there are two bits for a pixel. This ends up being four colors unless you do something like the tv.spin does with a table (again I reference the Hydra book to learn more) to get more color.

You will need to reserve the space for two screens. Your LCD driver code will look at the "on screen" buffer and graphic.spin will look at the "off screen" buffer. When the "off screen" buffer is written, it is copied to the "on screen". Your LCD code will have to work its way through the "on screen" buffer depending on how the data needs to be sent to your LCD being used.

This should be a good start.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter

www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com

---

One little spark of imagination is all it takes for an idea to explode

Ken Peterson

You may not need two screen buffers. I eliminated one of them in my project (using a modified VGA object) and I was able to avoid flicker by making the graphics routines wait until vertical blanking interval to do the drawing. That eliminated about 90% of the flickering.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Erik Friesen

Thanks for the replies. Would you post your monochrome graphics driver? Or tell me, Do you only have to rework the 3 plot pixel routines in graphics.spin?

Ken Peterson

Not sure if it would be easier to re-write the graphics object to use a different bitmap layout, or if it would be easier to write code to pull the data out of the bitmap and feed it to the LCD in the proper order. At first glance, I'd be inclined to do the latter, but I have not picked apart the graphics driver to really understand what would need to change.

In my case I was using the VGA driver which needs the bitmap layout as-is.· Therefore I didn't develop anything that would get you any closer to a solution for your display.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Post Edited (Ken Peterson) : 4/23/2008 9:11:22 PM GMT

Timothy D. Swieter

Erik -

The monochrome driver that I refered to was for a product for my company that I am unable to release the code to at this time. Maybe in the future I can release it, I am reviewing the options because the product is not completed yet. In my monochrome application I left graphics driver all alone and didn't modify it. I then wrote a driver to read the "on screen" buffer and send the data to the LCD. It was a while ago when I wrote the driver, but I think my LCD wanted data clocked out by row. So the driver started in the upper left corner (the first long of the video memory) and then clocked out the first 16 pixels and then jumped to the tile of the next top column and clocked out 16 pixels. A mask was used to pull the correct pixels out of the memory. Data was sent to the LCD in bytes, so I actually had to gather a few pixels before I sent a byte to the LCD.

I hope this helps some. Do you have a datasheet or further information about your display?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter

www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com

---

One little spark of imagination is all it takes for an idea to explode

stevenmess2004

If you want to make the graphics driver two colour then there are four plot routines you will need to change as well as the wide pixel templates. It will be a fair amount of work but it will save a lot of memory.

Timothy D. Swieter

Or just leave the graphics routine as is and the code that renders the data to the display sees a 00 or non-00 in the graphics rame and writes the appropriate information to the LCD display.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter

www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com

---

One little spark of imagination is all it takes for an idea to explode