PicoCalc 6.01.00 RC23 Available for Download

When I run pure PicoMite on a standalone chip I get good output.

20-12-2025 04:08:53
 18.74033914     275.5178958     5.263124214    -8.173535009
 15.42289086     294.6744188     5.942979712     7.409734178

You’re getting closer! Instead of the correct answer above, now I get

20-12-2025 04:08:52
0       220.3482136   0    0
0       220,3482136   0    0  

Not me, that is ….

https://github.com/UKTailwind/PicoMiteAllVersions/commit/85cba0e2499e4d5d55dc88abc8b5d6a9d85590e9

I have nothing to do with that part of the mess ….

There seems to be a disconnect between Peter’s uf2 files and UKTailwind’s source. Peter’s uf2s work with the example I gave. UKTailwind’s source (with your changes), doesn’t run properly (see my last post here).

Please download picocalc_v6.01.00_rc27e.zip

GPS.c was uploaded three hours ago, I did run your program and the result looks different now.

Please note that I did a rebuild with the new GPS.c and I did not change the revision code.

It’s fixed! the ASTRO command is now working properly, thanks to an updated GPS.c file that was sent to UKTailwind. Since there were no PicoCalc-specific changes to it, it dropped right into the PicoCalc modified files as-is.

We’re crossing wires here! :slight_smile: I found the updated GPS.c and compiled your code just before you posted your message. Now I’m satisfied (until certain people decide to add more new features and not test them first)

The amount of random stuff built in to the MMBASIC interpreter as keywords in is vast and at times bizarre(a multi-algorithm PID controller? Wii Nunchucks?!). How much of it works? Who knows!

I can see that they probably don’t want to make having access to a SD Card necessary for additional functionality, but if I was running it I’d be prioritising implementing some kind of flash based virtual file system a-la MicroPython so that libraries written in MMBASIC could be loaded. Without either, as I understand it, every program has to be in one file which makes distributing any non-trivial functionality in MMBASIC unwiededly. Perhaps that doesn’t fit their vision of retro computing, or maybe the author doesn’t like his own language and prefers C.

You can create a library and store it so it doesn’t disappear at power-off. Any SUBs, FUNCTIONs, or code in the library will be available to all BASIC programs as if they were built into the system. I have a number of constants defined there such as TRUE=-1. FALSE=0 so I can use those keywords in my programs. I also have some functions I use a lot so every program I write can call them without defining them.

Did you see that Peter has added TYPE…END TYPE for user-defined data types (RP2350 only)? I don’t see the source on the UKTailwind GitHub site, though. Is there some other place to get it? That’s a great addition to MMBasic and I hope it makes it to the PicoCalc version!

1 Like

I have seen the latest developments and I have not seen any source files yet.
I think it will take a little bit of time before they are placed in the file dump on Github.

1 Like

I’m having a problem with 6.01.00 rc27e on a PicoCalc with the stock processor.

When running this firmware without UF2Loader, I get a restart. Here is how to reproduce the problem.

  1. Install ‘pcc.bas’ from GitHub - rgpapp/PicoCalc_PCC: PicoCalc Commander (PCC) is a dual-pane file manager and launcher for PicoCalc written in MMBasic onto A:
  2. run “pcc
  3. Q to exit
  4. Power off/on the PicoCalc
  5. Run “pcc
  6. “invalid address…resetting” message flashes by, the screen clears and > prompt is displayed.
  7. If you again Run “pcc it works fine this time.

With UF2Loader, everything works fine, except when you power off/on, the UF2 bootloader seems to be corrupted since I only get a blank screen.

Any idea why this is happening?….thanks…..Brian

1 Like

I been trying to find the root cause for the “Invalid address” error but I have come to the conclusion that too much flashing has reduced the magic smoke in the chip and it is now having a problem to get up to speed on reboot.

The could be some truth in the above, I have a few Pico 1 boards with this problem, I don’t know why it happens and I been unable to find the cause. There simple solution is to replace the Pico 1 and hope that the new Pico 1 does not leak magic smoke, another solution is to replace the Pico 1 with a Pico 2 because there is no evidence that Pico 2 is leaky. If that is not acceptable then you may be able to plug the hole by giving the Pico 1 a good spanking, you can do this by entering “OPTION BADPICO 1” on the console.

I don’t know anything about UF2loader, maybe the author can say something to this.

Ummmm I did a LOL when I read your post, but I tried entering OPTION BADPICO 1 and the problem disappeared! I then entered OPTION BADPICO 0 and the problem returned!

What does turning the option on do???

(I’m going to try this with UF2Loader next)

UF2Loader’s bootloader still gets corrupted. :frowning:

1 Like

It causes an additional restart after power-on. The problem is that something is causing an exception error restart and then everything works as normal. After restart the option causes a memory location to be checked, if this location is not set then it is updated and a restart is done.

Just tried rc27e and although at first seemed fine has already errored with “option backlight kb 30 Error : Invalid in a program “

‘Option backlight kb’ was one of @adcockm ‘s additions…

AFAIK this should not be possible because I removed that option. Under what conditions did this error appear ? This option has been replaced with “OPTION BACKLIGHT KBD” and “OPTION BACKLIGHT LCD”.

While testing I found that there is a problem that I must look into, the command “OPTION BACKLIGHT KDB” without a value causes a reset with the error “invalid address”. I will attend to this problem in this year :wink:

1 Like

Ah…. It was in my autorun program. I’ll try your new commands. Guess the range is 0 to 255 for both ?

Also notice ‘RTC gettime’ no longer functions correctly (yet doesnt generate an error via MM.Errno !?). My own RTC program still works perfectly though. I think I remember Peter saying he’d changed something re RTC recently ?, I’ll check through his posts on the Backshed.

The RTC GETTIME has been modified by me and the changes Peter made have been ignored BECAUSE of the use of MM.I2C. The problem is that original code for RTC and the keyboard use MM.I2C in the background which corrupts this value if I2C commands are used in a program and the I2C protocol has been implemented incorrectly. This is the reason why phantom I2C devices appear when using “LIST SYSTEM I2C”. If you let me know what the problem with RTC is then I can look into it.

1 Like