rob.rho.org.uk

My recent post was accompanied by a picture of the Lion and the Unicorn from Through the Looking Glass, flanking Alice holding a cake. This isn’t as random as it might seem. My new server is called unicorn (partly in a nod to Mythic Beast’s traditional branding), and the old server was called cake.

Those names aren’t random either; I follow the venerable sysadmin tradition of naming computers according to a theme. In fact, I have two schemes; one for my personal machines, and one for my work ones. See if you can guess what they are:

Personal: unicorn, cake, cheshire, dodo, tweedle, redqueen, hatter…

Work: gnoll, carrion, kobold, bugbear, owlbear, hobgoblin…

The first is probably pretty obvious, but the latter less so (it’s very specific). As an extra point of clarification, my current personal laptop is called gryphon, and that’s not ambiguous.

I’ll update this post to include a (hidden) answer, but for the moment I’d be interested to hear your theories on Mastodon.

A long while ago, when I first moved this domain to its own server¹, I went with ByteMark, on the basis of recommendations from a few people I knew and who’s opinion I trusted. This trust turned out to be well-founded, and I was a happy customer for a long while.

However, in 2018, they were acquired by IOMart. This was uneventful at first, but then prices started to creep up, and I started to hear grumblings from other customers about the service going downhill. However, I didn’t hit any problems myself (my needs are very simple), so inertia kept me where I was.

Things came to a head last February, which ByteMark (“An IOMart Company”) announced that they were shutting down BigV, the virtual hosting product I used, with three month’s notice. This put the wind up me and many of their other customers, and I started to look around for alternatives. Ultimately, on that occasion, they relented and kept the service going, but my confidence in them was gone. When they made a similar announcement again a few months ago, I pulled my finger out and actually started to move things.

After a brief search, I’ve gone with the strongly Cambridge-connected Mythic Beats, again on the basis of many personal recommendations. Not only has this cut my monthly bill in half, but I’ve so far been impressed with the service, the support, and the general ease with getting everything set up. As of this evening, all of my web, mail and DNS presence has been migrated over to a brand-new virtual server, and I can wind down the old one.

I’ve also used the opportunity to revisit and modernise my setup (some of the configuration was literally two decades old; time tested, but due a refresh). I’ll be following up with some more posts over the next few weeks, going over some of the highlights of what’s changed. Overall, though, it was a very straightforward process, and my only regret was not doing it sooner.

Last weekend, I decided to take a break from the ZX81 to play with something more colourful, a Recreated ZX Spectrum that we picked up at the same time. When looking at the extra BASIC commands on offer, I noticed CIRCLE, and before I knew it had whipped up something topical:

This was pleasingly easy to do, and also reveals the Spectrum’s characteristic colour clash. For comparison, I decided to do the same thing on the Electron:

Pro: no colour clash. Con: had to write my own circle-drawing routine. Pro: in BBC BASIC, you can do this as a PROC.

I posted a video of the Electron laboriously drawing the circles, and then quickly folowed by tweak that made it approximately as fast the Spectrum. It was at this point an old friend nerd-sniped me by pointing out that I’d used a naive algorithm, and there was a far smarter one available.

100 REM Circle drawing using simple trigonometry
110 DEF PROCcircleT(cx%,cy%,r%,s)
120 tau=PI*2+0.3
130 MOVE cx%,cy%+r%
140 FOR t=0 TO tau STEP s
150 DRAW cx%+SIN(t)*r%, cy%+COS(t)*r%
160 NEXT
170 ENDPROC

Suitably chastened (and switching to Owlet for convenience), I implemented Jesko’s method, an extension of Bresenham’s line drawing algorithm that draws accurate circles with only integer additions. (Forgive the repetitious PLOTs; I wanted a quick proof of concept.)

200 REM Bresenham circle drawing
210 DEF PROCcircleB(cx%,cy%,r%)
220 t1% = r%/16
230 x% = r%
240 y% = 0
250 REPEAT
260 PLOT 69,cx%+x%,cy%+y%
270 PLOT 69,cx%-x%,cy%+y%
280 PLOT 69,cx%+x%,cy%-y%
290 PLOT 69,cx%-x%,cy%-y%
300 PLOT 69,cx%+y%,cy%+x%
310 PLOT 69,cx%-y%,cy%+x%
320 PLOT 69,cx%+y%,cy%-x%
330 PLOT 69,cx%-y%,cy%-x%
340 y% = y% + 1
350 t1% = t1% + y%
360 t2% = t1% - x%
370 IF t2% >= 0 THEN t1% = t2%: x% = x% - 1
380 UNTIL x%=y%
390 ENDPROC

The result were a bit of a surprise; it was slower by a factor of two when compared to my naive trigonometry method (7.88s vs 3.86s), as you can see here. For comparison, the circle plot function in the Acorn Graphics Extension ROM (available in Owlet, but obviously not my Electron) clocks in at 0.01s.

A bit of thought revealed the problem; the above implementation takes unit steps in coordinate space. BBC BASIC keeps this fixed at 1280x1024, no matter what how many pixels are actually available. I was running in MODE 2 (the only mode capable of displaying enough simultaneous colours to recreate those Olympic rings), which as a resolution of 160x256 pixels, meaning that each pixel was eight by four coordinate units. Hence, my naive implementation was plotting each physical pixel many times.

Fixing this fully would involve taking into account the non-square pixels, making the symetry between the octants far trickier. However, we can get most of the way there by taking a simpler approach and skipping four pixels at a time (the smaller edge). Here, we’re still double-drawing some pixels, but the symetry remains intact and the resulting circle doesn’t have any gaps. Making that change brings the time down to a far more respectable 2.02s. Flushed with success, I managed to get it down to 1.6s by moving the PLOTs into assembler.

The next step would be to move the main loop into assembler, but that’s a fair but of work due to the bigger-than-a-byte integer maths, so I decided to call it a day. It was an enjoyable diversion; the well-defined problem on a limited system meant the above was only a few five- and ten-minute stretches of playing around between other things, rather than a major commitment. A brain-teaser rather than a whole project. Sometimes, that’s exactly what you’re after.

In the 80s school playground, home computers were a bit like football teams. You (or perhaps your parents) picked a team, and that was the side you were on, logic be damned. If you were a Commodore kid, anything from, say, Amstrad or Atari, was just wrong.

We were an Acorn household; specifically, we had an Electron. That, and the closely-related BBC Micros at school, were my introduction to computers, and indelibly shaped how I thought of them. Arguably, we got lucky: out of all of the options, this is perhaps the strongest foundation. However, it’s also a limited one, and as time went on I wondered what might be different if I’d happened to fall into a different bucket.

Fast forward four decades or so, and another visit to the Centre for Computing History. In their line-up of 80s home micros, between an Acorn Atom and an Atari 800, I spotted a Sinclair ZX81. I’d never got anywhere with these machines before due to their weird keyword-entry BASIC (more on this later), but over the course of some Dixons-style light vandalism it clicked for me, and I became intrigued by this odd little machine from the other side of the fence.

10 PRINT "6502 RULES"
20 GOTO 10

There are good emulators easily available, but as the ZX81 was so ubiquitous you can get a real one at a very reasonable price — the going rate on eBay is about £25-30. I picked one up back at the CCH, at their Bring and Byte sale, and after a bit of work on the video output (see Retro Frustrations, Bread and Crocodiles and ZX81 Composite Mod) and adding a modern RAM pack (visible in the photo; see also Mystery RAM) I had a working system to play around with. I’ve also had enough time with it to feel it worth recording my impressions so far.

Firstly, the hardware. Visually, I think it’s a stunner — arguably the best looking micro of the era. Designer Rick Dickinson’s follow-up, the ZX Spectrum is perhaps better known, but for me the ZX81’s wedge shape and black/grey/red graphics has the edge for me (and won Dickinson a British Design Council award).

Thing you notice before even plugging it in is the weight and size. It’s almost square, 16cm across, and little over 3cm deep at its thickest point. This is tiny compared to most other micros at the time, especially if you compare it to (admittedly more capable) behemoths like the BBC Micro and Apple ][. It’s light, too — the first time you pick one up you’d be forgiven for thinking it was just an empty case. In combination, this makes for a device that feels personal and unimposing. It’s not a portable computer, but it’s far more amenable to slinging in a bag to take with you than its peers.

Once you do plug it in and turn it on, you immediately run into one of the things that the ZX81 is most know for: the keyboard. It’s a membrane keyboard, but not in the sense of cheap keyboards today. There are no moving parts at all, and it’s completely flat. It looks gorgeous, and it certainly helped with keeping the cost down, but the typing experience is neither pleasant or quick. You’d think twice about using it to write a shopping list, let alone a novel¹. That said, it isn’t designed for novel writing. It’s designed for one very specific task: programming in BASIC.

Like most almost every home computer of the era, the ZX81 launches directly into BASIC, and its particular flavour is somewhat idiosyncratic. It’s based on a “keyword system”, where BASIC keywords (PRINT, FOR and so on) are entered by a single keypress rather than typing them out in full. The thing that threw me whenever I encountered this in the 80s is that, unlike the superficially similar feature on the Electron, this is not optional. Even though typing the letters individually would produce similar results on the screen, they wouldn’t be recognised as by BASIC. At the time, this seemed very foreign to me, almost gleefully obtuse.

However, once I started to get my head around it, I began to see the benefits. Firstly, it mitigates the awful keyboard, by vastly reducing the number of keypresses you need to achieve an end. It also provides a handy reference, in the form of the intricate key labels. Finally, it reduces the scope for syntax errors, in a similar way to block-based systems such as Scratch.

This last point is an interesting one, as it gets to the heart of my impression of the machine. While other micros were all about doing things (playing games, running spreadsheets, controlling your garden sprinklers), the ZX81 feels like its focus is learning about computers. In the early eighties, computers were still alien to most people, something found in corporations not living rooms. Sinclair’s explicit aim with the ZX81 (and its predecessor the ZX80) was to get computers into the hands of the masses. They did this with a ruthless focus on simplification and cost reduction, and it worked. The ZX81 hit an unheard-of price point (£69.95, going to £49.95 in kit form) and was sold in high street retailers like W.H. Smith, and in only a few years provided well over a million buyers with their first taste of a computer.

This goal was furthered by the manual that came with it, ZX81 BASIC Programming by Steven Vickers (pictured above). All micros of that era came with printed documentation, much of which was of very high quality, but Vickers’ book stands out as a particularly fine example. It takes you through the capabilities of the machine in a logical and patient way, and is an excellent way for a beginner to get up to speed on the key concepts. Coupled with the surprisingly friendly (for the time) interactive environment, it’s easy to see why it gained such traction in the early 80s as an introduction to the brave new world.

This wasn’t to last, however. As the decade progressed, microcomputers became more common, and the focus shifted to more capable devices (not least the ZX81’s successor, the aforementioned Spectrum). Nevertheless, the ZX81 has a special place in many hearts, and having spent a bit of time exploring it I can see why. It does a lot with a little, and has a particular charm of its own. I’m glad I decided to take a look on the other side of the fence.

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.