ZX Spectrum Game: TuT-TuT 2020 Ed

After the success of the ZX81 version of Tut-Tut it was suggested to me by several people that it should be ported to the ZX Spectrum. But didn't the game start on the Spectrum you say? Indeed, back in October 2019 the very first version of Tut-Tut was released as a good old fashioned type in game for Paleotronic Magazine. 

Brining Tomb Raiding Back to the Speccy

The initial version of Tut-Tut was a sizeable challenge to get working in pure Sinclair BASIC. The ZX81 version proved a nice little conversion project in C. This time around I've taken both versions, squashed them together and used ZXbasic as the modern development tool of choice.

Keeping it Early 8bit

Despite constantly changing implementation languages, TuT's core game mechanics and functionality are all based around the algorithms and techniques outlined in the Paleotronic article.

Staying true to the BASIC version of the game became a key style choice for new Spectrum edition of Tut-Tut. In particular the decision not to introduce fluid animation into the game was something that I'd much internally debated about.

In the end I felt retaining character square based movement lead heavily to an early 80s home micro aesthetic, one that most retro games (understandably) shy away from. That's not to say the game feels old, it's just meant after a fashion to feel like a kick arse earlier tittle.

Screen Shots from ZX Spectrum TuT-TuT 2020 Edition

New Elements for the Ancient  

Of course nothing stands still, the new edition includes all the enhanced game play elements introduced in the ZX81 version, including bracelets and amulets. All 29 ZX81 levels have been updated for the Spectrum; plus 6 new levels to discover if you've previously played the ZX81 game.

Being that this game is for the ZX Spectrum I've really tried to give the Tut-Tut a great Ancient Egyptian tomb raiding colour vibe. All the graphics have had a good makeover from those in the original BASIC version. In addition the game now contains several minor graphic tile sets that weave together throughout the tombs.

For ease of play-ability, the 2020 Spectrum edition adds joystick support and a much converted ability to pause the game; having to play the ZX81 version in one sitting without coffee became a little taxing.

Download Excavate a Copy of the Game

• Download A Digital copy of ZX Spectrum Tut-Tut. File last updated 05/05/22
• Cassette copies of the game are available from Cronosoft

Thanks for Helping it Happen

I'd really like to thank a number of people in particular for helping out and generally supporting the Tut-Tut project from the beginning till the present:

• Melody Ayres-Griffiths for suggesting something Halloween inspired for the Paleotronic Article.
• Rod (Villordsutch) Bell and his support for the game, plus suggesting the ZX81 version really ought to be on a real tape.
• Simon Ullyatt of Cronosoft fame for publishing the game and being generally enthusiastic and awesome.
• Jim (Magenta) Blimey gets much thanks for play testing a lot of demo versions and providing some really useful dev tools. 

Read More

ZX81 Game: TuT-TuT - Editions

What news of the ZX81 version of the TuT-TuT since the initial release you ask? Well there are some exciting developments that need some sharing.

Physical Tape Release of TuT-TuT

I'd mentioned in the previous post that a physical tape release was in the works. Simon Ullyatt and his brilliant retro publishing label Cronosoft will be releasing the game in the not to distant future.

Simon is busy putting the game through some additional testing on real hardware, checking the loading from real tapes and the like. Then of course there is the small matter of cassette production, once all is confirmed the release date will be announced, so stay tuned for exact dates.

Of course what's a physical tape release without some good cover art? After an intense drawing session on my part and some quality layout work on Simon's side of things we have a tape inlay cover ready to go. Those mummies really look menacing, would you dare enter this tomb? (Of course you will)

Coming to a Tape Player near you, the Soon to be released Tape version of TuT-TuT  

UDG 4 ZXpand Edition 

For those fortunate enough to own both a ZXpand and a UDG 4 ZXpand expansion cards for their ZX81s, Moggy from over on the Sinclair ZX World forums created a User Defined Graphics set for TuT-TuT. Don't have the expansion or a ZX81, no need to worry the enhancements can be used with the excellent EightyOne Sinclair Emulator.

All instructions on how to use the UDG version in an Emulator or with a real ZX81, along with the required files are all now included in the TuT-TuT tape file download.

Original ZX81 version and the enhanced UDG 4 ZXpand graphics set.

Get TuTing on an iPhone

In need of a mobile on the go fix of some TuT-TuT action? Kevin Palser has your desires covered if you're an iPhone / IOS user. TuT-TuT is to be included in the next release of the his ZX81 for IOS emulator. The latest version of the emulator should be appearing later this week (Late Nov 20119).

The ZX Spectrum Version

The ZX Spectrum version of TuT-TuT has been a huge success all off it's own. A big thanks for the overwhelmingly positive reviews circulating out there in the wild.

A special shoutout to Ewan Spence for his play through of the game on his Retro Spectrum YouTube channel. It's been great to see so many great reactions to the game. Who would have thought a game written in Spectrum BASIC could be such a hit in 2019.

The Spectrum version of the game was all about challenging the idea that Sinclair BASIC couldn't be used effectively in games creation, I think I've managed to help in some way to bust that myth. If you haven't yet, go grab yourself a copy from Paleotroic Magazine and get playing, remember to check out some of the other articles while there.

The ZX81 Version is more than a Conversion

If you've had fun playing TuT-TuT on the ZX Spectrum be sure to give the ZX81 version a play through.

Unlike the Spectrum TuT-TuT, the ZX81 game is not written in BASIC, this left the door open for some enhancements of gameplay and features. While some of the levels will be familiar, many have been subtly changed and many more added, in fact there are almost twice the amount on the ZX81.

---

Getting a Copy of TuT-TuT

ZX81 Versions

• A Digital copy at Itch.io
• Get the Cassette from Cronosoft.
• Play it on you iPad or iPhone, get a copy of ZX81 for IOS

ZX Spectrum Versions

• Brand new for 2020, Tut-Tut 2020 Edition: Based on the ZX81 version
• Original BASIC copy: Physical Paper type-in release and Digital Copies will be available from Paleotronic Magazine

Love the Game?

• Why not buy me a Coffee, I needed quite a few writing it, and with more there could be a TuT-TuT II.

Read More

ZX81 Game: TuT-TuT

For the October 2019 issue of Paleotronic Magazine I took on the challenge of writing a ZX Spectrum game in BASIC. The result being the fast paced Halloween inspired, Ancient Egyptian themed arcade puzzler Tut-Tut. Now with the Spectrum version sorted, how about a ZX81 version of the same game, only better?!

---

Tomb Raiding with a ZX81

It's coming to the end of 1921's digging season in Egypt. Your excavations have not gone so well this year, failing to find any trace of the legendary and as yet undiscovered Pharaohs tomb. Then in your final weeks wild stories recounting the wrath of vengeful mummies strangling would be tomb local raiders filter back to base camp.

At last some concrete leads worth looking into, and opportunities to good to pass up. Oculist tales of curses be dammed, you're an Egyptologist and grand adventurer, such nonsense can't possibly hurt you. Or can it?

How far into the tomb of the Pharaoh can you make it? 

Playing the Game

Tut-Tut is one part puzzle, two parts arcade action. The game is comprised of 28 levels, plus a hidden treasure chamber which may only be opened if you are deemed worthy.

Collect gems, amulets and bracelets for points, you'll need 5000 before the end of "Sutekh's Eye" (level 28) for the treasure chamber to open. Amulets and Bracelets will freeze the player or halt mummies respectively.

To complete each level the player will need to collect keys, open doors, move blocks before finding exits to lower crypt levels. Keep an eye out for Pharaohs roaming guardians, they're not the smartest of the undead but they are relentless.

Keys are: ‘O’ left, ‘P’ right, ‘Q’ up, ‘A’ for down and ‘R’ to reset the level (at a cost).

Details on where and how to acquire a copy of TuT-Tut are listed at the end of this blog entry.

---

The reMaking of TuT-TuT

The original version of Tut-Tut was written as a type-in game for the ZX Spectrum and published in Paleotronic Magazine. The game was entirely constructed in BASIC, this presented numerous challenges, the the greatest being the problem of speed and squeezing enough of it out of the machine. The trials and tribulations of undertaking that task on the ZX Spectrum is pretty well documented in the magazine.

I had considered re-pointing the BASIC game to the ZX81, but the challenge of writing a good game in BASIC had kind of been dealt with. The greater challenge on the ZX81 is in presenting an atmospheric game that transcends the limits imposed by the machines most obvious shortcomings; black and white predefined chunky graphics. To that end the ZX81 version of Tut-Tut has been written in C, targeted towards Z88dk for compilation.

TuT-TuT: ZX Spectrum vs ZX81 Version

I've been careful to maintain the core game play between versions. The choice not to use BASIC could have been a catalyst to greatly enhance elements such as enemy mummy movement for example. The choice not to change to much has however kept the feel of the game, and ensured the overall design feels consistent.

Despite remaining essentially the same game, opportunities have been taken to add additional elements. The size and scope of TuT-TuT has increased, there are now 28 normal levels, plus 1 special level. Extra levels necessitated the creation of a couple of additional items to hold player interest; Amulets and Bracelets provide chances for scoring extra points alongside the potential disadvantage of actually interacting with the items.

That's about it, be sure to check out the article in Paleotronic and enjoy both the original and especially this ZX81 enhancements. Special thanks to Paleotronic for both suggesting and providing the space the Spectrum game and a shout out to Rod Bell for supporting the project.

Be sure to check out Rods video review of the ZX81 TuT-TuT Demo Version

---

Getting a Copy of TuT-TuT

ZX81 Versions

• A Digital copy at Itch.io
• Get the Cassette from Cronosoft.
• Play it on you iPad or iPhone, get a copy of ZX81 for IOS

ZX Spectrum Versions

• Physical Paper Type in release and Digital Copies will be available from Paleotronic Magazine

Love the Game?

• Why not buy me a Coffee, I needed quite a few writing it, and with more there could be a TuT-TuT II.

Read More

RetroChallenge 2017/10: Part 7

Developing Software on the NEC PC-8401?

Just a bit of fun for this entry. After experimenting with some software development last post, it quickly became apparent that writing software directly on the PC-8401 is a little inconvenient (at least without a memory expansion). This lead to the use of Z88dk for external development and a little cross-compiling to CPM to suite our purposes.

I couldn't help thinking that although the outcome was successful, it seemed a little like cheating. So lets cheat a tiny bit less.

As we know, the PC-8401 comes with a very capable Vt100 compatible Terminal program, one that's perfect for interfacing with LINUX. Now with minimal imagination required  lets pretend it's 1985 and we're developing on some extremely expensive time sharing remote platform tended by white coat wearing professionals.

There are many ways to configure serial / rs232 terminal sessions within LINIX, so here's one way, and one that's really simple although not a permanent on boot ready option.

First, we need to find the correct Serial Port. I'm using a USB to serial adaptor and need to know which exact device to target.

From the command line in LINUX issue: dmesg | grep USB

This yields a load of messages, but I'm looking for something as below.

[   22.444199] usbserial: USB Serial support registered for pl2303
[   22.444774] usb 1-10: pl2303 converter now attached to ttyUSB1

Now knowing knowing which USB device is the serial converter, it's an easy matter to setup a terminal console.

sudo stty -F /dev/ttyUSB1 cols 80 rows 15 1200
TERM=vt100 ksh </dev/ttyUSB1 > /dev/ttyUSB1 2>&1 &

Once that's all done, I can start up the PC-8401s Terminal program, configure it to 1200 baud 1 stop bit, no parity and 8 bit word length and I'm up and running a LINUX remote console. From there it's time to start up a text editor, VI, Emacs or Nano and get developing.

NEC-PC8401 with and open LINUX console running nano and editing code

Once some very impressive software has been developed, it'll need to be transferred to the PC-8401 to be executed in all it's glory, and LINUX provides a couple of easy to use xmodem commands to do just that.

To send files from LINUX via Xmodem:
sx my_file.com

To receive files from the PC-8401
rx my_file.com

Now there is absolutely no excuse, not in the slightest to use a 27 inch widescreen monitor to interact with a high powered modern PC to write applications.

Finally, thanks to Mike Spooner for indirectly generating the idea behind this post.

See RetroChallenge Intro, Part 1, Part_2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8

Read More

RetroChallenge 2017/10: Part 6

Writting New Software for an NEC PC-8401

As noted previously, the PC-8401 came sans BASIC interpreter, which was quite an anathema in the day. This lack of BASIC presents no real impediment in producing new software for the machine today, even back in the 80s a CPM targeted variety of BASIC could be sourced for the machine (if not a specific PC-8401 version). 30 years on, being equipt with a Z80A processor and the CPM 2.2 operating systems puts this laptop a good position for some software development.

Getting into BASIC

To start we'll need to copy BASIC interpreters onto the PC-8401. AS with all software, BASIC will be taking up valuable chunks of the 32k reserved as drive space. Our own BASIC text files will then need to fit in whatever space remains. Ideally we'd have a RAM extension, either a PC-8406A 32K RAM pack or a PC-8407A 128K pack, in order to program something of a reasonable size. Still even without a RAM pack we can at least try out a number of BASIC flavors.

Both the versions of BASIC mentioned below are available from Gary J. Webes' excellent NEC PC-8201 support site WEB8201, where he holds a selection of software for the NEC PC-8401. NEC PC-8401. Check out the NEC 8401A / 8500 File Collection portion of the File Downloads page.

Microsoft BASIC

In the stakes to use the greatest amount of memory possible, Microsoft BASIC wins hands down. The last CPM version 5.29 will take up huge 23.4k of 'disk space' and when executed leaves a little over 1k of active memory on the PC-8401 to play around with. On the plus side, it's the version of BASIC that's the most familiar, and baring some commands unavailable in the CPM version, there are a wealth of examples laying around to learn from.

Unfortunately the size of MS BASIC makes it a non stater, it's more of a curiosity than something of practical usage. There are compilers available for MS BASIC, though a you still require libraries on the disk to run complied applications. Due to lack of disk space, compilation would need to be run on a host computer before moving the end product over to the PC-8401.

ZBAS

Luckily there are other options, ZBAS is quite a usable option only requiring 16.4k, leaving us with some room to write programs interactively, and some space to save these applications to disk.

Interestingly and extra fortunately when saving files, ZBAS tokenises BASIC Commands, much like on a 128k ZX Spectrum. Thus allowing for some larger than expected applications to be saved on our rather limited 'solid' state storage.

If your going to leave BASIC laying around on the System, then ZBAS is clearly the one to have.

Moving to Modern 'C' Developement

While there are plenty of period development platforms and languages available for CPM, including 'C's and Pascals, you'll need to run these in a emulated environment as there is no room on the PC-8401 for such niceties. A load of CPM software and utilities are available on the retroarchive, although none of these programs are specific to the PC-8401.

Z88DK

Perhaps the easiest way to pursue software development for a CPM machine and the PC-8401 today is via the use of Z88dk. Z88dk is a 'C' compiler targeting TRS80s, Commodore 128s, Sinclair ZX81s and just about any machine containing a Z80 processor. Specifically for out purposes there is a dedicated CPM library.

In order to test Z88DK out with the PC-8401 I borrowed from an older ZX81 program I wrote up some time ago, "ZX Roman Numeral-Izer". The program is a simple roman numeral format checker, it takes Roman numerals as an argument and then correctly formats them to the agreed standards (Standards that even the Romans didn't always adhere to). After a couple of minor changes to remove some specific ZX81 extensions and put in some specific PC-8401-isations the project compiled perfectly.

If you're interested then the full source is below, bit of a rush and there will be better ways to achieve the same result I'm sure, still proof of concept proven.

NEC PC-8401 Roman Numeral-iser Listing

// To Compile for CPM do as below.
// zcc +cpm -lm -o rome.com rome.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

typedef enum { true = 0, false = !true } bool;

static short isaNumArab[7] = {1, 5, 10,50,100,500,1000};
static char csaNumRome[8] = "ivxlcdm";

// Function Get Arabic value of Roman Numeral
short GetArabValue(char csMyNumerals[15]){

 char csMyNumeral[2];
 char csNumRome[2];

 short iNumberNow = 0;
 short iNumberLast = 0;
 short iNumberTotal = 0;

 short iCount1 = 0;
 short iCount2 = 0;

 bool bTest = false;
 bool bNegative = false;

 //Go through sMyNumerals input string backwards for easier rule matching
 for (iCount1=strlen (csMyNumerals)-1; iCount1>=0; iCount1--){
  strncpy(csMyNumeral, csMyNumerals+(iCount1*1), 1);
  csMyNumeral[1]='\0';

  for (iCount2=0; iCount2<=strlen(csaNumRome)-1; iCount2++){
   strncpy(csNumRome, csaNumRome+(iCount2*1), 1);
   csNumRome[1]='\0';
   bTest = strnicmp(csMyNumeral, csNumRome,1);

   if (bTest == true){
    iNumberNow = isaNumArab[iCount2];

    if ((iNumberNow > iNumberLast) || ((iNumberNow == iNumberLast) && (bNegative == false))){
     iNumberTotal = iNumberTotal + iNumberNow;
     bNegative = false;
    } else {
     iNumberTotal = iNumberTotal - iNumberNow;
     bNegative = true;
    }
   }
   iNumberLast = iNumberNow;
  }
 }

 return iNumberTotal;
}

// Function Get Roman value of Arabic Numeral
void PrintRomeNumerals(int iMyNumberArab){
 char csNumRome[16];
 char csMyNumerals[16];
 char csMyNumeral[2];

 short iTemp[16];

 short iNumberNow;

 short iCount1 = 0;
 short iCount2 = 0;
 short iCount3 = 15;

 memset(csNumRome,0,strlen(csNumRome));

 memset(iTemp, 0, sizeof(iTemp));

 if(iMyNumberArab>=4000){
  strcpy(csNumRome,"Max Value 3999");
 } else {

  itoa(iMyNumberArab,csMyNumerals,10);
  //csMyNumerals[15]='\0';
  //Go through sMyNumerals input string backwards for easier rule matching

  for (iCount1=strlen(csMyNumerals)-1; iCount1>=0; iCount1--){

   strncpy(csMyNumeral, csMyNumerals+(iCount1*1), 1);
   iNumberNow = atoi(csMyNumeral);

   switch (iNumberNow) {
    case 1: case 2: case 3:
     for (iCount2=0;iCount2<iNumberNow;iCount2++){

      iTemp[iCount3] = csaNumRome[(strlen(csMyNumerals)-1)*2-iCount1*2];

      iCount3--;
     }

    break;

    case 4:

      iTemp[iCount3] = csaNumRome[(strlen(csMyNumerals)-1)*2-iCount1*2+1];
      iTemp[iCount3-1] = csaNumRome[(strlen(csMyNumerals)-1)*2-iCount1*2];
      iCount3=iCount3-2;
    break;

    case 5: case 6: case 7: case 8:

     for (iCount2=0;iCount2<iNumberNow-5;iCount2++){

      iTemp[iCount3] = csaNumRome[(strlen(csMyNumerals)-1)*2-iCount1*2];
      iCount3--;
     }
     iTemp[iCount3] = csaNumRome[(strlen(csMyNumerals)-1)*2-iCount1*2+1];
     iCount3--;
    break;

    case 9:

     iTemp[iCount3] = csaNumRome[(strlen(csMyNumerals)-1)*2-iCount1*2+2];
     iTemp[iCount3-1] = csaNumRome[(strlen(csMyNumerals)-1)*2-iCount1*2];
     iCount3=iCount3-2;
    break;
   }

  }
 }

 printf("\n Correct Format: ");
 for (iCount2=0;iCount2<16;iCount2++){
  if(iTemp[iCount2]!=0){
   printf("%c",iTemp[iCount2]);
  }

 }
 printf("\n");

 return;
}


void BannerLine(short iLength, char cCharter){
 short iCount1 = 0;
 for (iCount1=0; iCount1<iLength; iCount1++){
   printf("%c",cCharter);
 }
}


void BannerSet(void){
 short iCount1 = 0;
 printf("\n");
 BannerLine(32,149);
 printf( "\n PC-8401 Roman Numeral-iser\n" );
 BannerLine(32,149);

 for(iCount1=0;iCount1<=strlen(csaNumRome)-1;iCount1++){

  printf("\n Numeral: %c = Numeric: %d",csaNumRome[iCount1],isaNumArab[iCount1]);
  if(iCount1 == strlen(csaNumRome)-1){
   printf("\n");
  }
 }

 BannerLine(32,149);

 printf("\n Roman Numeral Format Check\n");

 BannerLine(32,149);

}


short PressAnyKey(void){

 char chr;

 BannerLine(32,149);
 printf("\n Input Another Numeral? Y/N: ");
 chr = getchar();

 if(chr == 'n' || chr == 'N'){
  return 1;
 } else {
  return 0;
 }
}


main(void)
{

 char csMyNumerals[15];

 bool PressKey = true;

 char csMyNumberRome[15];
 int iMyNumberArab = 0;

 while( PressKey != false ) {

  BannerSet();

  printf("\n Roman Numerals: ");
  fgets(csMyNumerals,15,stdin);
  iMyNumberArab = GetArabValue(csMyNumerals);
  printf(" Numeric  Value: %d",iMyNumberArab);

  PrintRomeNumerals(iMyNumberArab);

  memset(csMyNumerals,0,strlen(csMyNumerals));
  memset(csMyNumberRome,0,strlen(csMyNumberRome));

  PressKey = PressAnyKey();

 }
}

See RetroChallenge Intro, Part 1, Part_2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8

Read More

Peeking into the ZX81s Screen Maze

While thinking about some possibilities of how to approach various projects in my to-do list, I realised that these were going to need some screen reading elements, or rather I'd need to PEEK into the display file to see what was going on. This lead to some re-research into how the ZX81 handles its screen output. While some excellent information on the subject is not hard to find, I figure a poke into this might be of use to others.

What's being displayed by the ZX81 on a monitor at any given time is not exactly a mystery, nor is how it got there. What  can be mystery is how to retrieve that information for (re)usage in an application. Actually that's not much of a puzzle either, though possibly a little ambiguous at first.

The ZX81 stores screen related information in a area of memory known as the "display file" or DFILE for short, this is outlined briefly in chapters 27 of the ZX81 manual. What's not made quite so clear is how to access that area of memory, or how that area is configured at any given moment by the machine. This last part is particularly crucial if your ZX81 has less than 4k of RAM (Not of any real concern these days I suppose, but you never know.)

The relationship between the ZX81 Display File and D_File system variables laid out for easy reference.

First off we need to know where the DFILE resides. The location is not static (unlike the ZX Spectrum's DFILE) and moves up or down depending on the size the BASIC program listing. Thankfully there is a system variable, D_FILE, which stores this starting location. What we need to do is PEEK the address of the D_FILE variable to ascertain the location of the actual DFILE. Note that address is stored in 2 bytes.

PRINT PEEK 16396 + PEEK 16397 * 256

On a freshly booted system the result of  the above should be 16509. You might notice that this is also the starting address for the "Program" memory area, which indicates that there is currently no program stored.

Next we can determine how large the DFILE is by reading the system variable VARS. This is where a non expanded ZX81 will differ from one with a RAM pack attached. The returned value will give you the starting location of the user Variables memory allocation area. Again note that the returned listed values from PEEKing the VARS system variable assume there in no program loaded.

PRINT PEEK 16400 + PEEK 16401 * 256

Variables starting address on a 1k ZX81 (or 2k Timex 1000) is: 16534
On a ZX81 with 4k or more expanded memory: 17302


If we subtract the value of D_FILE from VARS, the byte allocation or size of the DFILE is revealed. What we notice is that on a 1k ZX81 the default size of the DFILE is 25 bytes, and on a 4k plus system the DFILE is allocated 793 bytes. The massive (overstatement) size difference between an expanded and unexpaned machine comes down to how the ZX81 handles the DFILE. On a 2k or less machine the DFILE is expanded as it is required, while on a 4k plus computer the DFILE is always fully extended.

On a 1k or 2k ZX81, each of those 25 bytes contains a CHR$ 118, the Newline Character. One CHR$ 118 marks the start of the DFILE , and when a line is printed to, the DFILE is expanded to a maximum of 32 characters per line, with each line always being terminated by a Newline.

A ZX81 with 4k or more always has a fully expanded DFILE, containing 25 CHR$ 118, marking the start of the DFILE and end of each line, plus 32 * 24 characters, which are initially CHR$ 0, the space character, yielding a 793 byte total.

Putting the above into practice, two programs below demonstrate how to POKE to the screen directly, instead of PRINTing. The key lines in both applications are 80 (highlighted), where the second PEEK address is adjusted for either the expanded or collapsed DFILE.


1) Program For a 1K ZX81. If using an emulator make sure it's set for 1K

10 PRINT "POKE MY SCREEN 1K"
20 PRINT AT 2,8;"+++"
30 PRINT TAB 8;"+ +"
40 PRINT TAB 8;"+++"
50 PRINT AT 6,0;"ENTER A CHARACTER AND NEWLINE","OR JUST NEWLINE TO STOP"
60 INPUT A$
70 IF A$="" THEN STOP
80 POKE PEEK 16396+PEEK 16397*256+41,CODE A$
90 GOTO 60

2) Program For a 4K and up ZX81. If using an emulator make sure it's set for 4K or more

10 PRINT "POKE MY SCREEN 4K AND UP"
20 PRINT AT 2,8;"+++"
30 PRINT TAB 8;"+ +"
40 PRINT TAB 8;"+++"
50 PRINT AT 6,0;"ENTER A CHARACTER AND NEWLINE","OR JUST NEWLINE TO STOP"
60 INPUT A$
70 IF A$="" THEN STOP
80 POKE PEEK 16396+PEEK 16397*256+109,CODE A$
90 GOTO 60

The programs above have been modified from listings originally published in the September / October 1981 issue of Sync Magazine, which is available from the Internet Archive. It's well worth trawling through the entire Sync back catalogue for all manner of useful insights.

Using the information above you can see how easy it is to read or write to the ZX81s screen, and then take that into more complex programs. For a deeper insights into the ZX81s display, you can't go past Wilf Rigters' extensive write up The ZX81 Video Display System.

Finally, yes you really can do something interesting with this information, the below maze is generated by a program written in C for the Z88DK compiler. The Maze generator relies heavily on being able to read the Screen / DFILE (that and a maze algorithm). Feel free to download The Maze C source and ZX81 P file for perusal.

Output of the ZX81 Maze Program.

Read More

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

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 No	4 Bit Shifted	Level Starting Position Tile Type
000	000	Empty: Clear Tile / Background
001	016	Block: Can't dig through tile
002	032	Bricks: Can be dug into to create traps
003	048	Bricks, Fake: Player falls through fake bricks
004	064	Rope: Player can move horizontally, or jump down
005	080	Ladder: Visible all game / level
006	096	Ladder, Escape: Visible only after all gold is collected on a level
007	112	Gold: Player to collect all gold
008	128	Guard: Starting position of Guards. After level begins guards fall from the top of screen (after being trapped).
009	144	Player: 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

ZX81 Draughts Challenge - Part 3 - Tims Checkers

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

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

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

ZX81 Draughts - Challenge Accepted 34 Years to Late

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

The ZX81, Z88dk, Apps & Roman Numerals.

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