P8X32A and VGA
megaionstorm
Posts: 178
I have a idea and i wan't create a 640X480 pixel vga picture with the p8x32a.
Each pixel 8 bit color value and double buffering.
Hardware:
P8X32A, 5 X K6X4008C1F-DB55 512KByte Static RAM.
The graphic data should be stored in the 2.5MByte RAM Memory.
2 pages X 640 X 480 X 3 Bytes = 1843200 bytes
The addresslines should be accessed through 74HC595 shift registers.
What do you mean ?
Each pixel 8 bit color value and double buffering.
Hardware:
P8X32A, 5 X K6X4008C1F-DB55 512KByte Static RAM.
The graphic data should be stored in the 2.5MByte RAM Memory.
2 pages X 640 X 480 X 3 Bytes = 1843200 bytes
The addresslines should be accessed through 74HC595 shift registers.
What do you mean ?
Comments
But, I didn't see how to update the image while showing it, for one thing.
What I wound up doing eventually is using the SSD1963 and a VGA DAC to make the "VGA Graphics Shield".
Still, this other way would be a fun project...
I think the ADV7123 looks good for my idea !
How do you handle this with one p8x32a ?
http://www.allshore.com/pdf/solomon_systech_ssd1963.pdf
Page 17, 7.1.5 Tearing Effect Signal (TE)
However, if the MCU is faster than the LCD controller, it should start updating the display content in the vertical non-display period (VNDP) to enable the LCD controller will always get the newly updated data.
Updating the image on SSD1963 is no problem, I've got example code on my website...
What I meant was that I didn't see how to update the memory very fast using external ram chips, like in your top post...
Is it possible one cog read data from a ram chip and a second cog writes data to a second ram chip ?
At the same time ?
Like I said, I thought about this for a long while, but it just seemed very complex...
Hardware:
P8X32A, 5 X K6X4008C1F-DB55 512KByte Static RAM.
but
Hardware:
2 P8X32A, 2 X DS1270 16Mb Nonvolatile SRAM
That DS1270 is seriously expensive and also slow.
You have not mentioned how quickly you need to update the RAM ?
It is hard to beat the SSD1963 Rayman has already mentioned, as it has RAM included, and of a useful width.
Any other solution will chew a lot of PCB space, and power.
eg If you want 24b colour that is a lot of data-bus routes, and 3 x 8 b or 2x 16b chips, or 1 x 32b chip.
The 25MHz VGA scan is also above a Prop 1, without hardware assist, - adding something like a loadable-counter, for the X axis would be needed.
Once you have a loadable X counter, and lots of SRAM, you are best to bump into SDRAM territory, as that is pretty much what you are building.
Many new SDRAM offer full page burst, and if you choose one with a full page of > X scan (eg 1024), then your hardware simplifies a lot.
For most uses, 16 bit Colour will be enough, and that can save a lot of PCB routing.
Yes, the DS1270 is to slow !
How should i manage the 16 bit colour ? How many bits for each colour ?
Follow what is already done ?
http://en.wikipedia.org/wiki/Color_depth
http://download.micron.com/pdf/datasheets/dram/sdram/512MbSDRAM.pdf
But don't found something usefull and no example schematic about it !
I think this thread has some examples :
http://forums.parallax.com/showthread.php/137266-Propeller-GUI-touchscreen-and-full-color-display
For the SDRAM, you look for one with a full-page burst and size, of at least your X axis, as they then have a loadable X counter.
Probably easiest to allocate (eg) 1024, and simply not use a portion of the count.
Please take a look.
Can i use one of this two ?
http://uk.farnell.com/amic/a43l0616bv-7f/memory-sdram-16m-50tsop/dp/1907101?Ntt=A43L0616BV-7F
http://uk.farnell.com/amic/a43l2616bv-7f/memory-sdram-64m-54tsop/dp/1907102?Ntt=A43L2616BV-7F
The chip can run to 143Mhz (6ns) and a lot of ram experiments have been done with 55ns ram chips (or even slower with serial ram). At the end of the day, a VGA output is a bunch of digital pins toggling up and down and even 3 bits per color would give a lot more color combinations. 16 bits would give a very nice color space.
Thinking aloud, either an external clock or the propeller could handle the timing. The chip will be dumping out data for each row on the display, but there is lots of spare time between each row and at the end of the screen for the propeller to send data to the ram chip.
The experiments with the touchscreens show where the limits are, and for displaying a static display things should be fine. Where one pushes against the limits is playing movies, and the limiting speed factor there is the rate you can get data off an SD card, not any display factors.
If one had a ram chip (or chips) with more memory than one screen, then you can store sprites and move them around in the ram chip as needed. This is how we got Pacman working on a touchscreen, and approx 1/4 of the ram was for the active display and about 3/4 was for sprites and other data.
That ram chip A343L0616BV-7F has 16 data lines and 9 address lines and some control lines. It may be necessary to move data in with two 8 bit latches as there might not be enough propeller pins but that is ok.
re
On the touchscreen it is RRRRRGGG_GGGBBBBB ie 5,6,5 bits which gives a little more weighting to the green as the eye is more sensitive to green. Both myself and AverageJoe have code to translate bitmaps and jpegs into this format.
Intriguing possibilities...
SDRAM are getting cheaper all the time, and using the Full page burst per line does make this simpler, but you need a page size of >= the Pixel count, to avoid needing a re-load.
The 16Mparts quoted above are smaller, and the data is vague, but says this
3. The full column burst (256bit) is available only at Sequential mode of burst type.
which sounds like they meant to say 256 clocks for Full Page mode.
As parts get larger, that Clock count per Full page increases, and that number will determine which part you need.
Likely there will be plenty of extra memory
Halving the memory width usually doubles that Clock count, so it may be an interim solution to find a 1024 x 8 and use 2, while you wait for the prices of the N x 1024 x 16 to come down. Google suggests 512M is needed to get 1024 x 16, but there are some 128M ones with 1024 x 8
( or, you could design with 512 x 16, and move to 1024 x16 later )
eg IS42S16800B-7TLI ISSI DRAM Chip SDRAM 128M-Bit 8Mx16 3.3V 54-Pin TSOP-II 864 : $2.2499
and the thread http://forums.parallax.com/showthread.php/137266-Propeller-GUI-touchscreen-and-full-color-display
There is code in that thread in propeller pasm to handle converting a bitmap to a 16 bit format. Initially we started off doing the conversion on a PC using other programming languages, but in the end it was easier to do it on the propeller. So we just store standard .bmp files on an SD card and then do the conversion once when the data is moved from the SD card to the external ram.
I need to brainstorm this with averagejoe as well, as I think your ram chip you found could greatly simplify driving the touchscreen, as we could use the burst mode rather than the five 74HC161 counters.
There could be some synergies between driving a VGA display directly with a ram chip, and with driving a touchscreen. Both have the same problem - dumping large amounts of 16 bit data out in a short space of time (you can't dump it from a propeller directly as the propeller ram is not big enough for a screen of pixels). So the driver for a touchscreen and a driver for directly driving a VGA display might be more similar than it would first appear.
At 6ns, one might also even be able to think about driving a TV screen directly using a fast D to A converter.
jmg said
Excellent point.
Ok, what is a pixel count? 640x480 to start with, so 640 pixels? Send one line, then do other things during the 'back porch" time. Would that work?
It depends on how many pixels you have in the Horiz Scan ?
Looks like AS4C8M16S-7TCN 128M and AS4C16M16S 256M SDRAM have 512 clock full page shifts, and are 1: $1.63 & 1: $2.15 resp. in TSSOP II 54 - prices keep coming down
Pacman looks very nice !
2)
MT48LC8M16A2P-6A IT
http://www.farnell.com/datasheets/1674468.pdf
Page 46, 1. For full-page accesses: y = 2048 (x4); y = 1024 (x8); y = 512 (x16).
jmg, is this one ok ?
Yes. It looks more expensive than the 256M one above, but the TSOP54 looks to be a widespread SDRAM standard, so you can move vendors easily.
I see a ISSI part IS42S16320D, is 1024(x16) @ 512M, but is over $10
Then i purchase 2 MT48LC8M16A2P-6A IT for my project.
When i calculate right then the chip has a 16MByte size ?