Jul 312016
 

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 at 8:47 am
Apr 112015
 

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 at 12:18 am
Feb 242015
 

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:

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 at 10:47 pm
Jan 152015
 

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 at 10:49 pm
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
Feb 092014
 

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.

 Posted by at 12:50 am