I'm not steeped in computer science, so please pardon me if the following are dumb questions.

> Programs written for Bedrock can run on any computer system, so long as a Bedrock emulator has been implemented for that system.

Isn't that true of any program? As long as the language that the program is written in is implemented on the system, any (valid?) program in that language will run on that system?

Love it, I think it's very cool! I am not sold on its "everlasting" promise yet, but as an addition to the family of "fantasy" platforms seems very solid.

This is fantastic! As someone who's used PICO-8 in after-school STEM enrichment classes (and has evaluated uxn), one of the frustrations that my students have always had is easy I/O and persisting state -- for saving/loading game progress and settings, of course. The clipboard and registry devices seem like a good fit.

I hope you stick with this!

> I designed Bedrock to make it easier to maintain programs as a solo developer.

Can you say more? I really love this idea but can’t think of any practical use case with 65k of memory. What programs are you now more easily maintaining with Bedrock? To what end?

The demos are surprisingly fun!

This is the latest in a very honourable tradition. My first encounter with it was with Martin Richards's BCPL system in 1972. The compiler generated a hypothetical ISA called OCODE, from which backends generated pretty good native code for Titan-2 and System/360, among others. One of those backends generated INTCODE, which was an extremely reduced ISA, for which an interpreter could be easily written (I wrote one in Fortran). Richards also provided the BCPL compiler and runtime library in INTCODE, so you could quickly have BCPL running interpretively. Then you could use this interpretive version to bootstrap a native-code backend implementation. Put this all together, and you now have a very easy compiler port.

Wirth's Pascal-P compiler of 1974(?) used the same idea, also in aid of a highly portable compiler. I have never been able to find out whether this was an independent invention, or whether Wirth was influenced by Richards's work.

Of course, the JVM and CLR are descendents of this, but they build a very complex structure on the basic idea. Writing an implementation of one of these virtual machines is not for the faint of heart.

So I think Bedrock can be very useful as a compiler target, if nothing else. However, I must agree with some of the other commenters that the 64KiB address space makes it very much of a niche tool. Come up with a 32-bit variant that's not much more complicated, and I think you have a winner.

I made a bedrock onion of death: https://paste.pictures/FgqbwUTCY8.png

Couldn't have done it without you

I have not delved to deep in the code, but is there any functional differences it has over Java other than the size ?

Presumably Java would also be pretty tiny if we wrote it in bytecode instead of higher lever Java.

For people curious about the differences between this and Uxn (as I was): https://benbridle.com/articles/bedrock-differences-from-uxn....

Why 8 bit?

Love this! Takes me back to the literal 8-bit computers of the 80s when it was much easier to learn to program with, for example, BASIC built into the operating system.