800x600 VGA (400x300) video driver

TheCbac

I posted an early thread in propeller Gcc, but I think this is a better spot, now that I have spin2cpp running.

I need to be able to create 800x600 VGA @ 60Hz (rendered as 400x300 would be fine) and be able to bitmap the pixels. I've been looking at the work that Kuroneko did below in the scanline demo (waitvid400x300, see link below), but I'm not sure how to adapt this. If anyone could give me some pointers, on how to do this it would be greatly appreciated!

http://forums.parallax.com/showthread.php/135844-POC-most-useless-piece-of-code-ever-The

kuroneko

That's probably not the most appropriate driver(?) (being proof of concept only). There is a more refined 400x300 scanline driver but without knowing more about your requirements it's hard to say whether it's appropriate (I use this on a C3 with a Synapse board to display full colour). So if you could provide more details that would be useful. Note that for pixel based graphics bandwidth becomes an issue too. Below is a list of available drivers (just ignore anything which isn't 800x600 timing).

TheCbac

I'm working on a LCD screen that takes a VGA input, which has to be exactly 800x600 @60Hz. Ideally, I just what to create an array that has an element for each pixel, so that I can turn each pixel on and off individually by writing to the array.

I looked around for any driver that was set up this way out of the box but I couldn't find one. Is any information that would be useful for clarification?

kuroneko

TheCbac wrote: »

I'm working on a LCD screen that takes a VGA input, which has to be exactly 800x600 @60Hz. Ideally, I just what to create an array that has an element for each pixel, so that I can turn each pixel on and off individually by writing to the array.

If you do the math 800x600 - even at two colours per pixel - costs you 60000 bytes which you don't have (without external memory). At 400x300 that comes down to 15000 bytes which fits but eats nearly half the hub RAM. I'm not aware of an existing monochrome driver that does that but it can be easily written. If you need more colours the resolution goes down further. Would two colours be acceptable?

TheCbac

Yes, two colors would be great. The initial plan is to use 400x300, but then to switch to XMMC format with Propgcc using an SD card to get away from the memory constraints.

kuroneko

TheCbac wrote: »

Yes, two colors would be great.

Attached is a quick and dirty 400x300 monochrome driver. See if you can work with it.

TheCbac

Quick turn around.

Thanks so much!

TheCbac

Update: I got the driver up and running successfully in Spin, then converted it to C using spin2cpp. I'm now booting in XMMC mode off a 2GB SD card. I have a bluetooth to UART dongle hooked up to the Prop, so when I type it plots pixels :-)

With memory no longer being an issue, is the driver you supplied easily adaptable to accept an 800x600 array for full resolution, instead of 400x300?

kuroneko

The driver can (or rather its parent). Can your h/w setup deliver a byte every 16 system clocks (5MB/s)?

TheCbac

kuroneko wrote: »

Can your h/w setup deliver a byte every 16 system clocks (5MB/s)?

I'm not sure. What would determine that? I'm using a Board of Education, and as I said earlier, booting off an SD card in XMMC mode.

jmg

TheCbac wrote: »

I'm not sure. What would determine that? I'm using a Board of Education, and as I said earlier, booting off an SD card in XMMC mode.

See in #4 If you do the math 800x600 - even at two colours per pixel - costs you 60000 bytes which you don't have (without external memory).

The problem with full pixel 800x600, is just not enough memory on chip.
An external Memory design, needs to deliver one byte every 200ns, which starts to get complex.
There are 8 pin QuadSPI SRAMS that can meet that, (using 2) but you need a set their mode and address, and somewhere find time to write the display data into them.