This confuses me as well. If you want to try something from a different repo, download everything in the folder below, including the assets and music folders, it will die horribly without them. Chdir into the pipboy folder and run pipboy.bas and see what happens. It is a fairly small program, but it does load a couple of images and can play MP3’s. I’d be curious to see if you have the same problem.
Edit: Since you are not using WebMite, you will probably want to comment out these lines;
IPAddress$ = MM.Info(ip address)
Text 25,185, “IP Adress:”
Text 25,200,IPAddress$,l
Thanks for testing (and providing the details) @cjstoddard.
Not sure if this has already been tried or suggested (sorry if I missed it if posted above), but @DamienGrief you might try erasing your flash completely and then flashing the firmware. This seems to be a common suggestion on TheBackShed for all kinds of weird behavior, and seems to be needed between PicoMite version updates that had significant changes with how they handle options in flash. I’ve never been clear on when it’s actually needed, but it’s one of those “maybe it will fix things” type of approaches, and it can’t hurt (beyond reducing flash life ever so slightly). If it does somehow fix the memory error, then I’m guessing you had flashed something else on the Pico2 and the contents of flash that PicoMite uses for options and such were somehow not initialized as expected.
The download for the flash “nuke” (from Raspberry Pi’s site) is linked here:
@adcockm - The nuke flash didn’t work. Same issue. Also, this is a brand new Pico 2. It never had anything on it before this, but I tried it anyway.
@cjstoddard - The Pipboy program runs just fine. But it errors and crashes when I try to play any music with the error “Error: CPUSPEED >=200000 for mp3 playback”.
You have to overclock your CPU to play MP3’s. With a Pico 2 not running WebMite, you can safely over clock it to 300000 or more, but I found 250000 is plenty for everything I do, even when I am not using WebMite.
option cpuspeed 250000
That is really interesting. Like I said, pipboy.bas is not a terribly large program, less than 220 lines. But it does use the framebuffer and decodes MP3’s, so I don’t think the problem is the CPU. I can’t think of a single reason why old text only programs don’t run, but pipboy.bas does.
That did it. I was able to play the MP3 just fine. Though, it was really quiet even with my volume on max. Haven’t tested sound on this before now.
Do I need to do the option cpuspeed command every time I launch the device if I want to use that? Or will it have saved that once I set it once?
That is really interesting. Like I said, pipboy.bas is not a terribly large program, less than 220 lines. But it does use the framebuffer and decodes MP3’s, so I don’t think the problem is the CPU. I can’t think of a single reason why old text only programs don’t run, but pipboy.bas does.
It seems to be related to the size of the program in memory when it’s first loading. But I have no idea.
Maybe it is something to do with rlauzon’s repo. Grab lunar.bas off my repo, see if it runs. Hypothetically, they should be the same, because the lunar.bas on his site is my code.
OPTION CPUSPEED is a permanent option. It’s saved for future reboots. See the 6.00.01 manual starting at page 88 for all the options available. The second column of the table will have a check mark if the option is permanent.
So we know its not your PicoCalc. I pulled his repo down using git clone on my Linux box and zipped it up for you. Here is Google Drive link, unzip it to your SDcard and see if they work now.
These all work. Which is weird. Because I downloaded them multiple times from the original repo before this thinking it was a corrupt file or something but it didn’t make a difference. Always got the memory error.
So… I downloaded the archive from the Google Drive share above. And I downloaded the archive from github by using the code link and “Download zip”. Then I extracted both into separate directories and compared all the files and they were identical, byte for byte.
Cloning the git repo should end up downloading the same files, but I just downloaded the zip for convenience.
I really don’t know what’s going on with this. How are you downloading the files from github? If you want to download individual files, then click on the file to view it in github, and then click on the download button. That’s why I just downloaded the zip file from github.
is somehow significantly different from the other methods of downloading the files. Earlier in the thread, tabemann suggested there may be an issue with how Windows handles new lines. Windows uses both a Carriage Return and a New Line (\r\n), while Linux only uses a New Line (\n). I have no idea why this would cause this error. though.
I am on Windows, but I downloaded the files with the download file button on the GitHub webpage. And when downloading them from @cjstoddard’s github page the same way, they worked fine. It’s really odd.
Current release was from a clean build and produced no errors. I suspect it’s because of the hacking around in the Pico SDK that the official PicoMite build requires. More details at link.
