Dec 152014
 

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:

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:

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 at 11:57 pm
Dec 032014
 

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 at 10:14 pm
Sep 172014
 
Heartland

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:

xored

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:

ored

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:

masked

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:

original

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

mask

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.

combined

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.

TelecomSoft

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 at 11:16 pm
Aug 232014
 

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 at 11:00 pm
Aug 132014
 

This may possibly jog a memory for Sheffield folk who went to school in the 70’s. :)

Where’s United gone – to division one!
Where’s United gone – to division one!
Far, far away
Far, far away

Where’s Wednesday gone – down the River Don!
Where’s Wednesday gone – down the River Don!
Far, far away
Far, far away

For reference:

 Posted by at 11:49 am
Jul 012014
 

Watter (rhymes with matter), which is simply water

“I’ll just ‘ave a drink o’watter”.

“Am not gooin’ to that pub, thi watter t’beer”.

Monk on. Somebody can be said to “have the monk on” if they are sulking, acting moody, or feeling sorry for themselves. Possibly arising from the vow of silence taken by some monks?

“She’s got the right monk on wi me”.

Gip. The act of being physically sick, nauseous.

“Just thinkin’ of eatin’ black pudding makes me want to gip”.

 Posted by at 8:53 pm
Jun 292014
 

Here’s a contribution from my Dad (thanks Dad!) This one is an old Yorkshire saying, words to live by. :)

Hear all, see all, say nowt, 
Eyt all, drink all, pay nowt,
And if tha ever does owt fer nowt,
Do it fer thi sen!

Or,

Hear everything, see everything, say nothing,
Eat everything, drink everything, pay nothing,
And if you ever do anything for nothing,
Do it for yourself!

Yorkshire folk do have a reputation of being “economical” …

 Posted by at 8:50 pm
May 012014
 

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 at 8:34 pm
Apr 202014
 

Yitten means “cowardly”, or “frightened”.

Example, “Tha’ yitten.” You are a coward/cowardly/afraid/scared.

Often used in an accusatorial manner, “Tha’ not goin’ darn’t pit cos tha’ yitten.” Or, “It occurs to me that the reason you do not want to go down the coal mine is because you are afraid.”

Another example, “Tha dun’t want to fight cock o’ t’class cos tha yitten.” Or, “Might I suggest that the reason you do not want to partake in fisticuffs with the acknowledged best fighter in the class is because you are a scaredy cat.”

 Posted by at 6:57 pm