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 "sm…
This is what I've been looking for! Can you fit a workable version on a 1.44 floppy?
ELKS: Linux for 16-bit Intel Processors
91–100 of 119 posts
Re: ELKS: Linux for 16-bit Intel Processors
#92Earlier quoted context omitted.
This is what I've been looking for! Can you fit a workable version on a 1.44 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 overla…
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 :)
Re: ELKS: Linux for 16-bit Intel Processors
#93Earlier quoted context omitted.
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 overla…
I'm totally going to run it on an Amstrad PPC640 soon :)))
Re: ELKS: Linux for 16-bit Intel Processors
#94We are removing 32 bit support from the Linux kernel because nobody uses that hardware anymore. Yet, this 16 bit version has commits from today.
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.
Re: ELKS: Linux for 16-bit Intel Processors
#95Earlier quoted context omitted.
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 overla…
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
Re: ELKS: Linux for 16-bit Intel Processors
#96Cool. 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.
Re: ELKS: Linux for 16-bit Intel Processors
#97What 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.
Re: ELKS: Linux for 16-bit Intel Processors
#98Cool. 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 :)
Re: ELKS: Linux for 16-bit Intel Processors
#99Thanks 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 "sm…
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…
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.
Re: ELKS: Linux for 16-bit Intel Processors
#100Earlier quoted context omitted.
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.