ROM based home computers since Atari ST?

I’ve got a question which will help me with my WIP, Postcards from Cutty. In this setting, most modern computers have backdoors. So, some space colonists use miniaturized retro computers to control spacecraft systems.

Currently, I’m thinking they’re mostly based on the Atari ST because it was ROM based, but also the 32 bit 68K CPU code and address space is adequate for most of the tasks required for spacecraft systems. In contrast, 8 bits are just too limited for a lot of things.

But are there other good possible systems to use instead?

Fundamentally, it needs to be something that enthusiasts could pick apart byte-by-byte and transistor-by-transistor to ensure there are no vulnerabilities. So something a bit “small” is good. And it needs to be able to eat its own dog-food. The entire development system needs to be able to run on itself (so - no specialized microcontroller systems).

And ideally, it needs to be popular enough that there would be an enthusiast scene in the first place who will have laboriously picked apart everything byte-by-byte. The Atari ST, of course, is a popular platform for the demo scene.


Oh - and hi there! My first post here.


Two 32-bit CPUs spring to mind . ARM - in the early days had a ROM based OS that was lightweight enough to be fully understood (to the chip level) by a small number of people. (RISCOS)

The other is Sparc - or perhaps early Sparc systems. They are also a fairly simple design and the early Suns had a ROM based operating system which was all written in Forth. (Maybe still has, but I’ve been away from them for a good number of years now).

I’d not be too concerned about 8/16/32 bit CPUs though. An ATmega at 8-bits is a very capable system more than capable of controlling a drone in flight, although things like floating point are relatively slow, being done in software (as it was on early ARM and Sparc chips)

And remember, a backdoor is only a backdoor if someone has the means to connect to it and open it.



Good to see you posting here @IsaacKuo!

Indeed, I was going to mention Acorn’s Archimedes and RISC PC lines - both of them had OS in ROM. From a system design perspective the ST and Acorn’s line were arguably both quite straightforward - no blitter, no separate frame buffer - but Acorn’s machines would always have had higher performance, in the years where the two overlapped. I would expect Acorn’s OS to be the more sophisticated, but I’m not unbiased!

Although Sun’s preboot Forth monitor was interesting and useful I’m not sure I’d call it an operating system - am I missing something? It surely was never the intended OS for the end user.

For both Atari and Acorn it seems a little odd to put a whole OS in ROM. It’s very handy to do it when there’s no floppy drive or similar, but once there is a floppy drive, that’s something else. The Amiga’s kickstart was in ROM, and I think it contains enough to be an OS, but it doesn’t contain the Workbench GUI - that loaded from floppy. At least, I think it did in mine.

Thanks for the info! Since I’m a USA person, I’m very unfamiliar with the Acorn/Risc computers.

I was completely unaware that Sun had used anything before *nix (which, of course, uses read-write operating system drive galore).

As for the required CPU power and address space - well, there’s a lot of sensor processing which is way too intense, but things like monitoring and running life support systems is okay.

And yeah - about the back doors … most computer systems in this setting are purposefully built with oodles of mandated security holes on a hardware level. Both due to various capitalism and authoritarianism reasons. It’s a cynical take but like … just look at the “Internet of Things”.

I think you could make the case that Sun’s Pre-boot OS was more akin to a better version of EFI / UEFI that we’re seeing now in our present day computers. It was just enough to get you to boot an OS.

I dunno, I recall an anecdote (how true it is I couldn’t say) that at some point the most powerful computer flying on the Space Shuttle was an HP-41 calculator.

And, of course, my other favorite anecdote was during a discussion of the Voyager probes. The commentator said that “many people carry a computer far more powerful than what flies on the Voyager. No, not your cell phone, but your key fob for your car.”

I also love the idea of seeing different scenes of folks walking through different space ships that are run by whatever thing they can find – C-64s, a TRS-80 here or there, the IMSAI navigation controller. Just a sort of mid-80’s “steampunk but with old micros” kind of thing. Someone carving out an Atari 800 to wall mount the keyboard, with an old portable TV and 2" screen as a display.

And then, of course, there’s this:

Forth (on Sparc based suns) … It’s probably correct that it’s not a “true” operating system, however Sun used it to build up a device tree of hardware before Unix started. It also probed any plug-in SBUS cards - each of them could have their own ROM - compiled Forth bytecode - to perform initialisations if required, and identify them to the main Forth system which then passed the device tree to the kernel when the kernel started.

So it essentially had the ability to use the network and local disk drives - BIOS or OS? Who knows, but it was possible to write programs in it and change things round (Once upon a time, I spent some time porting it to some new Sparc based hardware the company I worked with had developed)


There is a lot of history online, but briefly, Acorn developed the RISC processor which we now call ARM (Acorn RISC Machine). Their ARM based computer ran a GUI based OS initially written in BASIC, then natively. It is (is, for it’s still in-use) essentially a single user cooperatively multi tasking OS. It’s very light weight and responsive.

Today you can still run RISCOS on a variety of ARM platforms including the Raspberry Pi. It has a small but enthusiastic community surrounding it.


Let’s have some links. I started with the mistaken belief that the ST was so straightforward that it had no custom chips. Not so:

Now Acorn’s machines: first Archimedes, running Arthur, then running RISC OS, and then the RISC PC line.

As for Sun’s pre-boot Forth, it became part of the PCI standard. The OLPC also runs it for pre-boot (and can run a few pretty demos too.)

1 Like

Maybe I’m missing the point, but to me your plan doesn’t add up. First, the Apollo Guidance Computer, which landed people on the moon, was 16 bits (well, really 15) and had about the same memory as an Arduino Uno. It also had about 1/20th or less the speed.
The shuttle computers were IBMAP101s, which were “embedded” version of the 360 architecture. It originated in the late 60s. The first version used in the shuttle ran about 480,000 instructions per second and had roughly 256KB of CORE memory. They were used for general purpose, not just controlling the shuttle.
Most of the planetary exploration missions have used VERY slow 8 bit computers. Mostly custom, 1802, or 8085 processors, running at low megahertz speeds.

The OS in ROM is nice. But it won’t control the ship? Where’s the rest of the software gonna come from? Wherever, that will open plenty of “backdoors.” I don’t think an ST has a cartridge port, does it? At least with a Commodore 64 you could program your software into a ROM and put it in a cartridge.
Basically, you don’t need a quad-core, 1 GHz Raspberry Pi to blink an LED.

The stuff required for these spacecraft to operate is a lot more intense than what Apollo or the Space Shuttle required. Rather than using just a few navigation stars, for example, millions of stars and asteroids etc are tracked. This allows good navigation at all times regardless of orientation or position, or if there is poor visibility (such as during aerocapture).

Speed isn’t so much an issue, because the miniaturized retro computers have extremely high clock speeds. The rest of the software comes from emulated mass media. And yes - there’s the potential for security risks there. But the point is, it’s developed by enthusiasts and purposefully kept simple enough to make secure. There’s not a whole lot of software available and it’s not so flexible, but it’s … mostly adequate.

Only one of the characters uses a spacecraft which is heavily outfitted with retro computers. The others use more modern off-the-shelf hardware and software, and most of the space combat between them revolves around exploits and shutting down systems if necessary.

Unfortunately, most off-the-shelf hardware and software in that era is of the ilk of iOS/Android/etc … walled gardens infested with corporate and state back doors on a hardware level. The computer systems are more designed to pervasively monitor and analyse and control humans, rather than to serve them.

So they aren’t really retro computers, and could be anything you wanted to create. Oh, well.
Of course, calculating a position on

will take more than the 16MB address space of a 68000. But if you’re creating the retro ST than never (will) existed and has all sorts of futuristic features like super-high clock speeds, guess we can scratch that too.
Have fun :slight_smile:

Yeah, I don’t like calling a vintage computer a “retro” computer. A Commodore 64 isn’t “retro” it’s vintage. A C64 is only “old fashioned” because it’s just old. To me, a “retro” computer is one which is purposefully designed to be non-modern is some sense.

The hobby of using vintage computers is retro computing, but that’s talking about the activity, not the hardware being used (unless we’re talking stuff like SD adapters and HDMI converters and modern WiFi adapters and stuff).

But anyway - yeah, it COULD be anything I want to create. So I’m thinking more in terms of what might have built up a significant fan enthusiast following to build upon, rather than something created from scratch in a vaccuum. And even though I’m really an Amiga person, I feel like the Atari ST may be a better fit for this.

Now, how about Archimedes/RiscOS instead? Honestly, I just don’t know. I mean, I’m aware of the Atari and Commodore demo scenes, as well as various 8-bit demo scenes. I don’t know what the popularity of others are like.

1 Like

I suppose if you’re making up all your own definitions, you can say that. But I suspect an awful lot of people will disagree with you. And, by the way, this is the “retrocomputingforum” web site. Just thought I’d mention that.

I quite like the distinction of vintage (old) vs retro (relatively old)… and every piece of speculative fiction needs to be a mix of truths, half-truths, and convenient inventions.

One reason for mentioning the custom chips in the computers is the question of trust: it’s one thing to trust layers of software, but of course you also need to trust layers of hardware. Knowing how your computer is built and replacing parts with known equivalent parts from other sources could be part of a defence in depth. So, a simple CPU is better than a complex one, and a computer made from commodity parts is better than one made from custom parts.

The funny thing about the Church-Turing Thesis is that all computers, given storage, are equivalent. There’s a nice example here

So, with enough processing speed, or enough time, and with byzantine memory banking or swapping schemes, any machine can act as any other. You just have to trust the whole stack. (The Gigatron is a very nice example of a simple machine made from commodity parts, capable of running a virtual machine that’s competent enough to run games or a Basic interpreter. And of course you can emulate an ARM in Basic… or you can emulate a PDP-11 on a PDP-7!

Still, there’s fun in having a historical software environment, whether it be GEM or TOS, or Unix-11, or the Workbench.

As for RISC OS, would you believe there’s still a round of tradeshows where you can buy hardware and software for your Acorn machine? I’m not aware of a demo scene, but there’s a commercial ecosystem.


I don’t think that’s what @bdk6 meant. I think the distinction between a “vintage computer” and a “retro computer” in meaningful in this case. The C64 itself isn’t retro, using it in 2019 is retro. Certainly it’s nothing to get in a tussle about!

Indeed so! This thread does seem to have brought out some combative stances. Please, everyone, remember: we’re here to enjoy ourselves. Be kind. Be generous in your interpretations. Even if something is stated as fact, it’s most likely an opinion, especially if there’s room to disagree with it. If there are differences of opinion about terminology, consider how important and how interesting that really is. If you’re posting some interesting ideas or commentary and are tempted to sideswipe at something else, please think again: you know already that your sideswipe is inviting a reaction. We all share the same interests here - there’s no need to be controversial in order to start an interesting conversation.

1 Like

ROM based OS does not imply security. I develop Set-top-Box decoders that has the entire OS (linux) in ROM and its pretty solid to attacks… although there is no such thing as ‘un-hackable’

Security is by design, not by Operating System or by ROM.

If the design requires a CPU that is verifyable to the transistor level, then a FPGA and roll your own processor (picoblaze, microblaze or any of the other types) - Security by Obscurity although isn’t a good practice, but if a hacker doesn’t know where to start, its a good thing.

If using a modern CPU for security, the whole filesystem must be in RAM to avoid paging data in/out of a block device. PAGING is an attack vector… especially if its flash based where a bad actor can modify a secure executable after the checksum has been validated.

Booting must also have the chain-of-trust (CPU microcode verifies the bootloader - bootloader verifies runtime etc etc)

There are many more design considerations, but in todays world, everything is ROM-able.

1 Like

Many ROM operating systems will vector through RAM or otherwise allow for run-time adjustments, for bug fixing or for adding capabilities. There’s a nicely told story here about how patches were arranged for the Newton’s ROM-based OS. (No flash, ten week lead time for ROM manufacture, late-breaking software updates as ever, limited space for RAM vectors.)

1 Like