Missing file in RC4 , PicoMiteHDMIUSBV6.02.01RC4.uf2
/Peter63

Oops

PicoMiteHDMIUSBV6.02.01RC4.zip

Peter,

There is something very seriously wrong with RC4 for the 2350 (the microcontroller Game*Mite version). Something with flash adresses.

In the options, game mite uses OPTION AUTORUN 1,NORESET.
In flash slot 1 there is the startup menu.

In an initialized Game*Mite, everything working, GameMite in the menu.

When I upload the breakout program. It corrupts the flash slot 1. When I do a "FLASH LIST 1" the 2350 hangs.

Note that the upload happens by ctrl-C stopping the running program in flash slot 1, and then uploads.
When I press RESET on the GameMite, it starts the Breakout program, not the menu.
So it feels the Breakout is programmed in flash slot 1 ?

This behaviour is not observed in earlier GameMite work I did. The menu was stopped, and the program loaded in program memory, not flash memory.

Volhout

EDIT: just confirmed that RC2 works correct. It is really RC4 at fault. And just to make sure: I did nuke flash before testing RC4
Edited 2026-03-13 00:04 by Volhout

The breakout program overwrites flash slot 1 and flash list probably doesn't protect against a non-program usage - not a new issue

Has anyone used PNG files, and used the command: LOAD PNG "filename.png"
I get Error: Not enough Heap memory

Can someone test if it works (I don’t know if I have the right format or what it could be...)

The file that doesn’t work for me is this one



png-test.zip

/Peter63

So.. how do I make it use flash slot 3 (similar petscii robots does).

Volhout

This is a known limitation that has been discussed before. Decoding png files take a huge amount of memory. It will only work with relatively small files

OK !    /Peter63

  Quote  

So.. how do I make it use flash slot 3 (similar petscii robots does).

Change the flash load image to point to the flash slot you want. Then change tilemap create to use the same flash slot (second parameter)

G'day Peter,
I have finally had some time to do some further testing with the Stepper commands, for the most part working well.

G28 is causing me trouble, not sure if that is incorrect usage or a problem with the command, as soon as it hits the final home limit switch (if more than one axis specified) it goes into E-Stop mode without reversing.

Also noted that after hitting the limit switch, the axis will not always clear the switch before it comes to rest.

The machine only uses X and Y axis but I have tried it with Z set as well with no change.
The HWLIMITS command will not accept less than 3 axis even if the axis is not specified.


Strangely it does zero the axis if I hit the home limit switch whilst travelling in G0:


This is a cut down version of the program to illustrate the problem:


> option list
PicoMite MMBasic RP2350A V6.02.01RC1
OPTION SYSTEM SPI GP18,GP19,GP16
OPTION AUTORUN  ON
OPTION FLASH SIZE 4194304
OPTION COLOURCODE ON
OPTION CPUSPEED (KHz) 200000
OPTION LCDPANEL ILI9488, PORTRAIT,GP14,GP13,GP12
OPTION GUI CONTROLS 32
OPTION TOUCH GP15,GP17
GUI CALIBRATE 1, 196, 3972, 867, -1283
>

Should this be posted here or should I start a new thread specific to the stepper commands?

Regards,
Lyle

Hi Peter,
I seem to be having problems with USB keyboard on a HDMIUSBI2S fresh install standard options, the USB seems to just drop out randomly, this was happening on RC3, but now also RC4.
After using the keyboard for a few minutes it stops responding, even if I unplug it & put it in a different port, it is now not seen, I have to reboot to get it back. I've been using this keyboard for several months now, no problems.
Regards Kevin

I see that KEYDOWN( is a new function in V6.02.01RC4.
Could a simple example be posted?

Jan.

Kevin
Nothing has changed in this area for many months but you could try the attached which has added some defensive programming however, I would suspect something electrical is triggering the issue.

PicoMite.zip

Oops

Sorry for my question earlier. KEYDOWN(n) was already a function, see page 192 PicoMite_User_Manual V6.02.00 R5, but it was missing from the "list functions" list.

Jan.

Hi Peter,
Yes that seems to be better, I haven't yet had a problem since I changed to that version, probably about an hour, but I'll keep testing.
Regards, Kevin.

V6.02.01RC5
PicoMiteV6.02.01RC5.zip
Adds some defensive programming for misbehaving USB devices
Fixes bug in SPRITE SCROLL when MM.HRES not 320

PS the Blit Framebuffer in Modes 4 & 5 is working great :-) Thanks.
Edited 2026-03-13 06:02 by Bleep

G'day Peter,
Further to my post above, some more testing of G28 has shown:

The Homing switch inputs have active pullup initially, this is lost once the limit is activated (external pullup required)

The X axis goes through the precision homing procedure, the Y axis does not.
(This is with pullup resistors added)

Whilst there are numerous G/M/O codes, would you consider adding G54 / G55 to this implementation? this allows G54 to be left with machine co-ordinates (Default) and G55 to be set up as a fixture offset for the actual machining.
I would like to use this to drop back to G54 for tool changes then go back to G55 for machining the job.

Thanks again for all your work on this. Using a PicoMite instead of a PC for G-Code control is a dream come true.

Regards,
Lyle.
Edited 2026-03-14 00:20 by mozzie

V6.02.01RC6

PicoMiteV6.02.01RC6.zip

Adds TILEMAP support to RP2040 versions
RP2040 Picomite(USB) versions, max program size reduced from 128K to 120K. MMBasic Heap increased from 128K to 136K

Lyle: sorry but the PicoMite can't pretend to be a full motion controller. I think the current release takes it about as far as is reasonable.

Hi Peter,
Fair enough, it works amazingly well as it stands, I will see how I go implementing G54 / G55 in my interpreter program.

Just to clarify, is the way G28 works at the moment correct? X-axis does the precision homing procedure but Y(Z) do not? Y(Z) also trip the limit switch inputs and put the system into E-Stop after homing.

Regards,
Lyle.