4 ms·

Isn't this general idea what the 100 Rabbits people theorize? i.e with uxn and all that

gxd 2y ago
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/ 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".
- entaloneralie 2y ago
  > 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://wiki.xxiivv.com/site/devlog https://100r.co/site/weathering_software_winter.html 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 https://tinlizzie.org/VPRIPapers/tr2015004_cuneiform.pdf Other related similar projects: https://dercuano.github.io/notes/uvc-archiving.html https://dercuano.github.io/notes/uvc-archiving.html
  - gxd 2y ago
    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.
    - entaloneralie 2y ago
      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.

gxd 2y ago

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/ 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".

entaloneralie 2y ago
> 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://wiki.xxiivv.com/site/devlog https://100r.co/site/weathering_software_winter.html 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 https://tinlizzie.org/VPRIPapers/tr2015004_cuneiform.pdf Other related similar projects: https://dercuano.github.io/notes/uvc-archiving.html https://dercuano.github.io/notes/uvc-archiving.html
- gxd 2y ago
  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.
  - entaloneralie 2y ago
    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.