Pole Dodge is April’s Program of the Month and it is an odd one. Partially odd because I typed it in back in February, and partly because the program just doesn't play well. I know that doesn't lend well for one to give it a try, but try it you should. Why? Because the premise isn't bad. It is the execution that leaves a bit to be desired. Of course, I blame the slow hardware.

Okay, that isn't fair. Pole Dodge is meant to be just what it says. You maneuver your craft of dubious origins around poles that are moving towards you. Here is where I believe the premise is good. I was trying to create a 3D effect back in the early Eighties when 3D was being done with vector graphics or animation. Obviously on a ZX81, the effect is rather muted. I don’t see the Unreal or Quake engines running on this old hardware, although that would make for a great April's fool joke. Humm...okay back to reality. The 3D effect, sadly, isn't very prominent as the poles are printed, then you move, then the poles are printed again. This is way too slow to really show the effect and is why I believe the game falls flat.

I did allow the player to decide how much pain they’d deal with by selecting how long to play and the number of poles to display. I was probably thinking this would act as a difficulty setting. It doesn’t really work for two reasons. One, the game is way to slow making it obvious where the poles will be. Second, you can't select more than four poles. Go on, try to select more than four and see what happens. It doesn't help that the poles overlap, not at the start, but as they get closer they tend to print over each other. This spoils the effect and the lack of ground just makes it worse.

So why did I subject you to this program and, even worse, make it a program of the month? Well, one has to learn from doing things wrong. The program is pretty short and for the life of me, I couldn't remember what the program did before I typed it in. Considering these were the first programs I wrote, it isn't surprising to find lemons. However, in every lemon there is lemonade. Although the code doesn't add anything new, it does encompass a lot of ideas and algorithms in one place. Poles that change over time, use of data structures to store each pole, loops galore, various input routines, moving graphics, etc. Perhaps not a fun game, but there is still good stuff buried in there. And in many ways, the fun is in revisiting these programs and looking at all the ways I could have made these programs better. And maybe I still will.

If you want to run this program on your Android phone or tablet you can download a compressed copy of the program to your device. You'll need to save the .p version of the program to your device to allow Zed Ex (Beta) to run it. [ View Article ]

T.W.M. is March's program of the month. It is a simple animation that tries to mimic a computer's destruction of its defined target. February was actually pretty prolific for me as I transcribed this and another program, as well as updated a number of older programs using MCODER. fortunately, that means I have a few more programs available than I normally do. Of course, one is more than I normally have ready so I'm not sure that means much. Anyway, go give it a try and enjoy the animation in all its simplicity.

And simple is what this program is all about. The first display is a giant print statement. Why you ask? Because it's fast! Printing line by line isn't much slower, but it is noticeable when printing a large graphic. However, when I wanted it slower, printing line by line wasn't quite slow enough. In that case, I used some of the math functions like LET L=SIN PI to slow things down a bit for effect. I also used a simple loop later to pause a for a longer period. Although you can use PAUSE to add a delay in ZX81 BASIC, it has a couple of drawbacks. First, if you enter a key it will skip the delay. That isn't always desired. The other reason, and why I didn't use it here, was that PAUSE causes a the display to jump which is jarring in a smooth animation. There is a reason for this, which is that PAUSE displays the screen when in FAST mode.However, I didn't need that here. Incidentally, I did use the switching between FAST and SLOW to emulate a reset. Nice, huh? The bulk of the rest of program is PRINT statements. Sometimes the simple programs are the best.

If you want to run this program on your Android phone or tablet you can download a compressed copy of the program to your device. You'll need to save the .p version of the program to your device to allow Zed Ex (Beta) to run it. [ View Article ]

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.

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?

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.

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.

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.

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 play 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. [ View Article ]

It isn't all programming around here! Some days it is fun to just play around. I was adding an image to my other site which led to me reviewing some of my old Flickr images. In turn, I ran across my Wordle of Reid's for Fun image (article here). That, of course, made me wonder what Wordle would look like against my ZX81 site. I even adjusted the colors to something more appropriate: red and black. The image came out nicely and provided a nice diversion for the evening.

[ View Article ]

What's this, another version of Road Hog? Yep. This is January's Program converted to machine code using MCoder II. I was surprised how easy it was. Although MCoder is an integer compiler and limits some BASIC commands, I only needed to change a few lines to get Road Hog to run. Since machine code is much faster, I removed the various FAST and SLOW as they weren't needed anymore. I also found that the cars were too fast, requiring a delay loop. The delay actually provided an opportunity to add an adaptive routine to slowly speed up the game with each successive car. The speed resets each day, actually making use of that counter. This makes the game not only more challenging, but more fun overall. Not sure? Go on,
give it a try. You know you want to. [ View Article ]