|
Forum Index : Microcontroller and PC projects : Left behind ?
| Author | Message | ||||
| IanT Senior Member Joined: 29/11/2016 Location: United KingdomPosts: 132 |
Yes! Absolutely Mick (and I had a Nascom 2!) :-) Regards, IanT |
||||
| LeoNicolas Guru Joined: 07/10/2020 Location: CanadaPosts: 608 |
I like to implement games with MMBasic out of sheer nostalgia. Basic was the first programming language I learned at the end of the 80s. Unfortunately I'm feeling the MMBasic a little fragmented, with multiple not compatible versions. It is more convenient for me to implement my projects on my PC and running then on an emulator, and after completing the implementation, to move them to the real hardware. It is most because my projects are usually very complex, with multiple files, and long code. This is being a pain on the MMBasic ecosystem. I don't have a Windows machine and running the MMB4W on wine is not the best experience. MMB4L is still in development, but behind the Windows version. And both are way behind the MMBasic for the pico. Python is a nice programming language, it is modern, and the emulator version is similar to the Pico 3 version. Edited 2026-07-26 02:49 by LeoNicolas |
||||
| some_rando Newbie Joined: 25/03/2025 Location: AustraliaPosts: 8 |
My apologies ... for the most part I lurk here, and rarely feel the need to respond to discussions. I am sorry that you guys are experiencing a crisis of faith. Let me give a couple of reasons why I use MMBasic. Number one is that as a human being, I want to program in a non-Internet connected, off-grid, and low power environment. If I need to make a small program change (maybe as simple as changing a constant), I don't want to have to boot an internet capable machine to do so. I want a self-hosting environment. That is, I want access to the hardware at a micro-controller level, with an editor, a local file system, and most importantly some mechanism of backup to removable media. My intention is to have my hardware running 24/7. This may be very difficult to understand for those connected to mains power. When you are using off-grid power, and in the depths of winter, the (say) 10W power requirement of a Pi-class processor will inevitably kill you. My Pico hardware down-clocked to 48MHz is more in the 15mA category. There are plenty of hardware choices for monitoring the hardware, without turning on a monitor. Micropython is not self-hosting. You can't break into the REPL loop. To write micopython code, the straightforward way is to run thonny on more capable hardware. This inevitably means that you are administering both the low-level hardware, and another computer with the development environment. And if you were doing that, you may as well be internet connected and write code in Rust. Further, I want to write elegant code. Code that I can come back to perhaps some years later, and pick up where I left off, because the code is so understandable. AI may be very capable, and in time could exceed the abilities of human programmers. But do you trust it? When it breaks its boundaries, what might it insert in your code without permission? It also adds another whole level of power dependency into the mix, at orders of magnitude greater power requirement, ie we are assuming gigawatt class power centers available in the background. Don't be too quick to adopt AI. It is fragile technology, and might not go the distance. Isn't the human brain in the 100W class? There is no shortage of human ingenuity and intelligence. Really, short of using it on the battlefield, I can't see the business model. |
||||
| scruss Senior Member Joined: 20/09/2021 Location: CanadaPosts: 111 |
Ctrl-C has always worked for me in MicroPython. |
||||
| scruss Senior Member Joined: 20/09/2021 Location: CanadaPosts: 111 |
I'm a crap programmer too, but I really enjoy it. I don't consider it drudge work at all. I enjoy learning from what went wrong. As I have an exceptionally bad memory, I even enjoy re-implementing the same program that I'd forgotten I'd solved years ago. I've tried prompt-based programming, but it produced code that needed careful debugging and testing, if it worked at all. For me, that ended up taking longer than writing from scratch. Only AI can deal with the problems that AI creates. Me, I'm very slow and very human. Much of my code is deliberately futile, but it's my code. “I tell you, we are here on Earth to fart around, and don't let anybody tell you any different.” — Kurt Vonnegut |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 697 |
I have had the same spirit. Especially about Python.. AFAIK Anthropic (etc) uses Python for its AI, and now it is self-generating its own code - so it is able to write and use code faster and probably better than any human. So my pleasure in providing a useful program, and any satisfaction in its craft and design, is bypassed. [That is not to disparage Anthropic et al at all, a brilliant and admirable achievement, and maybe an inevitable step of human evolution ! And better Anthropic than ChatGPT, especially after the last news ]But for me in general there is still the admiration and satisfaction of seeing an elegant and intricate mechanism working as a whole, like a Swiss watch as they used to say, and hopefully creating something along those lines. No matter whether it is a program or an actual machine, there is a real beauty in it. So I still tinker away, for my own enjoyment. Learning how to use AI and Claude is probably better than learning Python. Instead of comprehending a problem, the required ability now is understanding how to make AI comprehend the problem. Instead of using a thermometer to measure, say, the boiling point of a liquid, you will use AI program XYZ and the instrument will tell you what it thinks the boiling point is, and it will probably be more accurate . Bring on the lawyers... I just hope humans do not become a "hive mind" as per the Borg (StartreK) |
||||
Grogster![]() Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 10000 |
I, like many others here, have ZERO intention of giving up on using MMBASIC for Micro-python or any Python-like alternative. It IS fantastic, that Peter is developing a Python port for the PM3 computer, as that increases the useage base for the PM3 platform, if it can actually run a couple of totally different language firmwares. So, I'm all for it, and watching and reading about the Python stuff with interest, but I don't plan to drop what works and works REALLY well for me, and that is still MMBASIC at this point. Speed isn't everything. Not in the applications I use MMBASIC for, anyway. I also ADORE the built-in editor in MMBASIC, which allows you to debug code right there in real-time, live on the running chip. This is something you simply CAN'T do with anything that requires an IDE to write the code, PICAXE included. The ability for you to stop a running code, and enter the built-in editor, play with things and squish bugs right there on the chip with nothing else but a terminal software is a glorious feature. I have no idea if MicroPython has a built-in editor or not - have not studied the port in enough detail to know that, so if it DOES, that is something in it's favour, but I will still keep using MMBASIC, cos I know it so well now, and as others have already hinted at - I am too old now, to start to learn yet ANOTHER programming language. ![]() Smoke makes things work. When the smoke gets out, it stops! |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11672 |
My Micropython port does have an in-built editor and can be used entirely stand-alone. That was the whole point of the port. No Thonny or anything else. Everything you need to replicate anything you can do in MMBasic without needing any outside involvement. It is not intended as a replacement for MMbasic - just an alternative but one that MAY see involvement from a new generation of hobbiests brought up on python rather than just us old farts. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8981 |
That's a very good point indeed. MicroPython and Circuit Python aren't self-contained. Having a language that's familiar *and* is self-contained in the hardware is something that many people won't have come across. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3833 |
My question is whether Raspberry Pi itself, or Olimex, or Adafruit or some other vendor might manufacture the Pico Computer 3 board and so make it available to a wider audience. Having just gone through the group purchase process with one failed board and 2 trips to the post office required to send boards off to others, and no RM2 wifi or PSRAM placed on the board from JLCPCB, it might make the board available to more buyers, and might ultimately bring more people to MMBasic. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on FOTS |
||||
Grogster![]() Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 10000 |
Well then, that is certainly a great feather to have in the MicroPython port for the PM3 then! No disrespect to any other platform, BTW, PICAXE included. I still use PICAXE for some dedicated simple stuff, that just needs to WORK, and run reliably, and PICAXE does that just fine, even though you have to use the IDE to write and upload the code. But when I discovered MMBASIC with it's built-in editor, I fell in love with that entire concept, and so I expect it will serve the MicroPython port just as well as it does the MMBASIC port. Smoke makes things work. When the smoke gets out, it stops! |
||||
Bryan1![]() Guru Joined: 22/02/2006 Location: AustraliaPosts: 2174 |
Well the excuse I used to get Claude was to really test this micropython making the car club project, those psram and wifi chips according to Mouser will be here between 10am-2pm today so got my ear out for the truck as they will be delivered to my farm So when my next batch turn up the job will be getting some boards to talk to each other over wifi then when using multiple kiosks each can be updated real time to avoid loss's and duplicates. Now for my CNC projects MMBasic will be used so the stepper system can be used and it will be interesting to see how Claude goes with the code. |
||||
| circuit Guru Joined: 10/01/2016 Location: United KingdomPosts: 308 |
Well, that is very much me too! I started in PICAXE and then when Peter "pointedly pointed out" the MMBasic alternative and Geoff's ingenuity, I never looked back, starting with the MX150 and then just about every hardware incarnation since then right through the most excellent Micomite eXtreme and now with the PicoMite stuff. Currently, though, I have got some MX170s out of the cupboard because I need chips with a true Sleep command - and the Pico range do not offer this. This is very much my thinking with the whole range; it is not necessarily the latest chip that is best, but the one that is best configured to one's purpose. I really enjoy MMBasic in all its forms; should I find a need to move to Python then I will, but right now I have no need. |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1490 |
Out of curiosity and because of the Video from ExplainingComputers, I just installed LM Studio on my Linux laptop. And I set up the gemma-4-e4b model locally. What can I say? It basically supports MMBasic, too. My question was: “I'd like to try the ‘Game of Life’ in MMBasic. Do you have any ideas about that?” His answer: “Absolutely! Conway's Game of Life is a perfect, classic project for any programming language—and for MMBasic, too.” That was followed by a presentation several pages long on how the program works and the logic behind it, and then he handed me a finished listing. // --- KONSTANTEN DEFINIEREN --- Sorry for the comments in German.DIM GridA(MAX_X, MAX_Y) AS INTEGER ' Das aktuelle Gitter DIM GridB(MAX_X, MAX_Y) AS INTEGER ' Das nächste zu berechnende Gitter CONST MAX_X = 50 ' Breite des Spielfelds CONST MAX_Y = 20 ' Höhe des Spielfelds // --- HAUPTPROGRAMM-SCHLEIFE --- SUB MainLoop() CALL InitialisiereGitter(GridA) ' Setzt ein Startmuster (optional) DO CALL ZeigeGitter(GridA) ' 1. Aktuellen Zustand anzeigen SLEEP(500) ' Kurze Pause zum Sehen CALL BerechneNaechstesGitter(GridA, GridB) ' 2. Die Logik des Lebens anwenden ' Tauschen der Gitter: Das "Nächste" wird das neue "Aktuelle" SwapGrids(GridA, GridB) LOOP WHILE TRUE ' Läuft unendlich, bis gestoppt // =========================================== // FUNKTIONEN // =========================================== SUB InitialisiereGitter(CurrentGrid) ' Setzt das gesamte Gitter auf 0 (Tot) FOR y = 1 TO MAX_Y FOR x = 1 TO MAX_X CurrentGrid[x, y] = 0 NEXT x NEXT y ' --- HIER EIN STARTMUSTER PLATZIEREN (z.B. ein Quadrat von Lebendzellen) --- Dim startX = MAX_X / 2 - 3 Dim startY = MAX_Y / 2 - 3 FOR y = 0 TO 1 { ' Nur 2 Zeilen hoch FOR x = 0 TO 2 CurrentGrid[startX + x, startY + y] = 1 NEXT x NEXT y END SUB SUB BerechneNaechstesGitter(CurrentGrid, NextGrid) ' Setzt das Zielgitter (NextGrid) einmalig auf 0 CALL ClearGrid(NextGrid) FOR y = 1 TO MAX_Y FOR x = 1 TO MAX_X Dim NachbarnCount AS INTEGER NachbarnCount = ZaehleLebendeNachbarn(CurrentGrid, x, y) ' Wenden der Spielregeln an: IF CurrentGrid[x, y] = 1 THEN ' Zell ist LEBEND IF NachbarnCount < 2 OR NachbarnCount > 3 THEN NextGrid[x, y] = 0 ' Stirbt ELSE NextGrid[x, y] = 1 ' Überlebt END IF ELSE ' Zell ist TOT (CurrentGrid[x, y] = 0) IF NachbarnCount = 3 THEN NextGrid[x, y] = 1 ' Wird geboren ELSE NextGrid[x, y] = 0 ' Bleibt tot END IF END IF NEXT x NEXT y END SUB SUB ZaehleLebendeNachbarn(Grid, X_Zelle, Y_Zelle) Dim Count AS INTEGER: Count = 0 ' Durch die 3x3 Nachbarschaft Schleifen (ohne das Zentrum selbst!) FOR dy = -1 TO 1 FOR dx = -1 TO 1 IF dx = 0 AND dy = 0 THEN CONTINUE ' Springe über die Zelle selbst Dim NeighX AS INTEGER: NeighX = X_Zelle + dx Dim NeighY AS INTEGER: NeighY = Y_Zelle + dy ' Randprüfung (Stellt sicher, dass wir nicht außerhalb des Spielfeldes sind) IF NeighX >= 1 AND NeighX <= MAX_X AND NeighY >= 1 AND NeighY <= MAX_Y THEN IF Grid[NeighX, NeighY] = 1 THEN Count = Count + 1 END IF END IF NEXT dx NEXT dy RETURN Count END SUB SUB SwapGrids(GridA, GridB) ' Tauscht die Inhalte von A und B (vereinfacht dargestellt) ' In echtem MMBasic müsste hier der Inhalt jedes Pixels/Arrays kopiert werden. FOR y = 1 TO MAX_Y FOR x = 1 TO MAX_X GridA[x, y] = GridB[x, y] ' Kopiere B nach A ' Wenn du das System nicht überschreibst, ist dies ausreichend: ' GridA(x, y) <-> GridB(x, y) NEXT x NEXT y END SUB SUB ZeigeGitter(Grid) PRINT "--- Game of Life ---" FOR y = 1 TO MAX_Y STEP 1 DIM ZeileStr AS STRING: ZeileStr = "" FOR x = 1 TO MAX_X STEP 1 IF Grid[x, y] = 1 THEN ZeileStr = ZeileStr + "█" ' Darstellung für Lebend (Block) ELSE ZeileStr = ZeileStr + " " ' Leerzeichen für Tot END IF NEXT x PRINT ZeileStr NEXT y PRINT "---------------------" END SUB ' Aufruf des Spiels CALL MainLoop() Of course, I can do that with Copilot, Gemini, ChatGPT, or Claude, but that was offline. What I'm trying to say is that using AI isn't limited to microPython—it can definitely help with other languages as well. The local model doesn't run very smoothly on my Core i5 16GB laptop, but then again, I don't have a dedicated graphics card installed. Cheers Martin 'no comment |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 2018 |
I checked with GPT: |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3833 |
['__class__', '__name__', 'ADC', 'I2C', 'I2CTarget', 'I2S', 'PWM', 'PWRON_RESET', 'Pin', 'RTC', 'SDCard', 'SPI', 'Signal', 'SoftI2C', 'SoftSPI', 'Timer', 'UART', 'WDT', 'WDT_RESET', '__dict__', 'bitstream', 'bootloader', 'deepsleep', 'dht_readinto', 'disable_irq', 'enable_irq', 'freq', 'idle', 'lightsleep', 'mem16', 'mem32', 'mem8', 'mem_backup', 'reset', 'reset_cause', 'soft_reset', 'time_pulse_us', 'unique_id'] A few things worth noting for this board: - Peripheral classes: ADC, I2C/SoftI2C, I2CTarget, I2S, PWM, Pin, RTC, SDCard, SPI/SoftSPI, Signal, Timer, UART, WDT. - Reset/cause: reset, soft_reset, reset_cause plus the constants PWRON_RESET / WDT_RESET — that's how you'd distinguish a watchdog reset from a power-on (relevant to the USB-enumeration test earlier). - freq is present but read-only on the PC3 (you set the clock via screen(mode, clock), per the board notes). - mem_backup is a PC3-specific extra (not in stock MicroPython) — retained memory across resets. - Not present: no _thread here (that's a top-level module anyway), and note core 1 is used for HDMI so threading is unavailable regardless. (Note: I don't yet have wifi on my boards.) PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on FOTS |
||||
| fred777 Regular Member Joined: 01/07/2021 Location: United KingdomPosts: 99 |
- Edited 2026-07-28 05:33 by fred777 |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |