Tuesday, March 07, 2017

RAMming in Some External Retrofits

2 comments
With the internal updates out of the way in the last 2 Retrofitting articles (Simple Start to Retrofitting a ZX81 and Advancing along with the Retrofitting of a ZX81), it's time to add an external RAM pack. Nothing unusual there, after all the first expansion (and possibly the only expansion) any ZX81 owner attaches to the back of their humble 1k micro is a 16k RAM pack. But this is 2017 and a simple 16k RAM expansion just doesn't cut it, and it certainly didn't cut it back in 2011 either, and so enters the amazing ZXpand, bringing RAM packs and ZX81s into the new millennium.

The Amazing ZXpand

ZXpand 


The ZXpand created by Charlie Robson is firstly a 32k RAM expansion, nothing odd there, however it's also an SD card reader, provides user configurable memory mapping, hires graphics modes, a reset switch, pads on the circuit board to add a joystick port and optionally (via an extra add on expansion) the ZXpand can accommodate an AY sound interface with a fully built in joystick port. For the moment I'm happy with the base model sans AY.

In a nut shell the ZXpand does for the ZX81 what the DIVIDE (in all it's incarnations) does for the ZX Spectrum. Coming pre-assembled, the ZXpand plugs right into the back of a ZX81 (or TS1000) and is ready to go. The build quality of the board is exceptional, and there are even little amusing gems of ZX81 lore written on the boards Silk screen layers.

If you need some convincing of the ZXpands merits check out VectrexRoli's typically flamboyant video review on the Youtubes.



The ZXpand is intermittently available on Sell My Retro, normally released in batches. You'll need to watch out for these appearing as they sell very quickly. The AY Sound interfaces seem to go at an even quicker rate.


ZXpand Needs a Case


Now for all it's merits the ZXpand comes without an encasing. The good news is that there are options, firstly if you have an existing Memotech RAM expansion, then you can gut that, make a minor modification, then slide the ZXpand into void.

The Elongated Cube ZXpand Board Enclosure


Alternatively, should the massacre of harmless ancient peripherals disturb your delicate sensibilities, or more likely you find yourself bereft of Memotech devices, then as luck would have it mhudson52 on Sell My Retro, has recently started producing 3D printed enclosures in various form factors. Models include a classic Memotech inspired design or the ever popular elongated cube form factor. Both versions have counterparts that allow for the AY interface. I obtained a rectangular version of the ZXpand Board Enclosure for my purposes.

The Enclosure  is a well designed smart little black case. The ZXpand fits very snugly inside, and the
whole unit nestles perfectly behind a grateful ZX81. Being 3D printed, the board enclosures finish is a little rough, so don't expect molded plastic perfection.

The only minor short coming in the cases design is the slightly diminutive hole at the back for accessing the ZXpands momentary reset / NMI switch. In order to press the switch through the case you require something the width of a knitting needle or a thin tablet stylis.

Wire Soldered to the ZXpands Pads


Adding A Joystick Port 


ZXpand Joystick Solder Pads
Adding a joystick port to the base ZXpand requires a little soldering, a DB9 male connector, and the usual assortment of wires. The location of attachment points / pads are outlined in the ZXpands manual and these can easily be hooked up to a male DB9 solder-able connector. Wiring should follow the standard Atari 2600 joysick pinouts.

As I intended to attach the  joystick port to the ZXpand Enclosure, I figured the best way would be to separate the metal casing on the DB9 connector. This would allow me to attach the connector to the inside of the enclosure and at the same time cover up any defects created when making some necessary holes in the enclosure on the outside.

Atari Joystick Port Pinout
Atari Joystick Port Pinout
DB9, with Metal Surrounds Separated
The two metal halves of the DB9 connector are pressed together, a lip in the bolt / screw holes keeps two halves firmly in place. To separate them you can file away the lip around the bolt holes. Once separated connecting wires from the ZXpand joystick pads can be attached to the back of the DB9 shell.

After some examination and testing, I found the most convenient location on the enclosure to place the DB9 connector was at the bottom right. This placement allows the ZXpand to slide in and out of the case without hindrance from the DB9 connector.

Using the outer metal shell of the connector as a template, the placement of the joystick port can be marked out before cutting into the case. I used a Dremel like tool for cutting into 3D printed case. You need to be careful and take your time, as printed plastic likes to re-melt when heated by friction generating power tools. Regardless of how genteel one is, the process will most likely leave a rough edge that needs to be carefully filed away by hand.


The Back of the ZXpand Enclosure, With Holes for the DB9 Connector and Mounting Bolts Cut Out

Joystick Port Mounted
Mounting the DB9 connector is straight forward, if a little fiddly. The enclosure is a little flexible and the mounting point I chose is rather close to one of the ICs on the ZXpand. For this reason I chose to use plastic bolts and nuts for mounting; I didn't want some accidental short circuiting taking place when inserting a joystick.

As the case is designed to fit the ZXpand snugly, the wires to the joystick port had to be routed via the bottom of the enclosure, not a major issue, as these can still be tucked up inside the case mostly out of sight and definitely out of the way.

Joystick Port as seen from the Rear of the Enclosure.


It should also be noted that there is no standard for Joystick interfaces on the ZX81. So much of the software supported by the ZXpands Joystick port has been adapted by the community. There is a list over at the Sinclair ZX World forum of some of the supported tittles.


Getting to that Reset Button


Fully Sprung Reset Tube
As mentioned earlier, the case design makes is a little challenging to access the reset / NMI switch. With fate on my side and some creative thinking I had the means to bodge up an effective solution to that minor issue.

In my draw of miscellaneous items I found a small aluminium tube with a handy flange on one end. The rim fitted over the momentary switch perfectly and the barrel was the perfect length and width to fit through the reset hole on the ZXpand enclosure.

To complete the switching mechanism, a spring extracted from a donor retractable biro was cut down to size, fitted over the tube, and a perfect rest switch was in place.

Another option for the reset switch length problem would be to de-solder the existing SPST momentary push button, replacing it with a longer stalked equivalent. This one from Altronics would do the job quite nicely, any components vendor should have similar items.

So that's it, a ZX81 fit for use, super charged and in better shape than it was 36 years when rolled off the Sinclair (ok Timex) production line.

ZXpand / Enclosure attached to the ZX81. The Reset Switch is the Perfect Length



For full details of the Retrofit, see See  Part 1 and Part 2 of this guide.


Read More

Sunday, February 19, 2017

Lode Runner on the ZX81 - Part 2 (Level Design)

Leave a Comment
There are going to be numerous challenges facing the design and implementation of Lode Runner on the ZX81, and one of the first I need to consider is level storage.

The original Apple II version of Lode Runner comprised 150 levels, these were loaded from disk when required. The ZX81 doesn't afford us the luxury of being able to load from a disk or tape without clearing the running application and memory. So even if we assume our ZX81 has 32k of RAM (about the maximum for the time), squeezing all 150 levels into the diminutive black box is an insurmountable task.

There are modern storage solutions available such as the ZXpand, that could be used to negate the space restrictions, however there is no common file access method shared across these modern deceives. So regardless of current available solutions, the challenge here is to fit as many levels as possible into the resources we do have at our disposal.

To make the challenge slightly easier I'm going to base the level design on the Apple II version, not the (possibly expected) ZX Spectrum incarnation. The reason for this is a simple matter of level storage space. The Apple II maps are a convenient space saving 28 wide x 16 tiles high, where as the Spectrum versions comes in at 32 wide x 22 tiles high. Or to put it another way, 448 tiles on the Apple version versus 704 tiles on the Spectrum version per level to define.

If we look to any "type in" game from the period as a (bad) example, most defined entire screens in the program listings on a one to one tile basis. This method would uses 1 byte per tile, and clearly there is not enough space in a ZX81 for even 10 levels defined in this manner (and still have a game to play). It's imperative to compress each level down as far as possible.

The solution is to store the tile type and the number of tiles(of the same type)  in succession into 1 byte. To achieve this, we can use two 4 bit numbers. This affords us up to 16 available tile types, and 16 successions of that tile. Wwe add the number of tile repeats, 0 to 15 to the tile type value. The tile type value is bit shifted before the addition, and this will produce an 8bit number we can store.


Lode Runner Map Tiles: 4 bit Number Values Chart
Tile No4 Bit ShiftedLevel Starting Position Tile Type
000000Empty: Clear Tile / Background
001016Block: Can't dig through tile
002032Bricks: Can be dug into to create traps
003048Bricks, Fake: Player falls through fake bricks
004064Rope: Player can move horizontally, or jump down
005080Ladder: Visible all game / level
006096Ladder, Escape: Visible only after all gold is collected on a level
007112Gold: Player to collect all gold
008128Guard: Starting position of Guards. After level begins guards fall from the top of screen (after being trapped).
009144Player: The Lode Runner


For example, using the table above, if we require 4 Bircks in a row, we take the value of Bricks, 32 and add it to the number of required repeats 3, for a total of 35. In, in order to produce the entire starting positions of the first level of the Apple II version of Load Runner, each of the 16 rows would be defined as bellow.

01) 15,1,96,8,
02) 3,112,12,96,8,
03) 38,80,38,2,96,8,
04) 6,80,73,96,3,112,3,
05) 6,80,3,33,80,2,38,80,33,
06) 6,80,3,33,80,9,80,1,
07) 4,128,0,80,3,33,80,9,80,1, (missing right guard and gold)
08) 33,80,36,3,39,80,38,
09) 1,80,15,0,80,6,
10) 1,80,10,128,4,80,6,
11) 40,80,41,80,6,
12) 8,80,9,80,6,
13) 6,112,0,80,73,80,2,112,2,
14) 3,80,37,8,38,80,
15) 3,80,8,144,1,112,8,80,
16) 47,43



Lode Runner, Level 1, Apple II Version

After reading the level data as outlined, the ZX81 level would look something like the bellow screen shot (if using standard character set, no hires graphics yet). Notice that the the escape ladder is drawn in with the "S" character.

Lode Runner, Level 1, ZX81 level Map., Starting Position.


Rather than guess the levels layout, I converted directly from the LodeRunner TotalRecall levels, as (re-)implented by Simon Hung. The TotalRecall levels are implemented in ASCII, which makes reading them easy. The ZX81 map is missing the 2nd guard and gold on line 7, I overlooked these items when writting up the test.

That's all for now, be assured I'm still wotking away on the project, it's just going a little slower than anticipated due to some time and life constraints.
Read More

Tuesday, February 14, 2017

Advancing along with the Retrofitting of a ZX81

Leave a Comment
At the end of the last article, 'Simple Start To Retrofitting A ZX81', a new power supply was sourced and a composite video mod was fitted. This entry sees the near completion of the internal retrofitting project; where some capacitors are replaced, a new voltage regulator is fitted, a lower Amperage CPU inserted and some heatsinks affixed.

Replace Those Old Capacitors


Over a number of years, particularly if exposed to continual high temperatures, electrolytic capacitors tend towards failure. While there is no obvious evidence that the capacitors in my ZX81 have bitten the dust, they are 35 old and probably due for replacement even if purely as a precautionary measure.

Depending on the Issue number of a ZX81, there will be either 2 or 3 electrolytic capacitors on the main board. I have an Issue 1 USA board, as such there are 2 capacitors I'd be replacing. The caps are numbered C3 and C5, are located up the back of the ZX81 PCB, to the right of the modulator and left of the expansion edge.

New Capacitors in Place
Visually the 35 year old capacitors seemed okay, there was no tell tale bulging, or leaking of electrolytic fluids. What wasn't so brilliant was the illegibility of the markings on C5, as the the outer plastic / paper casing of the Caps had shriveled over time (and heating). Handily the ZX81 Service and Assembly Manual is available from numerous online services, confirming the values required:

  • C3 22uF Electrolytic 16V minimum
  • C5 1uF Electrolytic 5V minimum

Both the existing capacitors had voltage levels specked well over the minimums at 50V. Higher voltage ratings are a good thing for capacitors, as a higher voltage rating will prolong their life expectancy. I had some 63V Electrolytic 22uF and 1uF caps at hand and so simply swapped those over for the existing ones.


Switch Mode Regulator


Heat is possibly one of greatest enemy of the aged microcomputer, and lurking inside a typical ZX81 are two major heat manufacturing components, the ULA and a linear voltage regulator. The ULA we can't do to much about, however the regulator can be replaced with a modern switch mode equivalent.

7805 Regulator and Replacement Recom R-78B5
Linear Regulators can get quite hot as all excess energy is converted to heat, the higher the voltage drop required the hotter the regulator becomes. As the case of the ZX81 has minimal ventilation this heat has very few places to go. Modern Switch mode regulators on the other hand produce very little in the way of heat, and no heat equals no ventilation problem.

There are a number of manufactures producing switching regulators, I'm using a Recom R-78B5.0-1.0L, which I sourced from Element14. If  you're conducting a similar mod, the main things to be sure of are that the switching regulator is a drop in replacement for 7805, is 5 volts and rated at 1A or 1.5A. (2A is overkill, unless your ZX81s controlling a nuclear power plant)

The voltage regulator is not hard to spot, it's attached to what looks like a tractor part, or aluminium heatsink if you prefer. If you ever wondered why your left hand got so toasty on a cold winters night programming (OK gaming)  on your ZX81, this thing is the most likely culprit.

Recom R-78B5 In Situ
I started the process by removing the bolt which secures the heatsink to the 7805  and circuit board, once unscrewed the heatsink slid out easily. The heatsink is not required after fitting the new regulator.

Removing the 7805 regulator itself proved slightly trickier due to the large amount of solder holing it in place, plus there being a channel selection switch (being a USA ZX81 variant) and some rubber like trim isolating the switch from the 7805 obscuring the pins at the base of the regulator. In the end I found it easiest to remove the channel selection switch before finally removing the 7805. Note that the process of converting the ZX81 to composite video out, had already made the channel selection switch redundant so decided not to reattach it latter.

The Recom R-78B5 dropped in easily and after soldering it to the board I powered the ZX81 on with no issues or incidents. The only thing to notice is a comparative drop in heat production, the keyboard certainly won't be roasting slowly over an aluminium hot plate anymore.


Cooling the ULA


Self-adhesive Heatsinks mounted onto the ULA.
With the heat now taken out off voltage regulation, this leaves the ULA as the only other major heat source. While there is no easy way to extract radiant heat from the ZX81 case, the overall temperature level inside has vastly subsided.The heat generated by the ULA is now able to permeate the cool void sans 7805. Hopefully attaching some self adhesive heatsinks to the ULA will help keep this vital part a little cooler in general, prolonging its lifespan.

I used two self adhesive heatsinks sourced from Jaycar, laid end to end on the ULA, these are a little overhang and don't quite cover the whole chip. If you're a little more OCD, then it is possible to track down exactly fitting 40 Pin DIP IC heatsinks at specialists stores like Retroleum, or more general and extensive component suppliers such as Element14.


CPU for a CPU, a Fair Swap


Swapping out the existing CPU is more about power consumption than anything else. There are no gains to be made in speed or reliability (unless the old CPU is on the blink of course). The original CPU in my ZX81 was Z80A  made by NEC an NEC - D780C NMOS chip. NMOS chips use quite a lot more power than the more modern CMOS equivalents.

An NMOS Z80 CPU requires  200mA, where as a CMOS Z80 CPU requires only 20mA when running at 4MHz. Considering I dropped the theoretical output of the regulator by 500mA when replacing the the linear regulator for the switching regulator that's a saving worth making.

You can drop in any 40pin DIP 8bit Z80 processor, no matter what the MHz rating. The CPU will only work as fast as permitted by the ZX81s oscillator circuit set at 3.35MHz. My drop in replacement is a 10MHz Zilog Z80.

Z80 processors are still readily available, they come up on Ebay (though proceed there with caution), specialists stores such as Retroleum, and once again though I procured mine via Element14.


Next Time


I still haven't covered everything, I'll attempt a summing up of the (semi) final fixes and extras and addons (which I failed to get to this time), next entry.

See  Part 1 and Part 3
Read More

Friday, February 03, 2017

Simple Start to Retrofitting a ZX81

2 comments

My Sourced ZX81 was Modified for the American Market
Having played around with emulating the ZX81 as part of building a Raspberry PI / Arduino platform in the AZ15, I thought it might be fun to revisit the real device.

To start I'd be needing a ZX81, a process that proved trickier than anticipated. There should be no shortage of ZX81s in Australia, yet they seem sparse enough to command high-ish prices, high enough to send me searching further afield. European and UK prices again seemed rather expensive, particularly if including postage. So to the USA then, a Timex 1000 would be just as acceptable, in the end I found a reasonably priced American fitted out ZX81, obviously sent to the new world before the official deal between Timex and Sinclair.

So what exactly can be done to update and bring a ZX81 into the now? Well, there is a great deal of information out there concerning the upgrading, modifying and repairing of ZX81s. Should you decide to do everything from scratch the information and resources are available. However the really good news is that many of the parts required for a refurbishment and upgrade can be bought right off the shelf.


New or Replacement Power Supply


Before even turning on my ZX81 for the first time (in my possession at least) I needed a power supply, my unit came sans power brick. While I had no option but to source a new supply, it's recommended that even if you still have an original Sinclair unregulated power brick that you should still replace it with a switch mode equivalent.

An original Sinclair unit is rated at 9V, however as the supply is unregulated that can get as high as 12V, this leaves the ZX81s internal regulator doing all the heavy lifting. Governing the required 5v (down from 12V) leads to an excessive amount of heat being generated inside the case.

You can use a regulated power supply of anywhere between 7.5V and 9V with a minimum 1000mA (1 Amp ) current draw. The easiest or most available substitution seems to be regulated 9V supply. The power supply should also have 3.5mm phono plug jack plug at the business end. Power input of +7.5V to +9V should be at the tip of the plug, with the lower / outer ring being ground.

I picked up an appropriate Switchmode Plugpack 9VDC 1.66A from Jaycar (Australian Electronics Chain), the unit provided a variety of jacks that can be substituted as or if required. Similar Plugpacks should be available just about everywhere. Ebay often seems to have packs marketed as being specifically for the ZX81.

Optionally a power switching cable can be added between the supply and the ZX81. This will save some wear and tear on the ZX81s power socket These can be made easily enough, or purchased from specialist suppliers such as the Retro Sparse Shop, that's if you don't want the hassle of tracking down appropriate parts yourself and in all actuality might prove more cost effective.


Composite Video Output


The second thing in need of attention is the video signal. as the combination of modern (not the best quality admittedly) LED TV and RF signal emitting from the ZX81 is terrible to say the least.

There are various video mod available that will provide composite video out, ranging from ones that you can build yourself to others ready to fit into the case with minimal fuss. I've gone with an off the shelf fix in the form of the ZX8-CCB, a video mod created by the venerable Pokemon. The ZX8-CCB is available from The Sell My Retro website. Before going into the fitting of the ZX8-CCB, lets quickly look at other composite video mods.

If you choose to build your own then it would be hard to do better than the mod by Joulesper Coulomb detailed in the YouTube video, 'ZX81 Video Conditioning'. A lot of effort has gone into the mod, and spectacular results have been achieved, which can clearly be seen in the video. Minimal parts are required to undertake the modification, it is easily assembled on strip board and once built, the entire project can be housed in the existing ZX81s modulator case.

There are slightly easier mods to build yourself, most of these use a single transistor and a some resistors, such as the simple mod by the ZX-TEAM. You can see the results of that video modification on Terry Stewart's (retro computer collector extraordinaire) web page. However, these simple mods may not work so well with earlier issues of the ZX81 due to a missing back porch signal, and possibly leaving the resulting picture a little on the dark side.

For off the shelf options, there is the Atari (yes you read that correctly) composite video mod for the ZX81, sold by The Future was 8 bit. Dave Curran on his Tynemouth Software Blog, details the fitting of this interface to great effect. Lastly (of course there are bound to be more), there is the Sinclair ZX81 ZXVid - Composite Video/ULA Fix, available from Sell My Retro. You can see the results of this mod on the YouTube video ZX81 - ZXVid board, Composite mod.


Fitting the ZX8-CCB


The process of fitting the ZX8-CCB is very well documented in the instruction sheet supplied with the kit. There is no assembly of the kit required, and it's down to a little soldering to the ZX81.

To start, it's simply a matter of attaching the input wires to the back of the ZX81 circuit board: red wire +5V to ULA pin 40, the black wire 0V to ULA pin 34 and the yellow wire to video In at ULA pin 16.

For the output wires you have a choice to make, either integrating a small video jack (3.5mm) between the two cover parts (as suggested in the instructions sheet), or re-purpose the modulator casing. The second option is what I decided to go with.

In order to fit the ZX8-CCB into the modulator case, the case needs to be removed from the ZX81 circuit board. There are 2 or 3 wires going into the side of modulator, these can be trimmed of at the base, or de-soldered. Also there are two large pins directly underneath the modulator, these hold the modulator unit in place. These also need to be de-soldered to remove the modulator from the ZX81s circuit board.

Once the modulator casing is free from the ZX81 you can then set about removing the existing contents (though a combination of cutting and de-soldering). What's inside the box will vary depending on the modulator, on PAL models there is a cross bar and the main circuit board to remove, as I have a USA model there was no crossbar.

ZX81-CCB Input Wires Soldered at the Back to the ZX81 Circuit Board


After the modulator has been gutted it can then be re-attached to the main circuit board, with the ZX8-CCB placed inside the casing affixed with a square of double sided tape. The remaining wires are then attached: brown wire for video out to the center of the phono socket, and the the black wire 0V to to the side of the modulator casing.

ZX81-CCB housed insdie the Modulator Case. (Wires latter moved to run through vaccant holes in the casing)


In the initial fitting I had the three wires which are soldered to the ZX81s circuit board running over the side of the modulator casing. With the modulator lid placed back over the top, this was perfectly serviceable but looked a little untidy. I latter decided to move these wires and have them running through the now vacant holes (of which there are three) on the side of the modulator.


Composite Results


So what of the results? In a word 'amazing'. It is unfortunate that I don't have a CRT TV laying around to give the proper picture, though even upscaled through a composite to VGA converter box the clarity is almost as clear as on many an emulators, it's certainly the best video I've even seen emanating from a ZX81.

After Composite Video Mod (with a little HRG graphic teaser)

Of course I'm not the only one to have retrofitted a ZX8-CCB to a ZX81, these things sell like hotcakes. And as is the way with these thing, half way through typing up this post I found another blog post detailing a similar install of a ZX8-CCB. I'd suggest checking out Kevin Phillip's entry 'Rejuvenating My Geriatric Childhood Friend' for extra information. The better you're informed before making any medications there better.


Next Time


There are a couple more modifications I'm wanting to make, along with a couple of interface addons to try out. (Hint one of the is in the final picture). I'll get around to detailing those and more soon.

See  Part 2 and Part 3

Read More

Monday, January 09, 2017

Lode Runner on the ZX81 - Part 1 (The Intent)

Leave a Comment

There are games and then there are the games we wished existed on the ZX81. For me, Lode Runner falls firmly into the second category.

Lode Runner was and still is ubiquitous, making an appearance on just about every 8 bit system to crawl out the 80s micro computer swamp. From its inception on the Apple ][, ports have made their way to the BBC, the NES, the SEGA SC3000, the Atari XL/XE, the ZX Spectrum and hell it even even made it onto the Vic 20. But yet the poor old ZX81 missed out, this is of course due to the rather obvious lack of a suitable graphical display capacity.

But I say enough excuse, It's time to write a great historical wrong and bring once and for all a (probably rather cut down) version of Lode Runner to the ZX81.

So there it is, a statement of intent, (mainly to ensure that I stick with what I'm setting out to achieve) that over the ensuing months I'll slowly document the process of either failing miserably or succeeding gloriously in the (re-)creation of passable version of Lode Runner on the ZX81.


Read More

Thursday, December 08, 2016

ZX81 Draughts Challenge - Part 3 - Tims Checkers

Leave a Comment
As this whole little (and I say little in heavy quotes) escapade has been inspired by two very informative ZX-Computing articles penned by the late great Tim Hartnell, the game he inspired now bears the official title of "Tims' Checkers".

And as such this is now the official announcement and launch of the hightly anticipated, completely compelling retro-tastic ZX81 game "Tims' Checkers".

After the last blog entry I had hopped to have a couple of varieties of checkers available in the one game, unfortunately this was not to be. No doubt some of this is down to some slightly shoddy C programming, however there is one very valuable lesson to be learnt when using the WRX hires graphics mode in z88dk, namely that you loose at least 4k of valuable game writing space to the hires graphics screen itself. So what this largely means is that in order to keep the game within 16k limits, some things just had to be dropped.

Would You Like to Play a Game?
So yes due to space constraints I've had to drop the multiple game play options, there is no option to play Spanish checkers or Corners as originally envisaged, instead what we do have is a full-ish checkers implementation.

The computer player has been enhanced from the basic opponent provided in Tims' ZX-Computing articles. Although again due to the self imposed space issues the ZX81 is not the most brilliant of strategists, yet competent enough to play an enjoyable and somewhat surprising game.

Basic Rules:

  • Men may move and capture only diagonally forwards.
  • Kings may move and capture diagonally forwards or backwards, but can not jump over empty squares.
  • If a player is in a position to make a capture then a capture move must be taken. If there are multiple capture options the player is free to choose. Once a man or king has captured that piece must continue to capture until there are no more capture options available.
  • If a man lands on the final row, the row furthest from a players starting position, the man is kinged.

A Bit Further in. The ZX81 has KInged.

Playing The Computer:

  • Select if you or the ZX81 goes first.
  • Use standard algebraic notation to enter moves.
  • There is no backspace, so if you start to enter the wrong move just make the rest of the entry an impossible move.

Really there is not much to it, after all checkers is a simple game and perfect for the ZX81. I'm considering this to a beta release, if you the prospective player find any glaring errors then please feel free to report them.

Download Tims' Checkers and give it a go in your favorite ZX81 emulator. Remember that you'll need to enable WRX graphics in your emulator to play correctly.

Read More

Monday, November 14, 2016

ZX81 Draughts Challenge - Part 2 - A Little Hi-Res

Leave a Comment
In the last post I took up a challenge set by Tim Hartnell 34 years ago, namely apply his BASIC ZX81 board games layout to multiple draughts games types. In this entry I'll delve into some of what's been put together so far.

In the Dec / Feb 1983 edition of ZX-Computing, Tim presented two versions of his finalised BASIC listing, one that plays the Corners variant of draughts from the previous ZX-Computing article, and another version that implements a Spanish checkers style game. The other standout new feature is the addition of a full screen and
 somewhat more graphical checkers board.

As graphics are where it's all at these days, best to start by bringing some major graphical improvements to Tims' Board. As covered last time, I'm developing (or is that re-developing?) the draughts game using the brilliant  Z88DK / C compiler. Of course C in itself does not have any real graphical capabilities, but thankfully within Z88DK are a host of ZX81 (and other micro-computer) targeted graphical options. Desire Hi-Res graphics on a ZX81? Yes we do. Well Z88DK has them, so of course we're going to be using those.

Draughts Board in Hi-Res ZX81 Style
There are three main parts to how I approached drawing the board and game men. Firstly, you can print regular characters with a simple printf("blah") statement, or the ZX81 character can be got at by switching with the zx_asciimode[0] command. More importantly the ZX81 BASIC "PRINT AT" statments are also catered for by Z88DK with the provision of the zx_setcursorpos(Y,X) function. Armed with these tools, the underlying checker board can be printed up quite easily.

Secondly, some nice Hi-Res flourished are easy enough to factor in with ZX88DK draw functions, such as drawing a boarder with drawb. All quite straight forward, with the exception that the Hi-Res screen does not allow normal characters to be output directly, as a different memory area is allocated to Hi-Res Graphics, one that swaps out the normal display page for its own. Again however once again there are commands for that. Anything written to the normal display can be copied to the Hi-Res display with a variety of copytxt() function options. So that's most of the standard display options accounted for.

Draughts Board Set up for Spanish Checks.
Thirdly, and lastly, the game men / pieces: There are options to define sprites for use with Z88DK, the men could have been created via this method, though at least for now, I've not used this functionality. Instead I've implemented a kind of User Definable Graphics option for the game men. The men are plotted via the Hi_Res functions onto the game board, thankfully this option is quite fast, and adds a nice animation quality. The UDGs are quarter of a full game piece, and credit to goes to the speccy_charater_builder website for making prototyping the men painlessly. The same UDG is used for both player and computer opponent. King pieces have also been defined for use in a fuller draughts game than described in the ZX-Computing articles.

That's it for the moment, in Part 3 I'll cover further graphic details as they affect the general game play and setup. I should say Games set up, as there are to be multiple draughts variants to choose from before the start of game play.



Read More

Sunday, October 23, 2016

ZX81 Draughts - Challenge Accepted 34 Years to Late

Leave a Comment
Way back in 1982, Tim Hartnell wrote the first part of a two article series detailing a method of creating board games on a computer for ZX-Computing magazine. At the end of the feature Tim expressed a desire to see what people made of his system, and send in their own programs derived from the article listings. Even though 34 years have passed since the article was first published, I thought I'd give it a shot. (Sadly Tim passed away in 1991).

Actually this is a multi level challenge, as I'm using Tims program and system to fiddle around some more with Z88DK, the C compiler for Z80 processors. Alongside this, I thought it would be interesting to see just how much faster a complied C program would run in comparison to a native ZX81 basic listing.

Tim Hartnells' Corners Program from 1982
I started by simply entering the listing as presented in the original feature, 'Board-Game Design' that can be found in ZX-Computing from Oct/Nov 1982. The entered program plays a fun rudimentary game of draughts, called Corners. Being a BASIC listing, the speed of the end result is best described as painfully slow. Of course given that we are talking about a BASIC program form 1982, written for a computer as simple as a ZX81, playing any sort of board game would have been considered a minor miracle at the time.

Next came a nearly straight conversion into C. I've pretty much used the exact structure of Tims' program as far as possible, in writing a version that would compile in Z88DK. Also none of the the more fancy features provided in the exteneded Z88DK ZX81 libraries were used (or for that matter any advanced C programing techniques) which is one reason why as you will notice when running the complied version that the screen redraw is not particularly seamless.

Z88DK complied C version of Corners
I did make some minor changes, the most noticeable being the layout, this is purely cosmetic, Another change, or rather oversight, I assume the Player always goes first. The real change was to add some extra checking into the validity of the Human players move. The original program assumed that the player was a humble honest sole, and never felt the need to cheat. That assumption also had a side effect of the program not checking the players move was even possible, and if not, the players move was basically ignored and the computer would gain a free turn.

In the end we have 2 quite passable ZX81 Corners (draughts) playing programs. But what about the speed test? Well the speed results are quite dramatic. The BASIC listing clocks in at around 12 seconds, just setting up the board in the background for the initial run (not including drawing the board itself). The Compiled C version takes about 2 seconds, including the initial board drawing. The overall speed difference just becomes more apparent from there on in.

Having tried out the BASIC listing and equivalent in C, it's now it's on to extending the program as Tim suggested. I'll continue to base the next version on the original idea. There is also the second article in the Dec 82 / Jan 1983 edition of ZX-Computing to peer into before proceeding.

Both versions of the Corners program are available in separate P files contained in zx81_corners_c_and_basic_files.tar.gz, and should run on any ZX81 emulator.

Hopefully soon I'll have a fine ZX81 board game playing program, 34 years after the initial call to action.
Read More

Sunday, October 02, 2016

Arduino Liberates the Recreated ZX Spectrum

Leave a Comment
Following on from the previous posts, in some free time this week, I butchered my ZX81 / AZ15 Arduino keyboard sketch libraries, sliced in some code for a USB host shield and beat an Arduino Leonardo into submission. The end result a fully working Recreated ZX Spectrum keyboard.

As talked about previously, the Recreated Spectrum has two keyboard modes, one for PS2 functionality and one for Emulation. The odd thing here being that in Emulation mode, the Recreated Spectrum is not compatible with the vast majority of Spectrum Emulators (at least at the time of writing). Disregarding this; Emulation or Mode 'A' as it is labeled, is the easiest to target for any external hardware solution used in remapping the Recreated Spectrum's keys in order to provide a Normal Spectrum Emulator experiance. See the previous post for a deeper explanation.

Emulation mode was quite straightforward in it's implementation, being that all keys are registered when pressed or released, if in a slightly odd way. It was a simple matter of matching the codes the Recreated Spectrum passed out on each of these events with the actual keys.

Once Mode 'A' was covered, it was time to move onto Normal / PS2 mode (Mode 'B'). Normally to enter either Mode 'A' or Mode 'B', a slider switch on the keyboard needs to be placed in the correct position. I decided that if using an external device to do the decoding, this mechanism would become problematic. Having already decoded Mode 'A' for usage, adding a simple keyboard selection would be simpler way to manage switching into Mode 'B' or vice versa. As a result, Mode 'A' is permanently set to on, at the back of the Recreated Spectrum, "CAPS SHIFT" + "SYMBOL SHIFT" + "ENTER" now changes modes on the external Arduino Leonardo based solution.

All key-mappings as described in the Recreated Spectrum's manual and Cheat Card remain the same, with the exception of the Windows, and Print Screen Keys which have been left unmapped at this stage.

While I've used a Leonardo and full sized USB host shield initially, there is no reason why a Pro Micro and mini USB host adapter could not be used to do the same thing. In fact one of the next steps could well be to do just that, along with mating the whole arrangement with a Raspberry Pi in a custom Sinclair inspired case.

For those that feel like a little experimentation, feel free to mess around with some hot of the presses Recreated ZX Spectrum Arduino Sketches. I'll be making changes regularly and the latest changes will be on the 'Recreated Spectrum Project Files to Download' page.

Also, make sure you download and install the Arduino USB_Host_Shield_2.0 libraries from Github before compliling the Recreated Spectrum Project Files.


Keyboard in Action

Read More

Saturday, September 24, 2016

It's all in the Modes & Mappings of the Recreated ZX Spectrum Keys

1 comment
As mentioned last post, the keyboard works perfectly in the standard PS2 mode, it's the emulator 'layer' that has usage issues. If you switch to mode A (the emulator layer) on the keyboard, the key presses register anything but what you'd expect. There seemed to be some rather odd mapping going on, leaving the emulator mode a little useless.

There would seem to be 3 ways in which to adjust the Recreated Spectrum for usage with Emulators, other than the designated but pulled Elite variants.
  1. Patch an Emulator, or wait for support to be added. Apparently the some patches exist for the Fuse Emulator, adding compatibility for the Recreated Spectrum. That's no guarantee that other emulators will support it; I'd wager many gradually will, though you never know.
  2. Rip out the existing control board and build up a new version.
  3. Come up with an external hardware solution to adjust the key codes sent back to the host computer.
I guess option 1 would be the easiest, at least from a general user perspective, though unless your favorite emulator is open source, this could take a while. Option 2 is the most problematic, as to replace the board in a non case destroying way would be difficult (not impossible) to achieve. Frankly I don't want to ruin the look of the Recreated Spectrum with a hatchet job. That leaves option 3 as a pretty good alternative.

The PS2 mode would be the logical mode to tap into for signal / code modification, we need to see what the Spectrum keyboard actually sends out across the USB cable. To do this easily I pulled out an Arduino USB host shield to read the key codes are being sent. The results where interesting. Firstly, the standard PS2 layer (Mode B), was sending exactly what would be expected. With all letters and combinations of 'shift' and 'Alt' key presses being sent in a seemingly standard manner. I found one glaring issue that puts a stop to tapping into the PS2 mode however; the keyboard does not send any codes for the combination of "CAPS SHIFT + 9". What this means to those who have not already guessed, is that you can't set the keyboard to graphics mode.

So this leaves us with Mode 'A', the emulator layer. This is where things get interesting. A PS2 style keyboard will normally send codes stating when a key is pressed, and a similar code indicating that a particular key has been released. The codes the Recreated Spectrum is sending in emulator mode do not follow that pattern. Instead, when you press 'q', for example the keyboard sends the code for 'u' being pressed, however on release the keyboard send the code for 'v' being released. There is not a single key that sends just the expected letter. I've mapped the keys in the table below.


The Recreated ZX Spectrums Mode 'A' Key Mapping

KEY 1 2 3 4 5 6 7 8 9 0
PRESS a c e g I k m o q s
RELEASE b d f h j l n p r t
KEY Q W E R T Y U I O P
PRESS u w y A C E G I K M
RELEASE v x z B D F H J L N
KEY A S D F G H J K L ENTER
PRESS O Q S U W Y 0 2 4 6
RELEASE P R T V X Z 1 3 5 7
KEY CAPS SHIFT Z X C V B N M SYM SHIFT SPACE
PRESS 8 < - [ ; , / { ! %
RELEASE 9 > = ] : . ? } $ ^

As can be seen from the table, the key code order is layed out in a very neat and predictable manner. Also crucially, all key presses are detected in emulator mode, there are no dead keys combination problems such as in the "CAPS SHIFT + 9" issue discovered in PS2 mode. This all makes adding a man in the middle hardware solution relatively easy to implement.

The next step is to write some Arduino code to see just what we can achieve.

Read More

Tuesday, September 20, 2016

Half Recreated ZX Spectrum

Leave a Comment
Curiosity got the better of me, with some help from continuous price drops and forced my hand into the procurement of a Recreated ZX Spectrum. The Elite Systems clone of the original Sinclair Spectrums keyboard was one of the inspirations behind the starting of this blog. Given these reasons (or excuses) it's not surprising that I felt the desire to try one out, a kind of celebration of the year since beginning the AZ15 project.


I'm not in much of a position to pass judgement on the overall look, feel or experiential replication embodied by the Recreated ZX, you see I've never owned a rubber keyed Spectrum (I had a +2a for a while quite recently), in fact I've only ever seen them in the wild twice. The most recent Spectrum encounter was with an extremely beaten up system found resting quietly in a computer store in Delfzijl, up in the north eastern Netherlands.

My only other brush with a rubber Spectrum was half a world away and decades in between, at the Sydney Personal Computer Show in 1983, where Sinclair had a very prominent and striking black pavilion right at the entrance to the exhibition. As a young teenager and ZX81 owner, this encounter was beyond exciting, though sadly owning one of the beasts on display was not in my near future.

Regardless of the above, we can still judge the Recreated on it's functionality as a keyboard. There are good and bad points to this device. The good points first. The keyboard is stunning, I mean really stunning, it does look to me (with my limited experience) look like a Spectrum. Secondly the keyboard works flawlessly, at least for a rubber keyed throwback to times past as a PC keyboard, though certainly not recommended for daily typing. Frankly is quite fun to use the keyboard, gaze at the keyboard and generally fiddle with it for a while.

Despite the attention to detail shown externally and in the immediate PC-keyboard compatibility, the real use for this keyboard is with Spectrum emulators. This is where functionality falls apart. For whatever reason Elite crippled the keyboard by limiting its emulation use to Elites own suite of applications. None of these Elite applications are supported, let alone available due to ongoing legal disputes. So unless Emulator writers decide to include support for the Recreated Spectrum, the device is functionally useless for emulation purposes. 

There is of course always an option another option: Rip out the internals, grab an Adruino or other micro-controller and retrofit for purpose. In fact retrofitting looks quite achievable, I haven't as yet opened the little box up to check it over, but Tero Heikkinen at the Old Machinery blog has and the possibilities are promising. So this is what I think I'll end up trying out, and if so, I'll of course post the details here.


Read More

Tuesday, September 13, 2016

The ZX81, Z88dk, Apps & Roman Numerals.

Leave a Comment
So what do you do with a Raspberry PI / Arduino ZX81 frankensteinian clone beast, that is other than play copious amounts of games?

In a world full of mobile phone apps, it's easy to forget that effectively computers of the ZX81s ilk only ever really ran what we would now consider apps. Refer to any listing in say, the magazine ZX-Computing, one that isn't a game of some dubious nature for examples. The case being, that really very serious software just wont fit into 16k, let alone 1k of RAM. (With all apologies to the masters of machine code and their associated assembly acolytes, who are at this very moment proving my point entirely incorrect.)

Of course all of the above being the case, the answer to the lead question is of to this post, is write an app.

Thanks to the wonders of the post-modern age, apps can quite easily be developed off on a PC some place, then cross complied for injection back into the plastic doorstop that is a ZX81. To give this all a good go, it was off to Z88dk, the C development tool of choice for targeting Z80 based machines.

I'm not about to bore the world with a run down on the inner most workings of Z88dk, not least because never really having used it before, my 2 cents of input here is not going to help anybody. Suffice to say that it's pretty easy to get to grips with, and really the hardest part about it is that you end up primarily programming in C.

Which leads to the point that there is only one really good reason that explains the existence of C++, and that is the annoyance that is C and specifically Cs' painful handling of Strings. The String and C problem being an extra annoyance as the App I ended up making was a conversion of a Roman Numeral Format checking applet, I'd originally written in Java and then moved to C++, an applet that I'd made the Strings do all the heavy lifting in.

Anyway, regardless of any pet C based grievances, Z88dk is brilliant, and in the end I produced a passable piece of ZX81 software.


The "ZX Roman Numeral-izer" is born.

The only real hard and fast rules to Roman Numeral conversion is this: Always add the numbers together from left to right, unless the numeral to the right is of a lower value, in that case subtract that numeral. That's it, see Wikipeadia for a better explanation.

Of course there is a correct, strict and socially acceptable way to format Roman Numerals, and this is precisely what my little ZX81 app is designed to do. It will check your dodgy formatting, make an informed guess at what you meant, spits out an Arabic Number and presents you with the Correct Roman formatting.

For the moment I've left the app a little bit on the gamey side, it's up to you to try and format your Roman Numeral correctly, there is no Arabic Numeral input option. The code behind the app would easily allow for it, I've just not implemented that extra code as yet, (and possibly wont).

You can download ZX Roman Numeral-izer and give it a go in your favourite ZX81 emulator.
Read More