A BASIC Interpreter For The Raspberry Pi Pico

It’s pretty easy to program the Raspberry Pi Pico in Python, or you can use C or C++ if you so desire. However, if you fancy the easy language of yesteryear, you might like PiccoloBASIC from [Gary Sims].

Putting it simply, piccoloBASIC is a BASIC interpreter that runs on the Raspberry Pi Pico. It features all the good bits of BASIC such as GOTO and GOSUB commands, that fancier languages kind of look down upon. It’s also got enough built-in routines to handle regular programming life, like sleeps, delays, a basic pseudorandom number source, trigonometric functions, and the ability to deal with floating point numbers. As far as microcontroller tasks go, it’s got rudimentary support for talking to GPIOs right now via the pinon and pinoff commands. However, it’s probably not the way to go if you want to bit-bang an SD card to within an inch of its speed rating.

Down the road, [Gary] hopes to add support for features like the Pico’s I2C, SPI, and PIO hardware, along with networking protocols and Bluetooth. PEEK and POKE are also hopefully on the way for those that like to fiddle with memory directly.

Meanwhile, if you’re looking for a different yet similar take, explore the port of MMBasic to the Pico platform. Video after the break.

38 thoughts on “A BASIC Interpreter For The Raspberry Pi Pico

    1. 16-bit fig platform independent forth using transparent portable c to generate machine code for those forth words which require a forth assembler [C,].

      ENCLOSE, FIND, and several other machine language verbs?

      U/ was super-difficult to get working right in the 1980s.

      But in 2023 hardware usually does this job.

      Super idea!?

      64-bit Intel MSC BASIC-52 machine language VM using software modules no longer than one page of code to be in compliance with Boeing hardware engineers software standards in focus.

        1. https://geoffg.net/OpenSource.html

          Geoff did not understand what “open source” meant, and was upset when people made changes to it that he didn’t approve of. He has a lot to say about this on his site, but here’s the most telling part:

          “My new license is simple, it is still open source, it is just not based on the GNU GPL. It says (in summary) that the executable program produced by me is free to be distributed in any way for any purpose. The source is freely available and can be modified for personal use but it, and any executables generated from it, may not be distributed without first consulting me and obtaining my permission.”

          That is, he STILL doesn’t understand what “open source” means. I will repeat: “may not be distributed without first consulting me and obtaining my permission.” So he SAYS that it’s open source, but roadblocks anyone who tries to make a derivative work. This came up a couple years ago, when, I’m sorry, I can’t remember the name of the project, but someone had built a 32 bit PIC based single-board computer and wanted to use MMBasic, but wanted to add commands to support the hardware on his board. Geoff refused permission, and he was forced to write his own interpreter from scratch. When something says “open source” you really have to read the fine print.

          1. Correction:
            The project I recalled is called Ello2M, and can be found on https://hackaday.io/project/9692-ello-2m. And he did not create a whole new BASIC interpreter – the project was just stalled for some time because he couldn’t get permission to release it with his modifications, but since has been releasing the kit with the code flashed on the microcontroller, so there must have been a resolution. Sorry for my mis-remember, but my point remains: a thing is NOT open-source if you have to get permission to distribute it with modifications.

          2. A page from the Ello2M crowdsource site: https://www.crowdsupply.com/yellow-beak-computer/ello-2m/updates/2399. In this, he explains that “the last obstacle is now gone” as he has come to an agreement with Geoff Graham, to allow him to distribute his modified version of MMBasic. This being the case, Konstantin Dimitrov, developer of Ello2M seems to have gone back and sanitized the history of this conflict, which I imagine was part of the agreement.

    1. Be sure to read the license for this carefully. Geoff calls it open source, and says that modifications can be made for personal use, but you can not release modified versions of his code without his permission. Which means that if you use his code and modify it for your own use, you are not free to share your code.

  1. What would be better is to make it support different variations of BASIC, like C64, Apple II ( and those weird video quarks), GWBASIC. I’d like to throw some bananas. It could use one of the VGA adapters to provide the output.

    1. Or QuickBasic/Turbo Basic/Power BASIC/VBDOS/PDS7. These were powerful dialects with Pascal elements, SUBs, no need for line numbers (GOTO/GOSUB could use names), etc. They’re *real* Basic versions, a far from poor C64 BASIC.

      Alternatively, Locomotive Basic 2 or Amiga Basic were proper candidates. Everything’s better than an home computer’s BASIC.

  2. Hey, if yous want to learn something, please have a look at 8052-AH BASIC.
    This was a microcontroller with built-in BASIC. But a powerful version, actually. The source code is available by now. Analyzing it perhaps helps to make something serious out of this project here. AH-BASIC was used in real-world applications, after all. It was no toy.

    1. Intel MCS BASIC-52 in a New Mexico prison lock apps.

      Reason: prison locks require opening all cells in event of fire.

      Lock vendor commented to me that you don’t know what is going to happen
      when all cell doors are opened.

      Prisoners may come out for coffee, he comment. Or worse?

      Poster did low-level 8052 code for lock vender.

      c/c++ software technology not good chose for safety-critical apps?

      1. But also, if you adhere to MISRA-C rules, almost all easy C and C++ errors are prevented. This is what the automotive industry has done (in addition to using tools that enforce these rules) to make C safe for embedded code in safety-critical systems. I think I prefer this approach over BASIC interpreters in microcontrollers.

        1. I assume/hope they did this after the incredible steaming pile of ECU from Toyota was examined.

          Seriously, they did everything exactly wrong. I mean the stack overflowed onto the kernel memory, right into the process list. Their main inner ‘tick’ function was a steaming pile of code, had a maintainability rating in the thousands (counting the # of flow control statements in the function) and was about half the source. Buggy recursive functions almost guaranteed rare stack overflows with all evidence gone after power cycle.

          Also hate to tell you, but Tesla isn’t exactly shipping bug free software lately. Multiyear 90% floating ‘almost done’ used to be seen as a sure sign of a failed project. But your full self driving will be here ‘real soon’ (sucker).

  3. Sandia National Laboratories BASICs weapons history:

    Before 1980s until after the mid 1980s BASICs were used to test
    land-based nuclear weapons software.

    Forth entered in ~1982 to implement a Missile Secure Cryptographic Unit
    with algorithm and funding supplied by the National Security Agency.

    Reason: Sandia was building a rad hard version of the 8080, a 8085.

    Forth MSCU app success impressed Sandia management.

    Sandia management realized they made a mistake trying to implement
    8085 plus peripheral chips. Too many parts to get rad- hard working.

    So Sandia switched to a rad hard version of the 8051.

    Since 8080 fig forth was so successful get the MSCU working,
    poster was assigned job of porting software to the 8051.

    Poster hired Intel 8080 metacompiler writer to lead the project.
    Writer would not accept contract if he had to write.

    1 ENCLOSE
    2 FIND
    3 U/
    4 the assembler.

    Poster agreed to do 1-4.

    Project succeeded.

    In ~1991 the c/c++ industry invaded SNLA.

    All of the BASIC/Forth programmers were forced out.

    But in 2023 untestable/maintainable/buggy/malware vulnerable software
    modules longer than one page of code in violation of the Boeing hardware engineers’ software standards in the 737 MAX and Navy F-35 may cause the c/c++ industry fatal injury?

    1. Well, hogwash. C & C++ are certainly easy to screw up in, but they are definitely far more scalable than BASIC. And maybe that’s why you see more buggy C code than BASIC code – it’s just too hard to do a complex application in BASIC in the first place.

      But I’m really not sure what you are saying – all of your subjects are written in 3rd-person, so I’m not sure where you fit in the story. Who is poster? Who is writer? Is English your native language?

      1. “Well, hogwash. C & C++ are certainly easy to screw up in, but they are definitely far more scalable than BASIC. ”

        Not necessarily, since some Basic dialects do borrow elements of Pascal language. A Basic+Pascal hybrid might be more scalable than that “super assembler” that C/C++ is.

        “And maybe that’s why you see more buggy C code than BASIC code – it’s just too hard to do a complex application in BASIC in the first place.”

        Again, not necessarily. Basic is “problem oriented”, which means that the application/problem is the center of everything, not the coding style or C compiler optimizations (which not seldomly mess things up, like the order of processing; Basic programmers define the order themselves how their programs flow).

        Historically, C/C++ programmers are like fighter jet pilots, they’re obsessed with their language and being cool. Basic programmers focus on the goal, rather than the fanciness of code base. They’re more like bus drivers, maybe. Pascal programmers are a bit more balanced, sitting between the chairs, so to say.

        1. Okay, first, Pascal kind of disappeared once it was discovered that it was basically a subset of C, with very slightly different syntax. So with that in mind, what you’re saying is that BASIC can approach being as useful as C, the more C-like you make it.

          1. Hm? I’m not sure if I can completely follow. English isn’t my native language, also, so please bear with me. 🐻

            Pascal.. Turbo Pascal, a popular extension, was very popular during the 80s and 90s. Even by the mid-90s, a large number of DOS programs were still being developed with TP (and QBasic/QB45). So Pascal was to DOS, what C/C++ is to *nix.

            PS: In the days of CP/M, Turbo Pascal and MBASIC were overly popular, as well. They allowed platform-independent programming, since these languages were available on processors like Z80, i8086, Motorola 68000 and so on.

            C.. C is like a combination of a debugger and a batch file compiler (or shell script compiler). Python is quite similar to C/C++, just less weird and more modern. All the helper files (.h) are needed, because C/C++ consists solely of a dozen individual macros, which then form the C/C++ language.

            Without them, not even a “Hello World” is possible. Because, since ANSI C, must be imcluded for something simple as a printf () command. Otherwise, it’s not proper syntax. By contrast, K+R C wasn’t as worse back then, I admit.

          2. Agreed. You are right about all of that. But sometime in the late-1980s or early-1990s, someone came up with a program to convert Pascal programs to C, which worked pretty well. And by “pretty well”, I mean that you only had to go back and make minor changes, if any, to make the generated C code compile and run. This is what I mean when I say that Pascal could be thought of as a subset of C, since Pascal could easily be converted to C, but not the other way. In other words, anything you could do in Pascal, you could do in C, but not the opposite. And when Borland introduced Turbo C++, it became hard to justify learning Pascal. Borland was so invested in this, they included their Pascal GUI interface system, Delphi, with Turbo C++, so there really was nothing you could do in Pascal that you couldn’t do in C.

            Meanwhile, those of us who cut our teeth on BASIC in the 1980s, and had learned either Z-80 or 6502 or 6809 assembler to do the things that BASIC just couldn’t do, finally started to get it, that BASIC just wasn’t for any serious work. And the newer dialects of BASIC, especially the event-driven Microsoft Visual Basic, were getting more and more of the Pascal/C features, but without the level of standardization that Pascal and C had. In fact, dialects of BASIC were drifting further apart from each other. Even Microsoft’s various BASICs (GW BASIC, QBasic, QuickBasic, Visual Basic) weren’t compatible with each other, even within the IBM PC DOS environment. But the absolute extinction of BASIC came with the introduction of protected memory with the Intel 80386, which made PEEK and POKE no longer possible in BASIC. So even if you knew all of the memory mapped and I/O mapped device addresses and register fields (as you did with your 8-bit home/hobby computers, and even your 8086 architecture DOS machine), you could no longer access devices in BASIC unless they were specifically supported by your particular version of BASIC. It was a dark time.

            In response to your critique of C not even having a built-in “print” command, this was by design, and it was a good decision. Kernighan and Ritchie decided to only include built-in commands as necessary to make the language logically complete, leaving the rest, like string manipulation, terminal input and output, and file and stream input/output, to be put into a standard library and additional features in optional libraries. The standard library, known in various environments as glibc.a or msvcrt.dll or other names, were to be written specifically for each hardware platform, leaving the C language itself completely independent of the small or large differences between different computers. This was extremely powerful, since it meant that the C language itself was independent from both the CPU’s instruction set architecture AND any computer’s specific I/O design. All other mid- or high-level languages since C have taken the same approach, so if you like Python, you can thank C for that. If you like Rust or Go, you can thank C. If you like Forth or Lisp, well, then you owe nothing to C. But if you like what passes for BASIC these days, a lot of that you also owe to C, both for their features and the fact that most of them are written in C.

          3. Joshua:

            At the end of Pascal, Pascal and C were the same thing with different operators.

            Object Pascal (as seen in Delphi) and C++ (as seen in C++ builder) were the same except syntax and operand order on stack. Right down to pointers/deref operator/ref operator etc etc.

            It died a natural death. There was no value there. There basically are no professional pascal programmers left. Likely more people writing COBOL today. If someone suggested using pascal on a project, I’d fire them almost as fast as if they’d suggested Javascript/Node/MySQL. You can train skills, but judgement that bad is unfixable.

            Modern basic has taken all the good things it does from C++, which in turn had half copied them from smalltalk.
            Java is just castrated C++ with massive performance deprovements and garbage accumulation.
            C# is a pragmatic, get it done fast, environment.
            Javascript is hell on earth.

            DOS was not written in Pascal the way Unix was written in C. It was never the only way available.

            .h files are headers, not helpers. They’re basically there to save the complier a pass. Which was worth it back in the day. Same as only using two digits for dates. Looks dumb now, but only to those without a clue.

            You can say the C/C++ makes you define functions in duplicate. Which is better than Ada…being a language spec’d by pinheaded pentagon paper pushers it requires you to write all code in triplicate.

          4. Joshua:
            Your the one who said: ‘So Pascal was to DOS, what C/C++ is to *nix.’

            Which is just plain wrong. Then you claim ‘revisionism’.

            ‘Pascal programmers’ don’t exist anymore, as such, they would have starved by now, no matter how fat (or ‘balanced’, whatever you mean by that) they were when they started.

            Pascal was once a popular teaching language in CS, right after they abandoned COBOL in mass. EEs used Fortran, C or assembler back in the day. No matter the problem one of those three was always a better choice than Pascal.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.