The Spectrum came with a built-in BASIC interpreter that are up the bottom 16kB of the 64kB addressing space. The BASIC was actually fairly powerful and easy-to-use, and included a very fun programming textbook. I just reread that textbook, and it is quite strikingly well-written and manages to cover both basic computer-science-style programming and deep close-to-the-machine and real-time programming in a compact 150 pages. There is no credit to a particular author in the book I have (Swedish translation by a group of people at Ord & Form here in Uppsala), but an online scan credits Steven Vickers.

Overall, the book does a very good job of explaining both the Sinclair BASIC interpreter, as well as some general programming concepts. And how the machine works deep down. Here are some highlights.

Explaining Functions

The way that functions are explained made me laugh out loud (quoting the original English according to the online resource I found):

Consider the sausage machine. You put a lump of meat in at one end, turn a handle, and out comes a sausage at the other end. A lump of pork gives a pork sausage, a lump of fish gives a fish sausage, and a load of beef a beef sausage.

Functions are practically indistinguishable from sausage machines but there is a difference: they work on numbers and strings instead of meat. You supply one value (called the argument), mince it up by doing some calculations on it, and eventually get another value, the result.

This is a very good analogy to introduce functions, in a fairly gender-neutral way and assuming no mathematical background on part of the user. I wonder if I ever cared to define any functions… as I recall it, GOSUB was as far as I got in sophistication before leaving BASIC and starting writing everything in Z80 assembler.

Reading a Changing Counter

Later on in the book, a suggestion is made to get a better time counter. Essentially, by reading a 24-bit value incrementing at 50 Hz, using three separate PEEK commands:

(65536*PEEK 23674+256*PEEK 23673+PEEK 23672)/50

This code does subject you to the issue of reading during an update and counter wrap from one byte to the next. This complication is cheerfully noted after a complete program using this feature as a by-the-way-the-code-is-correct by a small loop. There are many such small gems in the book, essential tricks and caveats that still apply to programming close to the hardware and doing real-time programming.

We have No Clock

The ZX Spectrum, as most computers of its day, did not have a real-time clock on board. Instead, you had to time things using the 50Hz screen refresh interrupt (which is what the code in previous section reads) or by just adjusting your code to wait appropriately. One example program is supposed to show a clock updating every second. However, getting to a second is a bit tricky when there is no firm time-base to work on. The suggesting instead is this:

This clock will run down after about 55.5 hours because of line 60, but you can easily make it run longer. Note how the timing is controlled by line 210. You might expect PAUSE 50 to make it tick one a second, but the computing takes a bit of time as well and has to be allowed for. This is best done by trial and error, timing the computer clock against a real one, and adjusting line 210 until they agree. (You can’t do this very accurately; an adjustment of one frame in one second is 2% or half an hour in a day.)

So what we have here is a classic “how long must I wait to get a steady pace of execution for my periodic code?” issue familiar to anyone using an RTOS and trying to determine how long to sleep a process for until the next periodic interval starts. Once again, illustrated in ten lines of BASIC and a few lines of text.

Repeatability and Randomness

In Chapter 11, randomness using the built-in random function is introduced. This was a 16-bit periodic pseudo-random system where you could set the random seed to put start the random generation at any particular point in a 100% repeatable manner. Indeed, the book introduces the concept of doing this in order to ensure repeatable execution of a program relying on randomness. This sounds familiar from my previous post on simulation determinism:

If you had a program with RND in it and it also had some mistakes that you had not found, then it would help to use RANDOMIZE like this so that the program behaved the same way each time you ran it.

Delving into Details

The BASIC manual does not try to hide how the BASIC interpreter works internally, rather on the contrary, including a list of all system variables so that they can be POKEd and changed if need be. It also explains the data layout of all variable types (the Spectrum BASIC used 32-bit integers, impressive for an 8-bit machine, and 40-bit floating point numbers).

The only useful information for me in the way I used the machine as a pure assembly-language target was the memory layout of the screen. Which is bizarre to say the least. It had a separate black-and-white bitmap and color overlay for every 8×8 character. And each scan line was NOT consecutive with the previous in memory, but rather offset by 256 bytes. I think the idea was to make it easy to insert a single character into the bitmap by just incrementing the high byte of the address by one for each pixel line.

To make that work, the screen was divided into three pieces of 8 character lines/2048 bytes each (8 character lines of 8 pixel lines each, each with 32×8 bits of data).  The sprite drawing routines that would work with that to plot a 16×16 sprite in any screen position was amazing code, to say the least. I independently invented unrolled loops to make this run fast. And misused the POP instruction to pull in data to draw (it took 11 cycles, rather than 12 as a more usual register-indirect load would do) — provided that you turned off interrupts or data corruption would ensue.

These were fun programming times. It shaped my programming habits for a decade, culminating in an infamous 68000 assembler hack in my first undergrad year at Uppsala, with some 50 pages of very tight and complicated assembly language making use of most features of the 68k instruction set… poor TA.

Final Notes

On it goes like that. The chapters are short but very much to the point, and a large number of fairly subtle concepts are introduced. The Spectrum was a good school for a budding programmer, with no compiler, no safety net, but also no way to break the machine in a way that a reboot would not cure.

I actually recommend seeking out the aforementioned online repository for the Spectrum programming book, it is almost still in shape to be used as an introduction to real-time and embedded programming.

I am currently trying to figure out what is a good ZX Spectrum emulator to relive these old times if I can find time. The hardware unit I have depends on an analog tape drive to load software… and I gave up analog sound back in 1993. As if the magnetic tapes which have been in storage for 20 years have any chance of containing useful data anyway.

But not everyone seems to consider this an important feature, judging from its relative rarity in the world of EDA and virtual platforms. Why is this? Let’s look at some possible explanations.

But first, let’s examine the subject of this post a bit more. What is checkpointing, precisely?

What?

In short, it is the ability of a virtual platform or virtualization environment to save the state of an executing simulation to disk (or memory or something) and later bring the saved state back and continue the simulation as if nothing had happened.

In detail, there are four operations that need to be supported for this to be truly useful:

• Saving and restoring to the same simulation system on the same host machine (i.e., into the exact same program binary for the simulation).
• Restoring on a different machine (where different can mean a machine with a different word-length, endianness, and operating system).
• Restoring into a bug-fixed version of the same simulation model.
• Restoring into a completely different simulation model that happens to have the same state.

Why?

Let’s look at some use cases for checkpointing:

The last operation is very interesting, since it carries with it the ability to change abstraction level. It is used in IBM Mambo (see a 2006 IBM paper that you now have to buy due to an annoying change in IBM policy) to exactly this effect, and in Simics for the Freescale QorIQ P4080 as well. It is also well exploited by academic research frameworks for Simics, such as GEMS and SimFlex. Essentially, the idea is to position using fast mode, and then move over to detailed mode. The advantage to doing this over a checkpoint is that you can farm out the experiments across many different hosts, save the precise starting point for future regression tests, and try different detailed settings from a known common starting position.

The most obvious use for checkpoints is to avoid repeating simulation work that does not add value, in particular booting of operating systems. A modern OS boot  easily takes billions of instructions (say 10 seconds on a dual-core gigahertz machine… do the math). Being able to save a simulation effort like this for instant reuse is such a standard part of how I work with virtual platforms that I could not imagine the pain of not having it.

Checkpointing is also a useful communications tool: it makes it possible for any user of a virtual platform to precisely communicate the system state and configuration to anybody else with access to the same virtual platform system (note that a Checkpoint, at least in Simics land, contains the list of objects in the simulation and how they are connected, so you do not need any other description of the simulation setup). This helps in debugging models – a user testing it can easily package problems and report them to the modeling team. And it helps in debugging software running on the virtual platform, as a tester can package up the precise system state right before a bug hits and send it back to development. Incredibly powerful! Here, portability of checkpoings across hosts is obviously very important, as well as across model versions. Once you have a fix for a model bug, you test it using the checkpoint, and check that things now proceed as they should.

Checkpointing also comes in handy as a backup-save ability when configuring an interactive target system. In many cases, the loading and configuration of software on a target is a very valuable and hard-to-repeat-exactly activity. Adding in software, configuring it, starting servers, assigning network addresses, configuring communications paths for backplanes can take a lot of time. On physical machines or virtual platforms, if you mess up, you have to go back and start over. With checkpointing, you can incrementally save work as you go along. This is a common use case for the snapshotting ability in VmWare, for example. But it works equally well for embedded targets modeled as virtual platforms.

There are more uses, the paragraphs above just scratch the surface of the utility of checkpoints.

Why Not?

But despite the obvious benefits, this feature is very rarely found in virtual platforms. I can see three main lines of argument:

• Meaningless: for tests comprising only short software runs like a few million or tens of millions of instructions, rerunning it is fast enough. Or changes major enough. That checkpointing seems pointless. I can buy that — but only until the simple target is part of a greater context. If a DSP, for example, is part of a big system setup, you want to save its state even if it is only running a few small million-instruction loops.
• Difficult: I think this might be the most important explanantion. Doing checkpointing right puts requirements on the simulation kernel and on all processors and device models. All models have to be coded with discipline so that all state is available and can be set at any point in time. In particular, this means that explicit threading like employed in SystemC SC_THREAD is out. It must also be admitted that certain types of models like detailed processor models can be very difficult to serialize and deserialize from disk, simply due to the enormous intricacies of their implementations. But had they been designed with checkpointing in mind from the start, it would have been less difficult.
• Overlooked: The virtual platform was designed without thinking of checkpointing. Alternatively, no customers asked for it, so it was not built.

I find the last argument very interesting, since I can see what happens once you have tried checkpointing. In my experience, once a user of a virtual platform has tried checkpointing, they want it. It goes from a interesting idea to a must-have feature very quickly. No arguments about why it is hard or why they can do without it work, as they have seen how things should be done.

For me, I think it is akin to my first encounter with a Macintosh computer, and the concept of “undo” in programs. Before that, I was happily editing code on a ZX Spectrum, in an environment where “undo” meant “manually remember how it looked at change it”. I had no problems with that, but once I saw how things could be done, there was no going back.