Followers of this site (ed. yeah like that’s a thing) will remember a few years ago I created a in-browser playable version of the Applesoft BASIC game Haunted House for this site. Over the past month or so I got it in my head to push my skills as a programmer and make a much more fully realized version of the game. Today I am releasing my new version of the game, Haunted House: Remastered! It’s a vast improvement on the original in almost every way possible. In other words, it’s actually fun to play.

While it’s nowhere near the level of sophistication of an Infocom game, I think it does some pretty impressive stuff (for my skill level as a programmer). It’s still a two word parser, but the vocabulary is increased. There are full-page help screens, triggered story events, a retro-styled monochrome monitor look, and a bunch of scary sound effects! Please take a few minutes and give the game a try. It’s not too long and I try to keep the puzzle reasonably fair.

In Applesoft you can prompt for user input in two ways. First there is INPUT A$ which will display a question mark on the screen and await user input followed by a RETURN. That user response then fills the variable A$. Similarly there is GET A$ which also displays a question mark but GET will only accept a single keypress as user input. My main problem with both of these is an aesthetic one: that darn question mark.

The solution is to write your own input routine leveraging machine code routines via PEEKs and POKEs. To do this, first I simulate a cursor by placing a flashing underscore character at the bottom of the screen.

101 VTAB 24 : HTAB 1 : CALL -868 : PRINT ":"; : FLASH : PRINT "_"; : NORMAL : GOSUB 55

A lot is going on in this line. The VTAB and HTAB commands position the screen cursor at line 24 and character 1. CALL -868 is a special machine code call that clears that single line of text. Now that we have an empty line we type a colon and then a flashing underscore. The result looks like this:

This looks like a user input prompt, but at this point it does nothing. The magic happens at the subroutine which is GOSUB’d at the end of that line.

55 KEY = PEEK (49152) : IF KEY < 128 THEN 55
56 IF KEY > 224 AND KEY < 251 THEN KEY = KEY - 32 : REM UPPERCASE
57 POKE 49168,0 : BUZZ = PEEK (49200) : RETURN

In line 55 we are creating a variable KEY and assigning to it the contents of memory location 49,152 to it ($C000 for you hex-heads). Turns out location 49,152 will read the keyboard and return the ASCII value of the currently pressed key. If that value is a character then we break out of the loop and go to line 56.

Line 56 insures that, if the ASCII value of the key denotes a lowercase key, it is converted to uppercase by shifting the ASCII value. POKE 49168,0 clears the keyboard buffer so that the PEEK in 55 will work next time around and not just register the same value. Finally, that BUZZ = PEEK (49200) bit triggers a speaker click so that the player’s keystroke has and audible sound.

When we return to the main game loop we now have a variable KEY which contains an ASCII value of the key pressed. I can then branch the program based on this value. I can also test if it’s a RETURN keypress and then toggle text display. Later in my program I can concatenate keypresses into a single string value by returning to that subroutine again and again until a return press is detected. That’s how I collect the OBJECT half of the VERB OBJECT pair.

I think the issue is the number of arrays that I am defining. For now I think I have a fix. I have set LOMEM: 24576 at the top of my program. Supposedly, this will force the interpreter to define variables in a memory location after the hi-res pages. We shall see.

In any event, the game is back and running again. And the text screen now has some text formatting enhancements:

One of the cooler things I have implemented is this text screen. If at any prompt you hit RETURN you turn off the hi-res graphics and can see this text screen. Here will be some valuable game info included the location’s name, exits and any TAKE-able objects. The code for this is rather simple:

58 IF GM = 1 THEN GM = 0 : TEXT : RETURN
59 GM = 1 : CALL -3100 : RETURN

GM is a flag which tracks where you are in graphics mode (1) or text mode (0). CALL -3100 triggers the hi-res graphics screen without erasing its contents. So exciting, right!?!

Continued in Part V

Verbs

Haunted House used a simple, two-word input parser: VERB NOUN. But I wanted this new game to simplify the number of verb choices in the same way the LucasArts adventures streamlined the interface of Sierra-style adventure games. The player will be limited to around a dozen verbs that are entered with a single keystroke.

The verb list is largely based on the options in Monkey Island. PUSH and PULL have been combined into MOVE. To move you must hit Go then enter either North, South, East, West, Up or Down. This is a little annoying, but there are only so many letters in on the keyboard and I needed that D, U and S elsewhere. Other commands require you to hit the keystroke, then type out an object NOUN and then hit Return. “Guess the verb” will no longer be an issue… welcome to 21st century “guess the noun” technology!

Each verb then get’s its own subroutine which contains the logic that triggers the various game actions (or provides a default message if nothing special happens). By assigning a number value VB to each verb, I can use the following to branch to the various subroutines: ON VB GOSUB 1000,600,800,850, ...

Game Data

The game data is set in the program by assigning strings and numbers to several arrays. In Applesoft you need to declare the size of an array by dimensioning it with the DIM command. For the rooms I will set the size of the rooms array to the number of rooms RM by declaring DIM RM$(RM). Then, near the start of my program I read data into the array by using GOSUB to a loop like this:

5000 DATA "Room description 1","Room Description 2", [...]
5005 FOR I = 1 to RM : READ RM$(I) : NEXT
5010 RETURN

The DATA can be listed anywhere in the code and it’s important to make sure that there are exactly as many data strings as READ commands. Otherwise, you might get OUT OF DATA errors.

This method of declaring rooms and object will eventually make your Applesoft program very long and hard to edit. I was pretty sure that I could figure out a way to read the data in from an external text file. But more on that later.

Continued in Part IV

So, Applesoft BASIC it is! With emulation and modern computing I have been able to develop my code on a Windows PC and then quickly run it in emulation. My workflow isn’t nearly as fancy as some other retro-programmers. I type my Applesoft in a text editor, then in AppleWin I paste the entire code listing into an emulated apple using SHIFT+INSERT. The benefit of using emulation as a development environment is that you can throttle the emulation to run hundreds of times faster (hit ScrLK) than real hardware. This makes testing small changes a breeze.

My first task was to see if I could successfully load a Graphics Magician image into a program. The program itself is a bit of a UI nightmare. Without a manual or reference card, it’s nearly impossible to know what keys do what. On top of that, the program requires that you use a joystick to move the drawing cursor on the screen. Fortunately, the manual can be found online and you can use a PC mouse as a joystick within AppleWin. I managed to crank out a couple of silly images for testing and save them to my game disk.

I then used to code provided in the manual to write a simple Applesoft program that displays the image:

1 PRINT CHR$ (4);"MAXFILES1"5 HIMEM: 32768
10 PRINT CHR$ (4);"BLOAD PICDRAWH"
20 PRINT CHR$ (4);"BLOAD ROOM1.SPC,A32768"
30 HGR
40 A = 32768:HI = INT (A / 256):LO = A - HI * 256: POKE 0,LO: POKE 1,HI50 CALL 36096

In order for this code to work, you are required to copy PICDRAWH from the Graphics Magician disk to your disk. This is the machine code rendering engine that is loaded into memory at the top of this program. The MAXFILES1 DOS command apparently frees up some memory by limiting the amount of open files. This command needs to be the first one in your code, before any string assignments, etc. I think HIMEM does something similar with allocating memory locations. I have never written an Applesoft program so large that it required memory management so the purpose of these commands alludes me somewhat. As this project grows, I may have to familiarize myself with them.

You will see CHR$(4) often in Applesoft programs. CHR$() is a function that retrieves the keyboard character in assigned to the numerical value in then parenthesis. For example, PRINT CHR$(65) prints the letter A. In this case, character number four is the equivalent of keying in CTRL+D. That instructs the computer that the next PRINTed string should be executed as a DOS command rather than PRINTed to the screen.

The Graphics Magician file is ROOM1.SPC. BLOAD ROOM1.SPC,A32768 loads the drawing code into memory location 32768. That seems like a crazy random number but it is actually $8000 in hexidecimal. HGR switches to high-resolution graphics mode and then line 40 stores the memory address of the picture into a location PICDRAWH will know to look. Finally, the CALL 36096 triggers the PICDRAWH draw routines.

There’s a lot of fancy stuff going on here, but it does the job as advertised. The Graphics Magician manual also goes deeper with more code that shows how to string multiple images into slide shows and how to overlay objects over backgrounds. More on that when I get to my object code. For now, this proof-of-concept was enough to get a simple working prototype up and running.

Continued in Part III

My go to art program back in the day was always Alpha Plot from Beagle Bros. It wasn’t the easiest software to use. In fact, it came bundled with a cardboard overlay for your keyboard so you had an immediate reference as to what the various keys did. Still, I managed to draw pixel by pixel and create masterpieces like this:

The Graphics Magician is something altogether different though. Instead of meticulously drawing each point on the screen, you create images programatically using a language of lines, fills and brushes. The end product is what today we would call vector art.

The advantage of vector art is that file sizes are small. The other advantage is that these drawing routines can be used within one’s own Apple ][ programs.

This gave me an idea for a project. Take the text-based adventure game I had made years ago, and use these routines to add graphics to the game. As I type this, I am already pretty far along in the project, but I will be going back and documenting my progress. Hopefully someone might find this informative and, if I am able to follow through, maybe I will have a releasable game in the end. It’s doing more than I ever imagined already:

Continue to Part II

Now, I am pretty familiar with Applesoft Basic programming, but I was always in awe of commercially released software on the Apple ][ that ran so fast, had fancy hi-res graphics and used sounds other than the system beep. What was the secret of these mythical programs that required you to type “BRUN” in order to get them to load? The secret was machine language.

This image shows you just how intuitive and user-friendly machine code is. It’s almost like it was written by the Terminator himself (just after he finished cutting out his eyeball with an Xacto knife). Despite the seeming impenetrability of machine code, in the past I made a few attempts to learn it. I would get a few chapters into Apple Machine Language and then the endless diversions into binary math would addle my art-school trained brain. It never really clicked for me.

What I didn’t know is that there was this thing called “assembly language” which is a human-readable method of creating machine code. It still is pretty brutal compared with Basic or JavaScript, but for the first time I think I am starting to understand machine language and, more generally, just how the Apple ][ works. Cryptic hex numbers and even the aforementioned binary math are still a part of assembly, but it uses three letter abbreviations for various functions and allows for comments and labels. The assembler will translate the letters into their numeric machine language equivalents and assemble the source code into a BRUN-able program. Woo-hoo!

The first hundred pages or so of Assembly Lines has been very informative and I have dutifully typed in many of the example programs. At one point I had a pretty nice “ah ha!” moment when I was messing around with creating tones. I created a small program that generated an annoying high pitch noise and decided I would further enhance the interactivity by outputting a stream of numbers to the screen showing the paddle positions. Before I got very far beyond just reading the paddles I noticed that I could use the joystick to change the pitch of the sound. I had no idea why this would change the pitch so I decided to look at the machine code in the built-in paddle routine. To my surprise, I was able to see that it got the paddle value by using a count down loop. The longer the count down, the lower the tone. I couldn’t really say why this was the case, but at least I was starting to be able to decipher that wall of hex values.

Now, back in the late eighties I got my hands on an issue of Compute! magazine. Kids nowadays with their fancy iWatches and download services may not believe this, but in the olden days there would be program listings in computer magazines. Readers could carefully type in the program and, “Voila!”, you had new software to use. This issue contained a listing for a game called Space Dodger, with a separate listing for just about every machine available at the time. Most were written in basic, but the one for Apple ][ was pure machine code. I had no idea what any of it meant, but I dutifully typed every line into my Apple’s monitor. The result was a pretty slick little arcade game:

You moved your ship to avoid the space junk which flew by from right to left at varying speeds. However, playing the game in emulation, I noticed a slight problem: the ship movement was mapped to the wrong joystick axis.

And now we get to my second assembly language “Ah ha!” moment. I now know the memory address where the paddles are read. I just needed to search the code listing for 00 1E FB and it would just be a matter of changing the 00 to 01. I found the values at $706B, made my edit and, magically, the joystick now worked correctly!

I still have no clue as to what the other 99% of the code does, but this was a breakthrough. Assembly language… I think I can do this. In the meantime, download Space Dodger and play it in your favorite emulator.

Gone are curly brackets and semi-colons. Now elements can be nicely nested within each other and there’s lots of neat shorthand to make code more portable.

Now, I am very late to this party and it turns out much of the SASS code you find on the net is written in a more standard CSS syntax (those sass files are saved as .SCSS rather than .SASS). I hope this cleaner, more modern syntax remains supported because I am completely sold on it.

For quite some time I have heard of SASS but have always been hesitant to dig into it because I always assumed that it was some server-side application that would require SSH and Linux and a bunch of crap I don’t care about. I have since realized that this is not the case. SASS files are compiled locally into a single, standard CSS file. Still, the first thing tutorials seem to tell you to do is to go install Ruby and dive into the command prompt. Yeech! Thankfully, smart people out there (“there” equals Nepal in this case) have developed a windows app that will compile and upload everything you need.

Prepros is a tiny little app that does it all and I highly recommend it if you are developing on Windows. It processes many other languages as well (including Jade and JavaScript) and, regarding SASS, also includes Compass.

Compass is a set of functions and extensions to SASS that makes cross-browser development super easy. A word of warning about Compass: unlike pure SASS it doesn’t work out-of-the-box and requires some research into creating a “config.rb” file. The Zen Drupal theme includes this file and I used that as a base, and I think I understand it now.

In any event, I’m syched about Web development for the first time in a long while and I am glad I made the leap. Also, support Prepros and buy a copy (or two).

The book takes you step-by-step through the process of creating a simple text adventure game using Applesoft Basic. The final product is an adventure called “Haunted House.” It’s about as crude and bare bones as a work of interactive fiction can be, but it does what it needs to: there are objects, rooms and key puzzles.

Well, in a recent flurry of Apple retro computing I got side tracked into porting this game into JavaScript. The result is here. Click the screenshot to launch the game in a new browser window (requires JavaScript, duh – View the actual page if you are viewing this in an RSS feed reader). It’s a fully working port of the original, with all its flaws and quirks. The only additions I made were to make the EXITS display more cleanly and added the verb “drop” to the vocabulary.

My daughter created her first “Hello World” program to today. It was programmed in sidewalk chalk++.

After posting Malfunction, my text adventure game for the Apple ][, I have been spending a whole bunch of time tinkering with my old Apple ][ software creations. Another one of my better creations was a golf game that I titled, Dippy Golf. This game featured nine holes which were loaded in from external graphics files and, even more impressive, was the use of audio samples of my voice! The game worked but still felt somewhat unfinished, so I decided to complete the game and post it here on the Pages of Fun!

One of the first major additions that you will see is the snazzy splash page and loading message:

This was actually the last thing I added to the new version of the game, but I wanted to use my other upgraded piece of software, Lo-Paint 2. More about that later. The game takes several seconds to load the audio samples. Creating samples on the Apple ][ was incredibly difficult. I used a piece of software called The Voice by Muse. This application was developed in part  by Silas Warner, the creator of the Castle Wolfenstein series of games.

The process of getting audio into the computer required taping myself on a cassette recorder, than plugging the recorder into the never-really-used tape data jack on the back of the Apple ][. The sound quality is awful, but this was about the best you could do on an Apple ][. You should note, that this is a golf game, so one of the samples is a naughty word. I stole the idea from an early Mac golf game which my neighbor owned.

Anyhow, on to the introduction/instructions screen:

I love that old, uppercase Apple ][ font. One of my improvements here was to center the text on the page and use a nicer prompt for a key press. After this page you proceed to the first hole:

As you can see, the graphics are in Apple 2 lo-res mode graphics. In this mode you are allowed 40×40 pixels, 16 colors and four lines of text. As crude as this image is, I believe it’s actually higher resolution than Atari 2600 golf.

The game mechanics are simple. You point in a direction then specify how hard you want to hit the ball. This was fine as a proof of concept, but didn’t provide much challenge once you memorized the best angles and swing percentages for each hole. The major 2009 update to game play was the addition of the random element of the wind. This makes the ball behavior somewhat unpredictable (like real golf for me) and can push the player into taking riskier shots in hopes of catching that breeze for a few extra pixels of distance. On some holes, like the one pictured next,  it really adds to the challenge.

Without the wind, you could reliably hit to the micro-islands off the right of the screen.

All of these holes where drawn using an art tool which I programmed called Lo-Paint. In addition to my Dippy Golf updates, I also updated Lo-Paint and included it on the disk. This was a major upgrade to the tool so I consider this version 2 of the software. The interface has been completely revamped and now you can save and load lo-res images! Check out this screen shot of Lo-Paint 2 in action!

If you want to try out Lo-Paint 2 or Dippy Golf download the disk image which is attached to this post and open it up in AppleWin or your favorite Apple ][ emulator.

(Okay, Masterpiece should probably be in quotes too!) I have been on a bit of a retro computing kick this evening. I have been playing around with AppleWin, which is the best Apple ][ emulator for Windows that I know of. I played a little bit of the original Castle Wolfenstein and then decided to fire up my trusty Apple ][gs and port some of my old Applesoft programs to PC.

The process of transforming a 5.25″ floppy to a disk image is somewhat complicated, but not too bad if you have the right tools. First, I turned on my ][gs and booted the System 6 disk. I then ran the awesome program Asimov (by Ninjaforce) which can create and “burn” Apple ][ disk images. I was able to save six 5.25″ disk images onto a single 3.5″ ProDos floppy. The next step is taking this 3.5″ floppy down to my System 9 Mac which I keep stowed away in my basement. The old Mac system could read ProDos disks so I am able to pull the files off the floppy and then save them to a PC formatted 3.5″ floppy (or send them over a network, but I am not connected in my basement). I have a USB floppy drive on my PC specifically for this purpose. Once the disk images are on my PC’s hard drive (with a .dsk extension) I can boot them in AppleWin.

I spent a few hours running my old programs. Most of them are pretty stupid, but I can’t believe I wrote them as a 10 or 11 year-old. I will post some screenshots in the near future. However, sometime in my sophomore or junior year of high school I took the time to create a full text adventure called, “Malfunction.” My code was based on the code in the book Write Your Own Adventure Programs For Your Microcomputer by Usborne Computer Books. The book guided you through the creation of a haunted house game. I was taken step-by-step through the process of game design–from creating maps and puzzles to programming a text parser. This was a great book, and I’d love to see an updated, perhaps Flash actionscript oriented, version.

Now, more than 20 years later, I have decided to publish my game!

In order to play the game you will need to install an Apple 2 emulator. For windows, I use AppleWin. It’s really simple and runs near-perfectly. As for other platforms like Mac, I’m not-so-sure. Look to Google for your answers.

The game is mediocre at best, but I am pretty proud of it. I learned a ton about programming when I created this. I hope you enjoy it. Please feel free to leave me some comments about what you think.