mlog - because blog is so 2010
2024-01-01

intro

	In the spirit of re-inventing the wheel I've written yet another micro-blog static-site-generator. I'm beginning to think that masochism is a defensive trait of nerds, we intentionally put us through unnecessary, but voluntary, grind to help shield us from the inevitable involuntary grind that is ahead of us.

So, what will be the point of this mlog (that just rolls off the tongue, m-pause-log, mmmm-log). I need somewhere to dump diagrams, schematics and transcripts of some upcoming projects of mine. Side-projects, I won't post much about chimerasyntax here since I simply won't post much about chimerasyntax anywhere. What are these side-projects? Glad you didn't ask.

I've slowly been driving myself insane this last year. The grind to get chimerasyntax finished has been so intense that I haven't even been able to take more than an hour or two off during any given day. This meant that as soon as we began watching a movie I immediately either picked up a notepad and pen to plan work the next day, or started looking up todo-flagged items in reference manuals. At most I played jump-in-and-out style games, primarly guild wars 2 and fallout 76. They allowed me to jump in, kill 15 minutes of time when I felt burned out.. but then I'd immediately get stressed about wasting time and jumped out again.

Variation is needed. Since chimerasyntax is now at the point where I can restrict it to ten hours of work every day I find myself with more free time (for the time being). Thus it's time to do something beefier, yet related. Namely I'm going to attempt to resurrect my youtube channel. I have to do this since chimerasyntax will feature quite a lot of video content, eventually. Thus getting back into the swing of things, learning how the toolchain I used to use has changed, et cetera is somewhat work-related and I'm hoping it won't stress me out about wasting time. But what projects should I start with?

There's three I've been wanting to do for years now. They're going to be somewhat large but they will be passion projects. Let's go through them one by one.

cba-08

	cba8 is a virtual architecture I've been fiddling with for ages. The name is an extremely poor pun relating to a swedish computer called ABC-80 which is in fact the first appliance computer I ever interacted with. The first I ever owned was the Commodore 64. CBA-08 literally means "Can't Be Arsed 8-bit". Funny, right?
Anyway, I've designed a very rudimentary set of registers for interacting with the cpu, designed a minimal (and I do mean minimal) assembly language, written a compiler and emulator for it. What remains is writing the firmware for running on a microcontroller and.. actually doing something with it. I think I've decided upon the RP2040 since they're cheap, absurdly cheap and have decently cheap proto boards available.

This will allow me to use rust on an embedded project for the first time. I've been fiddling with it over christmas and made a christmas star using 2812 leds that faded from green to red. A very neat experience. Due to the schizophrenic nature of rust there are, naturally, multiple runtimes available. The base sync locked one named simply rp-hal which is the rust Hardware Abstraction Layer for the 2040 but also an async one named Embassy. I opted for the regular one after experimenting with both. I will have no need for async for an 8-bit architecture, virtual or otherwise. But I do heartily recommend looking into embassy, its design lends itself to power savings at only a slight performance cost and it's almost a small, multi-tasking operating system by default.

cba8 will allow two types of input, a 10-key binary instruction typewriter where you use 8 keys to form a byte, one key to accept it and another to go back. This will allow you to write machinecode directly into the stack, interpreted by a 20x4 character display. Secondly a regular keyboard.

Output will come in the form of the aforementioned character display, but also a serial output that will interface with a program that off-loads things like blitter chips, video memory, etc to a computer of your choice. If I ever feel frisky I might also extend that over the rp2040's wifi chip to allow cordless video output. I will not be making any crude vga or composite outputs since a) I don't want any more monitors than I already do and b) obsolete technology doesn't interest me.. which is why I'm making an 8-bit architecture?

amiga games

	I intend to go back and develop a couple of small games on the amiga platform, likely developed on and targeting the amiga 1200 but it should be runnable on a stock amiga 500. One of my greatest regrets was selling my original amigas (a 500 and a 1200) and then losing my entire software archive of all the code I ever wrote on the platform. It's bitterness incarnate. This will be an attempt to bridge that chasm of despair.

The amiga was the first platform I began using C on, a love-story that lasted for over 30 years until I switched to rust a couple of years back. Thus I will NOT be using C for this project. I will attempt to embrace languages unique to the amiga. Specifically I'm looking at AMOS which is, from what I can gather, the most loved implementations of basic. It seems really interesting and I haven't used basic since the c64 days.

There's a number of restrictions I will put upon myself. All code, audio and visual material has to be made on an amiga (or rather, an emulator). It has to be created with applications that are time period accurate and I must have had some interaction with them at the time. Fortunately I still have some software from my amiga days, namely a box of Easy Amos including the rather excellent reference manual. And a copy of Deluxe paint 3. Those should get me off the ground.

c64 games

	This will be exactly the same as the amiga bit only using a commodore 64. And to spice things up I intend to use the C64 maxi hardware emulator. I've had amazing amounts of fun clacking my way through interactive fiction games using it and from my (limited) testing it seems to be accurate enough to do actual development on it.

The C64 game will likely be a pure text game since unlike so many of my peers I have almost no fond memories of gaming on the c64. Even at the time I found the games to be crude, uninteresting and vastly less enjoyable than simply programming. With the one exception being interactive fiction. I credit the c64 with teaching me english not just through text games but also from being forced to learn english to read the reference manuals.

Same restrictions apply. The game must be developed on the c64 using period accurate software. Since I mostly coded in assembly on the c64 I'm going to attempt to use the built-in basic interpreter. It's said that you can't really make any serious games using it but a text game should be absolutely fine.

Being the obsessive person that I am I naturally have a reason for this. I've been working on a wasm based, register driven machine for multi-player interactive fiction. At some point I'll reserve a couple of weeks and finish it for chimerasyntax along with a webbased editor and such. Doing a text game on the c64 will allow me to try out concepts before I commit to them on the wasm side.

outro

	Well that was a wall of text. Appears I've missed blogging.. or mmm-logging, as it were.. more than I initially thought I had. I doubt anyone will read this, but if you have, salutations. At this point I'm too stressed about wasting time not working on chimerasyntax so I will end it here. But I guess this is my new blog. So, welcome!