The choice was made to balance out the amount of free memory VS the processing power. Since the RP2040 was the only target at the time the limited RAM and the fact Lua need quite a bit of memory to work I based the choice on a CGA. You also have hi res sprites the work up to 256 colours.Most computers I know like the Amstrad CPC 464/664/6128 or the C64 had an 160x200 16 colors mode. I tried to program a demo with 100 pixels height and that is far more limiting than having 160 pixels width instead of 320.2 - 16 colours 320 x 100
Also, these 64k machines used an 16k framebuffer of some sort, which is 25% of available RAM. On a RP2040 Pico, same proportion would become 64k, and 128k for a RP2350 Pico 2.
64k allows for 320x200 256 colors, 640x200 16 colors, 640x400 4 colors, and so on.
A more conservative use of 32k (like Atari ST) allows 320x200 16 colors, 640x200 4 colors, 640x400 monochrome.
I'll try to look if these 16,000 bytes are not too deeply hardcoded in the source and make a merge request to allow for 32,000 or 64,000 framebuffer at compile time.
With The RP2350 I've only dumped more memory into heap and really kept the two versions compatible. I'm looking more into the memory, the sound driver will use some space up and I need to keep that balance so Lua can still load and execute code. The RP2040 was running into issues with memory when I was doing maze algorithms on it. Took some tweaks to the firmware and memory manager to get it working.
That said the RP2350 in the current rebuilding state has 468940 bytes of heap that doesn't take into account I need to add a buffer between heap and stack. The stack is too small and overflows that's why there is a custom linker script. I can tell you that the code organisation isn't the best and trying to make this sort of change in the current code base is not going to be easy. and choosing a branch to use also not an easy choice.
Bottom line would more frame buffer work? Yes but I disagree as to the resolutions vertical should top out at 200 pixels the screen can't display much more than that and the header, footer and status bars are still there to take up the rest of the display. So monochrome would be 640x200 double buffered maybe. then do 320x200 16 colors, 640x200 4 colors, and what ever 256 works out to be. you can see the graphic output here viewtopic.php?t=349834&hilit=image+format#p2137869
You could call it EGA Mode since I based the current version on CGA. but I think 32,000 bytes is the max I would use. the config.h would need a setting line #define PT52_EGA_MODE 1 then the video drives would need to be updated to handle the extra data.
The libraries all use 16000 and there are calculated addresses plus all the address that are calculated off the base address would all need to be updated. Thankfully VRAM brakes all the memory areas up so they can be addressed by section. I think this change is too big for the project in it's current stage core features are still missing or incomplete and some of them will require more memory to work.
Statistics: Posted by DarkElvenAngel — Fri Dec 20, 2024 12:19 am