Nodes of Yesod: ZX Spectrum Next – developer blog episode 2

As promised in the previous episode, in this (brief) update I'll delve into the tool selection process and talk a little about the setup I'm using for Spectrum Next development. First of all, I unashamedly admit that I am a Mac user. Nothing against Windows, or other OS choices, it's just something that I have gravitated to over the years, via iPhone development in the first instance, but also through working in the SF Bay Area tech bubble for the past several years. While there are a lot of great Mac development tools available, it seems that most (not all!) Spectrum development tools are for other operating systems, Windows primarily. I'm not a big fan of running virtualization software such as Parallels, Fusion or Virtual Box as these (in my experience) tend to be resource hogs (though I do use Virtual Box now and then, and it does have the attractive property of being free - that is to say Open Source Software). For the most part these days, in order to run a particular piece of Windows software on Mac, I've been using CrossOver, which is basically a bundled version of Wine for Mac and Linux (note that while Wine itself is open source, CrossOver is not). From the Wine site

Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.

In my experience, CrossOver works pretty well for most development tools, including the paint package ProMotion, and the Windows based Spectrum/Z80 assembler/emulator/debugger Zeus.

I really like Zeus, and the fact that it is a self-contained IDE for Spectrum development; however, even though Zeus has implemented a few of the extended hardware functions of the Spectrum Next (as of this writing, version 3.66 supports the Next hardware sprites), it is not the most up to date Next development environment. In a way, this makes sense, because many of the Next features are still "settling" in terms of final specs. Still, as I am committed to completing an updated version of Nodes of Yesod for the Next launch, I need something a little more current.

So, if not Zeus, what else? Well in terms of emulators there is ZEsarUX (which I can never pronounce, or remember how to spell - sorry Cesar!) which has some Next support and which'll run native on Mac. What I need though is an assembler, and the best one I have found so far is in the CSpect package, which as of this writing is at version 0.5. CSpect is a Windows based emulator/debugger that comes with an assembler, SNasm, which is tailored to the Next, and which is truly on the bleeding edge for feature parity with (and in some cases ahead of!) the Next. Importantly for me, this combination runs quite nicely in CrossOver on the Mac.

That's it for this update. In the next update I'll talk more about setting CSpect up to run with CrossOver and the Sublime Text editor on the Mac, along with the z80asm Sublime plugin.

Posted by Steve Wetherill in Retro, Sinclair, Spectrum, Z80, ZX Spectrum Next, 6 comments

Nodes of Yesod: ZX Spectrum Next – developer blog episode 1

Welcome to episode one of the Nodes of Yesod: ZX Spectrum Next developer blog. In this first episode, I'll cover "the story so far", which is basically a summary of the various Nodes of Yesod related efforts I've made in recent years, most of which were really just experiments, but several of these experiments seem to dovetail into the current effort - creating a version of Nodes of Yesod for the Next!

OK, so where to begin. The original version of Nodes was created for the ZX Spectrum back in 1985 (with versions for the C64 and Amstrad CPC). The Speccy version was written in Z80 assembler, as was typical for the day. Since then, I've created various versions of the game (for example, iOS, tvOS, Flash), but those versions use modern languages such as C++, Objective C and ActionScript, none of which are suitable for creating an updated Spectrum Next version.

Nodes of Yesod for tvOS

Arc of Yesod Unity experiment

In addition to the versions which were published, I've worked here and there on other experiments. My previous thoughts were along the lines of creating an updated (beyond the level of updates seen in the published versions) version of the game, but I've never been able to figure out the venue for such an effort.

One theme that seems to recur for example, is the idea of a smooth scrolling version of Nodes. Certainly, this would have been quite difficult on the original Spectrum machines as scrolling the screen is usually something that consumes a ton of CPU power and memory, not a great match for the humble Speccy. Still, this is something that appeals to me. 

Here's a video showing an experiment using Unity to display a smooth scrolling "Yesod" game (in this case using Arc of Yesod graphics).

Interesting as this is, it does not really help with a Next version. Or does it? Well, it might. Not that Unity is available for the Next, but the Next does now offer hardware scrolling, and hardware sprites! Still, the Unity version is not using original game maps, and I think that would be a good baseline for a Next version.

One other experiment I did was to take the original Nodes of Yesod map, and tried to come up with a tracking camera system that might allow for smooth scrolling within the confines of the original maps. See the HTML5 video grabs here for an example of what I mean.

Original Z80 disassembly

So, perhaps we can make a smooth scrolling version of Nodes for the Next? How do we start with that?

As I noted, there are versions of Nodes for various machines, but none of these codebases are suitable for targeting the Next. Another effort that I've undertaken recently is to disassemble the code from the original game. Sadly, the Z80 source code for Nodes has long since perished. That said, I am probably 90% done disassembling the original source code using IDA.

The Z80 code then, is available. The Next also has a 28Mhz mode, so perhaps using the C language becomes feasible, in combination with elements of the original Z80 code.

Given these, a plan starts to present itself. Here's what I am thinking:

  • Take the original maps
  • Retain the same main character (Astro Charlie) controls, for jumping etc
  • Implement a smooth scrolling camera, using the rails system demonstrated above
  • Add help and map functionality similar to the iOS/tvOS versions

As far as a graphics style, a set of colorful graphics was developed for the other versions, and these could be made to run on the Next; however, I am more partial to a sort of "enhanced, color-clash-less" look. It'd be something like the mockup to the right, masked graphics with a clear outline and zero attribute clash. I would be interested to hear comments on this approach.


Nodes Next mockup

For the avoidance of doubt, development of the actual Next version of Nodes of Yesod has yet to commence. That won't happen in earnest until I get access to hardware; however, in the meantime, a couple of the emulators out there are starting to support some of the Next features (sprites, scrolling) and selection and configuration of tools, along with other preparation can proceed.

In the next episode, I'll cover tool selection and start to get into more nitty gritty aspects of development. If anyone reading this has suggestions or other input for how I might tailor future updates, I'd be glad to have your comments!

Posted by Steve Wetherill in Retro, Sinclair, Spectrum, Z80, ZX Spectrum Next, 26 comments

ZX Spectrum 256 Byte Coding Competition

Here’s my entry for a recent Z80 Assembly Programming On The ZX Spectrum Facebook group coding competition.

The challenge was to come up with a game in 256 bytes without using ROM routines for the ZX Spectrum. Here’s my entry, “Infinite Blocky Runner“.

Source code is here. Some of the other entries to the competition were strong, all source code as well as playable demos may be found at the FB group (unsure if available off-group).

At the very least, this effort fits in (exactly) 256 bytes. I know of a couple of issues (the progress bar at the top will probably wrap in odd ways, should you progress far enough). There’s no audio, no difficulty progression, but you can at least die and restart. 🙂

I should add that I’ve embedded JSSpeccy, the JavaScript ZX Spectrum emulator here in order to run the game. On my laptop running Chrome, performance is not good. Seems to work OK elsewhere, so YMMV (let me know in comments if problems).

Press a key to jump. Enjoy. 🙂

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

Nodes of Yesod for Apple TV available now!

Nodes of Yesod for Apple TV is now here in all its retro glory!

Guide Astro Charlie through various moon caverns, defeating many monsters on your way. Collect 8 Alchiems to complete your quest!

In this enhanced version of the classic 8-bit retro platform game, you will find the complete original game, along with an enhanced version containing new graphics, new gameplay features, new audio, music remixes, and more!


  • Classic mode, with original 8-bit graphics
  • Enhanced mode featuring:
    • Enhanced graphics
    • Remixed music
    • Help system
    • Map mode
    • New game features
    • Resume feature to automatically save your progress
    • Support for Siri remote and official gamepad controllers (extended profile)
    • Find the Monolith, and help Astro Charlie escape from the moon!

Nodes of Yesod for Apple TV is $2.99






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

The Story of the ZX Spectrum in Pixels (volumes 1 & 2)

Back in late 2014, Chris Wilkins approached me to write a “memoir” for his upcoming book, “The Story of the ZX Spectrum in Pixels: VOLUME 1.

The book, which launched in December 2014, was the result of a successful Kickstarter campaign, and per Chris’s site:

The book, ‘The Story of the ZX Spectrum in Pixels‘, is 236 pages in length and finished to the very same high standard adopted for ‘The History of Ocean Software‘ and ‘The Story of U.S. Gold‘ publications . The ‘ Sinclair’ logo on the front cover is embossed making the book a desirable addition to any gaming fan or book collector

The book is predominantly a visual journey charting the best games on the ZX Spectrum from 1982 onwards until the early 90’s. Each spread contains a large iconic image of the game and is accompanied by artwork from the inlay, the game’s advertisement where available and further game screens showing the loading screen, menu etc.

We have also interviewed over 19 programmers, artists and musicians to get their view on the Spectrum and how it helped launch their careers into gaming including Rick Dickinson, the man who designed the Sinclair range of computers.

It’s an excellent read (my contribution notwithstanding), and recommended to anyone interested in the retro gaming scene (and specifically the Sinclair ZX Spectrum). Volume 2 is now well underway and available for preorder, having again been successfully Kickstarted, and I’m personally looking forward to reading it!

To (possibly) whet your appetite, here’s an extract from my contribution to volume 1:

The next year, back home in Barnsley, I bought a 16K Sinclair ZX Spectrum and 13” black & white TV, total price £200 in 1983 money from WH Smiths, with a lot of help from my Mum. My early recollections, upon acquiring the Spectrum, are spending hours and hours loading and exploring the Horizons tape, and then playing Manic Miner, Lunar Jetman and then later Atic Atac. I bought the Spectrum primarily due to my interest in electronic music, but pretty soon I was trying to figure out how to make games in Z80. I remember disassembling Time Gate by Quicksilver, and the minor epiphany when I finally understood LDIR for block byte copies. Thanks John Hollis!


Posted by Steve Wetherill in Amstrad, CPC 464, Retro, Sinclair, Spectrum, Z80, 0 comments

The “Sidewize Test”: ZX Spectrum floating bus shenanigans

Quite by chance, I came across a page on Chris Smith’s site: The Sidewize Test. Chris’ site focuses on “reverse engineering of the ZX Spectrum and related projects”, and this particular page is about problems Chris had running my game Sidewize on his Harlequin Spectrum ULA clone.

Sidewize is a game I wrote in 1987, and its one claim to fame/infamy is that it smooth-scrolls approx 2/3 of the Speccy screen @ a silky smooth 50 frames per second.

When I came across Chris’ site I was reminded of one of the tricks used in Sidewize to facilitate the smooth scroll. Back in the 80’s, before the Internet was a thing, information about computers and programming was often spread by word of mouth. And so it was, one fine day in Liverpool, in a conversation with Dougie Burns (programmer of HypaBall on the Speccy @ Odin), Dougie mentioned that his friend Joffa Smith had utilized an IO port on the Speccy to read the value of the current color attribute being written (by the ULA) to the screen, and that this was part of the secret sauce for the smooth scrolling seen in Joffa’s games (Cobra, for example). Being somewhat of a trade secret, the details of the port were not revealed, and so naturally I set out, by a process of trial and error, to discover it for myself – the utility of this being obvious.

On Chris Smith’s site, he extracted some Sidewize code that was causing his Harlequin Speccy ULA emulation some difficulty:

9CF4    LD    BC, 40FFh
9CF7    LD    E, 40h
9CF9    LD    A,R
9CFb    IN    A,(C)
9CFD    CP    E
9CFE    JP    NZ, 9CF9h
9D01    RET

In this code, you can see that I’m reading from port 0x40ff, checking for a value, and then looping if that value is not found. To be honest I am not clear what the LD A,R instruction is doing here (though I suspect this is related to the JP NZ,9CF9h instruction and possibly some self-modifying code to conditionally branch on the state of the Z80 parity flag which is set by the LD A,R), but generally this loop is waiting for an attribute value of 0x40, which corresponds to “bright black”, and this renders as plain old black on the TV screen (and so is visually indistinguishable from other parts of the screen). See the image below, which is a screen grab from the game:

Screen Shot 2015-02-24 at 10.13.10 PM


The area labeled below the active playing area is set to “bright black”. The above referenced code waits for the TV raster to reach the top of that area, and return flow back to the caller when that happens. Then, the game can start to redraw the screen, starting from the top, safe in the knowledge that game code will not cross with the raster and cause flickering or tearing. Ordinarily, program code can wait for the vertical blanking interrupt (typically using the HALT instruction on the Spectrum), but using the attribute waiting trick buys back a whole lot of extra time.

Chris’ site has a detailed discussion about the so called “floating bus”, which is the mechanism by which screen color attributes come to be on port 0x40ff. In my experimentation, I found that reading from port 0x40ff gave much more reliable results than other ports I tried. Chris’ site may shed some light on why that is (this address is in so called “contended” memory address space – memory that is accessed by both the ULA for screen updates and by the Z80 CPU). Perhaps the contention results in more “reliable” results when reading from that particular port?

Unfortunately, this trick is not very portable across the different ZX Spectrum models, being as it is “undocumented”. It’s also tricky to emulate, and the various ZX Spectrum emulators exhibit variable results in this area. Artifacts in the Sidewize game include flickering enemies and player weapon graphics (the walkthrough on YouTube suffers from these artifacts).

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

Orel BK-08 Russian Sinclair ZX Spectrum clone

So I’ve ordered one of these.

Orel BK-08 ex-USSR unofficial Sinclair ZX Spectrum clone.

It’s a ZX Spectrum clone built in the late 80’s / early 90’s in the ex-USSR (Ukraine). There were many ZX Spectrum clones manufactured unofficially in Russia, the particular example I have ordered (from eBay) is new, unused and sealed in its box.

It’s going to be a bit of an adventure to get this to display on a modern TV/monitor as it outputs a non-standard RGB + composite sync signal. In order to connect this to a modern (ish) VGA monitor, I’ve also ordered (from eBay, Amazon link below) one of these:

CGA to VGA converter

CGA to VGA converter

This board can take the low ~15Khz RGB signal in convert it to a VGA signal. None of this stuff has arrived yet, but I’ll post updates here later if I can get any of this to work.

Posted by Steve Wetherill in Orel, Retro, Sinclair, Soviet Spectrum Clones, Spectrum, Z80, 6 comments

Z80 Assembly for the ZX Spectrum

I recently joined a Facebook group Z80 Assembly for the ZX Spectrum which, as its name suggests, is a group focused on Z80 assembly language coding for the ZX range of computers.

The group recently organized a couple of casual Z80 coding challenges, the first of which was to fill the ZX Spectrum screen with a checkerboard pattern:

Something simple for the first challenge. Write the shortest code to fill the screen with a chequerboard pattern of 1 pixel squares. No RAM, ROM other than the 6144 byte bitmap screen memory should be written to.

Target: under 25 bytes.

1. Your program shouldn’t rely on the initial contents of registers.

2. Programs must return. The RET instruction is included in the size.

3. So everyone has a fair chance comment with the code size not code.

4. There are no prizes, just the chance to show off your coding skill.

This yielded some interesting solutions, the winning examples of which are archived here on John Metcalf’s blog site. The winning solutions came in at 15 bytes (see link), I could only manage 16 bytes:

checker_speccy:         ld      hl,$5700
                        ld      a,$55
l0:                     dec     l
                        ld      (hl),a
                        jr      nz,l0
                        dec     h
                        bit     6,h
                        jr      nz,l0

The next challenge was to mirror the ZX Speccy screen:

Something slightly more complex this time. Write the shortest code to mirror the entire Sinclair Spectrum screen (256×192 pixels) left to right including the colours / attributes. The deadline is Monday 15th, midday (GMT).

Target: under 50 bytes.Your program shouldn’t rely on the initial contents of registers.

No RAM/ROM other than the screen memory should be written to.

Programs must return. The RET instruction is included in the size.

So everyone has a fair chance comment with the code size not code.

There are no prizes, just the chance to show off your coding skills.

The winning solutions are again archived on John Metcalf’s site. The winning solution came in at 34(!) bytes; my effort came in @ a reasonable 38 bytes:

mirror_speccy:          ld      hl,$57ff

                        ld      a,1
                        rr      (hl)
                        jr      nc,l1
                        ld      (hl),a

                        dec     hl
                        bit     6,h
                        jr      nz,l0

                        ld      b,192+24
                        ld      de,16
                        add     hl,de
                        ld      de,hl

                        inc     hl

                        ld      c,(hl)
                        ld      a,(de)
                        ld      (hl),a
                        ld      a,c
                        ld      (de),a

                        dec     de

                        bit     4,e
                        jr      z,l3

                        djnz    l2


The Z80 programming prowess demonstrated by the winning entries is pretty impressive. The spec for the second challenge was to come up with a solution in the smallest number of bytes (which is not typical for real world applications), and I think many of us were thrown by this. For example, in order to save one byte in one of the winning solutions, Introspec observed that while seeking to load an immediate value of 0x8 in the B register, he already had the value 0x58 in the H register; the genius observation here was that 0x58 would do just as nicely as 0x8 since all that the value was used for was a loop count, and that rotating some registers around 88 (0x58) times is merely 11 times slower than rotating the same values 8 times, but it saves one whole byte, which is a win in this case!

Not that this stuff is directly useful in my day job, but I am definitely learning some new tricks here.

As an aside, I downloaded the excellent (and free!) “Zeus” Z80 development IDE by Simon Brattel for this stuff. The download (Windows only, unfortunately, but works well in VMWare Fusion on my Mac) can be found here, along with numerous example files. Zeus comprises an editor, assembler, disassembler, Spectrum Emulator and debugger. Highly recommended.

Looking forward to more of these challenges!

Posted by Steve Wetherill in Assembler, Retro, Sinclair, Spectrum, Z80, 5 comments

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, 2 comments