BASIC is like Marmite - you either love it or hate it.
A recent Hackaday article (1st Feb 2021) described one man’s (Alan Pope) journey to get a Raspberry Pi 400 to boot to BASIC.
I have known Alan for over a decade and he is a professional programmer - but he almost got to the point of pulling his hair out trying to get BASIC to boot on power-up on a Pi 400.
The irony here is that the Pi forces you into a Linux based operating system, whilst BBC BASIC was running on a bare-metal ARM 35 years ago.
BASIC as a language has many faults, and in the early 1980s it was limited by the speed of the popular microprocessors of that day, i.e. 6502 and Z80A.
But today we have a speed advantage and a $20 microcontroller can execute BASIC and generate all the graphics many times faster than the machines from the 1980s. Below is a link to the Maximite 2 computer that is built around the STM32F743 microcontroller.
I learned BASIC in 1978 on a Research Machines 380Z, and eventually in 1983 I could afford my own ZX81 built from a £39.99 kit.
Like I say - Marmite. Knock it if you wish, but it was the start of a career for many of us.
Once Basic had the advatage that you don’t need a powerful CPU, just ample memory,
thus it ran on everything but APL and LISP cpu’s.
Then it got a offical STANDARD the was not blessed by Microsoft and vanished.
BASIC and some other Early langages. The Retrocomputing Museum
Maximite 2 is nice! I’m a fan of booting to Basic, and it’s my background too.
It’s often said, but in fact there are numerous operating systems, as well as baremetal projects. In this particular case, I think RISC OS is the best fit, because it contains a native BBC Basic, and with a little configuration can boot straight to a Basic prompt. (Also available: BSD,
A few years ago, there was the RISC OS Pico build, a lightweight RISC OS which boots to Basic, but that doesn’t work on the newer models of Pi and is no longer offered as a download. It was never maintained. But as I say, a few config file tweaks do the job. (Or try this recipe.)
I don’t have a 400 to try this with. The Pi 4 was a bit of a departure and the 400 a bit more, so recipes and builds need to be relatively recent to work.
While BBC Basic is my strong preference, here’s a boot-to-emulated-C64 as a bare metal project:
We still don’t have a full-speed full-screen accurate Beeb emulation for the Pi, remarkably enough, even though there is a not-quite-published one for the Pico. At least, I think that’s so.
(Maybe worth noting: the Beeb is a boot-to-language machine, where Basic is usually the language ROM in question. Other languages are available.)
I don’t think Boot-To-BASIC (as the only OS) is necessary, but replacing the shell with a BASIC spiced up with the features and commands a shell needs might be a good idea. That would marry the power of a full featured OS with a much friendlier frontend.
Most shell scripting is a string operations intensive task and there BASIC is a lot nicer and safer while the shell is quoting hell.
I tried booting to BBC Basic with a rpi 400 with the tweaks, and it just boots to a different looking desktop. Works a treat on my rpi zero W. Wish it would work on the 400.
In the very early days of the Pi I got mine to boot into Basic (My own BASIC, written in C). It was not hard, however it took some 5-6 seconds. A far cry from the half second the Apple II or BBC Micro needed back “in the day”.
(edit: actually, the Apple II could then take another 20 seconds or so to load the disk operating system from floppy - BBC Micro had that in ROM)
The issue on the Pi: Load Linux from SD (a second or so), then go through the process of mounting a filesystem, enabling keyboard, network, time, and so on. I tweaked it and tuned it and could get it to under 4 seconds if I ignored a lot of the checks like localisation and so on - and the network and filesystem, but having a filesystem is nice if you actually want to do something and a keyboard is more or less essential, bu initialising USB seems to take an age…
My BASIC is a rather full featured thing and was designed to run under a Unix with the SDL and other C libraries, so it really needed Linux running on the Pi before it could start.
Booting RISC-OS and directly into BASIC should be faster, but I’ve never seen it (nor looked for it to be fair)
One of the things I really enjoy showing students, hooking a vintage computer to a modern LCD television, is that booting the television takes many seconds while the time from power on to a usable BASIC prompt on a vintage computer (I’ve demonstrated this with a TI 99/4A and an Apple II, but it’s generally applicable) is indistinguishable from instantaneous.
Even booting directly to BASIC, no Linux or RISC OS involved, on a Pi is probably going to take a second or two because of the GPU/bootloader chain.
A professor used to invite me every year to give a talk to his students and I would take my TI99/4A to give a demo (he would take a couple of old computers as well).
When I turned on the computer, selected the Extended Basic cartridge, typed in a short demo program and had 32 colored sprites moving around the screen in far less time than it took them to boot their laptops I would often get applause from the shocked students. They could not imagine that such a thing was possible.
Alan Kay used to show fragments of Engelbart’s 1968 and would mention the lack of an hourglass or rotating beachball. The computer never took more than a fraction of a second to respond, and this on a very slow computer without even enough memory to store the picture of it he was showing on his slide. He would ask “how were they able to do it?” and then would answer “Because they wanted to. It was one of their main design goals”
Or perhaps more realistically: “Any sufficiently advanced technology is indistinguishable from a rigged demo.” Engelbart only showed off what worked well, and had he gone off piste, there would have been plenty of opportunity to dig the slowness.
That could be true. i have certainly seen that many times.
But the point is that if you don’t have instant responses as a goal then your project won’t have it. Another example of seeking this is Chuck Moore and his Forth systems.
Of course, once you start building on other people’s systems instead of doing everything from scratch you can’t count on them having responsiveness as a goal.
Ironically, Alan Kay also warns against wasting time on optimization early in a research project. He says it is better to use a supercomputer to make it usable if you have to and when it works right you can worry about how to run it on normal computers.
Jumping back a bit, to boot times of the 8 bit machines and of a modern Pi, there is a connection: in the PiTubeDirect baremetal application, the Pi is connected to the databus of an Acorn BBC Micro or Master, and bitbangs responses to access requests as if it were a Second Processor connected with a Tube® chip.
Ideally, the Pi is booted and running by the time the MOS needs to interact with it.
And what we found is that earlier firmware revisions on earlier Pi models could boot in under 600ms, enough for most host machines, but then something changed and at 750ms the Pi was not always up in time. (As it happens, there’s an RC time constant somewhere in the reset circuitry, so individual Acorn machines differ in their boot times.)
As for fast booting a Linux on a Pi, I see here 5s mentioned, so that’s a benchmark to beat. Although this post claims 2s to start a Rasbian userspace. Possibly using configs like
disable_splash=1
boot_delay=0
initial_turbo=30
Some years ago I recorded RISC OS PICO booting to Basic in about 6 seconds:
There are several libraries that make it reasonable to boot directly to your own software on the pi… Circle and pigfx are good starting places. They replace kernel7.img with your binary, which uses their libraries for the things you’d normally expect from the OS (disk access, USB, graphics etc).
Another example of this kind of thing in action is ZXBaremulator
There’s now a port of the venerable BBC Basic to the Raspberry Pi Pico (that’s the microcontroller dev board, not like the bigger brother Pi models.) There’s both a console-only version (to be driven over a serial connection, either USB or RS232) and a home-computer version with VGA output and keyboard input. In both cases I’d expect a very rapid boot, although I haven’t yet tried it myself.
One commentator notes that when the ARM64 port of BBC Basic gets its assembler, this will be a very nice platform for both convenience and speed, and for self-hosted development. (BBC Basic usually includes an embedded assembler for the host micro, whether that be 6502, Z80, x86 or ARM.)
As far as I understand it, the RP2040 - the microcontroller on the Pi Pico - has 16MByte of on-chip flash and that’s where the Basic is stored, together with a small filesystem, and whatever libraries are needed to boot and run Basic.
So, yes, broadly speaking we can say the Basic is in ROM. Except it’s not read-only!
That would likely be an ARM32 assembler for BBC BASIC on the Pico, since the Cortex-M0+ cores are 32-bit microcontrollers. Richard Russell’s interpreter uses the assembler for debugging and a few other utility functions. Unlike the assembler in the Pico’s MicroPython implementation, I don’t think that BBC BASIC has user access to the PIO instructions yet.
Another BASIC for the Pico is MMBasic. The final version will be released as open source, but the beta versions are somewhat scattered around TheBackShed.com forum. There’s a recent UF2 installer here: TheBackShed.com - Forum and the manual here: TheBackShed.com - Forum - please excuse weirdly-formatted links, as TheBackShed is a homebrew forum running software quite unlike anything you’ve seen before.
It has good support for external LCD displays and many sensors, but the serial terminal I/O is a slight pain to set up
The Pico only has a tiny internal ROM used for booting. Any practical system will add an external SPI Flash chip. The Pico can execute code directly from the external Flash, which can be as small or as large (within the 16MB limit) as you like.
