Still Racing The Beam

30 Jul 2022

Pitfall on the Atari 2600

Atari recently celebrated its 50th anniversary, which reminded me of the excellent Racing the Beam, by Nick Montfort and Ian Bogost. It’s a fascinating exploration of their iconic home console, one of the first with interchangeable games (in the form of cartridges): the Atari 2600.

From pull quote on the dust jacket:

William Morris famously opined “You can’t have art without resistance in materials.”

The 2600 provided a lot of resistance. Architecturally, it offered little more than was necessary to implement Pong and similar games — two player sprites, two bullets, and some very low resolution play fields. It had 128 bytes of RAM (not kilobytes, bytes), and only 2KB of ROM in each cartridge.

The basic capabilities of the machine topped would, at first glance, seem to top out with things like Combat (which is, admittedly, quite fun). However, later developers (both withing Atari and elsewhere, notably Activision) pushed past these to produce far more sophisticated titles than the original designers had ever envisaged. Pitfall, pictured above, is a prime example. Another is Garry Kitchen’s truly remarkable effort to port Donkey Kong

This involved a deep understanding of how the machine worked, including the dynamic behaviour: when everything happened. A key technique was changing what was drawn (the playfield and sprites) while they were being drawn. This was usually done in the split-seconds when the cathode ray had finished one line and was returning back to the start of the next, hence the name of the book: the code was literally racing the beam.

In my previous job, we created a product that solved a very similar problem. When translating a digital circuit from the idealised world of 1s and 0s into the messier domain of physical wires and voltages, it’s imperative that a signal is steady at its intended value by the time it’s needed (setup), and it stays that way until everything that depends on it has stabilised (hold). This is a problem that gets harder, rather than easier, as technology improves – newer, smaller manufacturing processes are both more variable and can run at higher speeds, leading to tighter and tighter constraints. Our software would adjust circuits until they met these constraints, performing the job that the Atari programmers were doing at a far larger scale.

These days, I’ve moved away from silicon and into the cloud. When creating distributed applications, one of the primary things you have to bear in mind is latency, and which data can be where, by when. Networks get faster, but this is fundamentally limited by physics – the speed of light. We’re still racing the beam.

Flying Solo

3 Jul 2022

After a relatively short public beta, GitHub Copliot is now available to the public. While it’s certainly impressive, I won’t be adopting it (or similar services like Amazon CodeWhisperer) any time soon, for a couple of reaons.

One concern is the licensing implications. These systems exist to insert non-trivial chunks of code derived from other sources into the code you’re working on. There’s no guarantee that such inclusion is permitted by the licence for those sources, so this potentially opens users up to significant legal risk. While there’s some informed analysis suggesting it’s not violating copyright law (in the US, at least), it’s very early days, and the true situation is only likely to become clear when cases end up before a court.

Microsoft, and so presumably by extension GitHub, have phalanxes of very smart lawyers on board, and I have no doubt that they’ve thoroughly understood the risk they’re taking. However, they’re also very well resourced, and will have been mainly considering the effects on themselves rather than everyone else. Just because the HMS GitHub is sailing confidently into the storm, it doesn’t mean it’s a good idea to hop into your canoe and paddle after them.

More fundamentally, frictionlessly dumping code snippets that you don’t understand into your editor seems to me to be a very bad idea. Copilot may save on some typing, but at the risk of not knowing what you have at the end. Brian Kernighan said that debugging is twice as hard as writing a program in the first place. Copilot only addresses the second, while robbing you of the context you need to do the first.

I’m not against the idea of AI assistance — that would be an odd position to take for the CTO of a company aiming to provide exactly that in the context of surgery — but Copilot and its ilk seem to me to sit in a kind of coding uncanny valley. The results are convincing enough to be dangerous. In time, the performance of these tools will get even better, and more importantly we’ll get to grips with how humans and AI can work on code together. Until then, I’ll be flying solo.

The Ratio

28 May 2022

If you find yourself needing to entertain small (or indeed not-so-small) children, it’s useful to know that there are a few things that almost always provide delight vastly out of proportion to their cost. Bubbles, balloons, face paints. Playing with technology is typically an expensive hobby, but here too there are exceptions. In particular (and I’m far from the first to make this observation), microcontroller kits offer a stupendous ratio of money to fun.

In some ways, with their limited capabilities but openness to tinkering, they feel a lot like the home microcomputers of the 80s. However, those were still relatively expensive — even the famously cheap ZX Spectrum was comparable to a decent iPad or Xbox today1. In contrast, the Rapsberry Pi Pico starts at £3.90, literally a hundred times cheaper. If you fry it by wiring it up wrong, or want to permanently embed it into a project, no problem — just get another. This removes a big obstacle to messing around.

Another obstacle has traditionally been the accidental complexity of working with them, but no more. The Maker community and the companies around it — Arduino, Adafruit and many others — have done fantastic work on the tools and development environments, vastly reducing the distance between having an idea and seeing it work. For me, the apotheosis of this (so far, at least) is CircuitPython (and the closely related MicroPython):

  1. Plug your development board in via USB, and you’ll see a drive containing a file called code.py
  2. Edit that file and save the changes
  3. There is no step 3

Removing all of the tooling complexity makes coding for hardware as easy making stuff appear on the screen, and bridges the gap between the two. For someone who’s always been on the virtual side of that fence (even while writing tools for the physical side), it’s a refreshing expansion of horizons.

My only regret is that I’m late to the party. The girls and I have played around with BBC micro:bits and the Meowbit, and done a bit of GPIO stuff with the Raspberry Pi, but the real gateway for me was my recent interesting in keyboards. Now, though, I’m hooked, and if you enjoy messing around with code I strongly suggest you follow my lead and give it a go. After all, what have you got to lose? It’s cheaper than a pack of balloons.

  1. The ZX Spectrum was £125 when it launched in 1982, equivalent to about £500 today. At time of writing, an Xbox Series X is £450 (if you can get one), and a 64GB iPad Air is £569. [back]

Oops I Did It Again

2 May 2022

Manta keyboard with various objects for scale

To make one weird custom split keyboard may be considered unfortunate. To make two starts to look like a rabbit hole. Nevertheless, that’s where we are.

Even before I’d completely finished my first keyboard build, I was already looking for ideas for the next. Out of several contenders, the one that caught my eye was the Manta kit. This is a very compact single-piece split keyboard kit that takes the de facto standard Pro Micro controller board. It occurred to me that pairing it with the pin-compatible nice!nano would result in a neat and very compact wireless keyboard to complement my Corne. After vacillating a little about whether I could commit to such a restricted layout, I ordered the bits as a birthday present to myself.

As it happened, I should probably done a bit more research. Once I came to put things together, I realised that the Manta wasn’t actually on the list of supported hardware in ZMK, the preferred firmware for the nice!nano. A little searching suggests that I was the first person to try this particular combination1. This was more ambitious that I was aiming for on my second build. I felt like a challenge, though, so I pressed ahead.

The Manta doesn’t have the wealth of easily available resources as more popular kits like the Corne, but I did manage to track down a schematic showing how the pins are wired up (in particular, the rows and columns of the matrix). In combination with ZMK’s excellent new shield documentation2, this was enough to get the hardware up and running.

(One aspect worth mentioning is ZMK’s interesting tooling approach; while you can download a tool chain and build locally, this isn’t necessary if all you’re doing is adding new configurations. Instead, they have a very straightforward setup based on GitHub Actions. This builds the desired firmware on each change pushed to GitHub, and you just download the resulting artefact to flash to the controller. This sounds baroque on paper, but works really well on practice and removes a significant barrier to getting started.)

Manta keyboard with an iPad Mini

So far, I’m pretty pleased with the result. I’m using essentially the same layout as for my Corne, so the main differences are physical — the proximity of the two halves, and in particular the higher position of the thumb keys. The latter took a bit of getting used to, and isn’t quite as comfortable for me as the Corne’s more spacious arrangement, but it seems workable and a reasonable trade-off to reduce the overall footprint.

I wanted to try a tactile switch this time around, and went with Durock Tactile 67g Teal. I’ve not installed a heavier switch for the P key yet; I thought that the reasonably high activation force combined with the perceptible bump would mean it wasn’t necessary. So far this seems to be the case, but I’ll need to use it more to be sure.

The feel of the switches is great, and I think I prefer them over linear. I’m definitely noticing the noise, though — while not too obnoxious, it’s certainly a lot louder than the Silent Ink Blacks in my Corne. For my next build, I’ll be looking for something in between the two.

Yes; “next build”. The Corne is a good home keyboard, and the Manta joins it as a fine portable one, but there are more things I want to try, both for the pleasure of making them and the pursuit of elusive perfection. The rabbit hole goes on for while longer yet.

Manta keyboard with various unhelpful objects for scale

I may write up a build guide in due course, but if you want to try the Manta with a nice!nano my shield configuration is here.

  1. If you know differently, please let me know. [back]

  2. “Shield” is a term originating in the Arduino ecosystem; in ZMK, it specifically means a the board that carries the actual switches, and connects to a daughterboard containing the controller (the “board”) as opposed to having a controller built in. In this case, the Manta is the shield and the nice!nano is the board. [back]

There's No Place Like Home-Row

31 Mar 2022

My last post describe the process of figuring out how to lay out the letters on the Corne in a way that will work with my fingers. This works fine for MonkeyType, but isn’t quite sufficient for using the keyboard day to day. There are a few other things you need to cover. Before diving into the details, here’s the layout:

My full Corne keyboard layout (at time of writing)

The first thing that leaps out at you is the keys that aren’t used — along with the keys above and below the repositioned P, I’ve not assigned anything to the outermost (“pinky”) columns on both sides, or the outermost thumb keys.

This may seem like an odd choice, given that the keyboard doesn’t have that many keys to start off with. However, my experiments with the letters convinced me that reducing finger movement is a good thing to prioritise, even at the cost of some complexity.

Speaking of complexity, an explanation is in order for anyone not familiar with layered layouts. This basically means that additional modifiers (beyond the usual shift, control and so on) are used to pack multiple logical keys on to the same physical one. The blue legend shows what you get when you press a key on its own (almost exclusively letters in this case), the green when you hold the “raise” modifier, and the red when you hold the “lower” one. As a concrete example, to type an opening parenthesis “(“ you hold down “lower” and press the key that would usually type a “G”. This all sounds convoluted, but you get used to it surprisingly quickly1.

For everything down to a 60% keyboard2, layers alone are sufficient. However, when you get down to 40% (then reduce that to effectively 30% by ignoring ten of the keys), you run into a problem. Where do you put the modifier keys? There are various options, but the one that appealed to me was home row mods.

This approach takes advantage of the tap-and-hold functionality available in QMK and other firmware, which lets you double up the functionality of a key. There’s a lot of subtlety in the details, but basically a short tap has one function (e.g., typing an “F”) while holding the key down has another (e.g. the shift modifier). Home row mods puts the usual modifiers (shift, control, opt/alt and command/win) on to the home keys. This has the major benefit of placing them in the most accessible positions on the keyboard.

The main cost of home row mods, and layers in general, is cognitive load. Rather than just having to move your fingers to the required position, you need to figure out the combination (and, in some cases, temporal sequence) to get the effect you want. This can, of course, be learnt — people learn to play the piano, fly jet fighters, and use Emacs, after all — but it implies a significant learning curve. For something that has, for many of us, has been effortless for years or decades, it can be a bitter pill to swallow.

Nevertheless, the layout is now complete, which means I can use it for day-to-day work, and I’ve been doing so on-and-off for a couple of weeks now. Over the course of that time, I’ve made a couple of minor adjustments — most notably adding the extra Cmd key on the right to make one-handed use of the CUA keyboard shortcuts easier — but I’m generally pretty happy with it. I’m still climbing that ferocious learning curve, but it’s getting easier and I feel like it’ll be worth it in the long run.

This is definitely not the final endpoint for this layout. I’m sure there will be plenty of further tweaks and changes as I use it more. The basics are solid, though, and I expect to steadily approach and then surpass my proficiency with a standard keyboard. Moreover, I’ll have fun doing it. Learning a new skill is always stimulating, and I’m enjoying the mental gymnastics.

The QMK implementation of this layout is available on my GitHub account, if you want to look into more details.

  1. As is often pointed out, this isn’t a million miles away from how the soft keyboards on modern smartphones work, and plenty of people adapt to those just fine. [back]

  2. In the custom keyboard world, sizes are described as the rough number of keys expressed as a percentage, as a full keyboard layout has about 100 keys. So, 60%, a common choice for compact keyboards that takes that standard layout and drops the numpad, F keys, navigation cluster and arrows, has around 60 keys. [back]

This site is maintained by me, Rob Hague. The opinions here are my own, and not those of my employer or anyone else. You can mail me at rob@rho.org.uk, and I'm robhague on Twitter. The site has a full-text RSS feed if you're so inclined.

Body text is set in Georgia or the nearest equivalent. Headings and other non-body text is set in Cooper Hewitt Light. The latter is © 2014 Cooper Hewitt Smithsonian Design Museum, and used under the SIL Open Font License.

All content © Rob Hague 2002-2019, except where otherwise noted.