Loaded a new Pico2 with the bootloader: bootloader_pico2.uf2
Created a new SD card with the two partitions
Created a folder called “pico2-apps”
Copied PicoMite_PICORP2350_V6.00.02RC23.uf2 into the "pico2-apps folder
Copied BOOT2350.uf2 to the root folder of the SD card.
When I start the PICOCAL
it goes to the Boot Loader Screen and I choose PicoMite
it erases flash memory
it loads the .uf2 file (as seen at the bottom as it loads)
I then get a blank screen
Any ideas if I missed something?
The only thing I can think of is when I created the SD card I did not do the step of installing the FUSIX image. I didn’t think I wanted or need that. Was I wrong?
Yeah, it’s busted. I’ve already spent way more time than I’m happy about trying to fix some of PicoMite’s more egregious failings over the past couple of days (dear god it’s so bad please stop trying to use it), and hopefully I’ll get it sorted shortly and can stop thinking about it.
The Machikania basic compiler that you can find posted elsewhere on this forum works perfectly. Consider using that instead if you’re not wedded to MMBasic.
I deeply appreciate the effort you’re putting into this.
I had no idea PicoMite was so poorly designed, or that it contained so many bugs.
For the end user, PicoMite is a great tool (I’ve only had my PicoCalc for 5 days, and I’ve already written a hundred scripts of scripts with it: I can work with matrices, polynomials, systems of equations, and I’m planning to expand my “library” of tools even further). It’s very convenient to use.
Again, thank you for trying to make it compatible with the bootloader (or the other way around!).
I looked at the Machikania basic compiler and it looks great. I didn’t see any .uf2 files for the Picos. I have never done the process of “Making” a file. The directions looked pretty cryptic, made for someone who has done it before. Are there any more detailed instructions somewhere? I would love to learn how to do it.
I find @adcockm ‘s last release of Picomite/MMBasic great and have no issues whatsoever other than lack of access to display backlight. I’ll carry on using it if that’s ok with you…
As @adcockm has said, go to the releases page for machikania. The “PC” version of the zip is the one you want, it has uf2’s for all the different Pico’s in it.
Apparently there’s a “pcconnect” application in the repository that can transfer files over serial but I’ve not tried it yet.
Ha! Yeah, if you like it and it works for you then feel free to ignore me. I’m putting in the effort to fix it because I know there’s a lot of people like you who would appreciate it, even if it’s nails-on-a-chalkboard to me. I just need to vent a bit to stay sane while working on it
I agree that the state of the official PicoMite code is horrible. One of my goals with the PicoCalc fork has been to keep changes as minimal as possible so the diffs make it easier to maintain and sync when Peter makes lots of changes all over the place with new releases as he often does. It’s also why I’ve been less motivated to work on it over time, or add new features to it because even with “surgical strikes” things can break.
I saw your fork and updates, but I’m assuming those are a work in progress? While all those whitespace changes make the code easier to read and work in, they make it a nightmare to try to keep in sync with the original, especially since Peter makes his own whitespace changes (sometimes actively making it worse). I tried something similar at first and realized it was just creating lots of work for myself since Peter’s “releases” happen daily sometimes, and people seem to want the latest even though many times those releases are broken and the only reason they happen so often is to fix problems while sometimes creating new ones. And while the #ifdefs for PICOCALC make even more mess, I ensure any new code or changes are always blocked out that way to make merges cleaner. Part of me hates adding to the mess, but I hate wasting time merging code even more!
Oh, I also didn’t touch the janky process of overwriting the SDK files, again because I wanted clean merges. Since that janky process is part of the official build, I figured the PicoCalc build needed to match.
Having a clean fork would be great, but I expect it would go the same way as the Windows port and the Linux port. It would be stuck on a version and doubtful anyone would want to port over any code changes from Peter’s constant updates. It’s good for an escape plan, and it"s the sane option, but having a “living” fork that merges with new changes at least brings new features and maybe the slight chance the official port will improve. I was kind of hoping for a stable official release that would be a good one to stop or at least pause on, but I doubt there will ever be one.
Anyhow, I created a couple of local git stashes with just your functional changes from your fork. Both seemed to be works in progress (or maybe I made an error and missed something?) as the flash size function alone wasn’t enough to get it working in the loader (and adding my function call changes to use the newer flash routines along with it didn’t help either.) And the backlight changes seemed promising but those didn’t work for me either. Guess I should have waited for an announcement, but I wanted to take a peek and also get started on merging your changes in.
Thanks for doing this! Support for the u2floader will be really useful and maybe it will even encourage some folks to try other firmware. I’ve spent the past week mostly using the loader and other firmware. The umac emulator was a nice surprise! I think what machikana needs most is more accessible documentation. The large text files kind of have the same problem as the large PDF for PicoMite. A document and plan for porting PicoMite code over to it would help as well. I’m not familiar enough with it yet, but I’m toying with the idea of eventually trying to make such a guide.
If I haven’t announced anything (and I haven’t), then nothing in my repo is usable. I constantly push for backup purposes, and will happily rewrite history on a whim.
As for preventing merge conflicts with upstream, that is not something that makes any sense in my WIP state.
Looks like I’ve gotten it to start up to the command prompt - there’s a subtle bug around the new flash API and multicore that I hit and had to raise an issue on pico-sdk about. It’s still not functional - trying to save made it lock up - but that’s mostly because of other code that I need to debug now that it can actually get that far.
The original code is so dumb. Loading and saving is done a byte at a time even though the disk functions all happily support block reads and writes. whyyyyyy
I’ll take a look later tonight when I get back home. Thanks for working on this!
Does this have changes for both pico2 and pico or just the pico2? I’m not too keen on pulling my module so I’ll probably only test against pico2 but I can post a build for others to test for the pico.
Ok, it’s building for pico1 again. Had to pull out the I2C refactoring, which isn’t a big deal.
(fair warning: I just did a force-push on my main branch. In case you already pulled it, you might need to do a hard reset to the upstream main before pulling it again.)
