It'll also run in ROM, e.g. using a 8018x CPU w/onboard PIT and PIC.
The point of ELKS today is about "small is beautiful" and seeing what can be done when limited to 64k code and 64k data, and 640k RAM. It's based on a very old fork of Linux and many of the internal structures are similar to what was found in Linux 2.0, without the changes for SMP support.
We just recently got a native C compiler/assembler/linker toolchain up and running. I must say making that happen provided some vivid comparisons of what programmers had to go through in decades past in both slower speeds and small executable file sizes, versus what we all have and expect today at our fingertips.
The 8018x/ROM mode sounds like it could make for a fun breadboarding project, not that I'll likely wind up doing it myself. Is there any way to run it in emulation?
Running native compilers on XT/286 hardware does indeed sound sloooow. At least it can be tested, probably automatically, in emulators where it'd run faster than the native compilers did back when this all started :)
---
It's funny... 7-10 year old hardware back in 95-96 when this started could barely keep up with current software at all, and I'm writing this on a 7 year old Dell Precision (albeit upgraded well beyond stock :) ) that still runs Linux pretty darn well.
- Chad
Go back another 15 years to 1995 and you have Pentium desktops. Linux was created just a few years earlier for similar but even more modest hardware (as was Windows NT). Not every modern Linux distro will still run on Pentiums but many will. You may have to burn a CD but up-to-date Antix, Q4OS, or Adelie releases will still work out of the box. Certainly NetBSD will. Not everything will still run on 32 bit machines and RAM is going to be a problem. The “modern web” would bring those machines to their knees. Still, surprisingly modern.
Go back another 15 to January 1980 and you have to wait almost two years for hardware that will even run ELKS. Crazy.
And yes the native compilers are running way faster under emulation than the originals on real hardware! Funnily enough, we're finding the slowest portion of the native toolchain is the assembler, due to lots of symbols and slow hashing.
Given we were working with 286 era hardware (maybe 386?), I'd be surprised if ELKS doesn't fit on a 1.44. Indeed, simply looking at the downloads page linked from the original link would have answered your question.. [1]
https://en.wikipedia.org/wiki/Linux_Router_Project
I remember using this in the late 90s (maybe early 2000s). A linux distro designed to be a router, and to fit on (and run from) a single floppy.
https://raw.githubusercontent.com/ghaerr/elks/refs/heads/mas...
I could use some help testing it on EGA and VGA hardware, as I don’t have any 8 bit cards for those in my collection.
Most recently Al was learning Rust because he needs that for his current role, it might be fun to see whether you can write an ELKS target for Rust.
But AArch64 (or ARM64) and AMD64 did bring a lot more on the table than just larger address space. More registers, and a performance boost by just being better suited for the modern CPU core design.
Also, FWIW, security people can get real bothered that ASLR doesn't do much in 32-bit systems.
So, I think starting around 2GB DRAM, it's probably a "big enough" system to justify a 64-bit OS.
Provided you are not bothered by highmem. https://www.realworldtech.com/forum/?threadid=76912&curposti...
There is the x32 ABI - 32-bit pointer length, but the AMD64 ISA. I don’t think it ever saw significant adoption though.
I still think it's pretty safe to say 64 bit is the future, and will be for a long time (if I live long enough for 128 bit processors to become defacto or even widely necessary I'll be truly shocked).
If you're writing really space-optimised code, you can pack pointers closer together.
https://www.tech-faq.com/address-bus.html
My newish AMD laptop: `grep 'address sizes' /proc/cpuinfo`
address sizes : 48 bits physical, 48 bits virtual
>>> f'{2**32:>30_}'
' 4_294_967_296'
>>> f'{2**36:>30_}'
' 68_719_476_736'
>>> f'{2**40:>30_}'
' 1_099_511_627_776'
>>> f'{2**48:>30_}'
' 281_474_976_710_656'
>>> f'{2**64:>30_}'
' 18_446_744_073_709_551_616'The size of memory space is not necessarily aligned with the bit width of the CPU. There are a lot of 32 bit systems that can use much more than 4 GB of RAM. And there are no 64 bit systems I know of, that are even theoretically able to use 16 exabytes (16 million TB) of RAM.
AFAIK ARM32 is still the norm for embedded systems. And there is still a place for 8-bit microcontrollers.
Seriously, I haven't worked on this in a long time (I'm Chad) and I'm very impressed by the changelog! Wouldn't have ever thought it'd run DOOM. ;) (and the use of OS/2 for medium model is clever too)
And for sure the 2nd and 3rd world use 32 bit devices.
But a small band of hobbyists use old OSes with old machines.
So I used elks and lugged around a lead acid motorcycle battery.
It was great for my circumstances, but I wouldn't say I miss it compared to my many cores and gigs laptop.
They had a 386 version as well, but went all in on getting X-windows and graphics working, and ignored TCP/networking just as the Internet started to gain a lot of traction. Still an interesting OS to look at!
Freedos has released 1.4rc1 recently, thus 1.4 is close.
Svardos switched to EDR-DOS kernel, which is derived from DR-DOS. That's a very nice kernel, written in assembly. Notably, Windows 3.1 works with it, including protected mode.
https://www.theregister.com/2024/12/23/svardos_drdos_reborn/
I have built a hobby project around it:
That's super interesting.
Also the "Macintosh Classic" had System 6.0.3 in ROM as well, but you had to use a keyboard shortcut to boot from there. It did not run normally.
The only ROM-based-systems I worked with are the Atmel AVR microcontrollers. They don't need to load code into RAM for execution, they have the ROM memory mapped into the address space. I think they can't even run instructions from RAM, which makes remote code execution physically impossible.
x86 (and licensed derivatives) were a thing in more custom handhelds like the Psion Series 3, and games systems like the Wonderswan. The variants made by NEC alone were: https://en.m.wikipedia.org/wiki/NEC_V20#Variants_and_success...
The Cisco PIX firewall, in it's original incarnation, booted from non-volatile memory (I don't know if it was EEPROM or flash) an ISA card.
The first-gen PIX you mention had an 8M or 16M ISA flash card it booted from, containing the whole OS.
The Novell netboot is called "RPL".
Interestingly, somebody has made an emulator for it.
Here you can see it on an external board: https://www.os2museum.com/wp/diskonchip/
I have a few thinclients with a socket directly on the mainboard for a DOC
The root filesystem is only written to when you flash a new OS image
> But the most characteristic part was the operating environment - 384kB of ROM contained MS-DOS version 3.31 and Explorer GUI which allows to work in PIM programs, database and text editor using mouse. The GUI is shown using CGA mode and allows to launch DOS programs too.
https://oldcomputer.info/pc/hs_explorer/index.htm
CathodeRayDude (CRT) has an entertaining video on the subject:
It’s merely a ROM drive implemented in the BIOS. Drive 8 is used.
There’s also an INT 18h hook that operates by simply booting drive 8. This is the fallback bootstrap hook. No disks? No problem. Boots to DOS vs. IBM which booted BASIC or everyone else who just prints an error.
On one of these Tandy’s, DOS is really running from RAM, it is merely loaded from ROM, and even then it’s just a virtual disk.
I wrote a little tool to make the ROM drive accessible on non-Tandy DOS: https://github.com/dfelliott/tandy1000-romdrive
There are versions of DOS that can be run directly from ROM, but this isn’t one of them.
Curiously, Deskmate runs from ROM for real. Meaning the code is actually running in the Exxx segment backed by the actual ROM chip. The Deskmate files on the ROM drive are relatively small and are only a small part. The bulk of the code runs direct from ROM.
- Many Tandy PC compatibles could boot from ROM to their DeskMate GUI - HP, GRiD, Zenith and others had laptops that had DOS and in some cases Windows in ROM.
- IBM's PS/1 line could boot from ROM - Many GEOS devices booted from ROM into a GUI, and often could boot to DOS from ROM too.
There is an MS-DOS compatible ROM OS still sold today:
In that vein, I've got an old V20-based NEC laptop (the PC-17-02[0], arguably an Ultrabook in its day) that booted MS-DOS 3.3 from ROM. It had a 2MB battery-backed RAM disk that the ROM got copied into. It showed up as a hard disk drive with an INT 13H-style interface.
There are success stories with it on 8088 book, pocket 8086 and similar such hardware.
“It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.”
https://web.archive.org/web/20010626233912/http://www.elks.e...
Not sure if you are confusing that with the original Linux/Linus announcement post:
https://groups.google.com/g/comp.os.minix/c/dlNtH7RRrGA/m/Sw...
I happened upon the site when first playing with a (z80) Gameboy compiler (probably SDCC) and wanting to port Linux to it.
I fully admit i could be imagining it.
Yes, I should have said 386.
Since then, some (many?) contributors have supplied support for smaller systems.
ELKS: Embeddable Linux Kernel Subset.
It'a a subset of the Linux kernel, which is suitable for embedded systems. Meaning, "don't expect this to be a usable desktop OS."
Also, check delicate linux:
Do not try X under Delicate Linux, it will run dog slow with 8MB of RAM.
If you can upgrade it to 16MB and some 486, X would be fine, with icewm set to a light plain theme, no desktop icons.
Also PC/MIX was pretty cool.
How much would it cost, in cents, to just have those extra bits?
there's little real point in 8 bit chips anymore
You can just run MS-DOS or FreeDOS directly on those machines, that's what the machines were made for.
A good thing about DOSEMU against DOSBOX is that the first could run high end DOS game at amazing speeds as the environment was more like Wine than emulating the whole machine, so you could run Tomb Raider, Need For Speed, Duke Nukem 3D... on a Pentium II while 'simulating' a Pentium MMX or a Pentium 90-like speeds, if not more, being far closer to the performance you got under W95/W98.
And, as you said, booting SvarDOS either from a floppy or from an IDE->CF card it's straightforward.