Well PSRAM is about as fast as flash so if that was the only access to it you might pull it off but the updates would likely throw the timing off. I use yscale = 2 in the scanline driver I never did work out how to flip that on an off at will and I've only ever used 640x480 mode. In order to get the driver output I have now I'm overclocked to 250 MHz.FYI, here's my unfinished spreadsheet with some video modes:
Capture d’écran du 2025-02-02 21-52-50.png
I didn't include scratch X & Y and reserved 64K for system for environment, buffers (sound) and time critical code (scanvideo and sound).
I don't think PSRAM could be fast enough to be used as framebuffer. https://shop.pimoroni.com/products/pico ... 8911904851 does this but with double buffering: one RP2040 writes to one PSRAM when the other RP2040 reads the other PSRAM.
On another topic I'm still trying to find an file format for images which would not not need as much as 36K to decompress like PNG (see https://github.com/bitbank2/PNGdec), would handle 2/4/16/256 indexed colors and be supported as working files by modern software like GIMP.
I was looking a while back for such an image format to use. since my buffer was only 16K I just opted for a bin format. I looked at run length encoding and some other tricks. I have a python script somewhere to convert images to the format needed to directly load the frame buffer but I rarely use it. It also was able to generate the CLUT for the image so you got the best result. Now I have ppm format mostly I use it for the boot splash and soon I'll also have the Hard fault and Panic screens too these are generated at compile time with a Lua script. When it comes to image files on device I looked at things this way I've got a 16GB SD card that can hold a lot of 16K images and even at 64K for my EGA mode that's still a lot of images. Lua can process and convert ppm ascii and likely binary images directly on hardware to frame buffer. do that with C code and it shouldn't be too slow. The question is how are your colours arranged for the frame buffer? Are they fixed or do you use a dynamic table? PT52-VGA uses several look up tables so colours can be tweaked depending on what image you want to display, you can see the output in this post viewtopic.php?t=349834&hilit=image#p2137869. PT52-VGA also has sprites, font ram, an overlay all stuffed into the VRAM so when I use 64K for the frame buffer that's really 79,584 bytes for everything.
I've found GIMP a real pain to setup with index colour the colour table is never in the right order. I'm honestly thinking of just writing scripts to convert image or assets
UPDATE: Just because I had to see it I wrote a script to render ppm files right to the frame buffer as predicted it was dirt slow but it works. But when you use VRAM save and then VRAM load to put the raw buffer back it's quite quick.
Statistics: Posted by DarkElvenAngel — Mon Feb 03, 2025 1:21 am