Jim, Peter,

The format command works correct.
But when you are inside a folder of that same drive when executing, it throws an error.



It actually formats the drive, but cannot return to the folder in "path", and correctly gives an error. I misinterpreted the error for a format that failed, but actually it is a format that succeeded, but the path that is not found.

Volhout
Edited 2026-02-13 17:46 by Volhout

Easily fixed - in next release. Will probably be RC0 if nothing else reported

Peter,
PicoMite HDMI/VGA MMBasic RP2350A/RP2040 Edition V6.02.01b2

Unexpected behavior when printing text using PRINT and TEXT commands at the right edge of the screen, going beyond its borders.

Edited 2026-02-14 03:59 by javavi

Text is setting tiles incorrectly which I'll fix. I think the print output is correct. Print supports line wrap at a character level so at 312 you will get "P" on the first line and "icoMite" on the second. At 313 The whole word will wrap to the second line. This won't therefore overwrite the "P" from 312.

I don't see anything in the manual about this but I like to space out my TYPE statements to allow better reading but if I leave a blank line in the structure, it errors out:

  toml_12953 said  

I don't see anything in the manual about this but I like to space out my TYPE statements to allow better reading but if I leave a blank line in the structure, it errors out:

[13]
Error: Invalid member definition in TYPE


TYPE complex

 re AS float
 im AS float

END TYPE

Try if this works:

You beat me to it. Yes that does work.

I guess it is just personal preference but I try to avoid blank lines within a unit of code such as that. Only using them to separate units.
Edited 2026-02-14 07:38 by phil99

I also don't like blank lines after 'Type' and before 'End Type' but I like comments explaining the meaning/usage of struct-members, if their names would be endless to be "self-speaking".
Comments appended to the members in the same line look prettier, I think - so preferred if possble "with few words"..
Edited 2026-02-14 09:13 by bfwolf

I'm getting an error every now and again. It seems to happen when I start a program run:
"Error: Invalid address - resetting"
The system then resets. The program changes are still in place. If I simply run it again it starts and runs fine so it doesn't *seem* t be a problem in my program.

PicoMiteHDMI MMBasic RP2350B Edition V6.02.01b0
OPTION SYSTEM I2C GP6,GP7
OPTION FLASH SIZE 16777216
OPTION COLOURCODE ON
OPTION KEYBOARD UK
OPTION PICO OFF
OPTION RESOLUTION 640x480 @ 252000KHz
OPTION HDMI PINS  1, 3, 5, 7
OPTION SDCARD GP25, GP26, GP27, GP24
OPTION AUDIO I2S GP1,GP3', ON PWM CHANNEL 0
OPTION RTC AUTO ENABLE
OPTION PSRAM PIN GP47
OPTION HEARTBEAT PIN GP22

What about on 6.02.00?

I'll try it. I didn't put it on this new PGA.

I have it loaded now. I'll see how it goes.

That didn't last long. Immediately after the first run.
It seems to be when I've edited using F4 then saved using F1 then run using F2.
I just did a F2 without a F1 first and the program locked up before the end, needed a reset.

.
Edited 2026-02-15 02:19 by Mixtel90

I'm sorry but I still suspect and electrical issue with your board. I'm using the PGA2350 in my PicoCalc and it is rock solid reliable at 360MHz including with PSRAM enabled

That's fine - I can check it over and I still have a third PGA in reserve if I need it.

It's almost certainly the PSRAM.

I stripped off all extra hardware.
Stripped off the external regulator.
Enabled the on board 3V3 supply.
OPTION RESET.

Things *seem* to be ok like this.

added just OPTION PSRAM PIN GP47 and nothing else
and started getting occasional problems again.

OPTION PSRAM PIN DISABLE
gets it, apparently, working again.

I need to repeat these tests more but that's how it looks at the moment.

More tests...

Clean boot with PSRAM enabled

Error on first run, no errors for the next nine.
Edited the program by adding one blank line. F1 to exit.
Error on first run, no errors on next nine.
Repeated that test again, adding another blank line, with same result.

OPTION PSRAM PIN DISABLE

Ten clear runs.
Edited program exactly as previously
Ten clear runs.
Repeated the edit.
Ten clear runs.
A more aggressive edit, copying a sub and adding more blank lines
Ten clear runs

OPTION PSRAM PIN GP47
Error: Pin GP32 is in use

It's actually set as DOUT, that's all.
Ten clear runs
Edited a blank line in
Ten clear runs
More aggressive editing
Ten clear runs

So, anyone any idea what might be going on here? Is my machine haunted? Has the phase of the moon changed? >>confused<<

If it was a board fault then surely it would be more consistent as the board hasn't been physically touched apart from the power down to strip out the hardware and regulator. There's no load on the Pico's 3V3. One pin is being used to send data to the WS2912 strip at the end of each program run. It was difficult to disconnect so I left that. There's no HDMI connected.


EDIT:
Just for the Hell of it I connected HDMI and, after a couple of runs changed to 800x600 360MHz.
Ten clear runs.

OPTION PSRAM PIN GP47
Error: Pin GP32 is in use

It's still set as DOUT - nothing connected.
Ten clear runs.

Perhaps the cosmic rays were the wrong colour for a while? I dunno....


EDIT
DOH! The stupid GP32 error isn't. GP32 is on pin 47 so if I fumble type PSRAM PIN 47 then that's the correct error. And, because of the error, GP47 doesn't get allocated to PSRAM. :)

So yes, with GP now correctly configured for PSRAM the problem has returned and is repeatable again. There's a pretty reliable error on the first program run after a program edit. I've not gone completely mad. :)
.
Edited 2026-02-15 06:28 by Mixtel90

Since it only happens the first time after edit, Maybe the psram cache is not written to psram before the run is executed. Then it depends on the edit change made if the program executes withour error. So peter may have missed this.
Yeah…I also noticed pin 47 is gp32. But since gp32 does not have the requires hardware inside the 2350, you may corrupt psram. You do need a repower to recover.

Volhout
Edited 2026-02-15 19:44 by Volhout

I've just tried reinforcing the pull up by paralleling a second 100K resistor. TBH 100K just feels high for a pull up to me. I know it isn't really, but it just feels wrong. :)  There was no difference.

Good point about the cache. I hadn't considered that.

I've now had it running happily in the 1024 and 1280 resolutions too. This is mildly interesting as the monitor seemed to refuse to do these previously. It might have been on the other PC though. Dratted monitor keeps resetting to HDMI1 every time I change resolution though because it takes too long to resynch. Annoying but I have to live with it.

Is PORT() broken? It could be my programming.

I set GP30-GP36 as DOUT high and GP40-GP46 as DIN. Printing each one using PIN(GPn) works but print port(gp30,7) returns a value of 3. port(45,7) returns 3 also.

GP40 upwards seems to be the same. I've not tested other ranges as they are connected.

Tested in V6.02.00 HDMI RP2350B

Perhaps only a problem on that version.
Tested Port() command and function on both PicoMiteVGA RP2350A V6.02.00 and PicoMite RP2040 V6.02.00


Edit.
A useful bonus. If the number supplied to the Port command is too big it it ignores the excess bits rather than giving an error.

Edited 2026-02-16 07:36 by phil99

For PIO you must switch between Goois 0-31, or 16-47
Maybethis relaties to the problem

Volhout