Hacker News Reader

Comment by gxd | Hacker News Reader

I had never heard of it, so I went to find out more. Yes, I think it's the same philosophy. Very cool project.

Unfortunately, it seems that they went against the project's very principle by inventing a new language, new VM and toolchain instead of simply targeting one of the existing platforms. I can see why they wanted to build an abstraction layer, so their code is portable across different classic (and modern) platforms, but this is one more case of https://xkcd.com/927/.

It would have been totally okay if they had said "The future of software is creating applications targeting the Amiga 1000", or anything else from the 80s-90s, which I'll arbitrarily define as "simple enough to accurately emulate forever".

View on HN

> Unfortunately, it seems that they went against the project's very principle by inventing a new language, new VM and toolchain instead of simply targeting one of the existing platforms.

The intentions of Uxn are not directly in line with using say, a commodore 64, for preservation and as a portability layer, which is a monumental project to implement for each new system. The project's core principle is to design something perfectly tailored at hosting a handful of specific programs, document it in a way that if needed, others could create their own systems based on their own vision, and not centralize all preservation efforts around a handful of retrocomputing emulation.

https://wiki.xxiivv.com/site/devlog

https://100r.co/site/weathering_software_winter.html

It's more akin to using brainfuck or subleq, or Another World's VM or even Alan Kay's Chifir where the goal is to target a virtual machine that is so small(< 100 loc) that it can be easily ported. As opposed to a system so complex that it might take someone months to implement a passable C64, Amiga, or ST80 emulator.

https://tinlizzie.org/VPRIPapers/tr2015004_cuneiform.pdf

Other related similar projects:

https://dercuano.github.io/notes/uvc-archiving.html

Thank you for the great links!

It can be really hard to get accurate emulation with a somewhat loosely defined, high level VM such as some of your examples. If it's that small and simple, programmers might accidentally create a dependency on implementation idiosyncrasies. Just see what happens on the retro computing scene when emulators aren't perfectly cycle and hardware accurate - applications, the "demoscene" being a good example of them, that rely on very low-level details of the architecture don't work on certain emulators.

If we want to create a new "forever VM", that VM would have to very strictly define behaviors across I/O, graphics, audio and other areas. I don't want the application to stutter or run too fast on future emulators. I want the emulation to be perfectly cycle accurate.

Exactly, you get it. That's the goal of the project, no undefined behavior, no hazy specifications. :) I've dabbled in this space for quite a while now, I can assure you that dependency on implementation idiosyncrasies get increasingly worse with complex VMs.

Reply on news.ycombinator.com