BootBASIC Interpreter in 512 Bytes
github.com
github.com
Later I got to know that the original PC, IBM 5150, had such feature and the skill was simply removed as the "standard" evolved.
I think motherboard vendors should have kept this option on the BIOS. Being able to turn on the computer and have the instant possibility of writing and running code when every other software brakes is very powerful. Recovering a DOS based system was relatively easy if you had other computer available: simply put a floppy and type "sys a:" and you had a new boot disk, but you still needed other computer to do a recovery. Getting your computer to a usable or useful state without the help of another machine is something that we shouldn't have lost.
I once saw (and used) a similar feature on Mac: pressing some key combination during boot allowed you to wipe and reinstall OS from Internet. Not sure how exactly it was implemented, though, but I agree it would be cool if BIOS had a feature where you could type an URL to ISO and it would download and boot it.
> “It originated at Sun Microsystems, where it was known as OpenBoot, and has been used by vendors including Sun, Apple, IBM and ARM.”
> “Open Firmware allows the system to load platform-independent drivers directly from a PCI device, improving compatibility.”
> “Open Firmware may be accessed through its command line interface, which uses the Forth programming language.”
As I had written a few Forth programs on the Commodore 64, when I got an aluminium PowerBook G4 years ago (2003) I tried it out, and yes, it was Forth.
More recently, I used it for real when setting up a Sun Blade 150.
Here is a quick reference page listing the commands available: http://firmworks.com/QuickRef.html
Although yes, the fact that open firmware let you boot to a FORTH prompt is very relevant to this general discussion:)
option-command-r (on an intel mac at least) boots it into internet recovery mode
As sibling notes, macs can install themselves over the internet from firmware, which sounds like exactly what you want.
Macs can also boot in target disk mode, which does need another computer but also trivializes certain recovery tasks.
Several systems (Android, at least some PCs, I think Chromebooks) have either 2 root filesystems or a recovery system on their disk that can reinstall the main OS. This is weaker but still useful.
You can flash iPXE to a network card and use that to boot a PC over the internet kind of like a mac with more steps.
Coreboot can take arbitrary payloads; if your device has enough flash you could easily include GRUB, FreeDOS, and a BASIC/LISP/etc.
But not M* macs. Their firmware is only capable of initializing the most basic hardware and boot from the internal SSD, like good ol' times.
Heck, their boot picker is now a fullscreen application running on a stripped down macOS, which is started from the internal SSD.
This also means that if your internal SSD is hosed, so is your Mac. Enjoy!
Yup, cause the flash controller is on the SoC, the actual hard drive is just flash chips.
A lot of clone BIOSes just had to branch to a "please insert bootable media" or "No ROM BASIC - System Halted" message, but you could fairly easily inject something much like this.
I've modified the old "Anonymous XT clone" BIOS to support a stub that copies a chunk of ROM into RAM and then executes it.
This works reasonably well with some of the 512-byte "boot sector" tools I've tried, or with some minimal DOS .COM executables (i. e. an old Tiny Basic.) The copying step is a conservative approach because I suspect a lot of off the shelf software doesn't expect to be running inside ROM, and if it tries self-modifying code or simply writing to the same segment, all hell breaks loose.
For me, the limits were that, with an XT, you probably didn't want much more than 32-64k of ROM consuming precious address space, so unless you wanted to get gimmicky with banking in more memory or decompression, you're limited to maybe 20-40k of payload, which is a little small for "current" embeddable DOS products.
Or Forth, if you were lucky enough to have a Jupiter Ace.
For more advanced approach, get a device with physical "read only" switch, load a recovery image, set to R/O, and permanently connect to internal USB/IDE/SATA port. You'll have to disable it in your main OS, but boot menu will show it.
If you choose the good image, you'll get much more that BASIC of old: programming languages, graphical calculator, disk formater, and lots of other cool stuff.
In exploring this, I see BootBasic has no subroutine call and return. So there is no model in this code for such.
It's interesting because instead of GOTO, you assigned the target line number to a special variable. Instead of IF, you multiplied the result of a test with the line number and assigned the result to the special variable. An assignment of 0 is ignored.
Seems to me, at most one would maybe need another special system variable or two for peek and poke essentially and one could work with memory directly for bigger, more complex programs.
And it may do that. I did not examine all the special assignments in detail.
But yeah! Small and way more useful than it may appear.