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, 8 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, 38 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

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 Fusionretrobooks.com 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 zxdesign.info 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, 3 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

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