this is the answer... gui show all
cls
'define touch areas  
 gui area 1,0,199,80,40 ':line 0,239,80,239,rgb(blue)'left button
 gui area 2,140,199,80,40 ':line 140,239,220,239,rgb(blue)'right button
 gui area 3,279,40,40,80 ':line 319,40,319,120,rgb(blue)'up button
 gui area 4,279,159,40,80 ':line 319,179,319,239,rgb(blue)'down button
'cls
'draw direction buttons
 box 0,199,80,40,3,rgb(white),rgb(blue)'left button
 box 140,199,80,40,3,rgb(white),rgb(blue)'right button
 box 279,40,40,80,3,rgb(white),rgb(blue) 'up button
 box 279,159,40,80,3,rgb(white),rgb(blue)'down button
 do
   tr=TOUCH(REF)
 loop until tr>0
 cls
 gui show all
 
do
'init players start positions

regards stan

the manual
GUI SHOW ALL


This will undo the effects of GUI HIDE and restore the control(s) to being
visible and capable of normal operation.
'#ref' is the control's reference number. The keyword ALL can be used as the
argument and that will disable all controls.  
should be enable?
Edited 2025-08-23 06:33 by stanleyella

Hi Peter,
Is there any way to get back some version of the LCD320 option for SPI displays?
I am testing code for a 240*320 display on a 7796s and doing a merge on the whole screen, rather than 240*320 is proving problematic, speed wise.
As a half way house, would it be easier to do 240*480, so full width, but only 240 high? this would probably make it fast enough for most purposes.
Thanks for any sugestions.
Regards Kevin.

  stanleyella said  

The keyword ALL can be used as the
argument and that will disable all controls.  
should be enable?

Thanks Stanley, fixed.

Geoff

  Quote  

Is there any way to get back some version of the LCD320 option for SPI displays?

POKE DISPLAY HRES n
POKE DISPLAY VRES n
These commands change the stored value of MM.HRES and MM.VRES
allowing the programmer to configure non-standard displays.

That's all LCD320 did but it wasn't fully robust so I removed it but worth trying

Thank you for brill coding kit. I am luvin it, marvellous, thank you and Peter. Without the manual we'd be clueless, well I would be. I should read the "small print" before posting problems that are explained if I took time to read. happy days. regards, stan

Perhaps a slight manual change would be in order?
Page 100 - ADC OPEN command

  Quote  

This allocates up to 4 ADC channels for use and sets them to be converted at
the specified frequency.
The range of pins are GP26, GP27, GP28, and GP29 for the RP2940 and
RP2350A. Plus GP55, GP56, GP57, GP58 on the RP2350B. If the number of
channels is one then it will always be GP26 used, if two then GP26 and GP27
are used, etc. Sampling of multiple channels is sequential (there is only one

Suggested change:

This allocates up to 4 ADC channels from the ADC0-ADC3 group for use and sets them to be converted at the specified frequency.

The range of pins is GP26, GP27, GP28, and GP29 for the RP2040 and
RP2350A or GP40, GP41, GP42 and GP43 on the RP2350B. If the number of channels is one then it will always be ADC0 used, if two then ADC0 and ADC1 are used, etc. Sampling of multiple channels is sequential (there is only one ADC).

  matherp said  

  Quote  

Is there any way to get back some version of the LCD320 option for SPI displays?

POKE DISPLAY HRES n
POKE DISPLAY VRES n
These commands change the stored value of MM.HRES and MM.VRES
allowing the programmer to configure non-standard displays.

That's all LCD320 did but it wasn't fully robust so I removed it but worth trying

Thanks for this hint.
I'm using a SSD1963 with a RP2040 latest firmware.
Option LCD320 on works fine called within the program. Coming back to console will leave this option on and editor is shown in 320x240 in the upper left edge.

Option LCD320 off gives an error at the console but switches back to standard Resolution 800x480 but seems not to reset hres/vres to correct values. When I call the program for the second time, the picture is scrambled and x/y is not correct.
Poke display then seems to help (quick test)


Edit: sorry, it does not help for me. Found no other way than doing cpu restart to get out of this
Edited 2025-08-27 19:28 by dddns

  matherp said  

Should be fixed


PicoMiteV6.01.00b10.zip

is b9 the last version that will work on a 2040 non-USB, non-VGA, non-HDMI?
Edited 2025-08-28 13:28 by toml_12953

Tom,

The b10 download file has been updated with the missing versions. If you clear browser cache, and download again, you will get the full list (including 2040 nonVGA,nonUSB(nonHDMI ... There never was a 2040 HDMI version).

Volhout

Tom V6.0100 and forward are for the 2350 as stated on the first post

  Bryan1 said  

Tom V6.0100 and forward are for the 2350 as stated on the first post

b10 still has all the files for the 2040.

Tom, Bryan,

V6.00.03 was the end of the 2040 series.

As far as I know for 6.01.00
- there are only bug fixes for 2040
- bug fixes for 2350 and new functionality

So for 2040 it may be interesting to use 6.01.00 since some bugs that are fixed are pretty essential.

Volhout

Hi Peter, a quick question: Is it possible that the illegal (and unintentional) use of path or file names longer than the allowed 63 characters can corrupt the memory structure?
Kind regards
Michael

Just don't do it. Something nasty will happen anyway. Even if there's no error flagged the string will probably be truncated, causing a different sort of error.

fullpath$ = path$ + filename$
if len(fullpath$) > 63 then do_some_sort_of_error_handling_or_you'll_be_in_the_wet_and_smelly

:)

Hi Mick,
Thanks for the good advice! And that's really the best solution if you only have three files on the drive. But there are cases that are more complicated, like many things in life. ;-)

I am still tinkering with the FM at the moment.
And for most problem cases there are already satisfactory solutions.
My question was addressed to Peter only because, during the days of testing - also with overly long pathnames - I observed strange effects.
I'm just looking to confirm or deny my suspicion.

It is relatively easy to prevent the copying of files/directories with long pathnames  into locations with other long pathnames. But there are special cases that are difficult - and require great effort - to handle. For example, a user may want to rename an existing directory and choose a name which, when combined with one name somewhere among the possible thousands of files and directories beneath it, would exceed the permitted length.

To prevent this, the entire drive would have to be scanned each time the rename command is used, which would render the command unusable.

Regards
Michael
Edited 2025-08-29 21:23 by twofingers

Hi Peter,
Is it to be expected that the Framebuffer Sync, only works with background merge and not with background copy? It would be handy if it did, currently the program waits forever if I use it with copy.
Regards Kevin

@Twofingers
In theory it can happen no matter what the maximum length is. The only way to be sure is to have unlimited length file names. That's not going to happen on a Pico. The alternative is to throw an error - and that's something I haven't tested. Truncating the string without warning wouldn't be acceptable, it's safer to do a proper crash! The Pico doesn't have incredibly clever error handling and something like this might be something you just have to live with. It'll be interesting to see what @matherp says though.

Much, much safer to parse what the user is trying to do and catch any error before the command is passed to MMBasic's file handling.

Hi Mick,
I agree with you. For me, having a file system for the Picos is a small miracle; I'm happy to accept its limitations. It's just important to know the limitations and the potential consequences. Hence my question to Peter.
Michael
Edited 2025-08-29 22:54 by twofingers

  twofingers said  

Hi Peter, a quick question: Is it possible that the illegal (and unintentional) use of path or file names longer than the allowed 63 characters can corrupt the memory structure?
Kind regards
Michael

Hi,

It definitly makes problems, because I learned this the hard way. I was searching for two whole days the problem in my program. I had a variable set to 1 to trigger an subroutine and open a file to preview it. I got an error, that this file doesn't exists. I checked a million times via PRINT debugging the state of all variables and everything was fine. I was about to ask about a bug in this forum and then it HIT me like a stone ... There is a 63 char limitation! Damn!    Now everything became clear, problem fixed.

So the answer is, it does make problems.

Greetings
Daniel