Video Graphics Array

gambrino

Hello , i want to write a program that can drive screen 256x128 , this program use one cog to write to the memory and another cog to read from the memory and to display it on the screen . Is it possible like this . Which code in the library can be the base of my program ? Thank you forum.

Baggers

Gambrino, it depends on what bit resolution you want for your display, I'm guessing you're thinking 256x128x8bit giving you the full colour range?
If so, there's a few things.
1) it will use up ALL 32KB of HUB-RAM and the first 16 bytes are used by the prop so you wouldn't be able to have 256x128, would have to be less than that.
2) because you're using all the available HUB-RAM your cog writing to the screen, would have to e coded in asm, and not a spin app.
3) You'd probably be better going with 240x120 double'd in Y resolution to 240x240 [noparse];)[/noparse] that would use 28.25K giving you a little more HUB-RAM spare especially the first 16bytes

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Baggers

Hi, since you want 1bit per pixel.
Here's my spectrum driver, with a few routines, like print and plot and unplot.
I'm guessing your using a Protoboard or Demoboard, so will have to change the settings block at the top of the SpecDemo.spin file. instructions are in the file.

Hope this helps.
Jim.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

gambrino

Hello again , i read the VGA_640x240_Bitmap in the library, is it possible from this code to make a driver for a screen 128x64 monochrome mode , black and white : pixel on/off?How can i summarize steps to achieve this goal ? Thank you in advance for the important information

potatohead

Need to parse how the screen addressing is currently done. Is is linear, as in x bytes per scanline, or tiles?

Does that match your screen addressing goals?

If not, modify original driver to match your layout, leaving the pixel timing where it is.

Having settled that.

Parse the scanline rendering code. There are waitvids and timing constants that get it all done.

Derive the pixel size timing required for your pixel size.

Refactor the waitvid code to take advantage of the new timing.

Test.

Iterate until you have the scanline you want.

It's not a bad idea to lay out a test screen buffer, with some known pixel data you can debug with.

Having gotten here, that's gonna be two bits per pixel, as I think that driver is 2 bits, not one.

If that's the case, then you will need to start out by converting the original driver to one bit per pixel, before going down the road of obtaining your specific pixel size.

That's done in a fashion similar to what I described to get the pixel size changed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

Timothy D. Swieter

I recently posted a 128x96 monochrome graphic LCD driver. You can look at that code for an example to create your own. With the code I wrote you use the standard graphics.spin from the library to draw into graphics memory. Then use the LCD driver to send the graphics memory to the LCD.

The code is in the object exchange here: obex.parallax.com/objects/389/
or product specific information for the Graphical LCD or a video showing the use of the code is on the Brilldea site.

I chose to use graphics.spin because I figure others were use to it. Also, in my case the graphical LCD actually has four total gray scale modes. In the past I have created ASM drivers that still used the graphics.spin, but I only looked to see if the pixel was non-zero for the 2-bit pixel.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com