But seriously, the PicoCalc came out of nowhere and ClockworkPi made some missteps regarding licensing that made people that matter in the MMBasic community “unhappy”.
It will most likely all turn out alright in the end.
As I have said before, I don’t think it is necessary to keep up with Peter. A quarterly update is perfectly fine, I don’t think anyone will die if they miss out on a couple of RC updates. The goal here should be a stable working image that breaks as few things as possible. Me personally, I will probably update once a year, heck the last time I updated my MaxiMite 2 was in 2020 and it works perfectly fine.
To amplify what Tom said above, here is the page discussing RC19 on the TheBackShed forum:
And here is a short video clip that Peter put out (link is also on the TheBackShed forum page referenced above, but I also put it down below for your convenience) that shows how fast scrolling can be on the IL9488 display if implemented properly:
Yes, but I think that’s because the firmware itself resides in flash. The missing amount is about the same size as the firmware itself. And Picomite carves out a little more for the 3 (numbered) user accessible flash slots. It must use a little for saving persistent options too.
The original Pico will have a lot less flash space free. I haven’t swapped mine back in for a long time, but i’d be surprised it it even has 1MB free. It’s probably more like 700KB or so.
Long story short, best to use the SD card for storage for most stuff unless you have a reason not to.
You’re missing the point here, that command is not for showing free space but total size of the flash chip !. Makes me think a parameter hasn’t been set correctly or maybe a bug. I’ll try the supplied pico for comparison asap…
I still think the mm.info(disk size) is showing the flash space that is partitioned to be used for the A: drive filesystem.
The flash that the firmware resides in shouldn’t be accessible from the application directly and would not be part of the filesystem. And similarly, the flash storage that PicoMite is using for the 3 slots is not a part of the A: drive and is accessed internally by PicoMite. Same for the little bit it uses for permanent OPTIONS storage.
The mm.info(disk size) command doesn’y imply it’s total flash available on the hardware – it specifically says it’s the flash filesystem. I don’t think there is a command in PicoMite to show total available flash on the hardware.
790k sounds about right for the Pico that comes with the device, and 2MB seems about right for the Pico2, if it’s just the available flash partitioned for use as the A: drive.
Yep, I’m excited about this as well! Just haven’t had time to sync the code and try it out. I’m hoping to get to that soon. Been a long day, but I want to see it working too and get it released. It was a nice surprise to see that included in RC19!
Need your coffee link sir, never done this before (you must be worth it someone said ). Yes I notice upping clock speed beyond say 320,000 on pico2 can cause scroll corruption (as result of repeated prints), will be interesting to see how rc19 behaves.
A new release is up. Details at the link. It is not bug free. If anyone else wants to take a look, I’m open to suggestions/fixes, but someone else has already pointed out a different bug on TheBackShed (and it sounds like it might be related to fonts, which is what I think is going on here too), so I suspect the fix might be found in the PicoMite code rather than the PicoCalc customizations.
I may take a look at it again when I get a chance, but for now I’m going to get some sleep.
Working well here my friend. Currently running at a higher 360Mhz and 44.5c doing constant graphic drawing on a warm day (bit of a smell coming out of the back so thinking heatsink needed). No corruption noticed so far in constant scrolling text though ! (repeated ‘print’) so seems better in that respect when overclocked.
I notice an odd change in the flash list though, now seems to report where the slot file came from ? (b:/). UPDATE the b:/ has now vanished .
The only minor font issue I noticed (in the last release too) is in the editor when moving the cursor. If you pass a character that drops below the line (say p,y,q,g etc) the cursor erases the bottom pixel or two !?.
New release, based on the RC20 update that was posted earlier today. Seems to be mostly fixes related to the recent code churn around the display code.
Naaa font issue in editor still there. Running fine otherwise yet like you say no fixes or additions that matter to me right now. Hopefully a coffee on its way for the next release (got to break the pattern lol)