This is part of the Writing a Game Boy emulator in Go series.

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?

Read more »

This is part of the Writing a Game Boy emulator in Go series.

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. Implementing the memory instructions was probably a bit more involved than, say, the arithmetic ones but I thought that if I could get the memory instructions right the others would follow easily.

Read more »

This is part of the Writing a Game Boy emulator in Go series.

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.

Read more »

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.

Read more »

I recently went back to my old bootcamp, Founders and Coders, to give an alumni talk on The Internet.

Bootcamps have the difficult task of condensing an immense amount of information into a short space of time. The focus is on getting people to the stage where they can be productive developers. Inevitably this means that some topics get delegated to the “you’ll pick this up along the way” category. At Founders & Coders we use Heroku for deployment in order to abstract away the infrastructure details and allow students to focus on their development skills.

Read more »

After four posts we still haven’t produced any sound. Let’s change that! I’m going to start with the aural equivalent of “Hello, world!”, which is changing the volume of the output. I’ll also go through a refactor I did to allow each effect component to be linked to multiple parameters.

You can find the code for this post here.

Setup

So, I’m using the Audio Injector stereo hat to handle audio input and output on my Pi. There are plenty of Pi sound cards available but this one had good reviews at a reasonable price. Setup is pretty straightforward, requiring nothing more than connecting it and running a shell script. Straight away I could play tracks through my Pi using sox.

Read more »

Hello! I’m a software engineer based near Sheffield, UK.

I have a decade of programming experience across the full web stack. For the last four years I’ve worked at Amazon building the Prime Video app on your TV, using Rust and Typescript/React. It’s hugely rewarding due to the technical challenges of Amazon’s scale and the performance constraints of living room devices. I’ve led efforts to adopt AI internally and have built LLM tools that are used across Prime Video.

Read more »

Having updated the Arduino code to output more complex messages, we now need to update the Pi app to be able to understand these messages. Remember that we’ll have a set of audio effect components running, each linked to a physical control made up of a potentiometer and button. The task that now befalls our Pi app is to parse the binary messages coming across on the serial and then dispatch the message to the correct effect component.

Read more »

So far in the blog series we’ve set up the basic hardware structure and got everything talking. The next step is to expand the Arduino code so that it can handle multiple controls and send more useful messages.

Remember that each virtual effect component running on the Pi will have a single potentiometer and button for control. I’m working on the basis that I’ll end up with six effects simply because my Arduino only has six analogue pins but the code will be able to handle more.

Read more »

Continuing my theme of ’things to do with a Raspberry Pi involving music’, I have turned my Pi and external HDD into a little NAS. My iTunes library now sits on the HDD and is shared over Samba to my laptop. The cool thing about this is that it makes it possible to access my music library from anywhere over the internet. In the age of Spotify and other streaming services this is a lot less cool than it would have been, but it’s still pretty useful if you value having control over your music files. I have tried two approaches, each with different pros and cons.

Read more »