I was invited to speak at this year’s AI Engineer Europe conference on the topic of how to do AI-native engineering in big tech companies. Sadly, my extremely peculiar employer refused me permission to speak. So you’re reading this instead of watching a talk. If you’re trying to do meaningful, novel AI work inside a big company (not just Big Tech, with capital letters), it’s difficult because you’re being squeezed from two sides simultaneously.

Sheffield has always been the doe-eyed ingenue compared to the oi-oi-oi brashness of Manchester and whatever it is that Leeds is. Many are attracted by the climbing and the trees. Fewer are attracted by the local tech industry. I’ve worked remotely since moving to Sheffield four years ago, so I’ve never had much reason to care about the local scene. That changed when I was nearly made redundant and suddenly found myself asking: what software companies are actually based in Sheffield?

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.