I used the p-System on a Heathkit H-89. I think the overall approach of future-proofing your software by compiling it to a simple, portable virtual machine is

I used the p-System on a Heathkit H-89. I think the overall approach of future-proofing your software by compiling it to a simple, portable virtual machine is valid. Since the p-System, in addition to the JVM and Zork Z-machine mentioned in this post, we've seen Smalltalk-80, PostScript, Open Firmware aka OpenBoot, Glulx, the ASS/400, the Open Software Foundation's ANDF (the architecture-neutral distribution format), Google's NaCl and pNaCl, Microsoft's CIL, JS as a compilation target, WebAssembly, uxn, and the revival of old video game consoles in emulation as a stable software target. A problem with this approach is that most of these portable platform layers are still far too unstable for reliable archival; even video game emulators face a constant struggle to maintain compatibility as they are updated to keep up with whatever platform they're running on. Platforms like the JVM, which make more concessions to efficiency than MAME, have even more difficulty, so the JVM's slogan of "write once, run anywhere" was widely mocked as "write once, debug everywhere". But it's a good aspiration. I'd like to see it realized in a practical way. My memory of the p-System is that it was almost unusably slow, a problem made worse by its filesystem being so simple it didn't support fragmentation, so sometimes you had to defragment your floppy disk in order to write new files onto it. It's true that its UI was screen-oriented, as wduquette said, and it was driven by a Lotus-1-2-3-like menu system, which enhanced its usability quite a lot. Being a pure bytecode interpreter was a serious handicap, especially on the sub-1-MIPS machines we were running it on. EUMEL managed to make a go of it. I never got a chance to use EUMEL on an actual Z80, but I hear it was usably fast; I suspect the EUMEL virtual-machine instruction set (which included string operations) and operating environment went a long way towards compensating for the slowness of bytecode interpretation, much as Numpy does on CPython today. I suspect you could have done a better job with a bytecode more like Dalvik, designed for efficient JIT compilation by leaving less work for the JIT compiler. But Deutsch and Schiffman didn't publish the first JIT-compilation paper until a few years after the p-System was released. (Schiffman told me a self-deprecating joke about this which I guess I can't really repeat.) Long Tien Nguyen and Alan Kay published a paper on designing a very simple virtual machine for such digital preservation 10 years ago: https://tinlizzie.org/VPRIPapers/tr2015004_cuneiform.pdf https://tinlizzie.org/VPRIPapers/tr2015004_cuneiform.pdf I think these ideas point the way to achieving the kind of future-proofness that the p-System was shooting for.