←back to thread

Show HN: Bedrock – An 8-bit computing system for running programs anywhere

(benbridle.com)
221 points benbridle | 1 comments | 10 Jul 25 22:20 UTC | HN request time: 0.214s | source

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.

Show context
Lerc ◴[15 Jul 25 14:42 UTC] No.44571643[source]▶
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.

replies(1): >>44576430 #
1. benbridle ◴[15 Jul 25 22:17 UTC] No.44576430[source]▶
> Locked and changed?

That could do with some better wording. Normally the user can freely drag-resize the window, but after the program sets the width or height then the user will be unable to resize that axis. This is for, say, a list program where the screen contents would have a fixed width but a dynamic height, so you'd want to keep the height resizable (unlocked).

> You also seem to be using double to refer to two bytes

Double does mean a 16-bit value, yeah, there's a list of definitions on the main page of the user manual and specification. Short tends to be the expected name for a 16-bit value (from C et al.), but it doesn't make much sense for a short to be the wider of two values. I briefly considered word, but the definition is too broad, with a byte also being a type of word. Double felt like the most intuitive name, because it's double the width of a byte. There weren't really any other decent candidates.

> a individual device for each permission that you wanted to supply and have the host environment optionally provide them

That's more or less the plan, only with a bit more granularity depending on the implementation, so that you can, say, allow reading files but forbid writing or deleting.