Perhaps Geoff updated the manual today and changed the download again?

Geoff updated the manual and created the download today (Aus time) with files I supplied to him yesterday (my time). Remember, we have a massive timezone difference to confuse everything as well.

  matherp said  

Remember, we have a massive timezone difference to confuse everything as well.

Yes, indeed !!!

Just checked for the new "clipboard" after update to V6.02.00b: Works!

Regards ant thx!

Edit:
Ah: Perhaps you could consider incrementing the last digit of the version number when you release an update for a new version? That would be great and would avoid confusion.

So, in this case, V6.02.01
Edited 2026-01-27 00:11 by bfwolf

Editor issues with 6.02 here (LCD)....

F4 no longer highlights all lines making it difficult to know what you've selected, yet still works. In some .bas files the highlighted section flashes on and off each time you move down a line. Repeatedly pressing up results in the same flashing yet alternate lines are then left highlighted !?.

If F10 is pressed followed immediately by 'esc' the screen goes white !.

What LCD, what version? Tested on SSD1963 and works fine.
Edited 2026-01-27 01:38 by matherp

  matherp said  

What LCD, what version?

Best I can do right now is from the option list...

Picomite MMBasic RP2350A V6.02.00
Option lcdpanel console ,, FF00
Option display 26, 40
Option lcdpanel st7796sp, portrait,gp14,gp15, gp13,,invert
Edited 2026-01-27 01:41 by DigitalDreams

In other words a PicoCalc? No idea what they have done. Just tested a RP2040 and a RP2350A with a waveshare 320x240 ST7789 and that also works perfectly. Do you get any issues if you only use F4 on the same screen without it scrolling?
UPDATE:
Also tested ST7796SP and ST7796BUFF with no issues
Edited 2026-01-27 02:50 by matherp

Peter,

Above mentioned 2 bugs did not exist in 6.02.00_a release (the one originally posted). They only exist in the current download. Tested on bare pico (not geek) with RP2040.

Volhout

Sorry Peter!

I tried the latest FW and thought I had to specify the drive when saving the marker. As a result, I cannot delete the file. Except, of course, by formatting drive A:.

But loading works ;-)

Matthias

Addendum: Renaming/moving with FM helped.


Edited 2026-01-27 04:31 by homa

The only change in the newer release is in the editor relating to F4. I've tested everything on windows and it just works. I've checked it has masses of stack available and the program size is still within the same 848Kbyte envelope. Try clear_flash and re-load.
I've just rebuilt it to test again so you can try this if you want but I can't see it behaving any different.

PicoMite.zip

  Quote  

I tried the latest FW and thought I had to specify the drive when saving the marker.

You need a:/ to indicate the drive when saving. You could have deleted the file with
KILL "a:/a:clipboard.bas"
Edited 2026-01-27 04:37 by matherp

  matherp said  

The only change in the newer release is in the editor relating to F4. I've tested everything on windows and it just works. I've checked it has masses of stack available and the program size is still within the same 848Kbyte envelope. Try clear_flash and re-load.
I've just rebuilt it to test again so you can try this if you want but I can't see it behaving any different.

PicoMite.zip

Who do you mean?

  matherp said  

  Quote  

I tried the latest FW and thought I had to specify the drive when saving the marker.

You need a:/ to indicate the drive when saving. You could have deleted the file with
KILL "a:/a:clipboard.bas"

Thank you! It's a great feature in general!

  Quote  

Who do you mean?

Harm

Peter,

On a bare pico with only SD card attached, running 6.02.00_b (the one with the new edit clipboard save function) from Geoff's site (not your re-build).

- The F4 problem seen once, this time shifting the whole text 1 line down. And the highlighting then is shifted with respect to the text. But could not repeat. This was just the first time after installing the firmware (after a flash clear). Successive tries to replicate it was working fine.

- The file transfer problem with MMCC was not duplicated.

Tomorrow I'll try again the GEEK board. Find out if it is related to something in the GEEK (the GEEK is a RP2040 with 4Gbyte flash (not 2), configured with "pico off").
Maybe it is related to the GEEK.

B.t.w. The GEEK is a RP2040 microcontroller (defaulting to 200MHz) that is configured through OPTION CPUSPEED to 252 MHz. Maybe that is a bit too much for the tiny board with miniature voltage regulator. But that remark is unrelated to my observations, since I manually configure it down to 200MHz anyway.

Volhout

EDIT: pulled out the second GEEK. With 60200_b the file transfer with MMCC works fine. The issue with the F4 in the editor, with the text shifted down 1 line can be duplicated. The first time after a CPU RESTART, when opening the editor, the text starts with a blank line on screen, followed by the text of the program listing. When pressing F4 to top line is highlighted (in this case the blank line) but in the highlight is the text of the second line. It is as of a "line feed" is in the buffer of the screen output when opening the editor. But this cannot be duplicated after the first time. Only after a CPU RESTART (or changing the OPTIONS) this happens once.
To me it is a no-brainer. Not nice, but not obstructing any progress.
Edited 2026-01-27 06:11 by Volhout

  Volhout said  

@Peter,
- File Manager MMCC (linux) cannot transfer files anymore from GEEK to PC
Volhout

Problem with MMCC Linux V5.4.0, not MMBasic.
I will investigate.

JIm

  Quote  

The issue with the F4 in the editor, with the text shifted down 1 line can be duplicated. The first time after a CPU RESTART, when opening the editor, the text starts with a blank line on screen, followed by the text of the program listing. When pressing F4 to top line is highlighted (in this case the blank line) but in the highlight is the text of the second line. It is as of a "line feed" is in the buffer of the screen output when opening the editor. But this cannot be duplicated after the first time. Only after a CPU RESTART (or changing the OPTIONS) this happens once.

Sounds like linux is putting a CR or LF in the output as you open the editor. I certainly can't replicate this in windows.

@Peter,

Sounds like a Linux issue that upsets Putty. GFXterm on Linux does not show this.
Maybe it is even related to opening/closing of the USB port. Note that Linux closes the port when pico reboots. Manual restart of Putty re-opens it (and therefore also misses/does not show the bootmessage). But maybe (timing) the last CR or LF of the bootmessage is in the USB buffer still when Putty grabs it.

Anyway, not something you can worry about.

Volhout

Just to confirm then, With GFXterm on Linux you are seeing no issues and Jim has confirmed that the transfer issue is in MMCC so there is nothing for me?
Edited 2026-01-27 21:27 by matherp

Peter,

No issues at the moment, but I am currently not able to spend much time on verification. To busy at work. Hardly time to breathe.

Volhout

  Quote  

To busy at work. Hardly time to breathe.

Just wait until you are retired, then you will really have no time

Hehe....
Very, very true.  lol