Tumble Forth(tumbleforth.hardcoded.net) |
Tumble Forth(tumbleforth.hardcoded.net) |
OSDev is such a fascinating and lost topic, due to how niche it is and how computers and hardware have become a complicated mass of abstractions only a few have full access to. Writing a OS that talks with 90% of your hardware is relatively doable, writing a GPU driver is pretty much impossible these days unless you are the manufacturer.
We need more research into alternative computing. We need to move past UNIX which has served us well but it is a local maxima, not the best we can do. We need to return to the roots somewhat (maximecb's uvm, Devine Lu Linvega's uxn, etc.) to find a way forward.
I started with OsDev at 16 [1], had to find a regular boring job for the rest of my career, but my goal right now is to bootstrap my own small "lifestyle" business to find money, time and freedom to explore the world of bare metal alternative OS again. Something Lispy and Smalltalky to power the entire thing. I wrote a bit about it in my website. [2][3]
--
Sorry for the tangent. I love OSDev. Many of you would too, I bet.
1: https://github.com/1player/klesh
2: https://combo.cc/posts/in-search-of-the-holy-grail/
3: https://combo.cc/posts/what-i-would-like-to-see-in-a-modern-...
It runs in the browser via WebAssembly.
It isn't about taking prudent steps to cover yourself again likely scenarios.
It's an excuse to put a flamethrower on you pickup / write you own software stack from scratch.
The appeal of Forth is mostly in a principled sense of, if you want Forth to be your interface, you have to build your own Forth, because Forth does as little as possible to structure you. And building your own Forth is not impractical; that's the whole point. It's wonderful as an exercise and can be productive in the right context.
But any highly developed or standardized Forth system gradually converges on being "just another platform." And once it's just another platform, it's an annoying dependency, and you end up demanding more structure for it to help tame the complexity, so the Forthiness habitually erodes.
E.g. for my experimental long-languishing Ruby compiler I bootstrapped a tiny typeless s-expression based language - not a lisp/scheme, just borrowed some syntax - to let me "escape" the warm embrace of Ruby to bootstrap the basics. It wasn't very carefully planned, and there are many things I'd like to change when I get time to play with that project again (it's been literally years, but it's not forgotten), but that aspect is part I still like, though I might like to change parts of that low-level language too.
You could gain a large amount in energy efficiency and portability over implementations from that era as well. A small pocket computer that runs well crafted software and a battery that lasts for weeks.
Why do you think it will be a decision instead of something that just happens due to sudden/slowly approaching physical unavailability of required hardware?
What's lacking from discussions about projects like Collapse OS, Dusk OS, Uxn & similar, is discussion about peripherals. In particular: screens.
Nice you can run a small OS on a uC if needed. Bring it down to 1W, 0.1W or even less power consumption. Keyboards can be hand-wired switches if necessary.
But then what? Make do with a 16x2 character LCD? Attach 15+y old VGA monitor that consumes 30W? Attach (expensive) epaper screen that will also be thin on the ground in a collapse scenario, and can't be fabricated if technology falls away? Go back to switch frontpanels & lightbulbs?
It's easy to toss a heap of IC's & flash media into safe storage. Wiring, circuit boards, soldering iron, documentation printouts, some way to produce electricity: done. But produce OLED screens in post-collapse low tech society? Good luck with that.
Would be nice if there were at least some discussion about viable pathways there. No point having compute if you can't see what it's doing.
Collapse OS
> preserve the ability to program microcontrollers through civilizational collapse […]
> Runs on Z80, 8086, 6809 and 6502 machines with very little resources
Dusk OS
> Dusk OS is a 32-bit Forth and big brother to Collapse OS. Its primary purpose is to be maximally useful during the first stage of civilizational collapse, that is, when we can't produce modern computers anymore but that there's still many modern computers around.
In these scenarios it makes sense to give up on TLS. So probably that is why the author decided to serve their sites over plain HTTP only.
But all in all, I'd imagine we'd have to settle on scraping the old equipment stocks. I bet there are piles of discarded but still useable CRTs lying around somewhere.
[0] http://www.vintagecalculators.com/html/calculator_displays.h...
With plenty of source power, pixel grids are flexible. You can construct these from LEDs and paper, https://www.youtube.com/watch?v=QWGoC-9z2Qw. Or chain together 16x2 displays, or use flip-dot displays if you can source them.
If you are low on power, morse-code over a single LED would go a long way - low on equipment cost. Audio output and radio could also be decent low power outputs.
Seven-segment displays are workhorses. Restrict the interaction to hexidecimal characters.
Other obstacles for post-apocalyptic computing are power and storage.
For power - generation itself could be ok from a bicycle. But you need a way to buffer the power.
For storage - FeRAM should be a good option. Will not decay like conventional disks, so long as you repopulate it every few years.
I wonder how much power a teleprinter consume? Or a modern version of it?