Sinclair ZX Spectrum Vega

The Indiegogo campaign to create a game-controllerified Speccy has been funded in 1 day!

As I write this, the crowd-funded project (to which Sir Clive Sinclair has lent his support) is sitting @ £110K, with the funding target @ £100K, which will fund 1,000 units.

Personally, my hopes were raised when I read about the project through social media links. The nitty gritty specifications are:

  • Smaller than original Spectrum – “controller” sized for use two-handed as a controller.
  • Has 4 direction keys plus another 5 keys of unknown function (presumably programmable somehow). The dead flesh keyboard of the original Spectrum has gone (though there is supposed to be an onscreen keyboard).
  • Has composite video output only (no HDMI or other high quality video output). Video connector on the back of the unit.
  • Is powered through a second connection on the back.
  • No other expansion connectors.
  • SD reader/writer built-in.
  • 1,000 bundled games (though rights to these games are not yet secured).
  • ARM based emulation of Spectrum functionality.

As I analyzed the specs however, I had a gradual sinking feeling. If the unit featured the following I’d be a lot more excited:

  • Full keyboard (dropping the keyboard seems like a major shortcoming).
  • HDMI connector (composite video in 2014?)  Apparently HDMI is too expensive/complicated.
  • Ethernet.
  • Joystick connector (USB).

I’d even consider cracking open the old Z80 assembler if the device was more full featured. It’s not clear how you could do remote development for the device without more connections to the outside, for example. Copying files to SD would be a pain. Perhaps there’s a way hook up some sort of downloader. I suppose there are numerous ways to do Speccy development using emulators, but it’d be cool to have an easy to use real hardware target.

I’m not sure how this device is really any better than a Raspberry Pi , which would offer much more functionality at a fraction of the cost. Embed a Rasp Pi in a new case, done.

The crowd-sourced units are pretty expensive for what they are too – £100 each!

Having said all this, the crowd-sourced fundraising was very successful. There’s definitely a latent fondness for the old Spectrum machine, and this project seems to have ignited that.

Posted by Steve Wetherill in Retro, Sinclair, Spectrum, 0 comments

The Making of Heartland for Sinclair ZX Spectrum


Heartland loading screen for ZX Spectrum.

Note: this article expands upon material I provided for the RetroGamer #129 article on Heartland.

In 1986, Odin Computer Graphics Ltd published the game “Heartland” for 8-bit platforms such as the Sinclair Spectrum, Commodore 64 and Amstrad CPC. Colin Grunes was responsible for art, level design & background lore. I did the coding on the Spectrum and Amstrad CPC versions, and contributed to gameplay design. Keith Robinson coded the Commodore 64 version.

Initial Development

Heartland development was commenced around the time of the Odin deal with TelecomSoft to create 10 new games, and Heartland was the first title released under that deal. As it happened, Odin moved office in the middle of development of Heartland, though it was not a very big move (it was across the courtyard in Canning Place to another unit – the old Bug Byte office, as it happens). The new office was much bigger – we needed the space for the additional developers we would hire for the TelecomSoft deal. The move was not unduly difficult, we just carried our gear over one afternoon. That building was demolished in the 90’s to make way for downtown redevelopment in Liverpool.

The catalyst for Heartland’s development occurred during the development of Robin of the Wood (on which Paul Salmon was the main artist). In that period, Colin Grunes (lead artist on Nodes of Yesod) was creating the initial walk cycle for the main Heartland character, the Hero Wizard Eldritch (otherwise known as Bertie, who’s full name may or may not have been Bertie Big Boy), in addition to other graphics ideas for backgrounds and some of the enemies. As soon as RotW was finished I began to experiment with dynamic mask generator code using the walk cycle. Before long, I had lots of Berties walking left and right on the screen using the masking technique, and this really gelled the visual direction for Heartland.

We tended not to do a lot of up-front design at Odin, not on details. So we would agree on the large stuff and then work out the details as we went along. Lots of things could drive the design, such as how many 16 pixel wide sprites would fit into a certain space (for the number of pages to collect), etc.

In terms of story development, Heartland was very much a collaborative effort. The graphics drove a lot of the back story, certainly, but ideas came from all around, as each idea came up, we’d discuss ways to integrate this or that idea into the game. I’m sure there were ideas from other developers, and from Paul McKenna (our Managing Director). It is likely that ideas came from Marc Wilding, Paul Salmon, Keith Robinson, Stuart Fotheringham and other founding members of Odin.

There are clearly elements of Nodes of Yesod and Robin of the Wood in the game, in that the game is in side view and is room based. The map is a lot less linear than either of those games, the screens being linked by portals going into and out of the screen, in addition to the screen flipping, elevators and staircases.. A few of the ideas I’d included in the much expanded Amstrad CPC version of Jet Set Willy made an appearance here too – the space section, for example, though that of course was also a nod to Nodes of Yesod.

Colin and I worked together very well. We had already collaborated on Nodes of Yesod, and after Heartland we worked on Sidewize and Crosswize together at Odin. We also later worked on an (ultimately abortive) Atari ST/Amiga game @ Denton Designs called Gargantuan. Heartland was the first time we worked directly together as a duo (Nodes was always more of a team effort).

Graphics Development

On the art side, we had graphics for the first level very early on, along with the main Bertie sprites. The other graphics were developed in tandem with the game code and level editor that I created. Colin created all the pixel art in in Melbourne Draw, painstakingly using the Spectrum’s rubber keys, though there may have been some sketches. It’s amazing what could be done without a drawing tablet, or even a mouse! There was definitely collaboration on ideas for art, but Colin did the vast majority of the pixel work. Stuart “Stoo” Fotheringham did a bunch of the in-game plants, and maybe one or two other things. Colin did the loading screen, I remember him slaving away trying to get the attributes to line up with the hand and the planet! That said, Stoo did create several of the loading screens for other games at Odin/Thor.

Gerry Fisher did a fantastic job on the box art (on which the game’s loading screen is based) as usual. He did the Nodes of Yesod, Arc of Yesod and Robin of the Wood covers too.

Development Environment

Heartland was written from scratch (not based on Nodes of Yesod or Robin of the Wood) in Z80 assembly language. The code for the game was developed on a BBC Model B computer with the Z80 second processor running CPM. Under CPM we used the M80/L80 assembler/linker combination, and the Memo text editor. The Beebs had twin disk drives, so tools would run on one drive and game code would live on the other. In order to get code to the Spectrum, we’d use one of a variety of downloaders. At different times we used custom parallel and serial downloaders attached in various ways to the Spectrums (including Interface 1). Early on at Odin, some development had been attempted on Spectrums using MicroDrives, but this was quickly abandoned due to the unreliability of the Microdrive media.

The Beebs were really nice to use, though I seldom used the machine in actual BBC Micro mode. I think I might have spent a few hours playing Elite, having said that. 🙂

I developed a visual tool for level creation. It allowed Colin to design room layouts, and then move between the rooms. It could save and load data (I think we had disk drives for the Spectrums at this stage).

Dynamic Masking

For Heartland I developed a graphical masking technique that was the cornerstone of the game – I wanted to be able to give a more solid feel to the sprites. In order to explain this, I’ll contrast how previous games drew their sprites. Bear in mind that the techniques here are pretty specific to what is essentially a 1 bit wide bitplane on the ZX Spectrum.

XOR Technique

In Nodes of Yesod I used an “XOR” technique, which basically creates a “hole” where sprites or other graphical elements overlap. In a nutshell, the XOR (exclusive or) logical operation combines pixels as shown in the following image:


The XOR technique is efficient and easy to implement, and it has the benefit that in order to erase a sprite, you just draw it again in the same position! So, there’s no need to keep track of which parts of the screen have changes. You’ll notice that in Nodes of Yesod, things seldom overlap for very long. This is in part to avoid seeing holes where things overlap.

OR Technique

In Robin of the Wood, I used an “OR” technique, which results in a slightly more solid feel when sprites overlap each other. Combining pixels using OR looks like this:


This explains the lack of “holes” contained in the image when sprites overlap. The downside to this technique is that it is not in itself “self erasing”, and it takes more programming effort, and more CPU cycles (in general) to keep the screen updated. It is also more difficult to discern foreground details from the background.

For Robin of the Wood, I kept a list of “dirty rectangles” so that instead of redrawing the entire screen I could just redraw those parts that changed. Again, more CPU cycles and additional complexity are introduced in this approach.

In RotW, things are allowed to overlap more than in Nodes of Yesod. This is because the OR technique is not as visually distracting as the XOR technique.

AND & OR Mask Technique

In Heartland I used a “mask” approach, which essentially uses a “cookie cutter” to remove all pixels behind each sprite. Usually this cookie cutter has a larger area than the actual sprite, resulting in a (typically) black border around the sprites, and solid black areas in the inner part of the sprite. The cookie cutter mask is applied before drawing the sprite, using and AND approach, the result looks like this:

You can clearly see that one of the elements is supposed to be in front of the other. By creating a cookie cutter “AND” mask, you can clear space behind each sprite in which to draw it. Drawing of the actual sprite is then accomplished using the OR approach.

This technique is quite effective in producing more solid looking graphics, but it has a couple of drawbacks. For one, more CPU cycles are needed to draw each sprite (since you have to “cookie cut” a hole for every sprite); additionally, storing this mask for every pixel doubles (on the ZX Spectrum) the amount of memory needed to store each sprite. The main problem in Heartland was fitting everything into memory (it was a single load game), and this is where the “dynamic mask” approach came in. To do this, every sprite and “prop” in the game was stored without a mask. In order to generate the mask dynamically, at level initialization time each graphic was shifted one pixel left, one pixel right, one pixel up and one pixel down. These resulting images were then combined together to create an image “fatter” than the original, and then this image was inverted to become the mask. The following images shows this visually:


A raw “Bertie” sprite from Heartland, as drawn by Colin Grunes and as stored in the game code.


In this image, we see the result of taking the raw sprite, and OR’ing it with versions shifted up, down, left and right. This generates the “AND mask” – this is the shape of the hole to be cut in the background.


Final composited image, showing the raw sprite inverted (black for white) overlaid into the mask.

The technique of generating the masks worked pretty well. Occasionally, there’d be a “hole” in the mask if more than a 3 pixel gap existed in the original art, but it was usually a quick job for Colin to fix up the error.

Music & Audio

Keith Tinman did the music, I did the sound effects, such as they were. The music player was an evolution of previous code that we’d used in Robin of the Woods, and that player was written by Andy Walker and I. It was a 2 channel player that made use of the fact that the Spectrum beeper could actually output three levels (essentially zero volume, ear bit, mic bit), so you could play two notes at once by careful bit toggling. We didn’t really have a good way of transcribing music from musical keyboard to the game, so there was lots of manual data entry involved.


As I mentioned earlier, Heartland was the first full game to be delivered under the agreement between Odin and Telecomsoft, in fact it was probably one of the reasons the deal was signed in the first place. There was certainly pressure to complete games once the deal was signed, as we were supposed to completed 10 games inside of 1 year.

We actually hired a bunch of people to help develop those 10 titles (I did 2.5 of them, with Heartland Speccy, Heartland CPC and Sidewize), but it was hard to maintain quality and pace of development with the new hires. Frankly, there wasn’t enough management experience at Odin, and what had worked for one or two concurrent titles just didn’t scale well to 10 titles in a year. Doing so many titles in a year definitely drove down the quality of the games.

As far as I remember TelecomSoft had very little input on the creative direction for Heartland, they had some approvals, but generally left us to get on with it. They did start to take rather more of an interest in things as we approached the end of the 12 month period as it became clear that Odin was having difficulty delivering the agreed upon number of games. There were several visits during that period.

C64 & Amstrad Versions

I did the Amstrad CPC ports (both the cassette version and the disk version), and I had a lot of fun with that. I used mode 0 on the Amstrad, which gave the game a chunky, but very colorful look. I worked from home for a few weeks during this work, and it was a very productive time. The Amstrad version came together very quickly.

Colin created the mode 0 art, and even though the screen aspect ratio was different on the CPC, I made all the existing room layouts work OK with minimal changes (much to Colin’s relief!)

The music on the CPC version is derived directly from the Spectrum version. The Spectrum beeper track has 2 channels, so to fill out the sound for the CPC on the 3-channel AY chip I simply doubled up the lead line, detuning one of the channels by a small amount to give a “chorus” or “phasing” effect.

I had very little involvement with the C64 version of the game, other than some input on the data structures and graphics organization, and then to answer any questions that came up with the code. The C64 version was coded by Keith Robinson, and work started on the game after the Spectrum game was underway.

Random Trivia

While the working title for the game was “Kimera”, it turned out that there was another game by a similar name (Chimera), so the name Heartland was selected for the final game. By the way, Heartland is the name of a Sisters of Mercy song, and the lead singer of the Sisters of Mercy is Andrew Eldritch.

Other random trivia. After Odin had closed, Colin and I pitched a game called Heart of Yesod around to a few publishers. This was to be an Amiga and Atari ST game that brought the worlds of Nodes of Yesod and Heartland together. It was something like Nodes of Yesod meets Heartland by way of Narnia (there was a wardrobe involved) and Mr Ben. I have a copy of the typewritten backstory doc around here somewhere, but perhaps needless to say, that game did not get funded.

Final Thoughts

There are a couple of things I would do differently if I could do it over again. First, the mechanic for going through doorways is really fiddly! Should have just used two keys, one for “into screen” and one for “out”. More importantly, I wish there were platforms in the games. All action occurs at ground level, and you effectively play out a big maze. Platforms would have allowed us to create more puzzles, and opened up the game world somewhat.

Thanks to Colin’s art, Heartland is a very pretty looking game. As I mentioned above, certain aspects of the control scheme seem overly fiddly to my 2014 eyes, and I wish the game had more of a platform aspect to it, but overall I am reasonably happy with it. I especially like the Amstrad CPC versions of the game – the frame rate is higher and the game is more colorful there.

Posted by Steve Wetherill in Retro, Sinclair, Spectrum, 4 comments

ZX Spectrum Modifications

A couple of videos below that should be pretty interesting for fans of the good old ZX Spectrum. These are the first two parts in a series, with more major modifications (including making a portable Speccy) coming. Enjoy!

Updated Sunday August 24 2014: post updated with all three parts of the portable Speccy project. Disappointing that we don’t actually see more of the finished project. Kind of amazing that it works at all! Cool stuff though.

Posted by Steve Wetherill in Retro, Sinclair, Spectrum, 0 comments

Odin/Thor ZX Spectrum Games now exclusive to Spectaculator!

Robin-Of-The-WoodFurther to my earlier posts on the subject (here and here), I am happy to announce that the Odin/Thor ZX Spectrum games Heartland, Hypaball, Nodes of Yesod, The Plot, Robin of the Wood, Sidewize, Arc of Yesod, I.C.U.P.S and Crosswize are now available exclusively on SPECTACULATOR for iOS, Android and PC.

Many thanks to Alex Tutty @ Sheridans for his efforts to resolve the problematic licensing situation related to these games on a certain other emulator.

Posted by Steve Wetherill in Retro, Sinclair, Spectrum, 0 comments

Interview from 2012 on El Mundo del Spectrum

Check out this interview posted on the World of Spectrum site about my time at Odin Computer Graphics. The interview was originally posted in Spanish on the elmundodelspectrum.com site in May 2012, but I’ve never linked it from here.

Screen Shot 2014-02-16 at 1.22.44 AM

Posted by Steve Wetherill in Interview, Retro, Sinclair, Spectrum, 0 comments


Today saw the appearance of an article about the ZX Spectrum Bluetooth Keyboard in the Grauniad technology blog, courtesy of @alexhern.

While I have slight concerns over the title (the Kickstarter was not stalled, and in fact was successfully funded), the article contains an interesting angle on the issue of older games, and brings up the topic of “abandonware”.

When Alex pinged me for some quotes for his article, he asked me about abandonware, and my comments are contained in the article and excerpted here:

AH: While many gamers may think that software as old as that shipped by Elite Systems is somehow in the public domain, the truth is that games are covered by copyright in just the same way – and for just the same time – as other creative works.

“Older games are sometimes treated as ‘abandonware’”, says Wetherill, “which is an invented term used to justify the copying of games.

“I think people sometimes have the sense of, ‘I bought that game in 1985, why should I pay for it again’, but in that respect I think games are not really much different to other media – you can’t play your old vinyl records on a CD player, you have to buy the CD. On the whole though, in this case most feedback seems sympathetic.”

Some have taken exception to my definition of abandonware, but my point really is that if official versions of older titles are available commercially (through an emulator, say), and if you lose your original copy or if you can’t use it any more (in this case, because the good old Sinclair Speccy is obsolete), then it seems reasonable to expect players to cough up a couple of bucks for the supported version.

Posted by Steve Wetherill in Retro, Sinclair, Spectrum, 0 comments

Nodes of Yesod Music Remixes

Since I’ve been covering various game music remixes here I thought I’d post these links to remixes of the Nodes of Yesod music. The original music was by Fred Gray,  these versions originate in the iOS version of the game (the 25th Anniversary Edition).

I’ve included a couple of tracks, firstly, the main “theme” music. This version was created by Julien Nevo in MIDI format, to which I added instrumentation and production for this PCM version:

And then the in game “Moon Music” by Matti Paalanen:

Posted by Steve Wetherill in Music, Retro, Sinclair, Spectrum, 0 comments

HQX Scaling and Retro Video Game Art

A couple of years ago I became interested in methods of automatically “up-scaling” retro video game art for the high resolution screens that are everywhere these days, without generating a blurry mess. I came across the “HQX” algorithm, which is a pixel art scaling algorithm developed by Martin Stepin, and which is used in various places, including several emulators (such as NestopiaFCEUX and more). There are three hqx algorithms, corresponding to 2x, 3x and 4x scaling respectively. Code for the algorithm can be found here.

This weekend I was playing around with art from my ZX Spectrum game Crosswize, and I thought I’d share some of the results obtained by applying hq4x. The original art for the game was in typical ZX Spectrum “2 color with 8×8 pixel attributes” mode (though nicely done by Colin Grunes). What I’ve done here is first added some color shading into the low resolution art by hand and then applied the hq4x algorithm (the final result is unretouched, bar some cropping for inclusion here).

First example:

Original ZX Speccy image

Color shading added

HQ4X 4x scaled result

And another example:

Screen Shot 2014-02-09 at 8.57.36 PM

Original ZX Speccy image

Screen Shot 2014-02-09 at 8.57.43 PM

Color shading applied

Screen Shot 2014-02-09 at 9.16.52 PM

Resultant HQ4X image

I think the results are pretty remarkable! The resultant images remove any pixel stepping contained in the original low resolution image, and I think have a “retro” charm of their own. What may not be obvious here is that the original art is really tiny compared to the result – the original art is shown magnified using pixel quadrupling so you can compare the images. Also note that the “original” images are not quite the same as the colored and scaled ones due to simple laziness on my part – I just grabbed a similar part of the image because it was more convenient to do so.

Here’s an image at the original scale:


Image from ZX Speccy @ original scale

Posted by Steve Wetherill in Retro, Sinclair, Spectrum, 0 comments

More ZX Spectrum Nostalgia presented by Bernie Dugggs :)

Here’s a presentation given by “Bernie Dugggs” (Doug Burns) to a group @ an Oracle Users Group (I think ) a couple of years ago. Doug touches on some of the lessons learned early in his career while programming the ZX Speccy, and how those lessons are still useful today.


Posted by Steve Wetherill in Retro, Sinclair, Spectrum, 2 comments

Crosswize: ZX Spectrum. Self modifying Z80 code and the stack – a powerful combo!

The other day, I came across source code for Crosswize, a ZX Spectrum game I wrote back in the 80’s. Crosswize was written in Z80 assembly (of course), and featured a smooth-scrolling background, accomplished through a goodly amount of self-modifying code, along with the discovery that the fastest way to read and write to memory on the Z80 is to use the stack (if you can free up enough register pairs that is). The reason the stack is so fast is because the “push” instruction is encoded in only a single byte which specifies the 16 bit register pair to push (the source), and which naturally decrements the stack pointer before writing to memory when executed. Similarly, loading register pairs (using “pop”) from the stack is also fast, and that approach is also used here.

In the following code snippet (which is responsible for drawing 8 pixel rows of the smooth scrolling background), by the time the code gets to the label “push_00”, the register pairs AF, BC, DE, IY and IY have been loaded with pre-shifted bitmap data, and the register pair HL cleared. In a previous setup routine, the block of .db 0 starting @ label push_00 has been pre-populated with (using self-modifying code) a series of “push” instructions. The stack pointer (sp) is set to the byte just after the right edge of a screen pixel row. When the Z80 CPU executes the code following push_00, 16 bit values (corresponding to 16 pixels on the ZX Spectrum) are written to the screen from right to left (a push instruction first decrements the stack pointer and then writes the 16 bit value to the new location).

I had a struggle to find enough registers (as may be evident from the code), so ended up using push ix and push iy opcodes (which have an extra 0xdd or 0xfd byte prefix), so the “jp 0” at the label skip_00 is self-modified to jump into the correct spot in the buffer to allow for all combinations of 1 and 2 byte opcodes.

This code is rife with self-modifying code, a technique that is mostly obsolete today, but which was a handy tool for many Z80 coders back in the day.

ld hl, 0 ; SMC - source data
ld c, 2</code>

nop ; SMC
ld b, 8

ld sp, hl
ld hl, 0Ah
add hl, sp
pop af
pop bc
pop de
pop iy
pop ix
ex de, hl
ld sp, hl
ex de, hl
ld hl, 0 ; clear pixels

jp 0 ; SMC

push_00: ; push buffer SMC
.db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
.db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

inc d
djnz scan_00

ld de, 40BFh
dec c
jp nz, section_00
Posted by Steve Wetherill, 3 comments