Looks like it contains some suggestions and fixes for array handling. Given the speed at which Peter makes updates (impressive!), I’m definitely not going to try to keep pace with his RCs. I’ll try not to let it linger too long, but I think it makes a lot of practical sense to only focus on updates to the PicoCalc build for actual point releases and not the flood of RCs.
If the PicoCalc was ever considered a real target platform by the PicoMite crew then that would be the ideal solution. They’re already building binaries for everything else, and then it could be easily part of these RC releases with no additional effort. Playing nonstop catchup to Peter’s impressive dev cycle is not a game I want to play. But I understand why the PicoCalc may never be accepted or integrated by them as a platform, and I wouldn’t expect it to happen. I’m not even sure the Clockwork folks are really aware they exist, what they (Clockwork) may have done wrong, or how to properly react or respond to it. And that’s why I think the PicoCalc may forever be an unofficial platform that is only supported by community here that wants to try to sync up to the quick (and arguably erratic) development of PicoMite.
It’s a shame too, because I’m sure there are plenty of folks here who bought the PicoCalc specifically to learn or relearn BASIC and they’d probably benefit from the Back Shed community’s knowledge and even contribute to it. But as things are, most will never even know it exists.
After some badgering ClockworkPi have updated their homepage to be compliant with the MMBasic license and I am hopeful there are more updates in the pipeline.
There might be solution to the keyboard disconnect issue here… It mentions “other bugfixes from current firmware related to i2c and such”:
Though it appears to only be available as a binary, with no link to sources (yet). I found another updated keyboard firmware, with sources, that I mention below that post with links, but it only added features and didn’t seem to have any bugfixes.
Perhaps the problem wasn’t in changes to PicoMite, but was something to do with the keybaord firmware all along? I’ll test this out when I get a chance. Though since the problem is hard to reproduce, it might help if others try it too.
In what way was 1.1 better ?.. Im stuggling to find info re flashing the STM32 beyond using the usbC port too (lost the github thread), any pointers ?.
Did you see the new release of RC19 on May 2? It fixes the 40-column limit on editing and glitches in the display. Those alone would be worth revising your version. UKTailwind has the updated source on Github already.
Posted, but untested. Hopefully it works well. I know I’ve said it before, but I can’t constantly keep up with every minor update Peter makes to the code, especially mere moments after he posts it.
I haven’t yet created an account on TheBackShed, but I’ll do that soon. Then I can get notifications of updates to that thread. I also want to make a post and thank Peter for adding that video driver support, as it seems to be a very nice addition for the PicoCalc (and presumably anyone else using that display).
But these sorts of minor updates seem kind of silly to try keep up with anyway, especially when they are in the middle of folks at TheBackShed actively working on problems that aren’t yet fixed. The discussion on TheBackShed indicates there are still display bugs with this one that will undoubtedly be fixed soon, prompting another “need” for an update here, etc.
For PicoCalc, there’s another bug lurking. After data is typed at an INPUT statement, the cursor fails to move to a new line.
INPUT "What is your name";n$
PRINT "Hello, ";n$
What is your name?TOMHello, TOM
The problem is in PicoMite.c, around line 745. The PicoCalc keyboard returns 0x0A (\n) for Enter whereas most keyboards, generate 0xD (\r). I’ve shown the code to fix the problem in a Github error report. You just have to add the test for a PicoMite compile. I’ve tested my change and it works well.
Thanks for that fix, good catch! I’ve updated the github to include it, and it will be in the next release, sometime this weekend. I’m hoping to include some other stuff too.
First of all, thank you very much for your great work!!! I use PicoCalc with a Pico 2 W and everything worked great up to version RC20. With the following upgrade: WebMite_WEBRP2350_V6.00.02RC22_a.uf2
there is a problem! The Enter key is NO longer available in the programs. When Enter is pressed, there is no response in any of the programs. The Enter key is active on the start level, but not in any of the programs.
I can definitely live with downgrading to version RC20 – I just wanted to point this out.
Ah, this is something I should have mentioned in the release… For all other PicoMite platforms, the Enter key sends character code 13. The PicoCalc keyboard sends 10, so to handle it properly in the PicoMite application, it gets converted into 13 as expected.
But that means previous MMBasic code for PicoCalc that could successfuly detect a press of the Enter key with:
If Asc(a$)=10 Then GoTo EnterKeyPressed
will now need to be changed to:
If Asc(a$)=13 Then GoTo EnterKeyPressed
Sorry for requiring that code change, but there are several things in PicoMite that rely on it being a carriage return (\r) and not a linefeed (\n), and this seemed like the cleanest way to handle it. If it’s any consolation, it also means that the same code for detecting the Enter key could run on the PicoCalc and on other PicoMite platforms too.
EDIT: updated the release notes to include this information
As long as you’ve changed the Enter key to the expected value, how about changing the DEL key as well? Then you wouldn’t have to change as much in the code.
Interestingly (at least to me) I’ve just discovered/remembered that MMBasic for Linux uses \n for the [Enter] key - at the time I must have changed all the other surrounding code to cope with that. I would probably do it differently now; it’s several years ago and I have developed a much better understanding of MMBasic internals.
When I’m writing programs for MMBasic I usually check for the [Enter] key by comparison with both ASCII values 10 and 13 so as to cover my bases.
