HN user
https://benbridle.com
Oh cool, that'd be great! I'm wanting to write a disassembler in the future as part of a dedicated debugger for Bedrock programs. If you end up writing down any plans I'd love to take a look or help you out, my email address is ben@derelict.engineering.
There are free demos available on the store page for Windows, Linux, and Nintendo DS, so Cobalt can still be used by people who can't afford $5. Charging a higher price would make the program a lot less accessible, and charging nothing would be unsustainable, I can't live off attention alone.
Thank you!
The second revision of the Bedrock specification changed very little of consequence, but I should probably add a change note to the spec. The structure of the document was reworked, becoming a single long document instead of multiple smaller ones; some sections were reworded for clarity; the behaviour in some underspecified edge cases was made explicit; the assembler specification was cleaned up; reading from the action port on the file device returns error state instead of success state. I don't expect that any existing programs other than Cobalt will have been affected. The bedrock-nds emulator uses the second screen to run a second Bedrock program (the on-screen keyboard), it isn't exposed to the main program.
My intention for Bedrock is that it will never change going forwards, other than for minor clarifications, so that existing programs will continue to work on any emulator indefinitely. Have you played around with Bedrock before, or written a program for it?
It's such a good platform for running programs on. It's small, has plenty of grunt, and the dual screens are great for multi-window work.
Thank you! The customizable tools give a surprising amount of power to the user for a relatively small amount of work (just a couple of basic editing screens). The most interesting outcome of all this is that the scatter and spacing parameters work equally well on the bucket fill tool as they do for regular brushes, allowing you to emulate white noise and similar when filling large areas.
The sketch layer is accessed with the 'eye' button in the bottom-right corner of the canvas screen. Clicking that button toggles visibility of the sketch layer and reveals three more buttons, and clicking the newly-revealed pencil button toggles drawing to the sketch layer instead of the canvas.
The decision to implement only two layers for Cobalt was a conscious one. The design of Cobalt is focused towards speeding up the user and helping them to finish their images, and I found that being able to go back and tweak each layer made it more difficult to commit to a final image.
Thank you! I'm really passionate about exploring this direction of computing, digging around in a bargain bin of discarded futures to find ideas worth pursuing.
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.
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.
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.
Thank you! It's early days yet, we'll see how well it holds up in a few decades.
Thank you! That sounds fascinating, I'd love to hear how you get on with it if you do.
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.
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.
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.
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.
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
Each screen pixel has two colours because there are two screen layers, a foreground layer and a background layer. Anything you draw to the foreground layer will be draw over anything on the background layer, so you can use the foreground layer for fast-moving elements like mouse cursors and game characters without having to redraw the entire background every frame.
So each pixel has a colour on the foreground layer and a colour on the background layer, and will be drawn as one or the other. Normally the foreground colour of the pixel will be the colour used, but if the foreground colour is palette colour 0 (treated as transparent), the background colour will be used instead.
You've got it, yeah. It makes writing programs across different systems so much nicer, because you can just write your programs against a single tidy 'bedrock' abstraction of the file system, screen, networking, etc.
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.
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.
Amazing work, I love it
I've since been informed that public domain isn't really a proper term, legally speaking, so to clarify things I've released Torque under the MIT license.
Oh I think I see what you mean now, you're talking about the encoding of the Torque source code that gets fed into the assembler. To be honest I'd never really considered anything other than UTF-8, the parsing is all implemented in Rust which requires strings to be valid UTF-8 anyway. Are you wanting to write Torque code with a non-Unicode text editor, or are you thinking about how the document encoding affects the handling of string literals inside the assembler?
Some kind of table syntax would be useful for character mappings, but I'm not sure what it'd look like or if it'd be applicable outside of dealing with characters. I'll think more on that.
Thanks for the interest! Torque is public domain, feel free to use it or change it or share it however you want. I'd love to hear how people use it, but no obligation.
If you shared it someplace public I'd love to pop by, if you have a link.
I wholeheartedly agree with using "0o" as the octal prefix, I've never been a fan of "0". I've jut implemented this feature and released it in v2.2.0, you can grab it from the project page. Thanks for the suggestion!
I'm not too sure I understand what you're describing with non-Unicode text. Torque doesn't have a built-in concept of bytes, instead each character is treated as an integer with the value being the Unicode code point of that character (using decimal we have 65 for 'A', 955 for 'λ', 129302 for 'robot emoji', etc). It's up to the programmer to choose how to pack the character (integer) into a sequence of bits. Code points are different to encodings like UTF-8 or UTF-16, which define how a code point (integer) is packed down into one or more bytes.
If you want to assemble 7-bit ASCII text, one byte per character, you define a macro that packs each character value into the lower 7 bits of an 8-bit byte. If the string contains a non-ASCII character, the character value will be too large to fit into the field and an error will be displayed.
%ASCII:c #0ccc_cccc ;
ASCII:"This is a string."
%BYTE:n #nnnn_nnnn ;
%ISO-8859-1:c
?[c 0x7F <=] BYTE:c
?[c '¡' ==] BYTE:0xA1
?[c '¢' ==] BYTE:0xA2
?[c '£' ==] BYTE:0xA3 ;
ISO-8859-1:"£190.00"
Please let me know if that doesn't answer your suggestion, I'm keen to understand your use-case.
[0] https://benbridle.com/projects/torque/manual-v2.2.0.html#usi...
Thank you so much! It looks like the issue I described is what he calls the 'oscillator problem' [0]. This is an absolute goldmine, I'm going to be reading for days.
[0] https://board.flatassembler.net/topic.php?p=178828#178828
I should clarify, I was thinking of microcontroller toolchains when I wrote this. The documentation I've seen for Intel processors is solid.
Oh neat! Thanks for the link, I hadn't heard of fasmg before.
It looks like fasmg builds up from the byte level, so it would only work for architectures that use 8-bit words. Torque builds up from the bit level, so it can assemble code for architectures like in PIC microcontrollers, using word sizes of 12 or 14 bits.
However, fasmg does allow a lot more control over the syntax of the language. The documentation shows some pretty powerful string manipulation that's used to parse real x86 assembler code, which makes sense given the purpose of it. Torque doesn't allow overriding the syntax to that degree, the macro invocation syntax is baked into the assembler.
One thing that intrigues me about fasmg is how it handles circular dependencies in expressions [0] (search for 'circular'). Currently in Torque it isn't possible to use a label reference inside a predicate, because the predicate evaluating one way could insert additional code, moving the label and causing the predicate to evaluate the other way [1]. But in fasmg it's possible to use the result of an expression as part of its own calculation.