rob.rho.org.uk

One of the notable things about the ZX81 is the tiny amount of RAM — just 1K¹ in the base configuration. When you take off system housekeeping and the screen memory, that only leaves a few hundred bytes for both programs and data. While you could squeeze some impressive things into that space, for most practical use you’d need to add an external 16K RAM pack.

In order to get the full 80s experience, I found a modern kit version on eBay. Before assembling and installing it, I wanted to make sure I could measure the amount of RAM in the machine, in order to do a before-and-after comparison and check that it was working. That’s where things got weird.

The ZX81 maps its ROM into the first 16k of address space, and RAM after this. The variable RAMTOP defaults to the highest writable address:

PRINT PEEK 16388+256*PEEK 16389

On my machine, this reports 17,408 (2¹⁶ + 1024), as expected. However, I also came across this old forum post with the following test program:

10 FOR N=16640 TO 65536 STEP 256
20 POKE N,0
30 IF PEEK N<>0 THEN GOTO 50
40 NEXT N
50 PRINT "MEMORY SIZE ";(N/1024)-16;"K"

This looks reasonable — it just tries to write to higher and higher addresses, and check that the value read back matches the one written. I ran it to get a second opinion, and it reported 16k. What was going on?

When I first got my ZX81, it came with a couple of the original, hand-written guarantee cards, one of which had the model number as “16kb”, so I wondered if I had some kind of unusual internal upgrade. However, opening it up confirmed that it was the normal configuration with a pair of 4 kilobit 2114-compatible static RAM chips. The pinout on these chips — in particular, the ten address bits — also provides the explanation of the above behaviour.

The ZX81 is mapping the second 16K of its address space to a 14 bit address to the RAM. If there’s 16K of actual RAM available, all of this works as expected. However, if you only have 1K, it just ignores the top four bits. The 16K address space maps to sixteen copies of the same 1K of RAM. This is easy to confirm by POKEing a value to, say, 17000, and then PEEKing 18024 to confirm the same value comes back.

One of the nice things about playing around with old hardware is that it’s simple enough that, when something odd happens, you can figure out why. More than that, it provides a window into the thinking and priorities behind the design. The ZX81 was laser focussed on simplicity and low cost, and the approach to RAM reflects that, providing headroom for expansion without adding any additional hardware or software. It’s not what you’d expect in a modern system, but that’s what makes it fun.

I’ve been an Emacs user for a quarter of a century. One of several derivations of the name is Escape Meta Alt Control Shift, due to the heavy use of modifiers and prefix keys, which makes it a great fit for my home row mods layout.

However, I’ve recently found myself spending more time in Visual Studio Code, which follows a different set of conventions. I could reconfigure it to be more Emacs-like, but these days I like to stick with defaults where I can to avoid having to maintain complex setups. In this case, the conventions tend to match those of the OS for the most part, but the debugger in particular uses the function keys (F1-F12). These were not supported on the previous iteration of my layout, so I set about adding them.

The change is relatively straightforward — an additional layer, activated by holding down a modifier key, that exposes the function keys on the right hand half of the keyboard, largely following the numeric keypad layout. One interesting point is where to put that modifier key. I ended up putting it in two places — on the second right hand thumb key, and as a hold modifier on the N key. The latter is needed for the Manta, which only has one key for each thumb, but I added it everywhere for consistency.

I’m not 100% sure about using the N key as a hold modifier, but in early use it seems to work well. If you want to take inspiration from the change, the updates are in the Github repos:

• QMK (Corne)
• ZMK (Manta and Sweep)

I’m a keen user of Readwise, a service that collects highlights you make in various places — Kindle, OCR from physical books, their own read later service — and presents them for review at spaced intervals. It’s a great way to get more out of your reading, and helps make connections you might otherwise miss.

Around the 40th anniversary of the Mac at the start of the year, I found myself reading a lot about the early history of the project, in particular the period when it was still being driven by Jeff Raskin. I noted down the following passage from Genesis and History of the Macintosh Project (in Stanford’s “Making the Macintosh: Technology and Culture in Silicon Valley” collection), but at the time only thought of it as one amongst many interesting details of the proto-Mac and Canon Cat.

The original concept gave the word processing program access to calculator ability without having to leave the word processing environment. Studies have shown that having a multiple level system is more confusing than a single level system. IBM’s Displaywriter has a similar but more primitive facility. This opens the way to office computation applications, and a further enhancement was proposed (at the instigation of Steve Jobs [This isn’t strictly true, but once he understood my idea of expanding a word processor to include all other functions, he said Like Visicalc? and I said that that was what I meant. But he often believed that any suggestion of his could not have been previously thought of and it was therefore politic at the time to give him credit for many things that other people had done.] ) to give the editor abilities similar to Personal Software’s Visicalc, except that the facilities would be embedded in the editor so that no file shifting would have to take place to use Visicalc results in a document or vice versa. [This whole concept was lost when Jobs took over running the software end of the project. Key Mac software team members resigned in protest. The new team was much more conventional-minded.]

When this came up for review this week, it tied back to Apple’s recent WWDC to add an interesting perspective; pretty much exactly the feature Raskin describes as being planned for the original Mac but dropped before shipping is making it to the platform with macOS Sequoia (and its sister versions of iOS and iPadOS). In any case, Math Notes is probably the feature I’m most looking forward to from the new releases, and I’m glad it’s finally made it in. What’s a decade or four between friends?

Passkeys seem like a good idea in practice, offering a potent combination of being both more usable and more secure than traditional authentication approaches. However, as has been pointed out many times elsewhere, current implementations fall short of this promise. For those of us who are already using robust authentication can make matters worse.

About five years ago, I decided to get a Yubikey as a way to improve the security of my online accounts, both personal and professional. At the time, I was mainly using a 2013 MacBook Pro, so went with a USB-A version. The first generation of Retina MacBooks Pro were great machines, and it served me well for a long time (allowing me to skip over the butterfly keyboard fiasco entirely), but eventually it came time to upgrade to something more modern. For the last few years, I’ve been using an M1 MacBook Pro (another great generation). I quickly switched most of my portable cables and accessories over to USB-C, but was still carrying around an adapter for the Yubikey. This week, I finally got round to getting a Yubikey 5C NFC.

My problem came when I came to add this to my AWS IAM accounts. The plural is significant; at work, I have seven distinct users across multiple AWS accounts¹. 1Password and Firefox Multi-Account Containers make wrangling this manageable, and crucially the same hardware MFA token can be used for different users. Unfortunately, when I tried to add the new Yubikey to the user, there’s now a single option covering “hardware MFA token or Passkey”, and Firefox is very eager to steer you towards the latter.

Fair enough, I thought — as long as the functionality is the same, I don’t mind them using a more recent standard to provide it. However, as I went through the process, it became apparent that sharing Passkeys across multiple identities on the same website is not straightforward. One user would work, but the other would hang on the MFA screen when trying to log in. It seemed like there was some kind of persistent session confusing it, but it’s far from clear. It’s also not clear to what extent the issue is with macOS’s implementation of Passkeys, Firefox’s integration with it, or AWS’s use of them. Wherever the issue is, though, it breaks my day-to-day workflow.

After a bit of experimentation, I managed to work around the problem by going to about:config and setting security.webauthn.enable_macos_passkeys to false. This allowed me to add the new key as an old-fashioned MFA token, and everything works as it did before. Once the key is added, you can set that setting back to the default true, if you want to use Passkeys in other contexts.

To end on a positive note, another change that AWS has introduced in the years since I got my first Yubikey is the ability to add multiple MFA methods for a user. This is useful for backup, and also means I can leave my old key plugged into my desktop setup, and avoid fishing about in my pockets when I’m working at home. A device-based Passkey would be another good addition to this setup, as long as it actually did the job.

I remain pretty optimistic that Passkeys will ultimately be a step forward in an area that’s increasingly important. However, my experience over the last few days confirms what I’ve heard: it’s early days, and there’s a lot of work still to do.

A big and bitter-sweet change yesterday; Cydar has moved out of Bulbeck Mill.

A few weeks and ten years ago, I started work at Cydar, and went from working in a perfectly nice but fairly generic Business Park office to something very different.

There’s been a mill on the site since Roman times, but the current building dates from the early 19th century. As well as a mill it’s been a medical instruments factory, and more recently a photo gallery and yoga studio. The ghosts of these latter uses were still very much in evidence when I arrived, in particular in the floor-to-ceiling mirrors covering most of the walls on the first floor.

At first, the furniture was a bit of a hodge-podge, including not only a large desk made from an Ikea wooden kitchen countertop, but sofas, chairs, and a ping-pong table (generally used for meetings, rather than actual ping-pong). For a while, there was a baby grand piano in one corner, though I don’t recall anyone playing it.

Over the years, the furniture and fixtures and fittings became less esoteric, but the ancient building still made itself felt. Alas, as the company has grown and changed, and the kind of work we do has become more varied, it became increasingly hard to fit the two together. The time had come to move on.

One of the things I’ll miss most about working there was not the building itself, but the surroundings, and in particular the nature. We’d regularly see squirrels and foxes, egrets and swans, herons and kestrels. A kingfisher used to hide in the tree directly outside the window opposite my desk, and if you were very lucky you might catch a glimpse of it fishing in the millpond. Occasionally an otter would swim by. This year a pair of red kites are nesting on the other side of the pond, and just a couple of weeks ago, a stoat peered in through the window. You don’t get that on a science park or in the middle of a city.

On Monday, I’ll be turning up not to the mill, but at the new offices near the station in Cambridge. It certainly won’t be the same, but there will be different perks and annoyances. The past ten years have been good; let’s see what the next ten bring.