edit: maybe irrelevant but I mentioned, that "mm.info(fontwidth)" was changed into "DateTime$(fontwidth)" at one line in my program which persisted during update. Edited 2025-04-02 21:24 by dddns
Posted: 11:56am 02 Apr 2025 Copy link to clipboard
phil99 Guru
Sometimes updates involve changes to the allocation of command tokens so the main program and library routines, which have already been tokenised will have those commands changed. When that happens it is best to reload them all so they get new tokens.
Posted: 12:35pm 02 Apr 2025 Copy link to clipboard
ville56 Senior Member
RC9 needs to reload the basic sourcecode, the tokens seem to have changed. Same here with another program, mm.info(pinno gp0) was the troublemaker. Just reloaded and all was good again.
Posted: 01:12pm 02 Apr 2025 Copy link to clipboard
mozzie Senior Member
Peter, Many thanks for RC9 and the MM.FLAGS function, being able to check the state of the entire register is important IMHO. Also makes checking of multiple flags at once is possible.
Regards, Lyle.
Posted: 01:46pm 02 Apr 2025 Copy link to clipboard
homa Guru
Too bad. I think it would be better to use a separate variable. Then you can define the FLAGS at the start of the program in one go. It is also no longer possible to do simple BIT operations in an integer variable. This is really useful for some interface protocols! Can the BIT command and function also remain?
Matthias Edited 2025-04-02 23:50 by homa
Posted: 02:27pm 02 Apr 2025 Copy link to clipboard
matherp Guru
b%=1<<n a% = a% or b% a% = a% and inv b%
Posted: 03:34pm 02 Apr 2025 Copy link to clipboard
When exiting the editor, it seems to send a escape sequence different to versions before. The console font is set to white/black now for the standard console output. Nothing important, but maybe someone can confirm?
Posted: 03:52pm 02 Apr 2025 Copy link to clipboard
matherp Guru
It does, the firmware tries to protect the user from exiting into an unusable state.
Posted: 04:47pm 02 Apr 2025 Copy link to clipboard
dddns Guru
Just to get it right:
I open a putty console with fc=black and bc=white
it was: open editor with white bc and then leave it and my console stays as configured in putty
it is: open editor with white bc and then leave it and my console is fc=white bc=black from then on. Opening the editor once more, and the bc within the editor is white again, leaving it turns to fc=white bc=black again
This is wanted now?
Posted: 06:29pm 02 Apr 2025 Copy link to clipboard
Mixtel90 Guru
The Pico has no idea how Putty is configured, and never did. They are two different things. The only way that Putty can change it's colours dynamically is if it is sent VT52/VT100 ESC codes by the Pico.
The Editor can be seen via a serial or USB console or via the display device and they are different. When you see it via the console any colours are set by the terminal emulator program. When seen via the display device they are set by the Pico.
MMBasic protects you from dropping out of the program and into the command line with the background and foreground colours the same. It does this by setting FC = white, BC = black. It can't protect against you deliberately doing this on the terminal emulator though. :)
Note that the console display can appear on the default display device as well as on the serial or USB connected terminal emulator. This then puts colour control onto the Pico - just to add to the confusion. :)
. Edited 2025-04-03 04:31 by Mixtel90
Posted: 06:33pm 02 Apr 2025 Copy link to clipboard
dddns Guru
red light on :) ..don't need and wanna be protected by a firmware This behaviour is new, let's see..
Posted: 09:04pm 02 Apr 2025 Copy link to clipboard
Mixtel90 Guru
Dropping out to black text on a black background is confusing to say the least. :) You don't even know why as you can't see any error messages. In fact, you may not even know the power is still on in some circumstances.
Posted: 09:25pm 02 Apr 2025 Copy link to clipboard
bfwolf Regular Member
A very good idea in principle! A suggestion that followers of both "philosophies" might be able to live with: change colors when foreground==background. And then foreground=complementary_color(background) ?
bfwolf
Posted: 09:29pm 02 Apr 2025 Copy link to clipboard
JanVolk Senior Member
Still seen some strange things.
1. The backlight command does not work well with an oled i2c screen. The dimming should work from 0%-100% but only works up to 10% - 100% with a reduction in brightness and at < 10% I see no change anymore and the display certainly does not turn off.
2. > option list PicoMite MMBasic RP2350A Edition V6.00.02RC9 OPTION SYSTEM I2C GP4,GP5 OPTION FLASH SIZE 16777216 OPTION COLOURCODE ON OPTION HEARTBEAT OFF OPTION PICO OFF OPTION CPUSPEED (KHz) 150000 OPTION DISPLAY 44, 96 OPTION SDCARD GP15, GP10, GP11, GP12 OPTION RTC AUTO ENABLE
All list commands work normally again.
After an error message or with Ctrl+C and after leaving edit Tera Term does not go to the saved setup settings regarding my own foreground colors and screen foreground is white and background is black. When I restart Tera Term I have my own color setup again.
3. I have been struggling for a while with a problem that a memory leak may occur in the chr$() function I am working on a program with a 4x20 LCD and normally works fine with an LCDI2C subroutine. When defining characters yourself with a maximum of 8 pieces, you can for example make a degree sign LCDI2C_CMD(64) and LCDI2C_DATA() and read it with LCDI2C LINE,CHAR,Chr$(0). Normally this works fine but sometimes it doesn't and the Chr$() place is overwritten and cannot be restored by a reset, possibly by a memory leak and by flashing again it works fine again for a while. No problem with small programs, but with me it is a bit bigger and therefore problems. Has anyone else experienced this or does anyone know a solution for this problem? It also occurs in the latest firmware version see point 2.
Greetings,
Jan.
Posted: 09:35pm 02 Apr 2025 Copy link to clipboard
WhiteWizzard Guru
I have a really sensible solution to all this but I don't know how it will be received. Let me try explain.
It is based on the fact that MMBASIC has just three 'modes' as follows: 1> Command Prompt 2> Editor 3> Program Running
The user will simply be switching between these modes; for example from 1 to 3 by typing RUN (or F2), or from 1 to 2 by typing EDIT (or F4). Likewise, from 3 to 1 (and only to 1 - not possible from 3 to 2) by either CTRL-C or the program terminating.
So, at the time of switching from one of the three modes above to another one, the following simple logic would give the user full control:
When entering 1 - the two default 'Command Prompt' colours are used (see *** below) When entering 2 - IF Colourcode ON then use those colours, otherwise use the two default 'Editor' colours (see *** below) When entering 3 - the program code controls the colours (and uses 'Command Prompt' colours by default (i.e. if non defined in program code).
Ideally, something like OPTION TERMINAL COLOUR fcolour,bcolour and OPTION EDITOR fcolour,bcolour to set those two settings (noting that the EDITOR defined colours are only relevant if COLOURCODE OFF).
IF in 1 (command prompt), then typing any colour command will dynamically act dynamically as it currently does.
To clarify - the logic above is just when 'entering' into 1, 2, or 3.
The above may seem complex to read/follow, but I believe this logic is bullet-proof logic and satisfies all scenarios whether using a console, a display-module, or VGA/HDMI monitor/screen; and also not broken by the MODE or RESOLUTION commands (VGA/HDMI).
Posted: 09:49pm 02 Apr 2025 Copy link to clipboard
dddns Guru
Why not falling back to the default it was coming from? Or, even better, falling back to one which can be set.
Posted: 10:10pm 02 Apr 2025 Copy link to clipboard
WhiteWizzard Guru
Exactly what I propose above.
To emphasise the benefits:
1. The program code can do whatever it wants with colours - it is up to the programmer to avoid 'errors'.
2. When a running program is exited/terminates, the user is always returned to a command prompt in the preferred colours they have defined (OPTION TERMINAL COLOUR). and hence the user will never be left in a 'unknown' state (i.e. the program code will not define the command-prompt colours!).
3. When using the editor, different colours (than what is used for the command prompt) can be defined (OPTION EDITOR COLOUR) and are ignored if COLOURCODE ON
Posted: 11:42pm 02 Apr 2025 Copy link to clipboard
JanVolk Senior Member
The problem may be in LCDI2C, LINE, CHAR, Chr$(Status_KAS) , Chr$(Status_Meteo) , Chr$(Status_Arrow_DOWN) , Chr$(Status_Arrow_UP) or Chr$(Status_RAAM) because after turning off these Chr$() functions the disturbance stopped?
Greetings,
Jan.
Posted: 07:04am 03 Apr 2025 Copy link to clipboard
guma1975 Newbie
Do you have the same? Fresh install.. RC7 ok above files shows strange amount of available memory...
PicoMite MMBasic RP2350B Edition V6.00.02RC7 Copyright 2011-2025 Geoff Graham Copyright 2016-2025 Peter Mather
Posted: 07:43am 03 Apr 2025 Copy link to clipboard
58kk90 Regular Member
Question for Peter really, in an earlier post he wrote
Command BIT(var%,bitno)=0 or 1 'sets a specific bit (0-63) in an integer variable Function BIT(var%,bitno) 'returns the value of a specific bit (0-63) in a integer variable (0 or 1) These make it very easy to use flags in a program with minimum memory usage
I tried this and found it extremely useful and have used it several pieces of code, but it now appears that it has been removed in the latest beta, so the question is, will it come back? if not where can I still download the version that has it? I unfortunately downloaded the latest beta and deleted the old downloaded zip file on my PC and I wish to use the version having the bit function but no longer have it nor can I seem to find it to download.
Tony
Page 19 of 52
The Back Shed's forum code is written, and hosted, in Australia.
