Thanks for the comments! ELKS will run on an 8088, but also runs on any x86 PC using the legacy "real mode" which runs in 16-bit segmented architecture without an MMU or any hardware protection. It can be fun to boot a PC and see a close resemblance to Linux, but run the way things used to be, using only 16-bits.
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.
Very awesome work indeed... I haven't looked at ELKS in a long time and seeing everything it can do now is heartwarming.
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.
If you go back 15 years, to January 2010, you find x86-64 hardware that you could install modern Linux on as easily as running the installer off a USB stick. The unibody 2009 MacBook Pro was out by then, so your computer could even look totally normal at a Starbuck’s today (and connect to the WiFi just fine). That machine will take 8 GB of RAM and run the COSMIC desktop written in Rust for Wayland (run it well-I have done it).
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.
There's a couple of ROM versions, one which runs with a ROM filesystem and boots a shell over serial and another which uses BIOS INT 13h calls for an external MINIX or FAT filesystem. Both are run using an emulator which allows selection of ROM address, RAM size, etc. It'd be too hard to develop reliably without emulators for any of our images.
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.
Around 1996/97 timeframe, you could fit a kernel and userspace. I remember building a 1.44 setup that booted a compressed kernel and had enough user space tooling to bring up telnet, ftp, and the radio stack to drive the long haul radio cards (we were replacing JNOS [0] IIRC at an ISP ). Even had writable space at the end of the floppy (the kernel etc were readonly) to write overrides of the config; poor man's overlay I think, but it is rather a long time ago.
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]
We don't support a compressed kernel anymore but have a way to compress user executables which saves about 30%. Sadly, even with straightforward decompression, that process on ancient 8088's sometimes takes longer than reading an uncompressed executable. But we're finally at the point of having "too much stuff" to fit on a floppy. And of course everyone wants games. (Don't ask about Doom: yes we have it, no it doesn't fit on a floppy :)
Check NeHaBodi. Nethack 3.4.3 or Slashem 0.7f might compile under elks, slashem itself shouldn't need ncurses, but it would need some colour support to differentiate some mons (not as a requeriment, but it helps a lot on the gameplay).
I'm 99% sure the original kernel and thus the boot&root disk Linux (the original "distribution" I guess) only ran on the 386 & up as it required & used the memory management capabilities.
There were some forks that could run without the mmu (micro-Linux I think?) but as I recall it they came quite a bit later.
We dropped all support for 286 or 386+ protected mode/paging etc, as well as produce only 8088/8086 instructions so it'll run on any x86 (including the PCjr with its peculiarities, remember that?) running in real mode only without MMU. Of course, that means any program can write anywhere, so more care is taken towards program correctness, which is kind of fun.
Yes it runs on that Amstrad. A funny story about the Amstrad, at one point we added divide-by-zero trap handler in the kernel for user space apps. When the Amstrad reboots via our 'shutdown', its gets a div zero exception in its own BIOS (which at the time prohibited the reboot, lol).
Open up an issue on GitHub and we can help you better. The usual reason for problems like this is the layout of the image is incorrect on GoTek, and/or the GoTek is set to the wrong CHS (cylinders/head/sector) for the image being used.
Yes, one can actually boot and run a minimal system on 360k floppy, but if you want networking you need 720k. The native compiler might fit on 1440k but needs a lot more for any development if the C library header files etc are wanted.
I recently added dual screen support to the ELKS console-direct driver, so if your system has both MDA and CGA cards, you enable CONFIG_CONSOLE_DUAL in your kernel config and select runlevel 5 in /bootopts, it will allocate 4 ttys, with one of them on the MDA display. You can see this setup running on my hardware in this pic in the README:
Well I mean, he's a friend and in fact hosted the NYE party I was at so, in that sense he's still around. I might see him later this week and if so I'll try to remember to mention that ELKS is still going.
I do wonder in today’s landscape of single board computers what the right bit width is. A 64-bit system with like 1-2GB or RAM doesn’t make a ton of sense since your program size and data structure size grows by quite a bit but you don’t need it to since you don’t get to have more than 4GB of RAM. On the other hand there you do have SBCs with 8-16GBs of RAM but that’s a far cry from needing full 64 bits. Would an optimal bit width be 48 bits? 40?
32-bit ARM-based systems supported up to 1 TB of RAM. 32-bit x86 only up to 64 GB. Unless you want to map more than 4 GB in a single process, you could very well stay 32-bit.
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.
32-bit x86 linux will typically support 3GB per process, with 1GB kernel address area, I think? (Windows did 2GB / 2GB split by default, custom boot options can change it to 3GB / 1GB, but only some 32-bit apps fully supported it, like photoshop).
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.
On 32 bit you can of course make the kernel higher half, but yes AFAIK most mainstream kernels chose higher quarter to grant more vaddr space to processes.
> 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.
There is the x32 ABI - 32-bit pointer length, but the AMD64 ISA. I don’t think it ever saw significant adoption though.
32 bit gave you that much with PAE, which has its own set of unfortunate problems.
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).
Many "64-bit" systems only have ~48 bits of virtual address space, and while canonical pointers have all the high bits equal, you can put the otherwise-wasted bits to work by storing metadata.
If you're writing really space-optimised code, you can pack pointers closer together.
Yes, this already happens. Address bus width is usually different from register width due to cost. I found this, old CPU's address bus only getting to 44 bits wide on Itanium.
For embedded uses, 1GB is certainly big enough to not need to be 32-bit, so it makes sense IMO to use the same 64-bit binaries/toolchains/BSPs as larger platforms, especially since they're better supported by upstreams now.
I think it's either 8, 32 or 64 bit. Maybe 16 bit.
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.
It's a hobby, not big and professional like GNU^H^H^HLinux.
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)
There is a temporal element to your statement. 32-bit support is being removed from the kernel of today. No one uses that hardware for a modern OS anymore.
But a small band of hobbyists use old OSes with old machines.
Another operating system that deserves mention for 286 class machines is Coherent. This was an Unix like OS you could buy for $99, and it had all of the various Unix utilities and came with a HUGE manual to help you learn it.
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!
Tangentially related, DOS is a popular choice in this category of hardware.
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.
The memories. I had it run ("installed" would be a big word ona 2 flopppy and no hard drive system) on a super cute Carry-1 8088 computer ages ago, which I stupidly sold on Ebay shortly after as I had no use for it.
Here's one of the very rare photos online.
http://vintagescan.blogspot.com/2015/12/flytech-carry-i-1990...
Some of the Tandy 1000 computers (such as the HX) had MS-DOS 2.11 in ROM. So it's not unheard of for an IBM-Compatible PC to have an operating system in ROM.
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.
For what it’s worth, a significant proportion of the classic Mac OS’s implementation was in rom anyway - you “upgraded” the OS by patching in-memory jump tables to ROM functions.
Are those real ROM-based-systems, that could execute code directly from ROM, without loading it to RAM first?
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.
Memory devices were not accessed via exotic interfaces at the time. ROM was directly addressable on the bus in early PCs. They executed their ROM code directly as the access time was sufficient for low speed clocks. That is what the BIOS is. Any additional OS/BASIC environment worked the same. Later BIOS implementations had shadow RAM options to allow execution without wait states as bus speeds eclipsed ROM access times.
Even if you can't execute code from RAM, stack corruption and Return-Oriented-Programming (ROP) can still be a thing. It's just far more limited if you can't use ROP to set up regular code.
The Psions could do execute-in-place, including for third party software on ROM SSD - i.e. they did not have any fundamental distinction between working memory and disk storage.
Yes, NOR flash was common in these kind of devices and phones until maybe 2005 or so. So you could run code without loading it to RAM first. However, I believe RAM was still needed for stacks and heaps. Writing them to NOR flash sounds too slow.
No, I really do mean that they used the disks as ROM. No writing to it. This worked because you can just put the stack and heap at a difference position in the memory map from the executable code.
I've never seen a fully ROM-based PC, but I have worked with ISA NE2000 NICs with boot ROMs that allowed them to diskless boot into a DOS-based Novell NetWare client. It wouldn't surprise me if there were ROM-based local boot environments on ISA cards.
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.
Fully ROM/Flash PC-ish systems are/were pretty common in the embedded and industrial control space. Usually the boards emulate one or more floppy drives. I've got a half dozen variations, including PROM, Flash and battery backed SRAM. Even one with bubble memory, which is pretty nifty.
The first-gen PIX you mention had an 8M or 16M ISA flash card it booted from, containing the whole OS.
Another example was the Headstart Explorer from 1989. My parents had such a computer.
> 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.
Lots of embedded systems like routers run read only although maybe they're not technically ROM. Usually they mount the root filesystems read only and create some small ram disk/tempfs for logs. Persistent settings go to a small NVRAM area
The root filesystem is only written to when you flash a new OS image
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.
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.
Yes, there were many - including the original IBM PC which would could boot to BASIC loaded from ROM. Some more sophisticated machines included:
- 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.
The 8086 and 8088 etc. were relatively popular for embedded devices. For example some early 90s Apple printers used an 80186 as the controller. Such designs were often incompatible with the IBM PC; 8086 doesn't necessarily mean PC compatible.
I said in my earlier post that I hadn't seen a fully ROM-based PC but I completely forgot about stuff like the HP and Psion and Atari PC handhelds!
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.
I had tried to get some version of Linux running on my 386SX / 25MHz / 8MB RAM but only succeeded in getting BasicLinux[1] running bootstrapped from a DOS boot first. Somehow I had never found ELKS! But I was just able to trivially make a floppy and boot the system[2]. Amazing. Looking forward to playing with this.
I've been able to cross-compile from Linux (in Docker on my Mac; things didn't work well on macOS) to make binaries that run on the 386 under ELKS. Just had to juggle a few stock games to grab a couple dozen KB on the floppy to make room.
Does anybody have the archive of the original ELKS site with the quote from Linus that Linux is not suitable for anything but 486 or higher or something like that?
I searched archive a while ago and couldn't find it. It's probably referencing the announcement but I clearly remember a pull quote on the ELKS site, probably the same one quoted above.
I happened upon the site when first playing with a (z80) Gameboy compiler (probably SDCC) and wanting to port Linux to it.
How recent was the quote? Anywhere near 486 through Pentium, and the quote makes absolute sense. He wouldn’t have been optimizing for smaller architectures.
Since then, some (many?) contributors have supplied support for smaller systems.
The "getting started" doc briefly mentions the history: it began in 1995 as a fork of the standard Linux kernel (initially named Linux-8086), by Linux kernel developers Alan Cox and Chad Page. So it does share both code roots and some initial community with the "real" mainline Linux.
Could somebody with a good understanding of microchip production economics explain what the price difference would be if all 8-bit chips (such as the Atmega328) were replaced by otherwise equivalent 32-bit or 64-bit chops tomorrow (that is, same production capacity and unit counts sold)?
How much would it cost, in cents, to just have those extra bits?
Supply-chains are more complicated than merely the unit price. Things like existing stock, talent, software, product design, certifications (both chip and products based on chip), and hundreds of other things play just as substantial role.
a cheap 32 bit RISC-V chip like the CH32V003 goes for about $0.10, and the cheapest MCU I've heard of (PMS150C, barely useful for anything) goes for around $0.03
Even without special knowledgeon production economics, I dare say there would be a race to produce replacement compatible 8-bit microcontrollers to get people's stuff working again.
My oldest working systems are now a 386/DX40 and 486/DX2-66, but I never had a chance to run Linux on them back then. Did anybody here have a favorite distro for such early 90s hardware? When I find a 286 or earlier I'd love to give ELKS a try.
There was a version of KA9Q NOS with multitasking that could serve telnet, ftp, smtp, bbs, convers, and more plus give you multiple switchable terminals for telnet, ftp, all at the same time on an 8088 and connect to a packet driver for modem, ethernet, or AX25. It was a port of BSD networking with its own multitasking capability.
What would be really interesting: porting DOSEMU 1.4.0 to it. This would give us a maintained unix-like OS combined with a huge abandonware dos library turning those old machines into something fun and maybe useful.
This. I literally rebuild DOSEMU yesterday after years of not using it. It used that mode extensively.
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.
Computers which use 16-bit Intel processors (80286 or earlier) are quite rare nowadays - most of them are 30-40 years old, and are more valuable to collectors than newer and more capable hardware would be. If you want something "useful", this isn't where you'd find it.
Thanks for the comments! ELKS will run on an 8088, but also runs on any x86 PC using the legacy "real mode" which runs in 16-bit segmented architecture without an MMU or any hardware protection. It can be fun to boot a PC and see a close resemblance to Linux, but run the way things used to be, using only 16-bits.
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.
Very awesome work indeed... I haven't looked at ELKS in a long time and seeing everything it can do now is heartwarming.
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
If you go back 15 years, to January 2010, you find x86-64 hardware that you could install modern Linux on as easily as running the installer off a USB stick. The unibody 2009 MacBook Pro was out by then, so your computer could even look totally normal at a Starbuck’s today (and connect to the WiFi just fine). That machine will take 8 GB of RAM and run the COSMIC desktop written in Rust for Wayland (run it well-I have done it).
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.
Oh well... At least, in 1980 we got Xenix.
There's a couple of ROM versions, one which runs with a ROM filesystem and boots a shell over serial and another which uses BIOS INT 13h calls for an external MINIX or FAT filesystem. Both are run using an emulator which allows selection of ROM address, RAM size, etc. It'd be too hard to develop reliably without emulators for any of our images.
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.
This is what I've been looking for! Can you fit a workable version on a 1.44 floppy?
With so little context in your question I'll reply with
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.
Around 1996/97 timeframe, you could fit a kernel and userspace. I remember building a 1.44 setup that booted a compressed kernel and had enough user space tooling to bring up telnet, ftp, and the radio stack to drive the long haul radio cards (we were replacing JNOS [0] IIRC at an ISP ). Even had writable space at the end of the floppy (the kernel etc were readonly) to write overrides of the config; poor man's overlay I think, but it is rather a long time ago.
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]
0 - https://www.langelaar.net/jnos2/documents/about.html
1 - https://github.com/ghaerr/elks/releases
That's pretty cool about the radio stack!
We don't support a compressed kernel anymore but have a way to compress user executables which saves about 30%. Sadly, even with straightforward decompression, that process on ancient 8088's sometimes takes longer than reading an uncompressed executable. But we're finally at the point of having "too much stuff" to fit on a floppy. And of course everyone wants games. (Don't ask about Doom: yes we have it, no it doesn't fit on a floppy :)
Check NeHaBodi. Nethack 3.4.3 or Slashem 0.7f might compile under elks, slashem itself shouldn't need ncurses, but it would need some colour support to differentiate some mons (not as a requeriment, but it helps a lot on the gameplay).
Single-floppy router distributions were also in style: https://en.wikipedia.org/wiki/Floppyfw
I'm 99% sure the original kernel and thus the boot&root disk Linux (the original "distribution" I guess) only ran on the 386 & up as it required & used the memory management capabilities.
There were some forks that could run without the mmu (micro-Linux I think?) but as I recall it they came quite a bit later.
Edit: Ah, close, this: https://en.m.wikipedia.org/wiki/%CE%9CClinux
We dropped all support for 286 or 386+ protected mode/paging etc, as well as produce only 8088/8086 instructions so it'll run on any x86 (including the PCjr with its peculiarities, remember that?) running in real mode only without MMU. Of course, that means any program can write anywhere, so more care is taken towards program correctness, which is kind of fun.
I'm totally going to run it on an Amstrad PPC640 soon :)))
Yes it runs on that Amstrad. A funny story about the Amstrad, at one point we added divide-by-zero trap handler in the kernel for user space apps. When the Amstrad reboots via our 'shutdown', its gets a div zero exception in its own BIOS (which at the time prohibited the reboot, lol).
I'm having a play on the PPC640 with a Gotek running Flashfloppy with fd720-fat.img
It's erroring after the mount with panic:No init or sh found SYSTEM HALTED. BOOT:
The computer is unreponsive at the boot: prompt.
I've tried a few different settings in the ff.cfg, but no joy. Could it be a Gotek issue?
Open up an issue on GitHub and we can help you better. The usual reason for problems like this is the layout of the image is incorrect on GoTek, and/or the GoTek is set to the wrong CHS (cylinders/head/sector) for the image being used.
Also worth trying would be the 1440k image, as that's the later standard 3.5" floppy format.
Well, for that you need to fit it on a 720k floppy :) Unless you modded it with a 1.44 drive
Yes, one can actually boot and run a minimal system on 360k floppy, but if you want networking you need 720k. The native compiler might fit on 1440k but needs a lot more for any development if the C library header files etc are wanted.
Can you find a 1.44 floppy?
Could nethack be compiled under elks? Frotz? Inform6?
There was a DOS port of nethack, so likely it could be made to run on elks.
[dead]
I recently added dual screen support to the ELKS console-direct driver, so if your system has both MDA and CGA cards, you enable CONFIG_CONSOLE_DUAL in your kernel config and select runlevel 5 in /bootopts, it will allocate 4 ttys, with one of them on the MDA display. You can see this setup running on my hardware in this pic in the README:
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.
Cool. A quarter of a century ago a friend of mine worked on this and you can still see his name in some copyright notices (Alistair Riddoch)
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.
Is Alistair Riddoch still around? I've been wondering about him, his name is all over the early dev86 and ELKS C library code :)
Well I mean, he's a friend and in fact hosted the NYE party I was at so, in that sense he's still around. I might see him later this week and if so I'll try to remember to mention that ELKS is still going.
I do wonder in today’s landscape of single board computers what the right bit width is. A 64-bit system with like 1-2GB or RAM doesn’t make a ton of sense since your program size and data structure size grows by quite a bit but you don’t need it to since you don’t get to have more than 4GB of RAM. On the other hand there you do have SBCs with 8-16GBs of RAM but that’s a far cry from needing full 64 bits. Would an optimal bit width be 48 bits? 40?
32-bit ARM-based systems supported up to 1 TB of RAM. 32-bit x86 only up to 64 GB. Unless you want to map more than 4 GB in a single process, you could very well stay 32-bit.
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.
32-bit x86 linux will typically support 3GB per process, with 1GB kernel address area, I think? (Windows did 2GB / 2GB split by default, custom boot options can change it to 3GB / 1GB, but only some 32-bit apps fully supported it, like photoshop).
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.
On 32 bit you can of course make the kernel higher half, but yes AFAIK most mainstream kernels chose higher quarter to grant more vaddr space to processes.
> 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.
There is the x32 ABI - 32-bit pointer length, but the AMD64 ISA. I don’t think it ever saw significant adoption though.
>Unless you want to map more than 4 GB in a single process, you could very well stay 32-bit.
Provided you are not bothered by highmem. https://www.realworldtech.com/forum/?threadid=76912&curposti...
I didn't notice who wrote that initially, and was getting annoyed with his failure to notice that it's not HIGHMEM.SYS, it's HIMEM.SYS.
But why should Linus, even in 2007, use Win9x in the 21st century?
32 bit gave you that much with PAE, which has its own set of unfortunate problems.
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).
Many "64-bit" systems only have ~48 bits of virtual address space, and while canonical pointers have all the high bits equal, you can put the otherwise-wasted bits to work by storing metadata.
If you're writing really space-optimised code, you can pack pointers closer together.
Yes, this already happens. Address bus width is usually different from register width due to cost. I found this, old CPU's address bus only getting to 44 bits wide on Itanium.
https://www.tech-faq.com/address-bus.html
My newish AMD laptop: `grep 'address sizes' /proc/cpuinfo`
Looks like 36 bits wide is already plenty for anything typical, up to 68 GB:I guess no point wasting hardware supporting things that will never be possible for the lifetime of the processor.
AMD64 mandates 48bit virtual addressing minimum, with the rest sign-extended unless certain optional features are enabled.
For embedded uses, 1GB is certainly big enough to not need to be 32-bit, so it makes sense IMO to use the same 64-bit binaries/toolchains/BSPs as larger platforms, especially since they're better supported by upstreams now.
42-bit is the right answer of course.
I think it's either 8, 32 or 64 bit. Maybe 16 bit.
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.
We are removing 32 bit support from the Linux kernel because nobody uses that hardware anymore. Yet, this 16 bit version has commits from today.
It's a hobby, not big and professional like GNU^H^H^HLinux.
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)
Nobody is removing 32 bit support from the kernel.
Tons of embedded stuff use 32-bit Linux.
But that stuff is usually not x86.
Embedded projects where intel was involved often use something like Atom.
Yes, but this is being replaced by meaty Intel UpSquared boards
There is a temporal element to your statement. 32-bit support is being removed from the kernel of today. No one uses that hardware for a modern OS anymore.
But a small band of hobbyists use old OSes with old machines.
Hyperbola GNU/Linux, Parabola and Guix still have 32 bit support. And I still use a 32 bit computer.
And for sure the 2nd and 3rd world use 32 bit devices.
I bet more than 50% of computer e waste is 64 bit machines nowadays.
Another operating system that deserves mention for 286 class machines is Coherent. This was an Unix like OS you could buy for $99, and it had all of the various Unix utilities and came with a HUGE manual to help you learn it.
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!
The final version of Coherent is FOSS now:
https://github.com/gspu/Coherent
Tangentially related, DOS is a popular choice in this category of hardware.
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.
Yup. I wrote about it:
https://www.theregister.com/2024/12/23/svardos_drdos_reborn/
I have built a hobby project around it:
https://github.com/lproven/usb-dos
The memories. I had it run ("installed" would be a big word ona 2 flopppy and no hard drive system) on a super cute Carry-1 8088 computer ages ago, which I stupidly sold on Ebay shortly after as I had no use for it. Here's one of the very rare photos online. http://vintagescan.blogspot.com/2015/12/flytech-carry-i-1990...
Wait, "ROM-based systems"? Were there such x86 micros and is this saying you could run Linux from ROM?
That's super interesting.
Some of the Tandy 1000 computers (such as the HX) had MS-DOS 2.11 in ROM. So it's not unheard of for an IBM-Compatible PC to have an operating system in ROM.
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.
For what it’s worth, a significant proportion of the classic Mac OS’s implementation was in rom anyway - you “upgraded” the OS by patching in-memory jump tables to ROM functions.
Are those real ROM-based-systems, that could execute code directly from ROM, without loading it to RAM first?
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.
Memory devices were not accessed via exotic interfaces at the time. ROM was directly addressable on the bus in early PCs. They executed their ROM code directly as the access time was sufficient for low speed clocks. That is what the BIOS is. Any additional OS/BASIC environment worked the same. Later BIOS implementations had shadow RAM options to allow execution without wait states as bus speeds eclipsed ROM access times.
Even if you can't execute code from RAM, stack corruption and Return-Oriented-Programming (ROP) can still be a thing. It's just far more limited if you can't use ROP to set up regular code.
IBM itself made PS/2s with PC-DOS in ROM. The 5150 had ROM BASIC and that also continued through to the early PS/2s.
Less obvious than some of the embedded things: https://en.m.wikipedia.org/wiki/Atari_Portfolio
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 Psions could do execute-in-place, including for third party software on ROM SSD - i.e. they did not have any fundamental distinction between working memory and disk storage.
Yes, NOR flash was common in these kind of devices and phones until maybe 2005 or so. So you could run code without loading it to RAM first. However, I believe RAM was still needed for stacks and heaps. Writing them to NOR flash sounds too slow.
No, I really do mean that they used the disks as ROM. No writing to it. This worked because you can just put the stack and heap at a difference position in the memory map from the executable code.
I've never seen a fully ROM-based PC, but I have worked with ISA NE2000 NICs with boot ROMs that allowed them to diskless boot into a DOS-based Novell NetWare client. It wouldn't surprise me if there were ROM-based local boot environments on ISA cards.
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.
Fully ROM/Flash PC-ish systems are/were pretty common in the embedded and industrial control space. Usually the boards emulate one or more floppy drives. I've got a half dozen variations, including PROM, Flash and battery backed SRAM. Even one with bubble memory, which is pretty nifty.
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".
My first computer was a 286 PS/1 model 2011, with PC-DOS and a graphical shell in ROM.
Interestingly, somebody has made an emulator for it.
https://barotto.github.io/IBMulator/
The DiskOnChip was a somewhat popular solution (think of thinclients), often running stripped down versions of Linux in the early 00s.
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
Another example was the Headstart Explorer from 1989. My parents had such a computer.
> 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:
https://www.youtube.com/watch?v=d1jpIiST6ec
Lots of embedded systems like routers run read only although maybe they're not technically ROM. Usually they mount the root filesystems read only and create some small ram disk/tempfs for logs. Persistent settings go to a small NVRAM area
The root filesystem is only written to when you flash a new OS image
The context of ROM here is "can execute code without putting it in RAM" rather than "code is stored in a read-only memory".
The Tandy 1000 SL/2 I grew up with had DOS 3.3 in ROM, mounted on D:\
Sort of.
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.
Yes, there were many - including the original IBM PC which would could boot to BASIC loaded from ROM. Some more sophisticated machines included:
- 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.
I wouldn't be at all surprised.
There is an MS-DOS compatible ROM OS still sold today:
https://www.tuxera.com/products/rom-dos/
The 8086 and 8088 etc. were relatively popular for embedded devices. For example some early 90s Apple printers used an 80186 as the controller. Such designs were often incompatible with the IBM PC; 8086 doesn't necessarily mean PC compatible.
I said in my earlier post that I hadn't seen a fully ROM-based PC but I completely forgot about stuff like the HP and Psion and Atari PC handhelds!
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.
[0] http://old.chuma.org/ultralite/index.shtml
The original IBM PC was ROM-based. It worked fine without a disk drive, it just booted into ROM BASIC instead.
I had tried to get some version of Linux running on my 386SX / 25MHz / 8MB RAM but only succeeded in getting BasicLinux[1] running bootstrapped from a DOS boot first. Somehow I had never found ELKS! But I was just able to trivially make a floppy and boot the system[2]. Amazing. Looking forward to playing with this.
[1] https://distro.ibiblio.org/baslinux/
[2] https://mastodon.social/@incanus/113777573079528868
If you can compile and install TCC you might compiler further useful software and games.
Also, check delicate linux:
http://delicate-linux.net/
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.
I've been able to cross-compile from Linux (in Docker on my Mac; things didn't work well on macOS) to make binaries that run on the 386 under ELKS. Just had to juggle a few stock games to grab a couple dozen KB on the floppy to make room.
Does anybody have the archive of the original ELKS site with the quote from Linus that Linux is not suitable for anything but 486 or higher or something like that?
Linux started on the 386.
“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 :-(.”
Couldnt find that quote on the 2001 version of the site.
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 searched archive a while ago and couldn't find it. It's probably referencing the announcement but I clearly remember a pull quote on the ELKS site, probably the same one quoted above.
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.
How recent was the quote? Anywhere near 486 through Pentium, and the quote makes absolute sense. He wouldn’t have been optimizing for smaller architectures.
Since then, some (many?) contributors have supplied support for smaller systems.
They mention "SBC"s. Is this something that is intended also for modern 16bit SBCs?
Yes absolutely.
There are success stories with it on 8088 book, pocket 8086 and similar such hardware.
I'm confused what relation this has with Linux.
The "getting started" doc briefly mentions the history: it began in 1995 as a fork of the standard Linux kernel (initially named Linux-8086), by Linux kernel developers Alan Cox and Chad Page. So it does share both code roots and some initial community with the "real" mainline Linux.
What isn't explained by the name?
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."
Could somebody with a good understanding of microchip production economics explain what the price difference would be if all 8-bit chips (such as the Atmega328) were replaced by otherwise equivalent 32-bit or 64-bit chops tomorrow (that is, same production capacity and unit counts sold)?
How much would it cost, in cents, to just have those extra bits?
Probably more about ecosystem compatibility at this point. There are already RISC-V chips that sell for less than a 6502.
I doudbt about that stance, you can have 6502's on every keybard at ridiculous prices.
Supply-chains are more complicated than merely the unit price. Things like existing stock, talent, software, product design, certifications (both chip and products based on chip), and hundreds of other things play just as substantial role.
a cheap 32 bit RISC-V chip like the CH32V003 goes for about $0.10, and the cheapest MCU I've heard of (PMS150C, barely useful for anything) goes for around $0.03
there's little real point in 8 bit chips anymore
Even without special knowledgeon production economics, I dare say there would be a race to produce replacement compatible 8-bit microcontrollers to get people's stuff working again.
My oldest working systems are now a 386/DX40 and 486/DX2-66, but I never had a chance to run Linux on them back then. Did anybody here have a favorite distro for such early 90s hardware? When I find a 286 or earlier I'd love to give ELKS a try.
Slackware was the distro I started on, back around then.
This
I don't know exactly why, but this makes me happy.
I used elks back when I was too poor to buy a real laptop. My laptop was a 286 (old even then), with a shot battery.
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.
Sounds optimal for microservices.
There was a version of KA9Q NOS with multitasking that could serve telnet, ftp, smtp, bbs, convers, and more plus give you multiple switchable terminals for telnet, ftp, all at the same time on an 8088 and connect to a packet driver for modem, ethernet, or AX25. It was a port of BSD networking with its own multitasking capability.
Also PC/MIX was pretty cool.
What would be really interesting: porting DOSEMU 1.4.0 to it. This would give us a maintained unix-like OS combined with a huge abandonware dos library turning those old machines into something fun and maybe useful.
That makes no sense, since DOSEMU is based on virtual 8086 mode, which requires a 80386, while ELKS is for 8086-286 CPUs.
You can just run MS-DOS or FreeDOS directly on those machines, that's what the machines were made for.
This. I literally rebuild DOSEMU yesterday after years of not using it. It used that mode extensively.
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.
Computers which use 16-bit Intel processors (80286 or earlier) are quite rare nowadays - most of them are 30-40 years old, and are more valuable to collectors than newer and more capable hardware would be. If you want something "useful", this isn't where you'd find it.
I don't know that it's really Unix like, but I feel like freedos covers that use?