Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ELKS: Linux for 16-bit Intel Processors

github.com

Post reply on HN
Print view View original

81–90 of 119 posts

Re: ELKS: Linux for 16-bit Intel Processors

#81

Post by vasvir »

ikari_pl wrote: post #59
ghaerr wrote: post #47

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?

Can you find a 1.44 floppy?

Re: ELKS: Linux for 16-bit Intel Processors

#82

Post by lproven »

cloudsec9 wrote: post #69

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…

The final version of Coherent is FOSS now:

https://github.com/gspu/Coherent

Re: ELKS: Linux for 16-bit Intel Processors

#83

Post by lproven »

garaetjjte wrote: post #31
vardump wrote: post #24

Earlier quoted context omitted.

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.

>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?

Re: ELKS: Linux for 16-bit Intel Processors

#84

Post by lproven »

forinti wrote: post #3

Wait, "ROM-based systems"? Were there such x86 micros and is this saying you could run Linux from ROM? That's super interesting.

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/

Re: ELKS: Linux for 16-bit Intel Processors

#85

Post by lproven »

garaetjjte wrote: post #26

I'm confused what relation this has with 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."

Re: ELKS: Linux for 16-bit Intel Processors

#86

Post by lproven »

snvzz wrote: post #44

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

Re: ELKS: Linux for 16-bit Intel Processors

#87

Post by YakBizzarro »

ikari_pl wrote: post #68
cricalix wrote: post #66

Earlier 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 :)))

Well, for that you need to fit it on a 720k floppy :) Unless you modded it with a 1.44 drive

Re: ELKS: Linux for 16-bit Intel Processors

#88

Post by dcminter »

cricalix wrote: post #66
ikari_pl wrote: post #59

Earlier 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…

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

#89

Post by happycube »

ghaerr wrote: post #47

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…

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

Re: ELKS: Linux for 16-bit Intel Processors

#90

Post by ghaerr »

happycube wrote: post #89
ghaerr wrote: post #47

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…

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…

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.

Post reply on HN