That’s a very good point! Currently it’s using 0xd4 (PicoCalc’s value) rather than the default 0x7f (PicoMite’s expectation). I initially re-defined a few other keys that way in Editor.h and Hardware_Includes.h, and I can clean all that code up and move it into I2C.h this way. Then the PicoCalc can continue to send the codes it does, and they’ll all be translated to the codes that PicoMite expects, rather than having it look for the PicoCalc-specific ones. Plus, it keeps the translation map together in all one place, with I2C stuff, where it should be.
And @Ben, as @thwill said, it seems like changing the STM32 code to fix this would cause a lot of chaos elsewhere. There are also already far more skilled people working on updating the STM firmware/BIOS, and they’re being careful to ensure it is backwards compatible with all the current uses by MicroPython folks, PicoMite, Arduino, and other firmwares. Arbitratily changing it to suit PicoMite, and/or require PicoMite users to use a specific version of the STM32 code would probably annoy (and confuse) lots of people.
I’ll switch over to the other thread when I release it in a bit, but I also noticed there’s an RC23 on the BackShed now. I’ve already merged that code in. And I did something I’ve been waiting a little while to do – I removed all the old display code from the original PicoCalc port. Previously I had just commented it out, in case I missed something or needed to reference it again, but it seems like the mainline/upstream PicoMite code is working fine so it’s time to clean up that old stuff. As a nice side effect, it means, the amount of changes between the upstream code and the PicoCalc version is shrinking. Next release will also have the keyboard key mapping cleanup. That will mean the mappings for mmbasic programs will be expected to match the documented mappings in the PicoMite manual, and not the unique mappings the PicoCalc produces. I’ll note that in the release notes.
Thanks for the quick reply. I changed my programs and now everything works fine again.
By the way, I am eagerly following the project to load the firmware from the SD card, which unfortunately does not yet work with the precompiled uf2 files. That would make the PicoCalc very flexible to use.
And a calculator edition of PicoMite or, in my case, WebMite would also be nice, of course…
I’m also very interested in getting the SD_Boot firmware loader working with PicoMite. The last I looked, it was only supported on the Pico, but I see that it now supports the Pico2. The problem with the PicoMite port that will need to be solved is the way in which it accesses flash. Since the bootloader occupies a portion of flash, it moves the start of everything else, so assumptions about where PicoMite exists in flash, and where flash starts will be incorrect, and things won’t be where they are expected to be. This isn’t an impossible problem, by any means, but it’s something I’ve been putting off and kind of dreading, since as far as I could tell when I looked into it, I’ll need to very careful. PicoMite uses flash space for various things, like the 3 slots accessible by the FLASH command, and saving various persistent values across power cycles.
There’s a WebMite version for PicoCalc included in releases. That’s actually the most tested one because it’s the one I’m using on a daily basis. I don’t often actually test the PicoMite build for the Pico2 or the build for the Pico, but those should be ok as well, and if not I hope someone lets me know.
I don’t often actually test the PicoMite build for the Pico2 or the build for the Pico, but those should be ok as well, and if not I hope someone lets me know.