ville56 said  

typing  ~  character and CR at the commandline makes the firmware unresponsive (hang) which can only be cured by HW reset.

Peter,
I have implemented the tilde MM.xxx function on H7 and it works OK and errors ~ as an invalid character when not a function. The differences seems to be in isnamestart
~ is allowed in the current Picomite code, I think its a typo, the period should be allowed in lieu of the ~.



Footnote added 2025-03-25 13:23 by disco4now
OK probably not a typo. I see it came with 6.00,02RC1 (or 0).

Confirmed

"~" on the commandline (console) hangs the pico (GEEK), can only be revived with hard reset. Also in RC6.

Volhout
Edited 2025-03-25 17:02 by Volhout

One has to ask why anyone is typing a ~ on the command line when not enclosed in quotes. I'll look at the issue but it doesn't seem critical in the greater scheme of things.

Gerry: I don't understand your change. allowing a . will compromise number parsing
Edited 2025-03-25 18:35 by matherp

  matherp said  

Gerry: I don't understand your change. allowing a . will compromise number parsing

Peter,
Sorry,I have not made that change, just a wild guess on my part as to how the ~ got there. When I looked back at the source before RC1 (maybe RC0 as well) it was just the _ allowed, so no . or ~ previously allowed.
i.e.

In RC1 the ~ was added, was this for the PIO stuff?

On the H7 with neither . or ~ the MM.xxxx stuff using the tilde function seems to work OK. Typing a tilde at command line tells you its an invalid character, no hang.

Gerry
Edited 2025-03-25 19:08 by disco4now

RC7 updated

Fixes the ~ issue
Fixes a bug that Gerry found and fixed
Gives about 1.5% performance improvement on code with lots of function/subroutine calls

Where is MM.STARTUP supposed to be located? I saved this:



under the name MM.STARTUP but it doesn't run when I boot or reset the processor
(Pico 2 W)

I'm using RC7 from March 25.

  Quote  

Where is MM.STARTUP supposed to be located?

It isn't supposed to matter where in The program or library you put it, but in the past I noticed if it was at the end of a program sometimes it didn't run. Now I put it near the start and it always runs.
Currently using it in a 2350 VGA RC7 without issue.

Edit.
Moved it to the end, after the END statement and all other Subs and it still gets executed at start-up.
Edited 2025-03-25 22:21 by phil99

Footnote added 2025-03-25 22:31 by phil99
If you add Print "Startup running" to it you will get instant feedback if it does work.

WebMite MMBasic RP2350B Edition V6.00.02RC7

When using the inbuilt "LIST PINS" command, invoking it a second time now displays the following error

CLEAR (or ERASE _q%) works as designed and LIST PINS will now list one more time.

Previously, it seemed as if the command cleared used variables at the end of its run, as it could be run again with no error.
This error appears to have crept in sometime since B17, but I've been off line for a few days and cannot confirm which RCs were OK and which were not.

Just tested List Pins multiple times on a 2350A VGA RC7 without issue, perhaps only a problem on 2350B?

  Quote  

When using the inbuilt "LIST PINS" command, invoking it a second time now displays the following error
Error : _q% already declared

Not for me. Are you calling it from within a subroutine?

  Quote  

perhaps only a problem on 2350B

There is no WebMite RP2350B - perhaps that is the issue if BarryH is using a third party board - the WebMite firmware doesn't support a RP2350B and the LIST PINS may be getting confused. I've tested on the official Pico2-W and there is likewise no issue

perhaps only a problem on 2350B

On the WeAct 2350B card, the command works correctly (PicoMiteRP2350V6.00.02RC5)

  matherp said  

  Quote  

perhaps only a problem on 2350B

There is no WebMite RP2350B - perhaps that is the issue if BarryH is using a third party board - the WebMite firmware doesn't support a RP2350B and the LIST PINS may be getting confused. I've tested on the official Pico2-W and there is likewise no issue

most likely then, since reports from other modules are OK - thanks
Third Party Board = Pimoroni Pico Plus 2W
Waiting for the go-ahead to order the updated reference design with the RP2350B onboard from JLCPCB

  Quote  

Waiting for the go-ahead to order the updated reference design with the RP2350B onboard from JLCPCB

https://www.thebackshed.com/forum/ViewTopic.php?TID=17301&P=11

  PicoMite manual said  

GUI LED #ref, caption$, CenterX, CenterY, Diameter, Colour
This will draw an indicator light (it looks like a panel mounted LED).
When its value is set to one it will be illuminated and when it is set to zero it will be off (a dull version of its colour attribute).
The LED can be made to flash by setting its value to the number of milliseconds that it should remain on before turning off

A minor discrepancy at the command line - the flash setting doesn't work, it just stays on until turned off by command.
In a program it is as per the manual. If this is intended perhaps the next manual could mention the difference.

RC7
not a problem, just noticed something of minor importance
>OPTION LIST
displays ( _ and in HEX )

LIBRARY_FLASH_SIZE 2E000

> OPTION LIST
PicoMiteVGA MMBasic RP2350A Edition V6.00.02RC7
OPTION SYSTEM I2C GP14,GP15
OPTION FLASH SIZE 4194304
OPTION LIBRARY_FLASH_SIZE  2E000
OPTION COLOURCODE ON
OPTION KEYBOARD US
OPTION CPUSPEED (KHz) 360000
OPTION RESOLUTION 800x600
OPTION DISPLAY 55, 133
OPTION SDCARD GP13, GP10, GP11, GP12
OPTION RTC AUTO ENABLE
>
Edited 2025-03-26 15:57 by phil99

  phil99 said  

Which version?
May be a 2040 as 2E000 = 188416 ?

You see it
OPTION LIBRARY_FLASH_SIZE  2E000
But HDMI/USB/2350 RC7
Edited 2025-03-26 15:59 by electricat

The name OPTION LIBRARY_FLASH_SIZE is a bit misleading. It was historically the size of the flash required to hold the library in the original Micromites and Armmite F4. In those the library is actually tacked into the end of the Program memory, so having the library meant you lost a little bit of program memory, LIBRARY_FLASH_SIZE was used internally to tell the system how much, based on the actual size of the library code.
On Armmite H7 and the Picomites the library has its own dedicated flash and a known maximum size. The Option LIBRARY_FLASH_SIZE in these is now used internally to indicate a library exists and is the actual address of where the library is located.

  disco4now said  

The name OPTION LIBRARY_FLASH_SIZE is a bit misleading.

Bit off topic.

I highly liked idea of LIBRARY, especially as posibility to add commands.
For example added for myeself two simple: CD and CD.. as fingers makes it type faster instead of chdir "b:\" or chdir "..  

But I also wrote two 'system' utils for myeself (might be interesting for others too). Will share when finished, but did not solved minor problem yet somehow I am not satisfied myeself.

Two programs I wrote is rather independent utils called from cmd prompt and not SUBs aimed to call from running program. We could call them commands, but they are not. Still makes user`s life easier and more comfortable.

Problem is. If some program RUNS first time at cmd prompt typed in, or by pressing custom Fn key - they will run fine. As RUN clears any vars before start.
But if I would run next time, exit and run again, chances are - previous variables are still there declared and containing values until I CLEAR, RUN , NEW or F4 from cmd prompt.

I added on ERROR SKIP nn to skip DIMs as Peter suggested and it pass through them. But later it throws error on first met LOCAL

[LIBRARY] LOCAL somevar
Error : Local variable already declared.

In general - not a problem. Can be used CLEAR, RUN / F4 (not always NEW if user is on to editing something), but from potential users` perspective I should do it for them silently, so they will not be annoyed "it does not works" and it also makes it not so 'quick' to call/operate using custom optionally Fn key tied. Not good.

What came to my stupid head this morning (to be added as 'chruches'), was declare some VAR at the begining, get VAR`s adress and clear ~18 kb of varaible space on next run as it seems to be fixed area , not dynamical. (ERROR SKIPping VAR1 itself on next run) and then, using some MEMORY SET clear VAR space, but then LOCAL and STATIC are stored in heap (I believe), not in VARS area ?? If I would baypass LOCALS using ON ERROR SKIP , then random values would be there still. Erase LOCAL on every function or sub exit not tried if it will work. And still not elegant.

Stucked here for a moment with this obstacle. Maybe walking roundabouts.

I have a feeling, release candidate soon will be release status, so allowed post here instead of starting new topic.

P.S. Just in case, what I am writing here is not anoying, crying, asking for improvements or something. And please forgive me my english sentence structure. I better speak other two I know  
Using MMBasic makes me wonder and I enjoy it like a kid   . Reading the manual like it's the Bible, worshipping developers like gods.