I ran into the problem with restore already several times. I think the only safe way is to restore only to the same version and variant. Everything else semms to have the potential of corrupting the option settings.

A short report, that rc0 runs very solid and I have no problems with it.
It still happens as in versions before, that if a program is uploaded with autosave and then written to A: that the pico becomes unresponsive. This happens also sometimes with "Edit file file$". No matter if I turn on PSRAM or not.

I just realized, that for Font 1,7,8 there is a gap in the "|".

  Quote  

It still happens as in versions before, that if a program is uploaded with autosave and then written to A: that the pico becomes unresponsive. This happens also sometimes with "Edit file file$".

You mean AUTOSAVE. Then exit with ctrl-Z or F1 and then save fname$? Or exit with F2?

Sorry, my phrasing was not clear.

If I upload something with AUTOSAVE and then save it to A: or I want to edit a file and execute Edit file "filename" it hangs from the moment I press enter. But only rarely

Edit: Edit file "a:filename"
Edited 2025-10-14 03:11 by dddns

V6.01.00RC2


PicoMiteV6.01.00RC2.zip

Changes:
Files received on the Pico via XMODEM should no longer have any padding characters at the end

New:
Contains 2 new facilities thanks to CLAUDE with a bit of help from me

For all versions


This load a standard non-compressed RGB888 BMP file and dithers it to make the image look as good as possible on a display with either RGB121 or RGB332 colour.
fname$ is the name of the file to be loaded
the optional parameters xdisplay and ydisplay specify where on the display the file will load
the optional parameter RGB332 if set to 1 specified that dithering should take place from RGB888 to RGB332, if omitted (default) or set to 0 dithering is to RGB121
the optional parameters xfile and yfile give the use of choosing the x and y position in the image to start displaying so for example with a 640x480 image and a 320x240 display these could be set to 160,120 to dispolay just the central portion of the image

RP2350 non USB versions only


This command mimics XMODEM but transfers files much faster (>10x) over a CDC serial link
YMODEM is different from XMODEM in that the message carries the filename.
This means that when you send a file from the Pico to a computer the receiving program will use automatically use the same name as you send. In case the file already exists the receiver will automatically increment a version number on the name of the file received.
fred1.bas, fred2.bas etc.
When sending from memory with YMODEM S there are two possibilities. In the case that the file was loaded from the A: or B: drives it will contain a hidden filename and this will be used.
In the case of a file created through the editor or autosaved the receiving file will automatically have the name FILEn.DAT
It is the responsibility of the receiving program to specify where the file will be saved. In the case of teraterm this is an option you set on the general setting screen "File transfer folder"
When receiving a file on the Pico, you have complete freedom to specify the name and directory in the normal way

Hi Peter,

I have problems understanding your beta/release candidate process.
I though I heard you say 1 week ago that no new functions would be added once beta is closed.

FILL
YMODEM
LOAD DITHERED

I think this is beta 23 (b23) right ? When are we going for RC ??

Volhout

Point accepted but some changes are so self-contained that they can't impact core functionality. The only possible issue is if the image get to big for the amount of flash allowed in the configuration file. If that happens the impact is so obvious that the fix is both obvious and trivial.
My defense is that sometimes things interest me so I play with them and if they work out then why not if they add value....

It keeps life very interesting. :)

I'm enthusiastic about YMODEM. That's going to be popular, I think. As I've never even attempted to load a picture onto a PicoMite I can't comment on dithering!

  matherp said  

Point accepted but some changes are so self-contained that they can't impact core functionality. The only possible issue is if the image get to big for the amount of flash allowed in the configuration file. If that happens the impact is so obvious that the fix is both obvious and trivial.
My defense is that sometimes things interest me so I play with them and if they work out then why not if they add value....

Just teasing you Peter....;-)

Harm

Fantastic new features, many thanks!
Frankly speaking, I never used a stable longer than the next beta came up :)

PicoMiteV6.01.00RC2.zip


I've changed the dithering to allow you to select Floyd–Steinberg or Atkinson dithering

  Quote  

LOAD DITHERED fname$ [,xdisplay] [,ydisplay] [,mode] [,xfile] [,yfile]

mode 0: Floyd–Steinberg RGB121
mode 1: Floyd–Steinberg RGB332
mode 2: Atkinson RGB121
mode 3: Atkinson RGB332
Edited 2025-10-15 02:24 by matherp

Speed is amazing! Mode 0 is with the same picture I took yesterday more red but quality wise exactly the same, Mode 2 looks also very good but tends to show patterns. But don't get me wrong, that looks fantastic!

This new firmware erases the pico!

@Peter,

rc2 on 2040 VGA PS2

> load image "wp-Rei_36616.bmp"
> load dithered "wp-Rei_36616.bmp"
Error : BMP: Failed to read file header

Something wrong with this file ?

wp-Rei_36616.zip

It loads fine with load image.

Volhout

I told CLAUDE off and he has fixed it.

PicoMiteV6.01.00RC2.zip

  Quote  

I told CLAUDE off and he has fixed it.

Perhaps not on all versions?And also the Pico's own header.
Time stamp on the .uf2 in the .zip is 14/10/2025 22:52 so not a browser cache issue.

Edit.
Works well on RP2350A VGA.
Edited 2025-10-15 13:42 by phil99

Strange, I've rebuilt it again and it works for me

PicoMiteV6.01.00RC2.zip

Thanks for re-doing it, however no change.
The RP2350 VGA version is where it is of most use to me and it works well there so unless many others have an issue it isn't a problem.

@Peter,

I noticed the problem on the 2040 VGA PS2 version.
Phil tested on the 2040 (LCD attached ?) version (see boot message).
Maybe VGA is fixed now ? I cannot check until I am back home.

Volhout

UPDATE

Can reproduce. Seems to be specific to the A: drive. Please confirm loading off B: is OK. Will investigate further.
Edited 2025-10-15 19:01 by matherp

Yes, LOAD DITHERED "b:bubble test.bmp" worked perfectly.
As did Load dithered "b:wp-Rei_36616.bmp", 160, 80 on ST7796S

And on RP2350 VGA Load dithered "a:wp-Rei_36616.bmp" fails, so not platform specific, just from A: as you noted.
.
Edited 2025-10-15 21:29 by phil99