Build Your Own Bootable Emacs Environment

An old joke is that Emacs is a text editor with an operating system included, given that its extensibility and customization often goes far beyond traditional text editors. Part of its well-earned reputation comes from being built in Lisp which allows it to be expanded to do almost anything. Despite this in-joke in the community, though, you will still need an actual operating system to run it, but not much more than that.

This project uses User-Mode Linux (UML) as a foundation to load almost nothing other than an Emacs editor. UML is a virtualization technology that allows running multiple Linux kernel instances as separate virtual machines, so once the Linux environment is started and Emacs is compiled, the virtual machine can essentially boot straight into an Emacs environment. Some tools are needed outside of the Linux kernel like mount which allows the virtual file system to access the files needed to build Emacs, but as far as lightweight or minimalist Linux distributions go this one definitely gets at least an honorable mention.

While UML is virtualization software rather than a full-fledged Linux distribution, we would expect a similarly minimalist build could easily be done with something more hardware-based like Linux From Scratch. Emacs has been around for so long and had such a wide reach that it’s difficult to imagine a world without it. Even in more modern technology like browsers, knowing a little bit about Emacs can be an extremely powerful tool.

Computers For Fun

The last couple years have seen an incredible flourishing of the cyberdeck scene, and probably for about as many reasons as there are individual ’deck designs. Some people get really into the prop-making, some into scrapping old tech or reusing a particularly appealing case, and others simply into the customization possibilities. That’s awesome, and they’re all different motivations for making a computer that’s truly your own.

But I really like the motivation and sentiment behind [Andreas Eriksen]’s PotatoP. (Assuming that his real motivation isn’t all the bad potato puns.) This is a small microcomputer that’s built on a commonly available microcontroller, so it’s not a particularly powerful beast – hence the “potato”. But what makes up for that in my mind is that it’s running a rudimentary bare-metal OS of his own writing. It’s like he’s taken the cyberdeck’s DIY aesthetic into the software as well.

What I like most about the spirit of the project is the idea of a long-term project that’s also a constant companion. Once you get past a terminal and an interpreter – [Andreas] is using LISP for both – everything else consists of small projects that you can check off one by one, that maybe don’t take forever, and that are limited in complexity by the hardware you’re working on. A simple text editor, some graphics primitives, maybe a sound subsystem. A way to read and write files in flash. I don’t love LISP personally, but I love that it brings interactivity and independence from an external compiler, making the it possible to develop the system on the system, pulling itself up by its own bootstraps.

Pretty soon, you could have something capable, and completely DIY. But it doesn’t need to be done all at once either. With a light enough computer, and a good basic foundation, you could keep it in your backpack and play “OS development” whenever you’ve got the free time. A DIY play OS for a sandbox computing platform: what more could a nerd want?

WheatSystem Is A Homebrew 8-Bit OS

[Esperantanaso] has long been involved in producing homebrew 8-bit computers. His various builds could all achieve different things, but he grew frustrated that applications written for one could not be easily run on another. He recently took a big leap forward in this area, though, cooking up his own 8-bit operating system called WheatSystem.

The work initially began with BreadSystem, which relied on applications existing in bytecode. This would then be run by the BreadSystem OS which would handle the requisite conversion to the machine code of the system it ran on. However, the work quickly got out of hand when it came to implementing advanced features like the file system and floating-point handling. BreadSystem was looking likely to be too heavy to run on lightweight 8-bit systems.

That led to the development of WheatSystem, which kept the bytecode runtime environment, unified heap, and a memory permission system from BreadSystem. Fancier features like granular memory permissioning, automatic garbage collection, and file system directories were dropped.

WheatSystem quickly became a basic and functional OS. To demonstrate it, [Esperantanaso] created WheatBox 55A1, a small homebrew computer based on the ATmega328. It readily runs simple applications like a prime number generator or a basic RPG.

Creating one’s own OS is no mean feat, even at the 8-bit level. We’ve seen it done before, and it never fails to impress.

Continue reading “WheatSystem Is A Homebrew 8-Bit OS”

The NES Gets Its Own OS

Until recently, most video game systems didn’t need their own operating systems in order to play games. Especially in the cartridge era — the games themselves simply ran directly on the hardware and didn’t require the middleman of an operating system for any of the functionality of the consoles. There were exceptions for computers that doubled as home computers such as the Commodore, but systems like the NES never had their own dedicated OS. At least, until [Inkbox] designed and built the NES-OS.

The operating system does not have any command line, instead going directly for a graphical user interface. There are two programs that make up the operating system. The first is a settings application which allows the user to make various changes to the appearance and behavior of the OS, and the second is a word processor with support for the Japanese “Family Keyboard” accessory. The memory on the NES is limited, and since the OS loads entirely into RAM there’s only enough leftover space for eight total files. Those files themselves are limited to 832 bytes, which is one screen’s worth of text without scrolling.

While it might seem limited to those of us living in the modern era, the OS makes nearly complete use of the available processing power and memory of this 1980s system that was best known for Super Mario Bros. and Duck Hunt. It’s an impressive build for such a small package, and really dives into a lot of the hardware and limitations when building software for these systems. If you need more functionality than that, we’d recommend installing Linux on the NES Classic instead.

Continue reading “The NES Gets Its Own OS”

New OS For Commodore 64 Adds Modern Features

The Commodore 64 was a revolutionary computer for its day and age. After four decades, though, it gets harder and harder to use these computers for anything more than educational or hobby electronics projects. [Gregory Nacu] is fiercly determined to challenge this idea, though, and has gone to great extremes to make this hardware still relevant in the modern age by writing a completely new operating system for the Commodore machines.

Known as C64OS, it squeezes everything it can out of the 8 bit processor and 64 kB of memory. The new OS includes switchable desktop workspaces, a windowing system, draggable icons, a Mac-style menu bar at the top, and drop-down menus for the icons (known as aliases in the demonstrations). The filesystem is largely revamped as well and enables a more modern directory system to be used. There are still some limitations like a screen resolution of 320×200 pixels and a fixed color palette which only allows for a handful of colors, but this OS might give Windows 3.1 a run for its money.

The project is still being actively developed but it has come a long way into a fairly usable state. It can be run on original hardware as well as long as you have a method of getting the image to the antique machine somehow. If not, the OS can likely run on any number of C64 emulators we’ve featured in the past.

Thanks to [Stephen] for the tip!

Continue reading “New OS For Commodore 64 Adds Modern Features”

90s Apple Computer Finally Runs Unsigned Code

Back in the 90s, the console wars were in full swing. Nintendo vs Sega was an epic showdown at first, but when Nintendo seemed sure to clench the victory Sony came out of nowhere with the PlayStation. While these were the most popular consoles at the time, there were a few others around that are largely forgotten by history even if they were revolutionary in some ways. An example is the Pippin, a console made by Apple, which until now has been unable to run any software not signed by Apple.

The Pippin was Apple’s only foray into gaming consoles, but it did much more than that and included a primitive social networking system as well as the ability to run Apple’s Macintosh operating system. The idea was to be a full media center of sorts, and the software that it would run would be loaded from the CD-ROM at each boot. [Blitter] has finally cracked this computer, allowing it to run custom software, by creating an authentication file which is placed on the CD to tell the Pippin that it is “approved” by Apple.

The build log goes into incredible detail on the way these machines operated, and if you have a Pippin still sitting around it might be time to grab it out of the box and start customizing it in the way you probably always wanted to. For those interested in other obscure Apple products, take a look at this build which brings modern WiFi to the Apple Newton, their early PDA.

Continue reading “90s Apple Computer Finally Runs Unsigned Code”

Pumpkin OS running on x86

Palm OS: Reincarnate

[pmig96] loves PalmOS and has set about on the arduous task of reimplementing PalmOS from scratch, dubbing it Pumpkin OS. Pumpkin OS can run on x86 and ARM at native speed as it is not an emulator. System calls are trapped and intercepted by Pumpkin OS. Because it doesn’t emulate, Palm apps currently need to be recompiled for x86, though it’s hoped to support apps that use ARMlets soon. Since there are over 800 different system traps in PalmOS, he hasn’t implemented them all yet.

Generally speaking, his saving grace is that 80% of the apps only use 20% of the API. His starting point was a script that took the headers from the PalmOS SDK and converted them into functions with just a debug message letting him know that it isn’t implemented yet and a default return value. Additionally, [pmig96] is taking away some of the restrictions on the old PalmOS, such as being limited to only one running app at a time.

As if an x86 desktop version wasn’t enough, [pmig96] recompiled Pumpkin OS to a Raspberry Pi 4 with a ubiquitous 3.5″ 320×480 TFT SPI touch screen. Linux maps the TFT screen to a frame buffer (dev/fb0 or dev/fb1). He added a quick optimization to only draw areas that have changed so that the SPI writes could be kept small to keep the frame rate performance.

[pmig96] isn’t the only one trying to breathe some new life into PalmOS, and we hope to see more progress on PumpkinOS in the future.