E.T. Redux

E.T. may not have been my best game ever, but it was an interesting exercise in 1985. Loosely, and I really mean loosely, based on the Atari 2600 game, E.T. follows the exploits of the title character as he tries to find his way home. Originally written in ZX81 BASIC, I revisited E.T. to better understand how to use MCODER II. I was ultimately successful in compiling it and getting it to run. If you are adventurous, you can compare it to original version, bugs and all. Instructions for E.T. are available off my old ZX81 website.

E.T., Finding a Flower, 1985 by Steven Reid

My goal is to write an Ultima style program for the ZX81; however, I’m finding BASIC way to slow for what I need. Since my assembly language experience is practically zero, it’s been 20+ years since I coded in VAX assembler, I thought I’d try to use MCODER again. My parents originally bought me MCODER as a Christmas present, but I only used it a few times before moving on to my C64. After successfully using it to improve Road Hog, I thought I’d try my hand at converting a larger program.

I’ll admit, E.T. is a horrible game. It is slow, buggy, boring, just not fun. It was, however, fun to convert. Beyond the simple problems of altering lines to deal with MCODER's particular version of BASIC, I had to deal with memory constraints. The original program is about 6K. MCODER takes up about 4K which you have to merge with your program if you want to compile it. I quickly started to bump up against the 16K limit I normally use. Obviously, if you save the program and initialize the machine, you'll get 4K back. When I tried to compile the program, which takes that 6K and turns it into machine code, I found myself running out of memory. What was I to do?

E.T. MC, Finding a Flower, 2012 by Steven Reid

The obvious answer is to use 32K. I use EightyOne as my ZX81 emulator and it lets you configure the hardware to your choosing. Unfortunately, it didn't work. I did some digging around the Internet and came upon my problem. It seems you have to tell the ZX81 to use any memory above 16K by moving RAMTOP. In this case, typing POKE 16389, 192 followed by NEW did the trick, I could now load and compile my program without bumping up against the memory limit. For the final version of the program, I removed the BASIC code so it would run fine using a standard 16K memory pack.

Now the fun began. I kept running into minor issues with MCODER. One thing I found was that MCODER will handle multiple AND statements, but doesn't like multiple OR’s. That makes sense as it is easy to break out of an AND once one fails. Coding for multiple OR’s or mixed logic is much harder. Where I could, I removed the use of OR to make the logic better. Since I generally use Boolean logic as a way to avoid an IF statement, I just put the IF back in and things worked fine. I did have to use some GOTO routines to deal with some IF, THEN, ELSE logic.

E.T. MC, Waiting to Leave, 2012 by Steven Reid

The next problem of mine was that if you print too close to the bottom of the screen, MCODER likes to automatically scroll. I fixed the problem by printing at the top of the screen afterwards. As I think back, I wonder if adding a semicolon would have worked as well.

I also found you couldn’t have a FOR loop that uses a STEP. As the spaceship flies upwards, I needed to count backwards. I fixed this using a normal loop and a variable. I could have used simple math, but the existing solution was quick and easy to understand.

E.T. MC, Ship Landing, 2012 by Steven Reid

Random numbers are also different in MCODER, but it was easy enough to deal with. Instead of the normal INT (6*RND+1) to get a number between 1-6, I just divided instead: RND/5461+1. The 5461 is 32767, the maximum number returned by RND, divide by 6. In the future, I should create a subroutine instead.

The last issue I had to deal with was speed. I had some delay routines already in the program when animating the space ship. BASIC prints information pretty fast, so I used some of the math routines to add a slight amount of delay. Those routines don’t work in MCODER so I replaced them with a loop. Since moving around was much faster, I turned that loop into a subroutine and used it to slow down the program between inputs. This made the program playable, while still being much faster and more responsive than the original.

E.T. MC, Going Home, 2012 by Steven Reid

Overall, the program plays as a faster version of the original. I did fix a few of the bugs during my conversion, but I didn't change the overall mechanics. As I tend to do, I can see multiple improvements that would make the game more entertaining. For one, the contents of the pits are random each time you enter. That means you only need to enter one pit over and over again until you find all the telephone pieces. Instead, I should preposition the parts in different pits to force the player to explore them all. The power pills should drop more randomly and perhaps disappear if not picked up. Also, given the overall speed increase, adding an antagonist that you would have to avoid would add some drama to the overall sense of urgency. For now, though, I’m content with what I've learned during my conversion effort.