Not Endorsed by the IOC

12 Aug 2024

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:

The Olympic rings, rendered on a ZX Spectrum emulator. Not endorsed by the IOC; please don’t sue me.

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:

The Olympic rings, rendered on an actual Acorn Electron. Still not endorsed by the IOC.

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.

Getting to Know the ZX81

6 Aug 2024

ZX81 with a caseless RAM Pack and a spiral-bound book "ZX81 BASIC Programming", sat on grass

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 novel1. 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.

  1. Although apparently none other than Terry Pratchett used a ZX81 for some “very primitive word processing” before graduating to an Amstrad CPC 464. [back]

Mystery RAM

19 Jul 2024

One of the notable things about the ZX81 is the tiny amount of RAM — just 1K1 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 (216 + 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.

  1. For comparison, that’s about a third of the size of the plain text version of this post. [back]

Effin' Keys

14 Jul 2024

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.

Split keyboard layout with four layers

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)

Math Notes: Finally

6 Jul 2024

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?

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@mas.to on Mastodon and 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 (© 2014 Cooper Hewitt Smithsonian Design Museum, and used under the SIL Open Font License). BBC BASIC code is set in FontStruction “Acorn Mode 1” by “p1.mark” (licensed under a Creative Commons Attribution Share Alike license).

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