rob.rho.org.uk

As mentioned in the last post, I’ve been happily using my Corne at home, and Manta when I go into the office, since building them. However, they present something of a false dichotomy; true split on one hand, wireless portability on the other. A couple of weeks ago, I finally got round to building a keyboard the parts for which have been sat on my shelf for a year, and that answers with the question “why not both?”.

The keyboard in question is the Ferris Sweep¹, “a version of the more fabulous Ferris by Pierre Chevalier that uses a daughter board like a promicro, elite-c, bit-c, nice!nano etc. instead of using onboard components.” The idea of making a keyboard using onboard components intrigues me, but for this project the ability to add a daughter board was more important, as it allowed me to use a pair of nice!nanos. These fit the de facto standard ProMicro form factor, but pack in a more powerful microcontroller, battery charging circuitry, and wireless. One of these gives the Manta its Bluetooth chops, but it has a additional trick up its sleeve — the two halves can also use Bluetooth (specifically, BLE) to talk to each other, resulting in a fully wireless true split keyboard.

The board is also nice and simple, taking advantage that each controller only has a small number of keys to worry about (17). This allows it to avoid the need for the diodes found on most keyboards. The only things you need to solder on are the switches, the controller, and a power switch².

The version I have is from Mechboards, where I get most of my keyboard stuff. There was some kind of mixup with their variant, meaning that it’s not completely equivalent to the standard ones. This was easily worked around with a couple of questions on their excellent support forum, and the silver lining is that it shows off the more interesting side of the nice!nanos.

In terms of switches, you can get variants of Sweep that support the de facto standard MX switches, but I decided a better fit would be Choc low profile ones. This dramatically cuts down the choices available: while there are hundreds of MX-compatible switches from dozens of manufacturers, covering every conceivable style, material and price point, there are very few Chocs beyond the (perfectly reasonable) options offered by Kalih.

The ones that caught my eye were the Sunsets, a relatively new entry manufactured by Kalih but designed by LowproKB. “The first truly new Choc switch in years” claimed to achieve a decent tactile feel despite the short travel. I’ve been enjoying the Durock Teals I used in the Manta, so I decided to give them a go. I paired them with some simple blank POM keycaps. The are nice and neat, and feel great, but more than one person has pointed out that in white they look like Rennie indigestion tablets.

The kit came with FR4 switch and bottom plates (the same material used as the base for the PCB), but I opted to skip these, soldering the switches directly to the board and leaving the bottom open. One wrinkle that I encountered with this plan was that the rubber feet that came with the kit, which need to be positioned right at the edges of the board to prevent it rocking as you type, had to overlap the pins of the switches. This meant they didn’t sit flush, and more worryingly pushed at the switches, which doesn’t seem great for long term reliability. I worked around this by replacing them with smaller feet that fit in the gaps between pins. The result, in combination with the low profile switches and keycaps, is a very svelte keyboard, around half the height of the Corne (left) and Manta (right):

So, how does it all come together? Pretty well. The portability is fantastic, and the Sunsets deliver on their promise of tactility. It took me a little while to get used to the more aggressive stagger, particularly on the outermost columns, compared to my other keyboards, but once I’d got the hang of it the overall typing experience is superb.

So, have I reached keyboard nerd Nirvana? Is this the fabled End Game? It actually might be. I’ve been using it full time both at home and the office for a couple of weeks, and it fills both roles admirably. There might be tweaks here and there, but it’s close enough to what I’m after that I may not need to make another conventional keyboard³.

Of course, that doesn’t mean I’ll not make a keyboard at all. Even leaving aside elaborate joke projects, there are plenty of interesting directions to explore — one-handed keyboards, stenographic keyboards, built in pointing devices. My immediate next project is more prosaic, however: I’m going back to the start. The RGB lighting on my Corne is broken, due to the failure of my less-than-robust bodging around my inexperienced soldering. I picked up a replacement PCB in a Mechboards sale a while ago, so will rebuild at least the left half with the benefit of more experience. After that, who knows?

ZMK firmware here.

Believe it or not, I do actually use the weird keyboards I’ve made — the Corne at home, and the Manta when I go into the office. In spite of (or perhaps because of) the tiny number of keys they have, I can now type both more comfortably and faster than on a conventional keyboard. The thing that makes this possible is the layout — the arrangement of keys, and in particular key combinations.

I tweak this as I go, and it’s moved on quite a bit from the original layout I documented back in March last year. The QWERTY letters with the dropped P remains the same, and I’ve been really happy with the rest of the basic structure: the home row modifiers, the space-delete-enter arrangement, and the two layers behind the thumb keys. The contents of those layers, however, has evolved substantially.

The biggest change was to move the numbers. When I started out with these minimal layouts, I assumed that having the numbers across the top row would provide the smoothest transition from the more standard layout (this was also the logic behind sticking with QWERTY). However, I soon came to find this cumbersome, so decided to try out a numpad arrangement. This turned out to be a lot easier, and the learning curve I’d worried about never materialised.

It also clarified the purpose of the two layers. The “Num” layer (activated by holding down the left thumb key) contained arrows on the left half of the split, and a numpad plus a few mathematical symbols on the right half. The “Pun” layer was dedicated to punctuation, spread across both halves.

This arrangement served me well for many months, but a little while ago, I noticed that it had a weakness. Numbers needed two hands. While I’ve never been a big user of the numpad on 100% keyboard, the fact that I needed to have both hands on the keyboard to enter a column of figures started to grate.

The solution is simple; switch the layers on the right hand half of the keyboard. I’ve just got round to making this tweak, resulting in my current layout as shown above. The layers are now less logically consistent, but make physical sense. I’ve renamed them “Left” and “Right” to reflect this.

Other notable changes:

• I’ve dropped the single key Cmd and Enter on the second thumb keys; the Manta lacks these, and so I didn’t want to put anything significant on them.
• The Left layer has ⌘-Z/X/C/V on the corresponding letters, to give convenient one-handed access those shortcuts
• I’ve added preliminary support for Mouse Keys (on QMK only for now).
• On the implementation side, there’s more consistent use of transparency on the modified layers.

The layout is personal to me, but if you want to borrow some ideas, or see how things are done, the QMK and ZMK configurations are available on GitHub. I’m certainly not done yet, but I’m pretty happy with the current state of things. If you have a keyboard where you can perform this kind of customisation, I encourage you to give it a go.

Last weekend, we visited the Centre for Computing History in Cambridge with my brother and nephew. As we walked into the main room, children running ahead, one of the exhibits caught my eye. It was unfamiliar, but there was something about it that rang a bell. It turned out to be an Acorn Business Computer, a machine I’d read about but can’t recall seeing in person before. After a moment, I realised what I’d recognised. The keys were the same colour and font as those of another machine, one that’s apparently so deeply embedded in my psyche that I latch on to minor details of it from across the room.

The Acorn Electron was launched 40 years ago today. We got one a year or so later, when I was six, and it’s fair to say that it had an outsized influence on my life, starting an interest that turned into a hobby and then a career, and providing a springboard for learning and playing. It was, of course, replaced by a succession of more and more powerful machines, but it was the first. Given that history, there’s no way I can possibly be objective about it. So I won’t.

I’ve previously described the Electron as being for kids not rich enough to have a BBC Micro but not cool enough to have a Spectrum, and I think that stands up. The Electron was intended to provide the essence of what made the Beeb the Beeb at a price closer to that of the Spectrum. While it had to drop some features (notably Teletext mode and multichannel sound) and ran slower than its fuller-featured sibling, it did a pretty good job of retaining that essence. In particular, high resolution graphics¹ and the superlative BBC BASIC (with built-in assembler!) were present and correct. Somewhat counterintuitively, this might have been the reason behind its lacklustre reception compared to its rivals.

Both the BBC Micro and Spectrum trace their origins to the BBC Computer Literacy Project². The national broadcaster, in conjunction with the government, saw the need to inform, educate and entertain people about the new “computer” things that were going to be so important in the 1980s, and wanted a reference model to provide a solid basis for this programme. Several companies bid for the contract, but the field quickly narrowed down to two Cambridge companies: the already successful Sinclair, and the fledgling Acorn³.

Sinclair had a solid track record of introducing sophisticated technology — pocket calculators, digital watches, miniature TVs — to the consumers. In particular, the ZX80 and ZX81 brought microcomputers to the mass market at an unprecedentedly low price (£99 for the pre-built ZX80, down to £49 for the kit form of its successor). In all cases, the genius was in figuring out a coherent set of functionality that would provide value to regular users, and could also be implemented within the constraints of technology and cost.

In contrast, Acorn seem to have been more focussed on making a “real” computer, and then scaling it down to fit the consumer market⁴. With the Proton (renamed the BBC Micro when they won the CLP contract), they succeeded spectacularly. While it was expensive compared to other home computers, its capabilities were both broader and deeper. Not only did they have a long life in UK schools, they found some surprisingly serious applications. When I was an undergraduate in the late 90s, I’d still see them occasional, running scientific equipment or the information screens dotted around the Computer Lab.

However, in the Electron, Acorn arguably pushed the idea too far. The compromises to get the Electron down to a more Spectrum-like price point meant that it could do much of what its elder sibling could do, but it did it slower (often much slower). This compounded a weakness of the Beeb that was much more critical for the home market; games.

Like the Beeb, the Electron supported full colour, high resolution graphics — any pixel on the screen could be set to any colour in the palette. In contrast, the Spectrum split the screen into 8x8 blocks, each of which could only show two colours (foreground and background). This is clearly a less flexible approach, and leads to the much-maligned colour clash, but it has the distinct advantage: there’s far less data to shuffle around. While this doesn’t matter much for static pictures in an educational or scientific application, it’s critical for animation. The Electron’s slow RAM access makes fast, colourful graphics a challenge. The Spectrum’s design may be less general, less like a serious computer, but it’s well targeted at a key thing that home users want to do. The issue wasn’t insurmountable — there were plenty of fun games to be had, from Snapper to Repton to The Last Ninja — but the additional challenge, combined with the smaller market, meant there was never the creative explosion that happened for the Spectrum.

In an odd kind of way, this limitation plays into an an area where the Electron really did do well; learning about computers themselves. If the games are thin on the ground, you may as well investigate how the machine itself actually works. Here is where the Electron shines. Its design is logical and elegant. BBC BASIC provides a lot more structure and capability than the dialects on other home micros, and the built in assembler provides an easy on ramp to program the 6502 directly. It may not be as much of a “real” computer as the BBC Micro, but it’s enough of one to provide a solid jumping off point. It did so for me, and thousands of others.

The Electron was not a commercial success, both for the reasons suggested above and external factors having nothing to do with the machine itself⁵. It was one player amongst several, and before the decade was out all had been eclipsed by US behemoths like IBM, Commodore and Atari. Acorn faded, and you’d be forgiven for thinking that its influence was long gone.

Forgiven, but wrong. The MacBook Air on which I’m typing this is, in a distant but direct way, a descendant of the Electron we got that Christmas. But that’s another story.

The above image is taken from the box art of the Electron’s packaging, shown here. This was the version that we got for Christmas 1984, but this particular one is one I picked up on eBay a few years ago.

I’ll finish with another nod to the Centre for Computing History. They not only provided the setting for the opening anecdote, but also a fantastic resource for more information about the various vintage computers scattered throughout this post. They do some great preservation and education work, and their museum in Cambridge is well worth a visit.

The first keyboard I built had noticeably fewer keys than a standard, or even laptop one — broadly speaking, a “40%” in keyboard circles. My next one went even further, a 30%. This raises the question; how minimal could I get? In answer to that, I present the One Percent keyboard:

But, you may ask, how can you type anything on a keyboard with only one key? Fortunately, that was a question answered almost two hundred years ago:

As you can see in the video, you can plug in a real Morse key, or use the built-in MX switch. Either way, the interpretation of the morse code happens on the device — as far as the computer is concerned, it’s just a standard USB keyboard. Perhaps not the most practical one in the world, but a keyboard nonetheless.

The genesis of this project was a long while ago, when I came across this project. I thought it’d be a fun way to take the next step from building kit keyboards, and also a good reason to try out the Raspberry Pi Pico. I acquired a Pico and some Adafruit NeoKeys, but by the time they had arrived I’d decided to go off-piste and try something a bit different. Before too long, I had a breadboard prototype:

In addition to the Pico, the NeoKey provides a hot-swap socket for a standard MX key switch. It also includes a NeoPixel for RGB illumination. I also added a small (128x32) OLED display to provide feedback while typing; this makes it a lot easier to understand how the board is interpreting your taps, especially for someone who doesn’t know Morse code (like me).

On the code side, I went for CircuitPython — it’s well supported by the RP2040, and comes with libraries to support NeoPixels and USB HID devices. Moreover, the trivial transfer-and-run approach allows for very rapid iteration, and makes it a joy to use.

The process of writing the software was an interesting exercise in unlearning a few decades of instinct. Initially, I was pleasantly surprised to discover that CircuitPython supports async/await, and I immediately started to use these to allow fairly straightforward code that would nevertheless let other stuff run when necessary. It was only later I asked the in-retrospect-obvious question; what other stuff? I’ve spent so long working in multitasking environments, where a single logical processor will be running dozens or hundreds of things concurrently, that I’ve internalised that as a key part of my mental model of computation. Programming a microcontroller for an embedded device is more like programming an 80s home computer — you’ve got the entire thing at your disposal, and it’s up to you what you do with it. This reminder alone made the project worthwhile.

At this point, both hardware and software were working. However, I didn’t want to leave this as temporary prototype to be disassembled the next time I wanted to reuse the parts. I wanted it to be something more real, or at least more permanent. To this end, I decided to use the Tiny2040 from Pimoroni. This is built around the same RP2040 processor as the Raspberry Pi Pico, but on a smaller board (with fewer external connections, but not in a way that affects this project).

A few tweak to the software and everything works as expected. I also added a 3.5mm jack to allow a real Morse key to be added. I came across the Kanga Nano Key on eBay, and it does the job nicely, but any other key (modern or antique) should be easy to wire up.

Unfortunately, a variety of other commitments meant I had to shelve the project for while, but a couple of weeks ago I found time to pick it up again and do the final step of soldering it all up on a protoboard, as seen at the top of this post. Not the neatest work, by any means, but it’s functional, and I’m more than happy with the result.

I’ve put the code on GitHub, along with schematics. I wouldn’t hold it up as a great example of style, but if you’re looking to learn too then it might be useful, if only to make you feel better about your own progress.

Overall, I’m really pleased with how the project worked out. I don’t make any claims to originality — there have been plenty of previous morse keyboards and similar projects — but my aim was to try something new, and to learn things, and I certainly have. My next build is likely to be more run-of-the-mill, but I’m sure I’ll return to this kind of thing before too long. However long that takes, I’ll have a tangible reminder of the possibilities.

One of the most striking things about the Apple Vision Pro announcement is the price: $3499. This is even higher than the rumoured $3000, a whopping seven times the projected price of the Meta Quest 3, and has been cited as a reason that the Vision Pro will fail. While there are several reasons that might lead to it not taking off, I don’t think this is one of them.

That’s not to say that the price isn’t astronomically high, and out of reach of the vast majority of people. It is. However, as Steve Balmer famously pointed out at the time¹, so was the iPhone’s launch price. That product went on to do reasonably well. The swingingly expensive initial version seeded the market, and acted as a beachhead for the far more reasonably priced iPhone 3G to achieve more widespread success a year later.

The main challenge that the Vision has with following that trajectory is bringing the price down; while the hardware in the first iPhone was pretty impressive for the time, that in the Vision is even more complex, along more axes. Moreover, even if they managed to halve the price, it’s still over $1500 — closer to a MacBook Pro than an iPhone. Given what’s inside, that’s not that surprising, but it will still limit the market.

This perhaps explains Apple’s emphasis on productivity (i.e., Mac-like) users, but that’s also a potential problem. While the iPhone essentially additive, the Vision Pro is looking to replace existing devices — the Mac for work, and the iPad for consumption. Until the platform is established enough that people will buy one instead of replacing their Mac or iPad, that’s going to mean a slow burn.

This, rather than the price per se, seems to me to be the biggest risk for the success of Apple Vision as a platform. The longer it takes to be established, the more chance for another player (maybe Meta, maybe someone else, maybe even an open platform) to come in and define the market. If that happens, Apple Vision would be relegated to a niche. Apple will no doubt do everything they can to ensure that doesn’t happen, but I expect there’ll be quite a few who will be pushing to ensure that it does.