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 [email protected].
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.
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?
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.
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.
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.
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.