Completely agree and I'll go a bit further. I see old consoles and computers as the only VMs that will last. In 500 years, assuming we all survive, I believe it's more likely that code targeting the NES will be runnable than code targeting today's browsers, .NET or the JVM. The reason is that while these competing VMs are well documented, they are extremely complex and code targeting them tend to rely on idiosyncrasies of current operating systems, browsers and even hardware.
Also, the retro hardware itself is the ultimate documentation. You can look at every chip using (nowadays) accessible equipment and create an absolutely perfect replica in software or FPGA. VM documentation, however, can contain inaccuracies.
My speculative fiction statement of the day is that only software targeting relatively simple architectures will stand the test of time.
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".
> 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.
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.
Well, the 6502 in general. It's an extremely important processor in history. People want to emulate NES, Commodore, Atari 8-bit, Apple II - so an accurate 6502 emulator has a HUGE base of nostalgic geeks to improve it.
Yes, and we have freely available, cycle accurate 6502 emulation code bodies along with full coverage tests that include both the official opcodes and many illegal ones. Mostly the ones people used such as LAX, which can get the same value into both registers on a single read.
I just had a fleeting thought right now related to that behavior:
Basically, that opcode works because of how simple the design is. Electrically, wiring both registers up does the trick. And many parts of the chip can work together like that even though none or it was intended.
I wonder what a revisit, that takes these now well understood behaviors
into consideration, would look like!
Zeroing all or multiple registers, same with bit ops, maybe inc, dec...
Many new, efficient instructions are possible. Would be a fun programming exercize and design one too.
I think it has less to do with the architecture or medium and more to do with the type of media itself.
We are more likely to actively preserve art in usable forms than something like JIRA. We play Chess more than we use whatever contemporary accounting tool. We read old novels more than we read transcripts of business meetings.
So we'll be more motivated to keep these architectures and games continually preserved.
Also, the retro hardware itself is the ultimate documentation. You can look at every chip using (nowadays) accessible equipment and create an absolutely perfect replica in software or FPGA. VM documentation, however, can contain inaccuracies.
My speculative fiction statement of the day is that only software targeting relatively simple architectures will stand the test of time.