 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Portable MMBasic
Page 1 of 2   |
|||||
| Author | Message | ||||
| jvanderberg Newbie  Joined: 06/05/2026 Location: United StatesPosts: 12 |
So I've done an arguably silly thing. I started out just hacking away at MMBasic, trying to make it a bit faster for games. I added a byte code compiler, which was fun and interesting, but it didn't make games any faster, but that's another story. To make it easier to test and validate things, I did a lot of work to separate out the hardware dependencies, and got a version of mmbasic running on my mac, so I could run tests to validate the bytecode compiler. But once I had reasonable portable mmbasic C engine, I thought, 'hey, can't I compile this as WASM, and run it in a browser?' Turns out, yes, yes you can. You can try it here: MMBasic Web But this was all a bit of a mess, because I started with PicoMite, which has a bunch of hardware dependencies mixed in with core code, controlled with #ifdef flags. Getting all that to compile in wasm was an undertaking. So I went down an even further rabbit hole. What if you were to decouple the MMBasic compiler code as much as possible from the hardware, and where you can't, write a hardware abstraction layer, with per-port drivers for hardware specific code? Turns out that's a ton of work, even using Codex and Claude for help. So much has changed that there's really no way to merge new updates from the upstream. But mostly it's all still MMBasic/PicoMite, with stuff moved around and split up. The build system is quite a bit different. It prefers to compose a port from port specific drivers and stubs rather than with flags/switches. It's still a work in progress, but it should be much easier to port to another architecture or hardware config, and share the core logic between ports. This also has the side effect of allowing a single change to break all the ports, so I've invested a good amount of time in test harnesses and on device smoke tests. I've got an esp32 port in progress, there's the WASM port, and I even ported it to the 386/486 (only tested in QEMU, but there's a floppy image if you want to try it on real hardware). I've also validated that pico builds produced from the restructured codebase run on the picomite, and a homebrew pi pico 2 board with hdmi/psram/sd/i2s. This doesn't have all the latest MMBasic features, because I started from the wrong fork before I realized. I have ported some major new language features. But there's no way any longer to just directly take changes from upstream, especially big changes. Its more a manual process of extracting code and validating, but its roughly 6.01.00b10 + Struct/Tilemap/Const/redim. Am I crazy? Edited 2026-05-15 09:30 by jvanderberg |
||||
| lizby Guru  Joined: 17/05/2016 Location: United StatesPosts: 3751 |
If so, we need more crazy. I'd be interested in an ESP32 port which had comprehensive web support, but I suspect that's a different beast altogether. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on FOTS |
||||
| jvanderberg Newbie Joined: 06/05/2026 Location: United StatesPosts: 12 |
Yep, I've got full web support, telnet console, web server running on an adafruit esp32 s3 metro. There's a large surface area so it's tough to test it all thoroughly. Codex made some automated smoke tests that are comprehensive, but they've missed some nuance. So manual validation is important here, but there are so many web features in mmbasic, I am not familiar with them all. I am also experimenting with a sort of virtual console that would allow you to get at the mmbasic graphics console, with sound, over wifi. This is so you can test without plugging in an external display, and see graphical output. It's not fast, but it's mostly usable. |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 625 |
INPUT doesn't work for me. A question mark prints but I can't type anything. |
||||
BarryH Regular Member  Joined: 05/01/2025 Location: AustraliaPosts: 41 |
@jvanderberg - this is a fantastic concept and great project. If methods could be found to reduce the workload to keep it aligned with the latest MMBasic releases, then I can see this going a long way. BarryH |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2517 |
hi Josh, welcome to the forums! what you have been able to produce is quite an achievement, opening up the possibilities of having a core source that is 100% independent of the platform it is running on. Microsoft BASIC started out this way, with just a couple or three 'spliced in' routines containing the I/O code (keyboard, VDU, mass storage) that was hardware dependent. i believe that mmbasic started out this way, but slowly drifted towards #IFDEF mayhem as the only expedient way at the time of bringing in a multitude of different microcontroller-based platforms. i'd not be too worried about not starting out with the very latest version of mmbasic, as for a number of years most of the language additions have just been directed towards catering for quite specific hardware and bespoke user requests; the core of the language has not changed much at all since the MX170 version (5.05.05) and dates from early 2020s. indeed, the source for the MX170 version (and others) is available on request from https://mmbasic.com/source.html you may also like to have a look at Tom's work on a Linux port, here: https://sockpuppetstudios.com/ https://github.com/thwill1000/mmb4l cheers, rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2517 |
oops, duplicate post  Edited 2026-05-15 15:50 by robert.rozee |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4321 |
Wow! Crazy? Dunno. Very busy I suppose. I'm just trying it in a browser... John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4321 |
Works for me in firefox (on Linux, doubt that's relevant though). John |
||||
| jvanderberg Newbie Joined: 06/05/2026 Location: United StatesPosts: 12 |
This should be fixed. |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 751 |
Hi, this is really impressive! Wow! Can't wait to see more! Greetings Daniel |
||||
| ville56 Guru Joined: 08/06/2022 Location: AustriaPosts: 481 |
@jvanderberg, very impressive work indeed. I like the idea of having a codebase which is easily portable to new/other hardware. This opens up the path to use new hardware bases as they evolve. Did you also consider to make drivers loadable? This could keep the code of individual instances smaller and maybe also faster. It could also allow to share the load of driver development among more individuals. But I have no idea if this is feasible at all. At least it takes a lot of design considerations and maybe it is easier to drop support for "outdated" hardware from time to time. All in all to me it sounds like an approach of a redesign of MMBasic. I like this as a sign that MMBasic is alive and evolving. 73 de OE1HGA, Gerald |
||||
homa Guru Joined: 05/11/2021 Location: GermanyPosts: 582 |
WOW! REALLY COOL PROJECT! It only works for me in Edge; Firefox on Windows 11 doesn't work. The demos are impressive. The 'new' command doesn't clear the memory?! Matthias Addendum: Firefox is working after all; I just had to restart it once. The "new" problem remains. Edited 2026-05-16 02:32 by homa |
||||
| jvanderberg Newbie Joined: 06/05/2026 Location: United StatesPosts: 12 |
Absolutely no shade on the existing code base, it's amazing work that's grown organically over time. When I said 'mess' I meant more what I had to do to the existing code base to get it to compile as WASM. Thus the work to make it more portable. It's mostly just moving things around and breaking files up into more modular units - decoupling core interpreter logic from hardware interactions. Outside of the esp32 port, there's very little new code. So it's a testament to the existing code base that this can be done. I will definitely take a look at the Unix port, my mmbasic_ansi port is basically mmbasic written to a posix API, so it should compile on unix. It actually supports graphics in a terminal using halfblock rendering, but no sound, yet. I am not too worried about tracking the latest and greatest. Codex and Claude can help with that, though I don't think you can underestimate validation work, there's only so much you can automate. I've tried to keep major new language features, which aren't that hard, more obscure or new hardware features, I think I'll wait for somebody to ask. |
||||
| jvanderberg Newbie Joined: 06/05/2026 Location: United StatesPosts: 12 |
Thanks for the feedback, I will take a look. |
||||
| jvanderberg Newbie Joined: 06/05/2026 Location: United StatesPosts: 12 |
So what I am working towards is making it so you can compile drivers in, or not, your choice. If you don't include a driver, the functionality gets stubbed out. So for example, if your board doesn't have sound, a 'PLAY TONE' command would result in an error. I am not sure exactly how to load drivers dynamically. As it is right now, the code is either there or not. The memory and configuration a driver uses can be deferred until the driver is initialized. In fact I believe the SD card driver for my esp32 port does this. It waits until you access b: to configure and reserve memory for the driver. It might work this way on other ports, I am not sure. My goal would be to make it relatively easy to build a new port with exactly the drivers a particular board needs. I am getting there, but it's not perfect. |
||||
LeoNicolas Guru Joined: 07/10/2020 Location: CanadaPosts: 576 |
jvanderberg Do you have the code on a git repo where we can contribute for? |
||||
| jvanderberg Newbie Joined: 06/05/2026 Location: United StatesPosts: 12 |
Sorry, it's kind of linked by the demo, but yes, the repo is https://github.com/jvanderberg/PicoMiteAllVersions I will likely change the name, as it's not really PicoMite any longer, just the pico port is 'PicoMite'. It's a bit of a mess with some half finished plans and audits, but it should be in reasonably good shape, the Pico builds are usable on real hardware. Edited 2026-05-16 03:57 by jvanderberg |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4321 |
Yes, take a look at Tom's MMB4L as he also has unit tests. John |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4368 |
Hi folks, I thought I should show signs of life since MMB4L and I have been name-checked twice. I'm still here but real life has been a killer for the last month and will probably be for a month more - no free time at all. Impressive work @jvanderberg, looks like you and Claude have been burning the midnight tokens. Good luck to you trying to keep in-synch with the mainline features . I have largely given up that struggle as MMB4L's file organisation and conventions have diverged.If you do look at MMB4L then I suggest the https://github.com/thwill1000/mmb4l/commits/mmb4l-windows-6/ branch, but it's been too long now and I can't remember if I "parked" it terribly well. Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |
