Live data from Hacker News

ELKS: Linux for 16-bit Intel Processors

github.com

11–20 of 119 posts

Re: ELKS: Linux for 16-bit Intel Processors

#11
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.

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

Re: ELKS: Linux for 16-bit Intel Processors

#12

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.

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.

Re: ELKS: Linux for 16-bit Intel Processors

#13
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.

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/

Re: ELKS: Linux for 16-bit Intel Processors

#14
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'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".

Re: ELKS: Linux for 16-bit Intel Processors

#15
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.

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

Re: ELKS: Linux for 16-bit Intel Processors

#16
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.

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.

Re: ELKS: Linux for 16-bit Intel Processors

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

Re: ELKS: Linux for 16-bit Intel Processors

#18
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.

Re: ELKS: Linux for 16-bit Intel Processors

#19

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

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`

    address sizes : 48 bits physical, 48 bits virtual
Looks like 36 bits wide is already plenty for anything typical, up to 68 GB:

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

Re: ELKS: Linux for 16-bit Intel Processors

#20

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

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.

Post reply on HN