HN Explorer

Show HN: Bedrock – An 8-bit computing system for running programs anywhere (benbridle.com)

221 points by benbridle ↗ HN
Hey everyone, this is my latest project.

Bedrock is a lightweight program runtime: programs assemble down to a few kilobytes of bytecode that can run on any computer, console, or handheld. The runtime is tiny, it can be implemented from scratch in a few hours, and the I/O devices for accessing the keyboard, screen, networking, etc. can be added on as needed.

I designed Bedrock to make it easier to maintain programs as a solo developer. It's deeply inspired by Uxn and PICO-8, but it makes significant departures from Uxn to provide more capabilities to programs and to be easier to implement.

Let me know if you try it out or have any questions.

31 comments

[ 3.5 ms ] story [ 118 ms ] thread
treetalker
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?

benbridle
You're right, it's technically true of any program, but it wouldn't necessarily be practical. Implementing CPython on a Gameboy Advance, for example, would be tedious and likely not entirely possible.

The purpose of Bedrock was to make a system that is easy to implement on as many computer systems as possible. I've got plans to make a working system from a 64KB RAM chip and a $2 PIC12F1572 8-bit microcontroller (2K memory, 6mW power, 8 pins), just to see how far down I can take it.

untech
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.
benbridle
Thank you! It's early days yet, we'll see how well it holds up in a few decades.
nxobject
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!

benbridle
Thank you, that means a lot!

I've got plans for tooling in the future that will make Bedrock more accessible to people who are learning to program, like a high-level language that runs on Bedrock and a graphical debugger for visually clicking around and changing the internal state as your program runs.

behrlich
> 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?

apgwoz
It’s true you can’t build giant video editors or even photo editors. But, if you reestablish your expectations and think 8-bit retro, you’ll be reminded that very few things didn’t exist in some form in the 80s… just at a smaller scale. Spreadsheet? Check. Paint programs? Check. Music composition? Check.
benbridle
I'm currently selling a pixel-art drawing program called Cobalt, which is built on Bedrock (you can see a demo of it running at the bottom of the project page). It was initially only available for Windows and Linux, but I wanted to make it available for the Nintendo DS as well, so I wrote a new emulator and now it and all of my other programs work on the DS. It was far easier to write the emulator than it would have been to figure out how to port Cobalt to the DS directly, and now I don't have the issue of having to maintain two versions of the same software.

It's true that 64KB is pretty small in modern terms, but it feels massive when you're writing programs for Bedrock, and the interfaces exposed by Bedrock for accessing files and drawing to the screen and the likes make for very compact programs.

szczepu
My immediate reaction was, "oh, like Uxn!" but then of course I read it was originally a fork of Uxn. I love these 'toy' OSes, the more the better.
lastdong
The demos are surprisingly fun!
vincent-manis
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.

jonjacky
Another early example is Stoy and Strachey's virtual machine for running their OS-6 operating system on the Module One minicomputer, starting around 1969 [1,2]. It was written in BCPL. Butler Lampson wrote that it influenced the early pre-Smalltalk OS for the Xerox Alto, also in BCPL [3].

1. https://academic.oup.com/comjnl/article-abstract/15/2/117/35...

2. https://academic.oup.com/comjnl/article-abstract/15/3/195/48...

3. https://www.microsoft.com/en-us/research/publication/an-open...

great_psy
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.

WantonQuantum
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.
ChuckMcM
Fun stuff Ben! Nicely done. I'm building a simple terminal that talks over a SPI port or IIC port and this looks like it would be a fun demo to run on it.
benbridle
Thank you! That sounds fascinating, I'd love to hear how you get on with it if you do.
kragen
I like things like this.

One of the big differences from Uxn is the introduction of undefined behavior; by design, you can break it, unlike Stanislav's legos. So presumably Bedrock programs, like C programs, will do different things on different implementations of the system. That's not fatal to portability, obviously, just extra write-once-debug-everywhere work.

benbridle
The undefined behaviour is limited to only a couple of very edge-case situations that would cause issues for the program anyway, like overflowing the stacks. My thoughts were that a program would have to be broken in order to have triggered one of these situations in the first place.
Animats
There's Open Firmware, which runs on a portable Forth interpreter. That was supposed to be a standard for board setup code. But proprietary systems won out. It was too open.
anta40
There are few examples here: https://benbridle.com/projects/bedrock.html

But where are the source codes?

benbridle
The source code for the microwave clock program is available on the 'Example: Microwave clock' subpage [0]. I hadn't put up code for any of the other programs yet, just because they currently use a lot of library code and idioms that I thought could be confusing to people. I'm intending to make them tidier and release them as proper examplars with commentary sometime. I'll also package up and release my library code at some point, it'd be helpful for people to be able to grab and use all kinds of pre-made functions, and there's a whole user interface framework in there too.

For the meantime though, I uploaded the source code for each of the snake [1], keyboard [2], and system information [3] programs for you or anyone else here to have a look at. Each one is a single source code file with library macros and functions baked in, so you can run `br asm snake-full.brc | br -z` to assemble and run them.

[0] https://benbridle.com/projects/bedrock/example-microwave-clo...

[1] https://benbridle.com/share/snake-full.brc

[2] https://benbridle.com/share/keyboard-full.brc

[3] https://benbridle.com/share/sysinfo-full.brc

severak_cz
It's a pity there is not some similar concept using more high level language (instead of assembly).

But I can see why as every interpreted language can be "fantasy console" on itself.

benbridle
There's PICO-8 in this category if you haven't already heard of it, it uses Lua as the language for writing programs. It was another huge inspiration of mine while working on Bedrock.

https://www.lexaloffle.com/pico-8.php

Lerc
I have thought of doing a similar thing from time to time.

I had thought it could have a use in producing tiny visual apps. I am still somewhat bitter from when I found a volume control that used 3MB on a machine with 256MB total.

It seems you can change the shape of the display, which I like, although I don't really understand the documentation text

>Writing to this port group will perform an atomic write, requesting on commit that the width of the screen be locked and changed to the value written.

Locked and changed?

You also seem to be using double to refer to two bytes, is that correct? If so, I would recommend something that won't confuse people so much. Word is a common nomenclature for a 16 bit value, although it does share the space with the concept of machine words.

And of course to use it for a lot of things it would have to be able to talk to the outside world. A simplified version of what Deno does for allowing such capabilities could allow that. In the terms of Bedrock it would be easiest to have a individual device for each permission that you wanted to supply and have the host environment optionally provide them. I'd put the remote bytestream into it's own device to enable it that way.

ninetyninenine
Someone should make this for highly parallel architectures that runs over GPUs.
lihaciudaniel
Wow awesome imagine this in a browser console, for ... management of the codes, you are genius