Oops, ... Mistake?

I've finally got some time again and have been enjoying the whole development. I updated the rp2350 on the reference board to “PicoMiteHDMI MMBasic USB RP2350A Edition V6.00.02RC3”.

It looks good at first. The application “testcard.bas” shows the different graphic modes. Then I have:

executed. Here the screen reproducibly goes into sleep mode because there is no more graphics output! Was that intended? I find the previous behavior better.

Even a
does not help! Now there is even an error message that was not there before.

Only a reset helps.

Here is the option list:


Matthias

  Quote  

If Instr(MM.DEVICE$, “HDMI”) Then
Error : Expression Syntax

You need to re-download - this is the bug I reported fixed earlier this morning

I'll have a look at the mp3 issue

This is with the latest version

PicoMite MMBasic RP2040 Edition V6.00.02RC3
Copyright 2011-2025 Geoff Graham
Copyright 2016-2025 Peter Mather

> option list
PicoMite MMBasic RP2040 Edition V6.00.02RC3
OPTION SYSTEM I2C GP4,GP5
OPTION COLOURCODE ON
OPTION DISPLAY 44, 89
OPTION SDCARD GP17, GP18, GP19, GP16
> list functions
Error: Invalid address - resetting
>

Greetings,

Jan.

V6.00.02RC4 is available on

https://geoffg.net/Downloads/picomite/PicoMite_Beta.zip

Fixes MP3 playback on HDMI versions
Fixes LIST FUNCTIONS
Fixes instability in 1280x720 mode 3 HDMI
Fixes graphics commands in 800x600 VGA
Fixes memory issue in WAV playback on RP2040 VGA
Fixes bug in MM.DEVICE$ in USB versions

@Peter,

Yes, that later version (I call it "v6.00.02rc3_2" runs all the programs that have caused problems before. We have another winner.
This one is just as good as "v6.00.02b16_2" was...

- logic analyzer: runs
- petscii robots: runs
- as02-5 runs
- rocks: runs
- blocks_sound : runs (played for 20 minutes)
- kong : runs
- chemichaos : runs
- circle : runs
- asciimovie : runs
- flappy : runs
- snake : runs
- gems&rocks: runs
- flow : runs
- 2048 : runs
I still have to test the thermal camera.

Volhout

PicoMite VGA/HDMI 6.00.02b10
Is it possible to make the MAP(n) function work in MODE 1 to set the color with the COLOR command and other commands ?
For example, something like this:

No, you can set the tile colours. With HDMI you have a choice of 32768 RGB555 colours in 640x480 and 720x400 and 256 RGB332 colours in other modes. In VGA you kjust have the normal 16 colours

TILE 0,0,RGB(red),rgb(white),MM.HRES\MM.fontwidth,mm.vres\mm.fontheight
Edited 2025-03-16 03:05 by matherp

  matherp said  

No,

I recognize the first phase of the already traditional scheme of our communication with you.

Not in this case. The release is closed.

mp3 works   ==> rejoiced too soon!  



I miss an output of the CPU speed when it is not on default.

Matthias
Edited 2025-03-16 05:10 by homa

  Quote  

play mp3 "going"
Error : Not enough Heap memory

You don't give me a sequence or what else is loaded and/or has been run. If memory is used for other things you will get this

exactly the same sequence as above:

reset

> b:
> play mp3 "going"
> load "spriteDemo"
> run
CTRL+C
> mode 1
> option list
...
> ? MM.INFO$(CPUSPEED)
315000000
> play mp3 "going"
Error : Not enough Heap memory

  matherp said  

V6.00.02RC4 is available…
Fixes instability in 1280x720 mode 3…..

Confirming all is good once again.  

Thank You for the quick fix; it is very much appreciated.

Yes but you don't show how much memory spritedemo is taking. I've checked and playing mp3 doesn't leak memory so it just looks like you are using it all - nothing I can do about that. MP3 playing is very memory hungry

  matherp said  

Yes but you don't show how much memory spritedemo is taking. I've checked and playing mp3 doesn't leak memory so it just looks like you are using it all - nothing I can do about that. MP3 playing is very memory hungry

spriteDemo is your Code from here: https://www.thebackshed.com/forum/ViewTopic.php?TID=16672&PID=216958#216958#216958

you are right, a “new” helps to free the memory and then “play mp3” works again.
Edited 2025-03-16 09:12 by homa

  Quote  

you are right, a “new” helps to free the memory and then “play mp3” works again.

There does seem to be a bug but it looks like something to do with clean up of sprites rather than anything to do with mp3. Will invesigate further

UPDATE
It's caused by the sprites not being closed with ctrl-C. You can do this manually with SPRITE CLOSE ALL. This is a difficult question. How much do I clear up after ctrl-C and how much to leave? The advantage of leaving things is to allow debugging at the command line. So, at the moment, after exiting I could do type SPRITE SHOW to check something. The disadvantage, as you have found is that it leaves a resource tied up.

Any thoughts from anyone reading this appreciated
Edited 2025-03-16 19:47 by matherp

  Quote  

The advantage of leaving things is to allow debugging at the command line.

From my point of view please leave it as it is, for debugging it is really useful.
And there are commands like "memory" and "clear", a "new" is not necessary.

  matherp said  

UPDATE
It's caused by the sprites not being closed with ctrl-C. You can do this manually with SPRITE CLOSE ALL. This is a difficult question. How much do I clear up after ctrl-C and how much to leave? The advantage of leaving things is to allow debugging at the command line. So, at the moment, after exiting I could do type SPRITE SHOW to check something. The disadvantage, as you have found is that it leaves a resource tied up.

Any thoughts from anyone reading this appreciated

How about adding a non-remanent "DEBUG" option?
For example, "OPTION DEBUG SPRITE KEEP/CLEAR," where "CLEAR" would be the default.
Saving such "OPTION DEBUG" variants together in a bit field in RAM (integer = 64 bits) would also be memory efficient.
This would make it easy to add more "OPTION DEBUG" variants.
But I don't know if that would be easy to do.
Edited 2025-03-16 20:57 by bfwolf

Hi Peter,
I know it's too late for this release, but maybe an idea for the next one? Is it possible to automatically set the lengths of string constants? This means that MMBasic or the preprocessor limits the memory usage to the value required by the string constant, a kind of automatic "LENGTH" command in the background. I'm currently busy with VT100 escape codes. That can easily amount to more than 20 constants and consume more than 5-10kB of heap memory for constants that should actually only require 100 bytes. I'm not interested in discussing how to work around this, e.g., by inserting the escape sequences directly into the code or something similar.

Perhaps this is something you'd like to add to your to-do list?
Regards
Michael

Michael,



Shows that 21 strings length 10 characters (210 bytes) consume only 256 bytes heap. Quite efficient.



Volhout
Edited 2025-03-16 22:38 by Volhout