Category Archives: Computers

PCs’n’shit

Retrofabulation: reimagining the past

Leave a reply

Everybody dreams about reinventing the past.

I’m a technologist, and I sometimes (often) I like to think about how some basic technologies could look, if we knew then what we knew now. When a technology is ubiquitous, or even just successful, it’s easy to take for granted the warts in its design, or the tradeoffs that were made at the time. So it can be illuminating (and fun(!)) to think about how things could have been different.

This post introduces a project of mine to perform some surgical technological revisionism on a 1982 home computer icon: the Sinclair ZX Spectrum.

The Sinclair ZX Spectrum

In the early 1980s, in the UK, there was a microcomputer boom; a Cambrian explosion of 8-bit possibilities. (In 1981, our family bought a Sinclair ZX81, and I learned how to program. Then I got a ZX Spectrum.)

undefined

There were loads of games for the Spectrum, load of magazines devoted to the Spectrum, and it left an indelible mark on the UK computing scene. The ZX Spectrum, even today (2025), has a massive retro computing following. Only a year or so ago (2024) a new incarnation of it was released—The Spectrum—and enthusiasts still continue to release new games continue for this ancient, 40-something, computing platform.

The ZX Spectrum was launched in 1982 as a ‘home computer’, which in the 1980s meant:

  1. In practice, it was really a games device, competing for space on the family television, and played by the kids. Games were loaded via audio cassette tape: most households of that era had a portable cassette recorder which could be used to load and save programs.
  2. Some of these kids learned how to program, by typing in listings from computer magazines, or from reading the many books which were published. Almost every home computer in the 1980s had a version of the programming language BASIC.
  3. The advertisements for home micros all claimed that the family could use their new computer to balance the household expenses, run a business, do school homework, and do many of the things that now people use PCs or Macs to do. Perhaps a few people did, but not many.

Importantly, home computers, and the ZX Spectrum were amazingly successful. The Spectrum doesn’t need me to reinvent it to (retospectively) make it more successful.

What if

But, given 40 years of advances in programming languages; the art of User Experience; computer graphics & typography, looking back at old technology often makes me think: ‘What if the creators of this technology knew then what we know now?’

The Spectrum hardware design is remarkable: the engineers achieved a colour computer, with audio, and fast (ish) performance for a very low manufacturing cost, which could be sold very cheaply. And its industrial design is beautiful. These are probably the main reasons it was one of the most popular home computers of the era.

However, it was developed under great time pressure, and to be manufactured cheaply, it was heavily based on Sinclair’s previous home computer, the ZX81. There were a lot of loose ends and short-cuts in the ROM code. But, honestly, the magic of a little box that could make colour images and sounds, and play games, was astonishing enough.

In terms of the software:

With any technology, over time, people discover ways to eke out more performance, or do things that the technology was not designed to do. They discover optimisations, and share tricks. Today, 40 years after the Spectrum’s original launch, we’re seeing games for it, which display more colours on the screen, or have smoother animation, than ever thought possible at the product’s launch.

And the last 40 years have seen a seismic shift in how we relate to computers—what we expect from them, and the programming algorithms discovered in the meantime that we can use on them. ’80s micros were marketed as tools to learn how to program. Programming pedagogy and practice is very different nowadays than it was then.

In particular, the programming paradigm promoted by BASIC is horribly archaic. We call its coding style now ‘spaghetti coding’—a jumbled mess. Even in the early 1980s, late 1970s, better alternatives—structured coding and Object Oriented programming—were being developed. BASIC does not teach good (nor modern) practices.

And BASIC is easy to start using, but it does not lend itself to composing larger projects.

It’s also very slow, having been optimised for ease of implementation. Sinclair BASIC was originally designed to fit in the tiny Read Only Memory (ROM) of the ZX81, which lead to some significant compromises.

As a software designer, it’s very tempting to imagine rewriting it.

So just what could have been possible?

Side note: the role of the Spectrum ROM

Just a side note to point out that the Spectrum ROM is very well-suited to such a reimagining: The ZX Spectrum was designed to be very cheap to manufacture, and one aspect of this was that the hardware was as minimalistic as possible. As far as possible, features were implemented in the ROM software instead of in (expensive) hardware.

The simplicity of its hardware design possibly contributed to its flexibility and longevity, and, by replacing the ROM, we can change almost the whole character of the machine.

I implied that this project is about reimagining a 1980s computer, but really it’s about reimagining its ROM firmware layer, leaving the hardware unchanged.

There is one aspect of the hardware I’d change: I’d remove the hardware capability to flash blocks on and off, on the screen, and replace it with a little more flexibility to display colours. But we’ll leave that til later.

What started this idea

I don’t honestly know. A large part is probably the fact that my own children are approaching the age I was when I first discovered these Sinclair computers.

In any case, in February 2024, slightly bored with my day job, I started inadvertently obsessing about how the Spectrum ROM software could have been better designed. Something grabbed my brain and would not let go. I was particularly worrying away at two questions:

  1. Could it be possible to design a built-in programming language that was simultaneously: more memory-efficient (allowing larger, more complex user programs), and faster to execute, and clearer and easier to learn, than ZX BASIC? I thought I had a design that might work.
  2. The built-in Spectrum commands for text, graphics, sound, and everything else have since been greatly improved upon by others:
    • Drawing lines and circles should be about 20 times faster than the existing Spectrum ROM.
    • Tape loading routines could be about 50% faster
    • We could include some useful building blocks for writing games—because all the kids in the ’80s wanted to write a computer game—like simple sprites and screen-scrolling.
  3. Could the built-in Spectrum software look…well… prettier? Not just prettier, but also more approachable; more productive; easier to use. Importantly, it should be approachable for beginners, while offering a smooth ramp to more advanced use.
    • The on-screen typography could be easier to read, making programs easier to read, and potentially allowing editing code with syntax-highlighting.
    • Modules? A way of taking bits of program published in magazines, or on tapes and integrating them into your own program.
    • Some sort of way of disassembling machine code, or even assembling it. That would only be for advanced users, but, again, helps provide a more gradual on-ramp to advanced usage.

I thought we could take some of the modern affordances that 2020s software developers take for granted, and take them back to the 1980s.

Nine Tiles

The Spectrum ROM was originally designed by Steve Vickers & Richard Altwasser of Nine Tiles, in 1981. Steve Vickers also wrote the user manual. I do not want to diminish their achievement!

I think we can do better, but I have several advantages over the original ROM developers: I have their design to jump off from. That original version—and the Spectrum hardware itself—is now exceptionally well documented online. I have all the resources of today’s retro-programming scene to use as reference too, and I have the benefit of hindsight. They were working to a tight deadline; I am not.

And I have access to much more sophisticated software engineering tools (editors, source control, debuggers) than they did.

Journey of 1000 miles, etc.

So I started by redesigning the Spectrum font…

Hey, you have to start somewhere.

To be continued…

Scarecase: The Computer Game

Leave a reply

A couple of years ago, I decided that I wasn’t getting enough good, meaty, technical programming done. So I decided to write a computer game.

I locked myself away in an AirBnB for a weekend in Broughty Ferry, and wrote a game! …a very rough, prototype version of a game anyway.

It actually took me 2 years, on and off (mostly off) to complete it to a semi-acceptable level. A long weekend sorting out the sound effects; I sorted out some ‘impossible’ gameplay during a family holiday in Italy. One of my friends came up with the name, and another wonderful musician friend wrote the music.

It’s on the Apple AppStore: ‘Scarecase’.

Continue reading →

Java*: a critique (part 1/n)

1 Reply

Honestly, this post feels a bit unfinished. I still agree with it, but it’s a bit of a list without a start, and end, or… much of a point. Anyway, to enjoy, and maybe I’ll pull together more of a coherent argument in a future post.

*The Java Programming Language and JVM, that is. Sorry for the very pompous title, but I want to look at what—with the benefit of modern best-practice knowledge and hindsight—could have been different and better about 1995’s Java Programming Language.

Continue reading →

Typed collection keys

Leave a reply

Summary: When programming, often there is a requirement to store heterogeneous types of values in a collection. The Typed Keys pattern defines keys which ‘know’ the type of data to which they refer, and which encapsulate the type information and logic to convert it to and from the storage type.

Preamble

I seem to write on this theme a lot: how to leverage the type system of modern programming languages to reduce programming errors, and make application code less verbose. Well, this is another example of that, and it’s a technique I find myself using quite often in Java & C# to really simplify code, increase type-safety (i.e., reduce the opportunity for dumb errors) and make business logic more understandable.

The gist is that if you do the same thing every time you access particular keys/variables/lookup items, then you should encapsulate these actions within the key, rather than spreading them throughout the code.

It’s not an original idea, and we’ll point to some examples in a future post.

Motivating example:

Let’s say you have a map of strings to objects (in Java: Map<String, Object>), and you’re storing in it values of several different types:

‘sessionId’: Long
‘username’: String
‘loginDate’: Date object (representing a point-in-time)
‘userStaffId’: Integer (optional)

And let’s say that there could be a bunch of other such keys too—dozens or hundreds—it’s an open-ended list.

This situation occurs with session attributes, and configuration settings, and key-value databases.

If it is a small, relatively-fixed list of keys, the solution might be a wrapper class around the Map, with appropriately-typed getters and setters for each value. But the keys are an open-ended set. The code to retrieve a session-id might be:

long sessionId = (Long)map.get("sessionId");

Let’s imagine that we’re doing that a few times throughout the codebase.

And to set it:

map.put("sessionId") = /* generate the session id somehow */

Already, there are a couple of problems with this code, so let’s address them one at a time.

The string literal

A simple (and obvious) one to start:

We’re repeating the same constant strings throughout the codebase. This is error-prone, and makes the code fragile & hard to change.

It’s error-prone—because a typo at any of the string literals will never be caught at compile time, but will cause the code to fail at runtime.

It’s fragile—because these errors are easy to introduce accidentally.

It’s hard to change—because changing any key-name requires changing it at many places throughout the code.

So the obvious first step is to define each of the key-names we’re using as string constants:

public class Keys {
  public static final String SESSION_ID = “sessionId”;
  public static final String USERNAME = “username”;
  // etc.
}

And we change our access code to make use of the string constants:

long sessionId = (Long)map.get(SESSION_ID);

That’s an improvement. It’s one that you’d expect most people to make. Fairly uncontroversial.

However, there is another bit of repetition & fragility in the code as it stands, and it’s not immediately obvious how to refactor this one:

The type of each key

The repetition is the cast-to-long (or whatever the type of the key is) at each access point. This repetition leads to the same issues as the literal strings: fragility, error-proneness & difficulty in changing the code.

It’s error-prone—because a wrong cast at each any access point will never be caught at compile time, but will cause the code to fail at runtime. For example, there’s no compile-time guarantee that we’re casting to the same type when reading the value as the type we wrote to the key.

It’s fragile—because these errors are easy to introduce accidentally.

It’s hard to change—because changing any key’s type could require changing it at many, many places throughout the code.

Additionally, the repetition of the type casts—which is inherent to each key—is nevertheless written out explicitly each access point, and so clutters the code.

The idea

So can we somehow encapsulate the string key name with the type of the variable…?

Perhaps something like:

class Key<T> {
  final String keyName;
  final Class<T> valueType;
}

We can then construct a mechanism for getting and setting these variables:

static class KeyMapAccessor {
  static T getFrom<T>(Key<T> key, Map<String, Object> map) {
    Object untypedValue = map.get(key.keyName);
    return key.valueType.cast(untypedValue);
  }

  static void setIn<T>(Key<T> key, Map<String, Object> map, T value) {
    map.set(key.keyName, (Object)value);
  }
}

If we then declare SESSION_KEY as a variable of type Key<Long>, we can get its value like this:

long sessionId = getFrom(SESSION_ID, map);

And set it like this:

setIn(SESSION_ID, map, generateSessionId());

We’ve accomplished two big improvements here:

  1. Removed the visual clutter of type conversions from the ‘getter’ code.
  2. Made accesses of the value consistently typesafe. (This applies to the getter and the setter.)

Just to drive that last point home, you would get an error at compile time if you wrote:

setIn(SESSION_ID, map, "string value, should be a long!");
// or
int sessionId = getFrom(SESSION_ID, map); // int ≢ long

If you ever needed to change the type of a keyed variable, for example, changing the session ID from a Long to a GUID, you’d change the declaration of SESSION_ID, and the compiler would point out all the places in the code that needed to change.

Alternatively

Another, and common, approach to achieving type-safety is to wrap the (untyped) map in a typed wrapper, and provide accessors for each of the values. For example:

public class SessionMap {
  private final Map<String, Object> underlyingMap;
  private static final String SESSION_ID = "sessionId";
  // etc

  public Long getSessionId { return (Long)underlyingMap.get(SESSION_ID); }
  public void setSessionId { underlyingMap.set(SESSION_ID, value); }
  // etc
}

That’s very viable, especially when the number of keys/variables is bounded and/or small.

However, as soon as the number of keys is open-ended—or the keys don’t belong together, and putting them all in the same class would entail mixing of concerns—this becomes a less practical solution.

Summary & next steps

We’ve looked at the general model of associating type conversion logic and type information with a collection key name.

This technique can:

  • Increase code clarity, by moving type conversion code out of the business logic.
  • Increase code safety & robustness, by removing the fragile repetition of type conversion code throughout the codebase.

There are a few other variations on the technique that I might look at in future blog posts.