Yeah I’m not sure what’s going on, why it failed, and why it now works 
I guess it has to do with how the pico2 bootloader operates..?
Is there a way to have autoload option survive uf2 reinstallation trough the uf2 bootloader?
Changing drive at every relaunch gets old fast…
I struggled with this too. The only thing I found that sort of helps is to get your options set the way you want, with any shortcut keys assigned, etc. Then do something like this (with whatever filename you want):
B:
OPTION DISK SAVE "default.opt"
After switching to something else and coming back to PicoMite in the loader, do an:
B:
OPTION DISK LOAD "default.opt"
You have to save it to the SD explicitly and load it from there because anything on the A: drive is in flash and will be gone when you come back.
That will take care of some things you’d want to survive when switching back and forth. But I’m not aware of a way to automatically replace code that was stored in flash. You can manually do it, but that’s a pain. I’ve just been avoiding using the flash slots for libraries or code storage entirely when using the loader, which is unfortunate. Instead I’ve got a key code assignment in options that will just run a script. I’d love to know a practical workaround for the flash contents too.
BTW, this was also a problem when not using the loader, and just flashing a new, clean PicoMite firmware update. That was another reason why chasing every update from Peter was annoying because I got tired of setting up my environment manually every single damn update.
reference from manual:
Lately I have been thinking about an error message from the game “Mixed-up Mother Goose” that said something like “X.Y.Z. You did something we did not think of” when running on a faster cpu because of loops used for timing 
Yeah but you still have to manually load that option file. It would be great to have a way to avoid typing it 
My pain is to merge the changes I made to the @adcockm sources into the @pelrun sources, just now I gave up doing this and will wait for V6.01.00 to be released.
The last weeks I have been working on improving PicoMite for PicoCalc by rewriting the keyboard and RTC routines, to correct a few flaws in the initial implementation. Implemented persistent options, syncing backlight status with the keyboard using a modified bios, increased the I2C bus to 100/400Khz with the ability to change speed if required, mm.info(bios) to get bios version. The final result based on V6.01.00B10 looks very acceptable to me but I do not want to release it into the public because it might cause difficulty to bring the “official” V6.01.00 release to the PicoCalc. To avoid chaos I do not want to create another Github repository (competition) (me needing to learn github) because Michael (with pelrun) has been doing a good job that should be appreciated. After the official release I will adapt my changes so these can be implemented if wanted.
Please note: I will be away a few days, it may take some time for me to react.
4 Likes
Just for your info, GitHub forks aren’t “competition” per-se, they’re the mechanism for collaboration. Git provides tools for tracking and merging branches from multiple forks, so having changes on a fork with a common history makes integration work a lot easier.
I certainly can work with the diffs and working tree archive you generously provided to me (when I finally have time to pull out the laptop again), but it means I essentially have to recreate your repo from it instead of just doing a git remote add and a fetch.
No worries though, it’s not actually any more difficult on my end for a change set so close to the current tree.
3 Likes