Retro Mojo

Let’s (finally) get started with our game!

I originally was going to build a nice version of Space Invaders, but that was before it had already been done here.  While the world could certainly do with another version of the classic arcade game, I wanted to do something new, something that would help me learn along with the readers of this blog.

Instead, I’ve decided to create a version of the classic Tetris.  It won’t be the first version ever made.  In 1987 a company called MirrorSoft published the title under odd circumstances. The result was playable, even competent, and faithful to the original.  However, the graphics were mundane, and the music barely passable.  I won’t pretend that my graphic skills would be masterful enough to improve on the original much, nor my music-making skills; I merely mention these things to point reasons why I think it would be fun to try creating it for our project.

For those who were cryogenically frozen up up till now, let me explain how Tetris is played.  The field is a place where differently shaped blocks fall one by one at a slow but progressively faster pace.  The player is able  to move the piece left and right, and rotate it clockwise.  The idea is to fill gaps completely, line by line.  As each line is filled, it disappears, all the blocks higher up move down a line, and the player’s score  is increased.  After all that is determined another piece appears and the process continues. If a piece attempts to appear and there is already a piece there, the game is over.

It’s a rather simple game, but in the 80s it was considered one of the most addictive games ever made.  I myself recall playing a version for the PC so much that I began seeing the blocks falling whenever I would close my eyes.  Versions of it showed up on almost every platform, from the Apple II to the Nintendo Game Boy.  The arcade game was VERY well done, allowing for dual play and focusing on good graphics and outstanding music.  Still, I always felt like there could have been more done with it, particularly with the C-64 version.  Some nice adds:

• Have the next piece be on display to the left or right of the game field, so the player can prepare and strategize his next move.
• Have a special piece randomly come down that randomly changes shapes, adding much more challenge to the game.
• Have another piece that will explode if it isn’t placed soon enough.  The exploding piece will throw each of the four pieces that create it to the left and right wall, where it will stick.
• ability to choose a wider play field up to, say, fifteen wide.
• Multiplayer ability

Most of these features seem like they will be pretty straightforward to implement.  Speaking of implementation, let’s cover how a game like this could be created.

How will it work?

The game itself is easy to implement.  So easy, in fact, that whenever I learn a new language I make sure to create the game in that language.  It makes sense then to make it in C-64 Assembly.

The game field is a matrix of cells, taller than it is wide.  A typical size would be 15×40 but it could be any size.  The game loop could be something like this:

1. If a game piece is not in play, create one that is a copy of the game piece on display as the next piece.
2. if the location of the destination has populated cells, go to the game over loop.
3. Check for any user interaction.
4. If there is interaction, attempt to do the action.  Attempt to move left, move right, rotate or move rapidly down.
   1. check the cells that would be occupied should the action occur.
   2. if the cells are occupied, disallow the movement.
5. check the timer to see if it is time to move down a line.
6. if the timer is up, attempt to move the piece down one line.
7. If there are not obstacles, make the move.
8. if there ARE obstacles, go to step one.

I’m sure there will be changes and additions to this loop, particularly when we add in the new features we discussed earlier, and we’ll want to add in the music loop, but generally speaking that’s all there is to it.

Design Considerations

There are several design considerations we’ll have to think through.  First on the list is the display.  We basically have two options.  First, we could do everything in hi-res mode, and use a sprite for the game piece.  Once it is at a place where it can’t move anymore, it turns into part of the bitmap itself, then the next sprite appears at the top again.  But this is problematic.  Animation speed is a factor.  As well, converting the sprite to bitmap graphic will likely cause a nasty flicker and just won’t look right.

The other option is to use character graphics instead.  This will be considerably faster and easier to manage the game field matrix.  The concern I have with this is whether the characters might be too big to really be playable.

Since this is a learning process, I’m going to try both ideas and see how each turn out.

Next is sound.  I would like to have a version of the same music from the original playing.  So we have to figure out how to implement this music and have it match perfectly with the game animation.

Next Steps

Well, we have our game plan in place.  In the next blog post I’m going to work on getting the skeleton of the program set up.  In other words, we start coding!  See you then.

Ramp Up

Difficulty:

Welcome to part two of my little project.  In the last post I talked about the joys of programming the Commodore 128, and my intention of learning and relearning the intricacies of 8-bit programming on the Commodore 128.  As well, I covered a few prerequisites that you would need if you want to follow along with my project.  I mentioned that I’d be working on a computer game, and that we’d need some software to get ourselves started. I’m assuming at this point you’ve downloaded and installed the software.  Let’s start from there and get our 128 software, namely the Merlin Assembler, ready to go.

(Side note:  Starting with this post I’ve added a “difficulty” level.  This will help the reader gauge the level of involvement that may be involved with the article.  I’m doing this so that the more experienced reader can know if they can just brush over the content or if they need to delve in deep.)

Setting Up WinVice

I won’t go too deeply into this, but I thought it might be important to cover a few things for those who have never used this, or possibly never used a Commodore 128.

As I said in my last post (and as you likely already knew), WinVice is a Commodore 8-bit computer emulator that covers every 8-bit machine Commodore came out with in the 80s (and 70s, if you include the PET).  The awesomeness of this software is self-apparent, but the documentation is less than stellar.  Also, if you’ve never used a Commodore computer, you’re going to find that it’s not as easy as the more modern computers are.  Running the software is easy – locate the directory into which you installed the WinVice software and run the file x128.exe by double-clicking on it.

The first thing you’ll notice about the Commodore 128 emulator is that two windows are displayed when you run the software.  This is because the 128 had the ability to display text in both 40-column mode (like the Commodore 64) and 80 column-mode.  Each mode has its own window; however, by default control is given to the 40-column mode, just as it did on an actual Commodore 128.  That’s well and good, but the software we’ll be using to develop our game only runs in 80-column mode.  Actually this is preferred anyway for reasons that will become clear, but we need to get to that mode to continue.  As well, it would be nice to be able to default to 80-column mode so we don’t have to keep manually switching whenever we start WinVice.  First, let’s get to the proper mode.

Make sure your 40-column mode has focus.  Then, tap F7 on your keyboard.  This tells WinVice that you want to use the 80-column mode.  Next, type <Alt>-R.  This does a soft reset, restarting the emulator.  You’ll notice once you hit those keys that control now shifts over to the other screen, the 80-column screen.  By default that screen has a black background with some pleasant colored light blue text.  You’ll also see the word ‘Ready,’ followed below that by that all-familiar blinking cursor.

Ok, it looks like we have our system set up properly.  Now let’s get our development environment all set up.

Merlin

In the last post I mentioned that I’d be using Merlin 128 Assembler.  If you’re following along, I recommend you do the same.  There are several reasons for this, but the main reason is simple – it uses the Commodore 128  80-column mode, and it operates in FAST (2mhz) mode instead of the usual SLOW (1mhz) mode.  Other reasons include its ease of use and extensive flexibility, and the fact that the best 128 Assembly language book you can buy mentions it (You’ll find this book in the Dropbox link I provided in the last post).

Go ahead and attach the merlin128.g64 file to Drive 8 (File->Attach Disk Image -> Drive 8).  Be sure also to select the “Attach Read Only” checkbox.  This will treat the disk image as if there was no way to write to the disk, kind of a safety measure to prevent us from messing up the system disk.  Once attached (be sure to click the attach button), press ALT-R (or click File->Reset->Hard Reset).  This reboots your emulator and should automatically start Merlin for you, bringing you to the screen shown below.  If you’re not seeing this, verify that you’ve attached the proper disk image, and that you’ve properly set the 80-column mode to be booted by default.

Now that we’ve got the software running properly, my next still will be to make sure the software is going to work properly for me.  I won’t go through each of the menu items available to us, as I’d only be repeating what you could read in the book I mentioned earlier.  However, I do want to cover a few items that will be important.

First, exiting the app is easily done by pressing ‘B’ (for Basic).  You’ll be asked if you truly want to “abandon” Merlin.  Pressing ‘Y’ will bring you back to the familiar Ready prompt.  If you would like to return to Merlin, you don’t need to restart the emulator.  Merely type SYS 2048 and press <Return>, and you’ll find yourself right back in the Merlin main menu.

Second, I want to have a working disk in my second drive.  Merlin allows us to write programs to the system disk, but for obvious reasons that’s a bad idea.  Instead, I’m going to create a new blank disk and ‘insert’ it into device 9 (the second drive) by attaching the work disk image to it in the same way that I attached Merlin to drive 8.  Before I can do that, however, I need to create the work disk.  It’s rather simple, and indeed I can kill two birds with one stone.  I simple select File->Attach Disk Image -> Device 9.  This brings up the disk image selection dialog.  If you look toward the bottom of the dialog, you find the ability to create a disk image.  In the ‘name’ text box I’m putting ‘merlinwork’.  for the Type, I’m selecting d64, which tells WinVice that the disk is one meant for the 1541 single-sided drive.  While it may seem to make sense to select d71, thereby using the 1571’s capabilities (Faster, double-sided, etc), I’m developing my first game for the Commodore 64, not the 128.  So, I want to make sure the 64 can read the disk.  Anyway, I’m leaving the ID with the default, but you can use any 2-letter hexadecimal value you wish.  Now, I need to enter ‘merlinwork’ into the ‘File Name’ text box, and click ‘Attach.’

All that being done, I’m ready to go back into Merlin, so I type SYS 2048 and press enter. Once at the menu, press ‘D’ to change the work drive.  Merlin asks for the drive designation.  press ‘9’ and <Return>, and now any saving or loading that is done, is done on your newly created work drive.  (Since we loaded Merlin as read-only, we’re ensured that we won’t write on the system drive anyway, but it’s always good to be certain!).  If you’d like to be certain the drive change worked, you can type ‘C’ for Catalog and you’ll see the contents of your work drive (obviously, no file will be shown, but you’ll see the blocks free).

Ok, we’ve got Merlin running.  We’ve got a work disk set up, with Merlin pointed to it.  Now, I want to make sure Merlin will let us write a short assembly program, compile it, and save both the source and object file to our work disk.

Writing of source code is done via the Merlin editor.  You can enter Editor mode by tapping the ‘E’ key.  You’ll now be at the Editor prompt.  There’s quite a bit we can do from here, but for now we just want to start writing code.  Type ‘A’ (for Append) and press <Return>. This puts you in editing mode.  The screen clears and you find yourself at the Merlin editing screen.

If you’re used to modern text editors, this one may throw you for a bit of a loop.  I won’t go into details on how to enter text, but the basics are that you have four columns where you can enter the text.  The compiler expects the OpCode to be in the 2nd column, the Operand to be in the 3rd.  The 1st field is the label field,  and 4th is used for comments.  I highly recommend reading the manual (also found in my Dropbox share, mentioned in my previous post) to get a more thorough tutorial.  In the meantime, let’s write a little program.

As you enter each line, be sure to tap the space bar first before entering the line.  For instance, line one should be entered as <space>ORG<space>$1300<return>.  Do the same for each line.  Once completed you can return to the editor prompt by tapping the Commodore key and the white left-arrow key (on my keyboard that’s the left control key + the tilde key).  type ‘L’ and <Return> to get a listing of what you typed.  To compile this short program, type ‘ASM’ and press <Return>.  Very quickly you’ll see a list of the results, essentially showing no errors.  Hit ‘Q’ and <Return> to en – you know what?  From now on I’m just going to tell you which key to hit and assume you know to hit the <Return> key!  Anyway, the ‘Q’ command gets you back to the main menu.

Now, let’s make sure we can save the files properly.  At the main menu, tap ‘S’ to save.  Merlin will ask for the name of the file.  Type ‘Hello’ and press <Return>.  This will save the file with a .s extension, which is added automatically.  Next, we need to save the compiled code, or Object code.  Do this by typing ‘O’.  Merlin will again ask for a file name, but this time it assumes you want the same name.  Just press <Return> and the Object file is saved with a .o extension, again added automatically.  If you’d like to verify the files saved correctly, simply type ‘C’ and you’ll see a listing.  Ensure you have two files, hello.s and hello.o, then press <Return> to go back to the main menu.

Now let’s try running our program.  Hit ‘B’ to get out of Merlin.  Then, load your object code into memory by typing: LOAD “hello.o”,9,1.  After a moment you should see the Ready prompt.  Finally, type SYS 4864 and press <Return>.  You should see the word ‘HI’ printed.  If so, congrats!  Everything is working properly.  Now, we’re ready to actually start working on the game, which we’ll start in the next post.