Posted: 05:24pm 13 Apr 2025 Copy link to clipboard
Volhout Guru
Hi Kevin,
I think the message got through to Peter, and it is depending if he is willing to do something about it. The message is clear, starting and stopping sound has impact on speed (on some programs, read: some MMBasic instructions).
At the moment I am very hesitant to ask something this complex to Peter. He is close to a release, and this could mean digging into the core of the system, potentially resulting in an unstable system, and months of debugging to get every bug out of there. It happened at 5.09.00 -> 6.00.00, and then 6.00.00 -> 6.00.01. And again at 6.00.01 -> 6.00.02...and we are close to release....
Maybe it is something small, and Peter may know. Let's leave the judgement to him.
Volhout
P.S. 6.00.00 never saw daylight because of a toolchain change from RP. P.P.S. RP2040 sound (PWM) historically used 25% of CPU resources. SPI used more, and according Peter I2S uses less. But this may be depending on CPU speed. P.P.P.S It is possible that (in an effort to give 2040VGA back it's 100k+28k heap) some commands are pushed out of RAM and moved to flash. Thus became slower. Edited 2025-04-14 03:34 by Volhout
Posted: 05:50pm 13 Apr 2025 Copy link to clipboard
matherp Guru
There is something very odd about this program. I can only assume something about the audio running it is massively improving the cache hit ratio. If you try with a simple benchmark like grainbench, the impact of audio is massively negative.
I've found and fixed the play pause bug and also enabled the mouse to work properly in all resolutions - will post updated versions tomorrow
Edited 2025-04-14 03:58 by matherp
Posted: 06:22pm 13 Apr 2025 Copy link to clipboard
twofingers Guru
Hi Peter, I don't know if this is a bug or intended behavior (in EDIT FILE FName$) : It appears that an attempt is being made to create the swap file on drive A:.
System: PicoMiteHDMI MMBasic USB RP2350A Edition V6.00.02b11
I suspect you're not a fan of calling EDIT from within a program (neither am I). But it's used in FM. Can you confirm that this is the intended behavior (swap file on drive A:)? Kind regards Michael
Posted: 06:32pm 13 Apr 2025 Copy link to clipboard
Mixtel90 Guru
Doesn't it save the backup to whatever drive is current when the EDIT command is issued? It may not use a drive letter in the file path. I haven't got a system set up to test it on at the moment.
Posted: 06:44pm 13 Apr 2025 Copy link to clipboard
twofingers Guru
Hi Mick. I would have expected that, too. It would be useful if there was an option to specify an alternative drive. Michael
Posted: 07:37pm 13 Apr 2025 Copy link to clipboard
No, I would avoid running EDIT from within a program unless there's no alternative way to do it.
Posted: 07:52pm 13 Apr 2025 Copy link to clipboard
twofingers Guru
Hi Mick,
EDIT and EDIT fname$ can only be invoked at the command prompt. However, it you require to edit a file in a program you can use the EDIT FILE fname$ command. This differs from EDIT fname$ in that it does not clear any variables and can only use any free memory for the edit buffer. This will place greater limits on the size of the file that can be edited if the memory usage of the calling program is itself large.
This is about EDIT FILE. And yes, I'd like to avoid it too. I already wrote that above. I'm just interested to know if I'm making a mistake or if there's an implementation error. As it is now, it seems pretty unusable to me. I took a closer look at it for the first time today. I had it commented out in FM for a while. Michael Edited 2025-04-14 06:03 by twofingers
Posted: 10:01pm 13 Apr 2025 Copy link to clipboard
matherp Guru
Edit file requires enough space on the A: drive for an image of the system heap. If that space isn't available it will fail. Only the A: drive can be guaranteed to be available so I'm not changing this. If it doesn't work for you don't use it.
Posted: 10:10pm 13 Apr 2025 Copy link to clipboard
twofingers Guru
Hi Peter, thanks for the clarification. Perhaps EDIT FILE FNAme$, "B:" or something similar could be added later. Personally, I probably won't use it. A clarification in the manual would be helpful. Kind regards Michael
Posted: 10:14pm 13 Apr 2025 Copy link to clipboard
matherp Guru
I've isolated this issue to something to do with opening any file and leaving it open
Instead of playing an mp3 and pausing it just include the line "Open "bootcount" For input As #1" nothing else and you will get the performance back.
Now, if anyone can see where in the MMbasic code this is making the difference, please let me know. I thought it might be CheckSDCard(); but patching this out doesn't make the difference so at the moment I'm stumped.
Posted: 06:50am 14 Apr 2025 Copy link to clipboard
Volhout Guru
@Peter,
I can NOT confirm opening a file and keeping it open speeds up on 2040 VGA PS2. Tried on: - bubbles (mode 2) - logic analyzer (mode 1) - petscii (mode 2).
If anything then there is a 0.5% speed penalty, not a gain.
Volhout
Posted: 07:13am 14 Apr 2025 Copy link to clipboard
Bleep Guru
Hi Peter, Thanks for investigating. :-) I've also done some more looking, because I'd found like you, it was only really this particular program that benifited. I've narrowed it down to the Sin and Cos functions, if you remove some of them the improvement reduces, if you get rid of them completely, it vanishes. So, is there something about using Sin & Cos, that is different? a exteranl library, firing up a different part of the CPU, whatever? I'll have a look, see if I've got anything else that uses a lot if Trig. Solar system clock maybe? and see what happens. Regards Kevin Edited 2025-04-14 17:14 by Bleep
Posted: 07:28am 14 Apr 2025 Copy link to clipboard
matherp Guru
Kevin
Can you confirm this is an RP2350 only issue? Can you confirm if you see it with VGA and HDMI or just HDMI? Can you confirm my file open command has the same impact as playing an Mp3?
Thanks
Harm
Please run the attached on RC12 with and without the open line commented and report results
' Bubble Universe
'2 Nested loops each 52 =2704 points calculated VGA 'Pico 2040Anal @ 378MHz normal 316mS Framebuff 397mS 'Pico 2350Anal @ 378MHz normal 185mS Framebuff 185mS
'2 Nested loops each 66 =4356 points calculated VGA 'Pico 2040Anal @ 378MHz normal 553mS Framebuff 683mS 'Pico 2040Anal @ 378MHz Framebuff/CLS 607ms 'Pico 2350Anal @ 378MHz normal 341mS Framebuff 341mS 'Pico 2350HDMI @ 372MHz normal 333mS Framebuf 333mS 'Pico 2350HDMI @ 372MHz normal 278mS Framebuf 279mS CLS,remove arrays 'Open "bootcount" For input As #1 'Play mp3 "B:/hmp3" Pause 1000 'Play pause
MODE 2 Font 8 FRAMEBUFFER create FRAMEBUFFER write f
Dim Float u(65),w(65),p,q,t,v=0,x=0,b Dim Integer c(65),d(65),n(65),m(32,65),nn,dd,xc,yc,xs,ys Dim Integer a,g,i,j,cc',y,z,f(16,65),l(16,65) 'Dim Integer e(65):Math Set 2,e() Const r=(2*Pi)/235,k=255,s=50 CLS RGB(black) t=Rnd*10 't=1 nn=Peek(varaddr n()) dd=Peek(varaddr d()) cc=Peek(varaddr c()) 'calculate centre and scale factor xc=MM.HRES\2:yc=MM.VRES\2 xs=MM.HRES/4.2:ys=MM.VRES/4.0 'Oval 'xs=MM.HRes/6:ys=MM.VRes/4 'Circular
For a=0 To 65 For g=0 To 65 If a<18 And g<18 Then n(g)=RGB(0,255,0) Else n(g)=RGB(a*3.93,g*3.93,128*(a+g<65)) EndIf Next 'g Memory pack nn, Peek(varaddr m(0,a)),66,32 'pack pixel colours Next 'a Do CLS Inc t,0.035:g=0:Print Timer,MM.Info(heap):Timer =0 For i=60To 255Step 3 'z=Peek(varaddr f(0,g)):Memory unpack z,cc,66,16 'y=Peek(varaddr l(0,g)):Memory unpack y,dd,66,16 'Pixel c(),d(),0'Box c(),d(),e(),e(),0,,0 b=r*i+t For j=0To 65:u(j)=Sin(i+v)+Sin(x):v=Cos(i+v)+Cos(x):x=u(j)+b:w(j)=v:Next Math Scale u(),xs,c():Math Scale w(),ys,d():Math add c(),xc,c():Math Add d(),yc,d() Memory unpack Peek(varaddr m(0,g)),nn,66,32 'unpack pixel colours Pixel c(),d(),n()'Box c(),d(),e(),e(),0,,n() 'Memory pack cc,z,66,16:Memory pack dd,y,66,16 Inc g Next 'i FRAMEBUFFER copy f,n Loop
Edited 2025-04-14 17:35 by matherp
Posted: 07:31am 14 Apr 2025 Copy link to clipboard
Volhout Guru
@Peter,
Isn't there a difference between 2040 and 2350 with respect to floating point ? One of the 2 has math routines in it's ROM ? The other has a floating point co processor.
Volhout Edited 2025-04-14 17:34 by Volhout
Posted: 07:36am 14 Apr 2025 Copy link to clipboard
matherp Guru
Harm
Posts crossed - please see above test for VGA RP2040
Posted: 08:23am 14 Apr 2025 Copy link to clipboard
Bleep Guru
Hi Peter, No. 1 & No. 2: no I see this on a VGA 2040 as well, admititedly an older RC, I will update this one and let you know, but it'll take a while, it's an unusual setup, and I have to get it going blind. :-(
PicoMiteVGA MMBasic USB RP2040 Edition V6.00.02RC8 OPTION SERIAL CONSOLE COM2,GP24,GP25,BOTH OPTION SYSTEM I2C GP12,GP13 OPTION FLASH SIZE 16777216 OPTION COLOURCODE ON OPTION KEYBOARD UK OPTION HEARTBEAT OFF OPTION PICO OFF OPTION CPUSPEED (KHz) 378000 OPTION RESOLUTION 640x480 OPTION DISPLAY 30, 53 OPTION SDCARD GP22, GP18, GP19, GP16 OPTION VGA PINS GP4,GP6 OPTION KEYBOARD REPEAT 210,60 OPTION AUDIO GP10,GP11', ON PWM CHANNEL 5 OPTION RTC AUTO ENABLE
No. 3 Yes your opening a file has the same effect. The Above setup gave 555mS per itteration and 424mS per itteration, using open a file.
I have now tried my Solar clock, which has a fair amount of Trig. in it, and I can't see any noticable difference, so to be honest I think this is very specific to hammering the Sin Cos functions, and probably not worth persuing, unless you think there is something elso going on, worth the effort? Regards, Kevin. I will update my 2040 VGA and let you know. Just a thought, they are all USB? Edited 2025-04-14 18:24 by Bleep
Posted: 08:45am 14 Apr 2025 Copy link to clipboard
Volhout Guru
With this version of "bubbles" there is a MAJOR difference. RP2040 252MHz VGA PS2 - 920ms per loop with file closed - 630ms per loop with file open
Previously I tested with an other version of bubbles I had, and saw no difference (a loop time of 482ms). Amazing....
Volhout
EDIT: Amazing since the 2 versions of Bubbles are really not that different. I'll see where the differences are. FRAMEBUFFER use does not cause this. Edited 2025-04-14 19:00 by Volhout
Posted: 09:19am 14 Apr 2025 Copy link to clipboard
Bleep Guru
Yes the only difference was that the older version used arrays to blank out each point individually, made a big difference if using a LCD, however this version simply uses CLS and redraws the whole screen, with a frame buffer, (no frame buffer does not affect this particular speed up). I did then find that removing the now redundant arrays, made a significant differencs to the speed, everything is still there, commented out, just un-comment and then remove the CLS, and frame buffer stuff in the loop?
Posted: 09:23am 14 Apr 2025 Copy link to clipboard
Volhout Guru
@Peter,
There is some relation with the use of the framebuffer. 2040 VGA PS2
Above version of the program
Framebuffer File open File closed Yes 630ms 920ms No 630ms 735ms
But with the Bubbes.bas I have there is no difference.
Framebuffer File open File closed Yes 605ms 603ms No 489ms 487ms
Just for completeness, find attached my bubbles version
'Open "a:/bootcount" For input As #1 ' Bubble Universe ' '2 nested loops 52 each = 2704 points calculated. 'Pico 2040 @ 378MHz VGA normal 336mS VGA Framebuffer 418mS 'Pico 2350 @ 378MHz VGA normal 193mS VGA Framebuffer 194mS ' 'If modified to 2 Nested loops each 68 =4761 points calculated 'Pico 2350 @ 378MHz VGA normal 361mS VGA Framebuff 361mS ' MODE 2 'FRAMEBUFFER create 'FRAMEBUFFER write f
Dim Float u(51),w(51),p,q,t,v=0,x=0,b Dim Integer a,g,i,j,c(51),d(51),e(51),n(51),nn,dd,xc,yc,xs,ys Dim Integer f(13,51),l(13,51),m(26,51),y,z,cc,tt Const r=(2*Pi)/235,k=255,s=50 CLS RGB(black) t=Rnd*10:Math set 2,e() 't=1 nn=Peek(varaddr n()) dd=Peek(varaddr d()) cc=Peek(varaddr c()) 'calculate centre and scale factor xc=MM.HRES\2:yc=MM.VRES\2 'xs=MM.HRES/4.5:ys=MM.VRES/4.5 'Oval xs=MM.HRES/5:ys=MM.VRES/4 'Circular
For g=0 To 51 For a=0 To 51 If g<26 And a<13 Then n(a)=RGB(0,255,0) Else n(a)=RGB(g*5,a*5,128*(g+a<51)) EndIf Next 'a Memory pack nn, Peek(varaddr m(0,g)),52,32 Next 'g Do Timer =0 Inc t,0.015:g=0':Print Timer:Timer =0 For i=50To 255Step 4 z=Peek(varaddr f(0,g)):Memory unpack z,cc,52,16 y=Peek(varaddr l(0,g)):Memory unpack y,dd,52,16 Pixel c(),d(),0'Box c(),d(),e(),e(),0,,0 b=r*i+t For j=0To 51:u(j)=Sin(i+v)+Sin(x):v=Cos(i+v)+Cos(x):x=u(j)+b:w(j)=v:Next Math Scale u(),xs,c():Math Scale w(),ys,d():Math add c(),xc,c():Math Add d(),yc,d() Memory unpack Peek(varaddr m(0,g)),nn,52,32 Pixel c(),d(),n()'Box c(),d(),e(),e(),0,,n() Memory pack cc,z,52,16:Memory pack dd,y,52,16 Inc g Next 'i Print @(0,0);Timer 'FRAMEBUFFER copy f,n Loop
Amazing.. This version even performs more memory packs and memory unpacks, but over a smaller set of data (52 versus 66).
Volhout
Posted: 10:09am 14 Apr 2025 Copy link to clipboard
matherp Guru
Just done more testing and I see the effect on both RP2040 and RP2350 VGA non-USB. I'm beginning to believe it is all to do with memory page access conflicts and small difference in the placement of data in memory can have significant impacts
Page 25 of 39
The Back Shed's forum code is written, and hosted, in Australia.
