External Memory options for VGA(LCD) graphics storage

T Chap

I am out of memory and still have a lot of graphics to add for New Haven LCD Touch Screen that uses an adapted VGA object( Ray's ). There are graphics that are called up a la carte that I am parking on eeprom, but the screen draw is slow on the graphics that have to be read in first. What is a faster way to retrieve some data as needed? I was thinking of still putting the graphics on eeprom and on boot up, transfer to some type of RAM. I have never used an external RAM, but would assume that with SPI that the speed could be improved over eeprom? Any suggestions? At present there are no pins available for SD.

Dave Hein

Is your I2C driver written in Spin or PASM? You can get substantially higher data speed from an EEPROM using a PASM driver.

T Chap

True, I have used PASM drivers for higher speeds on EEPROM, but presently there are several other Spin I2C objects and devices that use the same pins 28/29 and the EEPROM is updated with the main program in Spin. I remember that trying to use PASM and SPIN on the same I2C pins gets awkward. That's why I am thinking about some other RAM. Last resort is to go to strictly PASM for all I2C needs. I also recall that there was a time when I was uploading to EEPROM from .dat files, and for some reason I could only upload with a SPIN driver, but could read from both. I believe it was due to the EEPROM not being able to be written as fast as the PASM driver was wanting to write, but reading was OK. This back and forth from various I2C types was too much work.

Rayman

I think an SPI RAM or flash chip would use the same number of pins as SD card...
SD usually has some overhead required though, that you might not want if short on space.
If you look on my website for "Flashpoint", you'll find a driver for a SPI flash chip. There is also code for SRAM SPI chips.
There's no file handling though, so you'd have to tell it where to write and read from and how many bytes, etc.

The new EVE FT801 chip might solve a lot of your space problems, although it would add some complexity with another chip...

I guess I'd try the PASM EEPROM driver first, since it's already there and basically free...
I think you would have to kill the SPIN version, if you have that running too first...

Dave Hein

If you use pasm_i2c_driver.spin it will let the clock and data lines float when not in use. Assuming you use pull-up resistors the lines will float high. pasm_i2c_driver is derived from basic_i2c_driver, which is a Spin implementation. basic_i2c_driver also releases the clock and data pins when not in use, so these 2 drivers could be used together. If you are using some other I2C driver it should be able to work with the other drivers if it also floats the lines.

T Chap

Thanks, I will revisit that Spin/PASM same pin idea.

T Chap

Can someone please explain the way the VGA works: Is the entire screen residing in a buffer that is recycling at some rate per second, or does the LCD controller and/or LCD retain the screen info, and the screen only updates if the Prop updates the ram buffer. My perception is that the screen is updated constantly at a high speed, or rather something like 30 frames per second approximately. In other words, the ram buffer containing the screen data is sent repeatedly even if there is no new data. When I see the EEPROM derived data on the LCD, it scrolls across versus immediately appearing. I a trying to understand how the process works and what is affecting the redraw rate. My assumption is that the EEPROM is read into ram in chunks, and the chunks appear on the screen as they are received, which alludes to the screen being constantly updated as each 16x16 block of pixels is fed.

Rayman

The VGA, TV (and my LCD) drivers all kinda work the same way...

These are "tile" drivers where the screen is made from 16x16 pixel tiles with 2-bit color (pixels in a given tile can only have 4 different colors).
There is an array (usually called "screen") that contains one word for each tile.
The driver does constantly refresh the screen based on the data in the array "screen".

Each tile word in "screen" has 16 bits. 10 of them are used as a pointer to the actual pixels that comprise the tile.
The other 6 bits are used to define the set of colors that the tile will be painted with.

Usually the 10-bit pointer is pointing to a ROM font character.
But, we've figured out how to point them instead to a bitmap in HUB RAM to do simple graphics.

So, if you're seeing your bitmap slowly change with new data, it's because the tile pointer is kept pointing to where you are sending new bitmap data.
One way to avoid that to set the screen tile pointer to something else, like the space character for example.
Then, set it back to the bitmap pointer when the bitmap data is loaded.