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.
Thank you! That sounds fascinating, I'd love to hear how you get on with it if you do.
Show HN: Bedrock – An 8-bit computing system for running programs anywhere
61–69 of 69 posts
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#62Love 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.
Thank you! It's early days yet, we'll see how well it holds up in a few decades.
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#63Why 8 bit?
That puzzled me too, since it's a fork of Uxn, a 16-bit architecture.
I had a hard time figuring out whether Bedrock counted as an 8-bit or 16-bit computer, because it doesn't line up so cleanly with the usual criteria as does a physical CPU. I decided that the 8-bit label fitted best because it has an 8-bit data path, an 8-bit instruction format, and the stacks hold only bytes. It also has a 16-bit address space and can perform 16-bit arithmetic, but so can the well-known 8-bit Z80 processor.
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#64Someone should make this for highly parallel architectures that runs over GPUs.
This would be fascinating to see, I have no idea how you'd even start.
There was a video I saw a couple of years back that was showcasing a cellular programming model, where each cell in a two dimensional grid performed an operation on values received from its neighbours. Values would move into one side of a cell and out the other every tick, something like Orca (by 100 rabbits), so the whole thing could be parallelised on the cell level very easily.
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#65It'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.
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
See also the wonderful LOAD81 from antirez:
https://github.com/antirez/load81
I've fantasised about turning LOAD81 into a much more full-featured development/execution environment for years, and have done a fair bit of work on extending it to support other things such as joystick devices, an internal sound synthesizer based on sfxr, and so on .. one of these days I'll get back to it ..
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#66Earlier quoted context omitted.
That puzzled me too, since it's a fork of Uxn, a 16-bit architecture.
I had a hard time figuring out whether Bedrock counted as an 8-bit or 16-bit computer, because it doesn't line up so cleanly with the usual criteria as does a physical CPU. I decided that the 8-bit label fitted best because it has an 8-bit data path, an 8-bit instruction format, and the stacks hold only bytes. It also has a 16-bit address space and can perform 16-bit arithmetic, but so can the well-known 8-bit Z80 pr…
The usual meaning of "data path" https://en.wikipedia.org/wiki/Datapath is the path from the register file (and/or memory access unit) to the ALU and back to the register file (and/or memory access unit). So we could say that both the 8088 and the 68000 had a 16-bit data path, because they used 16-bit buses for those transfers and a 16-bit ALU, even though the 68000 had 32-bit registers and the 8088 had an 8-bit data bus to connect it to RAM. The 68020 implemented the same instructions and registers as the 68000 (and additional ones) but used a 32-bit data path, so they were twice as fast.
In what sense does a virtual machine instruction set architecture with no hardware implementation have a "data path" separate from its arithmetic size? You seem to be using the term in a nonstandard way, which is fine, but I cannot guess what it is.
By your other criteria, the (uncontroversially "16-bit") 8088 would be an 8-bit computer, except that it had a 20-bit address space.
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#67Someone should make this for highly parallel architectures that runs over GPUs.
This would be fascinating to see, I have no idea how you'd even start. There was a video I saw a couple of years back that was showcasing a cellular programming model, where each cell in a two dimensional grid performed an operation on values received from its neighbours. Values would move into one side of a cell and out the other every tick, something like Orca (by 100 rabbits), so the whole thing could be paralleli…
You need a really simple set of assembly instructions for a vm that is based on gpu architecture.
Then make all the old school IO apis and rendering engine around it similar to pico 8 or bedrock.
The UI is a bit Similar to shader toy I guess.
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#68Earlier quoted context omitted.
I had a hard time figuring out whether Bedrock counted as an 8-bit or 16-bit computer, because it doesn't line up so cleanly with the usual criteria as does a physical CPU. I decided that the 8-bit label fitted best because it has an 8-bit data path, an 8-bit instruction format, and the stacks hold only bytes. It also has a 16-bit address space and can perform 16-bit arithmetic, but so can the well-known 8-bit Z80 pr…
The usual meaning of "data path" https://en.wikipedia.org/wiki/Datapath is the path from the register file (and/or memory access unit) to the ALU and back to the register file (and/or memory access unit). So we could say that both the 8088 and the 68000 had a 16-bit data path, because they used 16-bit buses for those transfers and a 16-bit ALU, even though the 68000 had 32-bit registers and the 8088 had an 8-bit data…
By data path, I mean the width of the values that are read from the stacks, program memory, and device bus. Pairs of 8-bit values can be treated as 16-bit values in order to perform wider arithmetic, but all data ultimately moves around the system as 8-bit values.
Re: Show HN: Bedrock – An 8-bit computing system for running programs anywhere
#69Earlier quoted context omitted.
The usual meaning of "data path" https://en.wikipedia.org/wiki/Datapath is the path from the register file (and/or memory access unit) to the ALU and back to the register file (and/or memory access unit). So we could say that both the 8088 and the 68000 had a 16-bit data path, because they used 16-bit buses for those transfers and a 16-bit ALU, even though the 68000 had 32-bit registers and the 8088 had an 8-bit data…
By data path, I mean the width of the values that are read from the stacks, program memory, and device bus. Pairs of 8-bit values can be treated as 16-bit values in order to perform wider arithmetic, but all data ultimately moves around the system as 8-bit values.
Whether 16-bit data moves around the system as 8-bit values or not sounds like a question about the implementation, not the architecture (the spec).
For example, the spec says, "Reading a double from program memory will read the high byte of the double from the given address and the low byte from the following address," but I'd think that generally you'd want the implementation to work by reading the whole 16-bit word at once and then byte-swapping it if necessary, because that would usually be faster, and there's no way for the program to tell if it's doing that, unless reading from the first byte has a side effect that changes the contents of the second byte or otherwise depends on whether you were reading the second byte at the same time.
(Of course if you have a "double" that crosses the boundaries of your memory subsystem's word, you have to fall back to two successive word reads, but that happens transparently on amd64 CPUs.)