Tale of emacs, tears and credit card fraud. Previously I wrote about how to develop ideas for passive income. Now that you’ve got your idea, what happens? In this post, I’ll describe the process that ended up with ‘The Computer Science Book’. Writing an entire book seems an impossible task when it stands before you. So many, many words! I hope that pulling back the curtain of the sausage-making factory [link both similes to youtube videos] will help show you how to plot a course.

The Computer Science Book has reached version 1.0! It’s a complete introduction to computer science for bootcamp graduates and self-taught developers. My hope is that the book will: Inform and inspire future generations Demonstrate that I can do computer science Generate passive income One of the recurring ideas in the book is that huge, seemingly impossibly complex things are easier to understand if you break down them into simpler things.

This post is a guide to setting up a bare-metal Kubernetes cluster on Hetzner Cloud. Why? Well, previously I had a couple of applications running on a Google Cloud virtual server. They were running on FreeBSD because my original plan had been to use it as an opportunity to learn a bit about FreeBSD. This failed because I’d forgotten that the end goal of setting up a server is to interact with it as little as possible.

One of my aims with Goboy was always to deploy a web-based version using Webassembly. It actually turned out be remarkably straightforward (see here). The first step is to build for the Webassembly architecture. Following the instructions in the Go repo, the build incantation was simple: GO111MODULE=on GOOS=js GOARCH=wasm go build -o builds/wasm/goboy.wasm cmd/goboy/main.go That ran in the browser using the helper JavaScript specified in the Go repo. Ebiten, the game runner library I’m using, supports Webassembly and so things were painless.

Goboy is nearly completion – well, as complete as a Gameboy emulator can ever be. My wife was volunteering in Phnom Penh for a few weeks and I had intended to use the time to implement the audio unit. As things turned out I ended up spending a few weeks chasing down various bugs. There is still some errant flickering sprites that I haven’t had time to debug yet and the audio remains unimplemented.

Goboy has reached a major milestone – a working display! Recently, my development process has been a bit unorthodox. My wife and I are spending this year travelling and so I only have bits of time between the many, many temple visits to program and blog. The display is the most complex single component of the Gameboy and, in my opinion, implementing it is pretty much an all or nothing job.

Finally the opcodes are implemented. I took the approach of getting all of the opcodes implemented and unit-tested before moving on to other components. In retrospect I wouldn’t recommend this approach because you go through a long period with nothing really to show for it. On the other hand, once the opcodes were done all I had to do was implement basic ROM loading and all of the blargg test ROMs would pass straight away, right?

The first tranch of instructions to implement are the various load and store operations. These are interesting to start off with because they obviously require some kind of memory model. The instructions themselves are quite variable. Some include immediate values, entailing variable-length instructions, some do complex addressing and so on. I spent quite a bit of time implementing these and refactoring what I had because I wanted to establish a solid pattern.

This is the first in a series of posts documenting my progress writing a Gameboy emulator in Go (imaginatively called Goboy). Sometimes it’s nice to write something that’s not a web app. My plan is more to track my progress and highlight interesting bits rather than create an in-depth guide to writing an emulator so these may be a bit scrappy and intermittent. I’m trying to take a fairly agile, one-instruction-at-a-time approach so there will probably be plenty of missteps and backtracking.

After the unprecedented success of making sound in the last post, it’s now time to actually process the input in some way. I’ll look at two types: fixed length and variable length. The basic idea of a delay is that you write the output into a buffer and then read it out again after some delay, adding the delayed output to the main output. This gets saved again and the process repeats, thereby creating an echoed fade out sound.