Most people don't think of them as computer systems, but late-90s and early-2000s phone and PDA OSes. Specifically, EPOC32/Symbian, Apple Newton, BlackberryOS, PalmOS, Qualcomm RexOS, and Windows CE/PocketPC/Mobile (and its later incarnation Windows Phone/10 Mobile)

Newer calculators, like the TI-Nspire Cx-series and HP Prisms.

Proprietary non-linear editing systems from the 80s and 90s before the switchover to software.

A few legacy systems that haven't quite been emulated yet are BeOS, and RISCOS, certain proprietary Unix implementations like A/UX, Amix, Irix, NeXtOS, Apollo DomainOS, AIX, PA-RISC, Ultrix, etc., and Japanese PCs like the PC-98, PC-88, Sharp X1, Sharp X6800, and FM-Towns

Minicomputer hardware, like VAX Machines, DEC Alpha Systems, and DECstations, are also lacking in good emulation, but the OSes (OpenVMS and Ultrix) are available to hobbyists.

Itanium has not so far been emulated, so IA-64 versions of Windows are probably going to be lost (as no more IA-64 processors are being made) should nothing be done.

I have a feeling OpenVMS won’t run on Alpha much longer. The recent company that acquired it seems really set in commercializing an x86 port. No idea how successful that’s gonna be.

Judging by your comment history, you seem to take quite a bit of interest in DEC. Did you ever work with the company or its products?

Apple Newton has an emulator. A lot of the other PDA OSes from the naughties are portable and have public (non-free) source code so simulators probably make more sense.

The IBM i (formerly AS/400) platform, despite its popularity over several decades as a server for business applications—and its importance in computing history as an example of features such as object-oriented, single-level storage—doesn’t have a comprehensive, generally-available emulator, as far as I know.

For anyone outside IBM, developing one might be difficult: neither the original, low-level CISC instruction set used through the 1990s, nor the PowerPC AS extension to the POWER architecture that replaced it, has been fully described in public documentation.

Circa 2005 I worked at an academic library where they were profoundly pessimistic about digital preservation: they thought Apple ][ programs and C64 word processing documents would soon become impossible to access.

Videogame and home computer emulation proved the opposite, that with a different organizational structure, preservation was possible, even easy. (It's not hard at all to write an emulator if you're not picky about performance.)

For a system to be unemulatable it has to be unloved. If it's unloved does it matter if it's emulatable?

> It's not hard at all to write an emulator if you're not picky about performance.

I'd argue writing an emulator is actually quite difficult. Due to the avalanche effect, slight errors in your emulation won't cause the emulated system to be slightly off, but it makes it completely unbootable, similar to how a bug in a (cryptographic) hash function can make the output entirely different from what it's intended to be. And unless there is an existing emulator you can compare against, debugging such bugs is very difficult and they can only be identified by painstakingly cross-referencing your entire implementation with the CPU specs. Years ago I wrote an Intel 8086 emulator and even the decoding of the instructions was non-trivial: the whole deal with MOD R/M encoding and prefix bytes can take considerable time to get perfectly right. Then there's the timer interrupt system, the IO layer, rendering the visuals by polling specific regions of memory depending on the mode, 80286+ protected mode etc.

>For a system to be unemulatable it has to be unloved. If it's unloved does it matter if it's emulatable?

Or it has to be completely tied to external network services. The gameboy (color?) web browser only recently started working in emulators for example. I wouldn't be surprised if we never saw an iPhone emulator.

Major systems seems difficult to come up with a good candidate. There, I'd worry more about trend to DRM, dependencies on servers/online services, ... as a hurdle to software preservation.

I don't have numbers on this, but have the impression that more often the software is the main issue, where nothing is known while some hardware and hardware documentation survived in a state that can be reverse-engineered.