Back in the olden days, when you booted up a computer, you got dumped into what was essentially a BASIC shell. If your input didn’t start with a line number it was interpreted immediately. Having only experienced that sort of environment, I didn’t understand how programming languages like Pascal that didn’t have line numbers worked.
It would be cool to have a modern computer that booted up in 500ms to a Python REPL or something rather than a shell or desktop GUI. Just turn on and immediately start playing around with your programming language. I’m sure this exists somewhere.
If you think about it, "booting" is an anachronism anyhow. Your washing machine doesn't boot. Your radio or TV doesn't boot (ironically, more modern smart TVs might). Your car doesn't boot.
When are we finally designing computers like proper products?
I mean, all of those things do "start" somehow. Capacitors fill up, motors spin up, etc. Lots of them have had microcontrollers that boot for a longer time than you are giving credit. I have CRT TVs that "boot", they are effectively computers.
There's a lot of philosophical ways you could see it as why a computer has to "boot" every time it is powered on, but the way I think about it, it all has to do with the volatility of memory. When power is removed, registers and DRAM all lose their state slowly. When a modern computer is powered on, a lot of things happen before the primary CPU even begins to boot. Once reset is pulled down on the CPU, it has to go through the process of actually booting. Each phase of bootstrap builds on the previous phase, on modern computers usually starting with some kind of ROM right on the CPU, to firmware in EEPROM which may boot in multiple phases, to a bootloader, to the actual operating system kernel. Embedded devices can be a lot simpler here but unilaterally there will be some sequence of code at the beginning whose job is to (re)initialize a bunch of state that holding reset won't. (From my spelunking on older hardware it seems like holding reset on most CPUs only ever does nearly the absolute bare minimum to make it possible for a bootrom to deal with the rest of initialization. Makes enough sense, really.)
This has to happen every time a computer is powered on because it's a clean slate every time it turns on. The registers won't just magically get into some state, there has to be some integrated logic that can reset the processor to a known state and start the process of bootstrapping again.
Let's say someone builds a computer with absolutely no volatile memory at all. If power is removed, registers keep all of their state. The RAM is durable. All of the caches are durable. Then what? Well, then you probably don't have to bootstrap every time the computer is turned on. At least in theory it ought to be possible to have a computer that works this way and simply resumes exactly where it left off when power is returned. You would probably design computers differently since you wouldn't necessarily need RAM and disk to be separate, it could possibly just be one thing, and what is now booting an OS would be somewhat more like installing it.
I don't really think we have the technology to make something like this practical, and it's hard to imagine it much since our hardware and software is designed tightly around the assumption of these processes and the existence of multiple tiers of memory, but that's my opinion for the best philosophical justification for why computers must bootstrap.
It would be interesting to see, though I don't really agree with the characterization that making a computer without a bootstrap process would make it any more "proper" of a product...
> I don't really think we have the technology to make something like this practical
I mean, Intel Optane is kind of this, although afaik, nobody ran systems with only Optane, and you would still need some amount of suspend/resume logic, because cpu registers need to be persisted including getting the cpu into the proper mode. Also, perhiperals would need to be reinitialized (and possibly redetected).
What you're describing would still need a bootstrap ROM, and would be rather challenging since it's not obvious how you'd handle unplanned power loss.
If you really want to avoid booting, the registers also need to be non-volatile, and all of the peripherals have to be built this way, too, e.g. the GPU.
You'd need something like a 'stop' state, distinct from reset. The system power supply would have to release the STOP line to allow the computer to continue processing, and the power supply would also have to assert STOP on event of the power sagging below specified levels. Whether the power dropping is due to a user intentionally hitting a power switch, or the grid dropping out would be immaterial. 'STOP' simply prevents the computer from attempting to process when low voltage would cause unreliable logic. You'd still want RESET because from time to time you want the ability to put the system into a known state.
You can build this. There's different strategies, but the least work option would be a minimal install of your OS of choice with your choice of REPL installed as /bin/init (or you can usually set init= as a kernel parameter)
You'd probably need to tune your chosen kernel to hit 500ms, but it's doable. Harder if you include the time in system firmware though.
> X11-Basic will compile on 64bit systems but it will not be 100% functional. X11-Basic internally uses 32bit pointers (--> VARPTR()). These are not compatible with 64bit. Some tricks have been implemented to make it work anyways, but do not expect 100% compatibility.
That would be fun. Give Iris Explorer a spin - the demos make any SGI seem like a supercomputer. (Better on an Indigo2 or Octane, but hey) I did real work in Octave + gnuplot on SGI machines of the era but I'd be surprised if recent versions compile.
I have said it many times before. You could fill a library with all the problem that BASIC leads too. But at its core is a message that is missing a little from modern computing - the ability to jump in and just get something simple built quick. The idea that you control the machine even if it is slow and sludgy.
This also goes a lot for the leap from command prompts to GUI's. You trade off control for functionality and that is not necessarily a bad thing. I just wish it was easier to get back to a middle path on this. Many have tried but it all seems a little too fragmented.
> The interpreter (xbasic) can be used as a shell. It can run basic-scripts in all environments, p.ex. *.cgi-Scripts for handling web-input.
This is both terrifying and something I definitely want to play with.
Back in the olden days, when you booted up a computer, you got dumped into what was essentially a BASIC shell. If your input didn’t start with a line number it was interpreted immediately. Having only experienced that sort of environment, I didn’t understand how programming languages like Pascal that didn’t have line numbers worked.
It would be cool to have a modern computer that booted up in 500ms to a Python REPL or something rather than a shell or desktop GUI. Just turn on and immediately start playing around with your programming language. I’m sure this exists somewhere.
If you think about it, "booting" is an anachronism anyhow. Your washing machine doesn't boot. Your radio or TV doesn't boot (ironically, more modern smart TVs might). Your car doesn't boot.
When are we finally designing computers like proper products?
When you turn on the tv/washing machine/car/set-top box/toaster, and the LEDs all light up and twirl around, what do you think the device is doing?
I mean, all of those things do "start" somehow. Capacitors fill up, motors spin up, etc. Lots of them have had microcontrollers that boot for a longer time than you are giving credit. I have CRT TVs that "boot", they are effectively computers.
There's a lot of philosophical ways you could see it as why a computer has to "boot" every time it is powered on, but the way I think about it, it all has to do with the volatility of memory. When power is removed, registers and DRAM all lose their state slowly. When a modern computer is powered on, a lot of things happen before the primary CPU even begins to boot. Once reset is pulled down on the CPU, it has to go through the process of actually booting. Each phase of bootstrap builds on the previous phase, on modern computers usually starting with some kind of ROM right on the CPU, to firmware in EEPROM which may boot in multiple phases, to a bootloader, to the actual operating system kernel. Embedded devices can be a lot simpler here but unilaterally there will be some sequence of code at the beginning whose job is to (re)initialize a bunch of state that holding reset won't. (From my spelunking on older hardware it seems like holding reset on most CPUs only ever does nearly the absolute bare minimum to make it possible for a bootrom to deal with the rest of initialization. Makes enough sense, really.)
This has to happen every time a computer is powered on because it's a clean slate every time it turns on. The registers won't just magically get into some state, there has to be some integrated logic that can reset the processor to a known state and start the process of bootstrapping again.
Let's say someone builds a computer with absolutely no volatile memory at all. If power is removed, registers keep all of their state. The RAM is durable. All of the caches are durable. Then what? Well, then you probably don't have to bootstrap every time the computer is turned on. At least in theory it ought to be possible to have a computer that works this way and simply resumes exactly where it left off when power is returned. You would probably design computers differently since you wouldn't necessarily need RAM and disk to be separate, it could possibly just be one thing, and what is now booting an OS would be somewhat more like installing it.
I don't really think we have the technology to make something like this practical, and it's hard to imagine it much since our hardware and software is designed tightly around the assumption of these processes and the existence of multiple tiers of memory, but that's my opinion for the best philosophical justification for why computers must bootstrap.
It would be interesting to see, though I don't really agree with the characterization that making a computer without a bootstrap process would make it any more "proper" of a product...
There was a research regarding implicit persistence OSes, see KeyKOS (https://web.archive.org/web/20030426221706/http://www.cis.up...) and EROS (https://web.archive.org/web/20030430223846/http://www.eros-o...).
> I don't really think we have the technology to make something like this practical
I mean, Intel Optane is kind of this, although afaik, nobody ran systems with only Optane, and you would still need some amount of suspend/resume logic, because cpu registers need to be persisted including getting the cpu into the proper mode. Also, perhiperals would need to be reinitialized (and possibly redetected).
What you're describing would still need a bootstrap ROM, and would be rather challenging since it's not obvious how you'd handle unplanned power loss.
If you really want to avoid booting, the registers also need to be non-volatile, and all of the peripherals have to be built this way, too, e.g. the GPU.
You'd need something like a 'stop' state, distinct from reset. The system power supply would have to release the STOP line to allow the computer to continue processing, and the power supply would also have to assert STOP on event of the power sagging below specified levels. Whether the power dropping is due to a user intentionally hitting a power switch, or the grid dropping out would be immaterial. 'STOP' simply prevents the computer from attempting to process when low voltage would cause unreliable logic. You'd still want RESET because from time to time you want the ability to put the system into a known state.
> [Raspberry] Pi is because originally we were going to produce a computer that could only really run Python.
https://www.techspot.com/article/531-eben-upton-interview/
See also https://youtu.be/PAHBZImmXsI?t=590
You can build this. There's different strategies, but the least work option would be a minimal install of your OS of choice with your choice of REPL installed as /bin/init (or you can usually set init= as a kernel parameter)
You'd probably need to tune your chosen kernel to hit 500ms, but it's doable. Harder if you include the time in system firmware though.
Like this maybe? https://tic80.com/
How have I lived for this long on the interwebs an never realised this was a thing?
I thought the same thing. I would have loved to have known about this 30 years ago. If only there had been an o'reilly book.
Has O'R ever used a dog? Because BASIC would have to be a dog. =P
Sloth
I had no idea that we could install third party software on TomTom car navigation systems until just now.
> A WEB interface (via bloutooth and cgi-scripts) using a webserver.
and serve cool warez
Oh yeah, I ran a location logger on mine for years until Google Maps location tracking popped up.
Now that they're killing it… I don't think I'll go back to using a TomTom any time soon lol
Now I want to know what the most hackable US model was.
I see old TomTom units in thrift stores and pass them by. Now I want to score one. Wild.
This looks like fun: https://wiki.openstreetmap.org/wiki/TTconsole
If you click through to the github, it's the same guy from X11-Basic. Looks like he wrote it for the ONE-V3.
There was also Basmark QuickBasic Compiler for Linux,
https://archive.org/details/bqb49
> X11-Basic will compile on 64bit systems but it will not be 100% functional. X11-Basic internally uses 32bit pointers (--> VARPTR()). These are not compatible with 64bit. Some tricks have been implemented to make it work anyways, but do not expect 100% compatibility.
I recently acquired an SGI Indy and was wondering if there was a good BASIC for it. Will have to check this out and see if it compiles!
That would be fun. Give Iris Explorer a spin - the demos make any SGI seem like a supercomputer. (Better on an Indigo2 or Octane, but hey) I did real work in Octave + gnuplot on SGI machines of the era but I'd be surprised if recent versions compile.
2022 https://github.com/kollokollo/X11Basic And https://codeberg.org/kollo/X11Basic
I see from the latter link that the last update was in February 2024 — glad that the project is still alive!
I have said it many times before. You could fill a library with all the problem that BASIC leads too. But at its core is a message that is missing a little from modern computing - the ability to jump in and just get something simple built quick. The idea that you control the machine even if it is slow and sludgy.
This also goes a lot for the leap from command prompts to GUI's. You trade off control for functionality and that is not necessarily a bad thing. I just wish it was easier to get back to a middle path on this. Many have tried but it all seems a little too fragmented.
>But at its core is a message that is missing a little from modern computing - the ability to jump in and just get something simple built quick.
That niche has been pretty much filled by Excel, for better or worse.
I definitely have to put X11 (Xwayland) inside https://exaequOS.com for running this version of Basic !