16-bit Linux-like Goodness

We see many 16-bit retrocomputers around here based on Intel and Intel-like chips such as the 8086, 8088, V20, and similar. While they don’t seem very powerful by today’s standards, they were perfectly capable machines and, thanks to Elks (Embeddedable Linux Kernel Subset), you can run something fairly Linux-like on these devices.

The requirements are light: 512K of RAM is desirable, but you can do something with 256K. If you have ROM, you can even get by with 128K. Most importantly, the system doesn’t require a memory management unit to remap memory like many operating systems.

The project has been around for a bit, but has had some recent updates both for the runtime and the build system. For example, you can now build under WSL or using the Open Watcom C compiler. Executables are now compressed, and there’s a new cache system. The kernel and standard library no longer use long division, to improve perfomance.

If you want to try the system, you can boot it in an emulator on your browser. Just log in as “root.” There’s even a fake serial port available. Plus you can play Adventure. Or Doom.

We’ve seen Elks in some very strange places. Really strange.

13 thoughts on “16-bit Linux-like Goodness

  1. You can also play a simple graphical Tetris clone. The command to start it is ‘nxtetris’. Press N to start a new game, Q to quit, P to pause, C to continue, S/D to rotate the piece, J/K to move it left and right, and space to drop it.

    My claim to fame: I wrote nxtetris about 25 years ago.

  2. This is a cute tech demo. Thumbs up!
    However, let’s keep in mind that DOS platform had EMS support and that applications and certain games could access up to 32 MB of RAM via LIM 4 specification.
    With typical Expanded Memory boards from the 1980s having an average memory expansion of 512KB to 2MB.
    This is no complaint, just a reminder. In these modern days it’s easy to forget that these PCs were no toys in their own time and that their users had standards, too.
    Especially the NEC V series chips (see V41/V51 and V33) and late Turbo XT chipsets had MMU features built-in, which often were used for providing EMS.

    1. While they had EMS boards in the late going that could swap out programs, in practice I only ever saw them used for specific apps like Lotus to swap out data. Big memory boards for the ISA bus were expensive and slow. I saw a couple of systems which were used to program swap with 286 class CPU’s, but that was awkward because you had to reset the CPU to get back to real mode. In my experience memory expansions above 640K were nothing but a curiosity used by a few people with serious particular needs until the 386 and operating systems like Windows that were able to manage such memory in flat mode. These were, of course, 32 bit CPU’s so that was expected.

      1. This is your experience, but not exactly mine. 🤷‍♂️
        I think it’s also important to distinguish between professional users and home users.

        In professional sector, the PCs were necessary equipment to get work done.
        If they needed an upgrade then they simply needed it, period.

        Commercial Windows 2 programs from 1987 onwards had supported EMS, for example.
        Venture Publisher, Auto Sketch 3 and DesqView on DOS come to mind, too.
        Various paint programs had EMS support, as well, I think.
        Windows 3.0 from 1990 had really needed EMS on an XT, because it grew so large.

        Home users and socalled “gamers” (formerly being known as video game players) had little interest in memory expansion and thus had no money left for it.
        Same time, though, they had massive money to spend on accessoires that took their interest. Priorities.

        Btw, Himem.sys from the 90s nolonger did reset the 286 CPU.
        It rather used LOADALL instruction to access memory beyond 1MB.
        It were early himem.sys versions from late 80s which did the CPU reset.

        But even with the CPU reset there were differences in detail (books could be filled with the topic).
        Himem.sys knew over 20 machine types and had different workarounds for A20 Gate control/CPU reset.
        Some 286/386/486 chipsets had a “Fast A20 Gate” feature and could do trigger CPU reset via chipset rather than keyboard controller pin.
        Then there was the tripple-faulting trick to cause a CPU reset..

        Windows 3.1 and GeoWorks ran just fine on 80286 PCs and could utilize XMS memory (GeoWork used Real-Mode and had EMS support, too).
        Windows 3.1 on 286 PC ran in Standard-Mode (via 16-Bit Protected Mode), without virtual memory.
        With 4 MB of total RAM it ran smoothly, from what I remember.
        On a 386 PC, Standard-Mode had been used automatically if the PC was low on RAM (2 MB total).

        The memory boards weren’t that expensive, I think, since they were often sold without RAM.
        Buying RAM chips rather was “expensive” in the late 80s, because there was a memory price crisis.
        In mid-80s, memory was still fairly cheap.
        That’s why PCs such as Amstrad PC1512 and PC1640 could be sold for little money, still.

        That being said, it’s true that a lot of XT class PCs and ATs (286) never saw more than a sad megabyte of RAM.
        Many users who had bought a PC compatible in the mid-80s used it for more than an electric typewriter, also.

        Let’s think of all those sad Atari PCs and Commodore PCs which never got any sorts of upgrade.
        Some had gotten a small hard disk, at best, but were otherwise unexpanded.

        Some had been left with a bare MDA card (not even Hercules).
        For Turbo Pascal and GW-Basic this was good enough, it seems.
        But that alone was barely professional use of a PC.
        That was the typical “I need a boring beige box for school” use case.

        1. As an FYI (I think you know this but for others) a short description of EMS and XMS, since I imagine it’s before many user’s time and some might be interested in just what is going on here.

          LIM (Lotus/Intel/Microsoft) EMS (Expanded Memory Spec) was not a hardware spec, it was a driver spec, you’d get an EMS card and it came with a model-specific EMS driver. (This turned out to be convenient later on since EMM386.SYS could just follow the EMS spec and provide EMS memory using the memory mapping features already built into the 386.) The EMS card (or EMM386) grabs a 64KB chunk of memory space between 640KB and 1MB. On request from the DOS software, the EMS driver maps a 64KB segment of expanded memory into that 64KB space. That space is below the 1MB barrier so the DOS program can access it directly.

          This working on data in 64KB segments probably sounds like a huge PITA to work with, but DOS software already accessed the “up to 1MB” in 64KB segments anyway, so DOS programmers, the compilers, etc. were used to having to deal with code and data 64KB at a time anyway.

          XMS (Extended Memory Spec) came out later, it relied on 286 or usually 386 system that could already access more than 1MB of memory (although not in the mode DOS runs in). XMS spec JUST took care of keeping track of memory allocations above 1MB so multiple programs wouldn’t scribble over each other’s memory… it didn’t actually help the DOS software access that memory. The DOS software would have to jump into 32-bit protected mode, or a choice of a few other very odd modes (“unreal mode” anyone?) to actually access that above 1MB memory.

          I indeed remember seeing someone with like $10,000+ workstation, it was a 486 but it was like dual or maybe even quad processor, with 32MB RAM in it, back when I had a 386 with 4MB. They were running DESQView/X and running engineering stuff on there. As you say, someone running a regular desktop up through the very early 1990s could still have their 640KB system, but run some engineering stuff and (if you had the cash for it) you could put in 8MB or more.

          As a side note, I’m pleased to see ELKS is now under active development again — I think it had been dormant for a good long while.

      2. I think it’s also important to remember that DOS users had been short on memory from very beginning.
        Even way back in the mid-80s users ran out of memory easily and felt a strong desire for more memory.
        So 512 or 640 KB of RAM never had been “enough”.

        That’s how LIM EMS came to be, after all. EMS was designed for 8088 PCs, originally, not for 386+.
        That’s why it had used bank-switching in first place.

        It’s just that the 386 MMU could provide EMS so easily without any extra hardware, increasing popularity of EMS.

        Hence, OSes like PC-MOS/386, Concurrent DOS 386 or Wendin DOS could multitask DOS applications if being given enough RAM.

        The 386 MMU could re-map memory space as needed, while the V86 mode assisted in virtualization.

        LIMulators that used hard disk space as EMS had existed, too.
        They simulated EMS 3.2 “RAM” by using a swap file.
        This was slow and worked with user data (spreadsheet, text files) only, of course.
        But it perhaps showed how badly users wanted more RAM.

        Programs like EMM286 simulated EMS on a 286 by copying data to/from XMS memory.
        Some 286 chipsets had an EMS driver, too and could simulate EMS.
        It did the work of the 386 MMU, so to say.

        Other work arounds to fight memory shortage had been the use of overlay files (ovl) by DOS programs, I think.
        Niche OSes like Xenix on PC had used other workarounds, maybe, not sure. Would be interesting to know.

        On other platforms, such as Macintosh, Atari ST and Amiga it was just natural to upgrade memory to 1MB and beyond.
        The professional or semi-professional Atari Mega ST series from the late 80s had 2MB or 4MB of RAM as standard.

        In my country the Atari STs with SM124 mono monitors had been used for serious work quite often by late 80s,
        because they were the better DOS PCs and not so much behind the times.

        They could handle DOS formatted floppy disks, but also run DOS in an emulator (with up to 704 or 736KB of RAM).
        The Atari ST was used as a poor man’s Macintosh, so to say.

        Speaking under correction.

    2. it’s true…the very last program i wrote with “Borland Turbo C++” used EMS for what at the time felt like unlimited RAM. but then the next program i wrote was on Linux and i simply called malloc() with as big a number as i cared and it was an epiphany i’m still raving about 30 years later. never going back :)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.