MMBasic “mm.hres” and “mm.vres” commands return 320 and 480 values instead of 320x320 real resolution.
I think it is related to the driver ILI9488 used by PicoMite firmware provided with PicoCalc.
The resolution 480x320 seems to be hardcoded in this driver.
The problem is that with the Pico 1 you can’t use framebuffer fonctions with this huge resolution because you can’t create both framebuffer and layerbuffer (not enough memory)
A solution is to replace the Pico 1 provided by a Pico 2 which has more RAM.
But maybe someone has another idea ?
That’s just a plain old bug with the PicoCalc patch, MM.VRES should return 320 … I’m not a hardware guy but think the wrong value is something to do with how Clockwork Pi have implemented hardware scrolling for the display.
It’s a real shame that Clockwork Pi don’t appear to have reached out in advance to the PicoMite maintainers … and I think by not doing so they have gotten off on the wrong foot with the people best placed to support them.
Note that even at 320x320 additional display buffers take more RAM than is comfortable. Existing PicoMite games target the PicoMiteVGA and Game*Mite which have 320x240 displays and are already pushing up against the RAM limits.
Thank you for your answer, I saw your work on Game*Mite, it is a really good job.
PicoMite should be more popular, I think PicoCalc will help, I didn’t know PicoMite before and I bought PicoCalc for it.
With a Pico 2 and the firmware from @guu, I’m now able to work with Framebuffer. F and L buffer take 75Kb each in memory so 150Kb in total !
As expected, using FRAMEBUFFER Merge function is really to slow with a 75Kb buffer size.
I made a try with the Flappy Bird game from GameMite by replacing the “FRAMEBUFFER Merge 9,b” command with a “BLIT Merge 9,0,0,320,240” command. The result is not as fast as the GameMite version but almost playable:
I can’t use the coprocessor for framebuffer operations because there is a bug with the firmware (crash).
Maybe by using a 256x192 resolution (25Kb buffer for BLIT Merge) the game will be more playable.
Having a feature on PicoMite for creating custom framebuffer size could be great.
Having a feature to use a resolution of 160x160 (13Kb for Framebuffer) and scale it x2 to have a full screen game could be great too, we will have a render like Pico 8 games
I saw your work on Game*Mite, it is a really good job.
Thank you, not as pretty as the PicoCalc but I was pleased as I’m not a hardware guy.
PicoMite should be more popular, I think PicoCalc will help …
I hope so.
I can’t use the coprocessor for framebuffer operations because there is a bug with the firmware (crash).
co-processor ?
Maybe by using a 256x192 resolution (25Kb buffer for BLIT Merge) the game will be more playable.
Having a feature on PicoMite for creating custom framebuffer size could be great.
Having a feature to use a resolution of 160x160 (13Kb for Framebuffer) and scale it x2 to have a full screen game could be great too, we will have a render like Pico 8 games
In my opinion a sensible and hopefully feasible firmware modification for the PicoCalc would be to support two MODEs (the PicoMiteVGA has a MODE keyword), one for the existing 320x320 resolution and another for a letter-box 320x240 for maximum compatibility with the (small but) existing PicoMite game development community … and also to keep the RAM requirements for extra screen buffers within more reasonable limits.
Note that I’m just sounding off as an MMBasic enthusiast, I’m not intending to be a PicoCalc customer - including import tax and batteries it would cost me in excess of 100 GBP for a device I have no practical use for (a role already filled by my DevTerm). It has however enthused me to look into an Android port of MMB4L later in the year, with a PicoCalc inspired UI.
