Not aware of any change, can you connect a usb-uart to gp8/gp9 to see what is going on?

Unfortunately, not right now. I'll have to make an adapter first...

Frank

Since when have /* and */ been prohibited in a library? I updated my PioCalc and wanted to use my existing library, which had been working fine until now. I couldn't load it into the editor using LOAD, so I had to load it using EDIT [filename] to make changes...

Frank

The Picomite has always stripped comments when saving to the library but previously forgot multi-line comments. Now it strips those as well to save space. The code is also more rigorous in imposing the multi-line comment rules as per the manual description as previously things like /*do without a space could cause runtime errors. Now they are caught when the code is tokenised.

  Quote  

LIBRARY SAVE will take whatever is in normal program memory, compress
it (remove redundant data such as comments) and append it to the library area
(main program memory is then empty).

  Quote  

Start and end of multiline comments. /* and */ must be the first non-space
characters at the start of a line and have a space or end-of-line after them (i.e.
they are MMBasic commands). Multi-line comments cannot be used inside
subroutines and functions. Any characters after */ on a line are also treated as
a comment.

Edited 2026-10-26 04:54 by matherp

Okay, but does it make sense that you can't even load a file like that with LOAD to edit it?

Frank

If you allow it then the checking has to be at runtime with performance overhead. You can edit it with EDIT fname$ save the file and then load it.

I've always kept my original library file because I want the comments in it. In that respect there's no point in editing a library file. Edit the original, save it (important!) then create a new library from it.

  matherp said  

You can edit it with EDIT fname$ save the file and then load it.

That's how I did it.

I used /* and */ to comment out a section of code that I didn't necessarily want to delete...

Frank

Peter,

I am not sure this item has surfaced before. But is there a random generator built in MMBasic that is deterministic (repeatable)? I know I can write one myself (i.e. use MATH CRC), so if there is none, don't worry.

I am looking at javavi's latest program that generates mazes randomly. And for forensic research I would like to be able to repeat a certain maze (from a seed). But the RND(n) and MATH RANDOMIZE n do not provide me a repeatable RND sequence.

Volhout

Peter,

thanks for the milliseconds correction to WEB NTP and RTC GETTIME

But, the TIME$ command still does not reset the milliseconds to 0 as stated in the manual. This would be very helpful in case one wants to sync the internal clock from an external signal like a DCF77 input pin. You then set the time at the start of the first seconds pulse at a new minute implicitly resetting the milliseconds counter to 0.
Edited 2026-10-26 19:23 by ville56

sorry Peter,

forget the post above ... must have accidentially reflashed RC3 yesterday evening, was too late and my brain was already shut off, so it seems ... have to test with RC5 now

mea culpa, mea maxima culpa
Gerald
Edited 2026-10-26 20:02 by ville56

Hi Peter,
Is it correct that the OPTION RESET HDMIUSBI2S does not include the
OPTION PSRAM PIN GP47, V7.00.00RC5 I was trying to test Matthias Backgammon and it wouldn't run, then I realised the PSRAM hadn't been activated, now runs ok.
Regards Kevin.
Edited 2026-10-26 23:13 by Bleep

  Quote  

Is it correct that the OPTION RESET HDMIUSBI2S

Yes, Only the PC3 build makes an assumption about what it is being run on

  matherp said  

Not aware of any change, can you connect a usb-uart to gp8/gp9 to see what is going on?

I figured out the problem with the RP2040-PICO-PC. I manually set the HDMI pins to OPTION HDMI PINS 1, 3, 7, 5 and called the command. Once I had a picture on the screen, I was able to call OPTION RESET OLIMEXUSB.

Now a message appears saying that the flash will be completely erased, which you have to confirm with “Y” - that message wasn't there before, and I couldn't see it!
Now everything works...

Thanks!

Frank

RC6: PNG from Print Screen can't be viewed in the file manager

Firmware: PicoMiteHDMI MMBasic USB RP2350A Edition V7.00.00RC6


Print Screen (also from a running program with OPTION PRINTSCREEN ON) saves SCREEN_yyyymmdd_hhmmss.PNG in the SD root - fine.

But opening that file in the file manager (FM) gives:


The same file copied to the PC (XMODEM) opens without problems, with the correct colours. So the file itself is OK - it seems the PNG viewer in FM doesn't accept the format that SAVE PNG / Print Screen writes (probably 24-bit RGB without alpha).

It would be great if FM could show the PNG files the firmware writes itself. Thanks for the new Print Screen feature - it even captures in the middle of an animation, perfect for manual screenshots!

Matthias

Peter,
Just to round off, since writing I have had no more problems with touch (other than the normal extra disconnect and reconnect at startup which is not an issue) - so please disregard.

Thanks too for the Screen-Print .png and the selective area which will help all of us with efficient posts on this forum.

One very minor request with the FRAME subsystem (I think the limitations of TILE subsystem should rightly prevent smaller fonts, but) it would be nice if it could allow for other (higher-resolution) fonts - as long as the box-drawing characters are catered for...e.g. I tried FONT 4 (10x16) - which has those chars - but when using FRAME the system automatically reverted to FONT 1 (8x12)


Regards Phil