Dark System

Devlog #7
It’s been a while, hasn’t it. I’ve been busy building a compiler! So I;ve finished the rough draft version, but it took quite a while, leading to the gap in devlogs. The language, Coral, looks like the first image below. The way compiling works is that it first parses the source code into an AST(Abstract Syntax Tree, the code represented as a tree), then converts that to a relatively high level IR (Intermediate Representation), which has similar syntax to the final Assembly, but has infinite virtual registers, and abstracts away having to select specfic instructions for diffrent data types (Unsigned vs Signed, Floats vs Ints, Int32 vs Int16). Then that IR is feed into the backend which translates it into bytecode.
Below is one source example, and its bytecode. From here, I have to implement generic types, defer and error handling and the compiler will be done! Or at least for now. Hopefully my next devlog isn’t in a month.

Devlog #6
The compiler kind works! It can parse in source code similar to the first image, and spit out IR at this point. I still have to implement some more language features, mainly match statements, and custom types, and implement IR->Assembly translation. Sorry for the long gap between devlogs, the midterms were quite bad. The stack system was also fixed.

Devlog #5
The graphics subsystem is finally done! I’ve integrated it into the device system, and now you can render sprites, layers, and mode-7 style graphics from the assembly code. I’ve also further expanded the capabilities of the executable builder, now it supports symbols for each function that’ll be initialized upon running that function, and I’ve reworked a few internal systems, mainly the data tagging system, so now the VM supports 32bit and 16bit ints, and 32-bit floats. The main thing I’ll tackle next is redoing the VM’s stack system, as currently any data type can be pushed on and off, with no tagging, so accessing the stack from a ptr is a bit messed up. That devlog will probably be in a while tho, as I’m burdened by midterms.

Devlog #4
The graphics engine kinda works now! See the demo below.

Devlog 2.5
I forgot the executable structure photo from the last devlog, so here it is.

Micro-16 Devlog #2
The loader works! We can now load executables, which are structured as shown in the first photo, from disk (A virtual one at least), into memory, and execute them! The driver system was also refactored to be more modular, and I implemented the audio system. We have 4 square wave channels, 2 triangle, 2 sample channels, which support loading wav files into, and 2 sawtooth channels. I’ve included the system diagram (which I forgot last week, sorry), a concept logo(sorry for it being so blurry, I forgot to upscale it) and the code for a test executable in the image gallery. The next major component to work on will be the graphics system, and it seems that it’ll take quite a while until that is done, so see y’all in a week!

Our first devlog! Up until this point, I’ve mostly worked on the inner workings of the interpreter, because, as this project is aiming to be a better verion of the Atto-24, having a strong core to stack more functionality on is pretty important. At this point, we have all arithmetic, stack, memory, function call, and IO instructions implemented. Since Micro is designed to allow for multiple games on one “cartridge”, I’ve been working on a executable format which allows us to load in games and libraries at runtime, at specific memory locations chosen at build time. The actual executable format and processing code is done, I just need to finish writing the loader. That’s gonna be done by the next devlog probably, and from there, we will tackle graphics and the other external devices needed to make this system work. The photos attached show the general architecture, and a sample executable I’ve been using for testing. I have been working on this project for a little bit before flavortown started, which accounts for the codebase size.