I spent a good amount of time porting MMBasic to WebAsm and then created a nice user interface for it. You can find it here: MMBasic Web
This is essentially a web emulator for the PicoCalc. It can make it a lot easier to develop basic programs for the PicoCalc. You can drag and drop files into its emulated SD card, edit the files live in the browser, and click a single button to run them in the emulator. This drastically shrinks the debugging loop.
Most things should work in the emulator. GPIO, I2S and other hardware specific stuff does not. MP3 support could work, but is currently unimplemented.
This all started out with an attempt to speed up PicoMite, the primary outcome was âFRUNâ (Fast run), which is a bytecode compiler for MMBasic. You can try it out with the âlightningâ icon in the web editor. For math intensive tight loops it can be 10x faster (try âmand.basâ with RUN and FRUN to compare). FRUN might not work on a given program, if so, let me know and I might fix it.
I also created a new âFASTGFXâ graphics primitive that can drive games at about 50fps. In the web emulator they donât do much, as itâs so much faster than a real pico, but on a real device it uses double buffering and DMA to make screen updates much faster. Try out âpico_blocks.basâ, it should perform about the same in the emulator as it does on real hardware, even an RP2040 (note, this requires the PicoCalc has the firmware from my Repo, see below).
If things run too fast in the emulator, edit the config and change the slowdown option until your program performs about the same on device as it does in the emulator.
This is great! One of the things I found really frustrating with MMBasic on the PicoCalc was how cumbersome it was to write code on the desktop and then transfer files for testing. Your WebAsm port and enhancements make for an excellent development environment, and easier testing.
A few notes:
In the about page you have: âThe PicoCalc build used here tracks Craig Madcockâs madcock/PicoMiteAllVersions.â I donât know where âCraig Madcockâ came from, but Iâm Michael Adcock, (madcock on github).
That code in my repo hasnât been updated in quite a while, and I wasnât really planning on maintaining it further, especially since the official releases now support PicoCalc builds. So itâs still stuck back at an earlier version of PicoMite MMBasic. At the time I last updated it, the version was newer than the original offering from Clockwork, with their changes and a few other things merged into the (official PicoMite) UKTailwind sources. But itâs well out of date now, and thanks to @ernstâs efforts, the official UKTailwind sources provide PicoCalc builds too. All this is to say that you may want to consider updating your WebAsm version to bring it in line with the official sources instead of my repo. Based on my experience, it seems like PicoMite users have always been keen on having access to the latest version. Trying to keep up with the official updates is often a chore though.
The FASTGFX and bytecode compiler sounds like something that should eventually make their way into the offiical release of PicoMite, assuming Peter and TheBackShed folks are interested and willing (which might be assuming a lot!) I havenât actually played around with FASTGFX on my PicoCalc yet, but Iâm looking forward to it.
I had all but given up on using PicoMite for game development on PicoCalc due to its poor speed, but it sounds like youâve improved things considerably! Nice.
Sorry about the name. I will fix that. I cloned this repo long ago and made the mistake of not checking before I embarked on extending it. So it looks like I might have a lot of work getting it up to date. I think there was a reason I picked yours, maybe psram support? Not sure. Or maybe you had uf2 builds?
The core performance improvement is FASTGFX. The byte code compiler is important for long running compute intensive loops, which games tend not to have. It helps a ton for stuff like the Mandelbrot viewer. I also tried to backport the fastgfx stuff to the FRAMEBUFFER code but couldnât get the same result. Itâs just doing more.
Unfortunately the original code base is not well structured for the bytecode and webasm work. There are monolithic files where the core interpreter is mixed with the hardware abstraction layer. I tried to break things apart, had a little success with that but then fell back to #ifdef. Ideally MMBasic would have a single repo with different hardware abstraction layers.
I think one of the core improvements here actually goes unmentioned in my post. I got the interpreter and graphics stack running natively on the host, as a precondition for running it in webasm, so thereâs a full test suite that runs locally on the developerâs machine. That was a massive help in validating the bytecode compiler.
One âfudgeâ in the web emulator is that it doesnât properly implement fastgfx stuff, because it doesnât need to. The web is super fast. So about all the fastgfx code does there is implements a frame per second blocking call on âswapâ. A FRAMEBUFFER game would probably be even faster in the web emulator. Iâd probably need to throttle graphics throughput if want to properly simulate on device behavior.
