08.02.1978

Why am I here??

The Eighties.  The “Decade of Greed.”  The Decade of “Me.”  Over the past 30 years, the decade in which I grew up has been maligned at best, and at worst derided as the worst decade of the modern age.  While it’s true there were many things from the eighties worthy of criticism, whether you agree or not you can’t argue that many good things… no, fantastic things also emerged from this time.  Cell Phones, Compact Discs, the birth of New Wave and Hair Metal (granted, those last two are pretty subjective, but still)…

And Computers.

Granted, computers have been around since 1959 and earlier.  Early IBM Behemoths such as the 704 and 7094, The TX-0, the PDP-1.  (For more information on these computers and the amazing stories of the growth of the computer industry, pick up Hackers: Heroes of the Computer Revolution by Stephen Levy.)  The Apple II was created in 1977, and many would argue that computer is what truly began the computer revolution.  However, it wasn’t until the 1980s that the computer revolution truly began.  Growth in the tech sector grew by leaps and bounds, as did the technology itself.  We experienced the Apple II, the TRS-80, the PET.  These beginnings were rudimentary, even crude.

Then we were blessed with the Commodore 64, and later the Amiga.  The Apple Macintosh, the Atari ST.  Most importantly from a business perspective, we have to include the IBM PC/XT/AT. Graphics improved, Sound went from beeps and boops to proper stereo synthesizers capable or producing commercial quality music.  Microsoft Windows became a thing.  We went from 8-bit to 32-bit.  All of this happened between 1978 and 1990.

Of course, I’m loving on the eighties for more than just the tech.  I grew up in the 80s.  My first computer was the Commodore VIC-20, in all its 5k RAM, 22-column display glory.  I graduated to the Commodore 128 before finally succumbing to the IBM compatible world.  Later on I became a programmer professionally, writing software for all of my professional life.  I’ve written software for gaming systems, big data environments and shrinkwrap development environments.  I’ve truly enjoyed the things I’ve been able to do and accomplish.

But as I’ve grown older I’ve found myself growing nostalgic  for the old days, the 8-bit days of the Commodore and Apple IIe.  I learned BASIC on my VIC-20.  I learned machine language on my 128, but never really became the expert programmer on it.  I’ve always wanted to go back to it, learn the intricacies of 6502 (well, 6510/8502) machine language programming… and hacking.

This blog is going to cover my journey in learning the tricks of the old trade.  I’m going to be eventually writing a game using the things I’ve learned over the years and the things I’ll learn over the next few months.  Everything I learn I’ll write about here, so if you’re as interested in learning 8-bit computing as much as I am, stick around.  It’ll be a bumpy ride, but at the end, it’ll be worth it.

Let’s get to work.

Tools Of The Trade

Back in the before time, writing software for your computer wasn’t as easy as it is today.  The development environments we have today are, in a word, amazing.  Whether you’re developing software with Visual Studio or Eclipse, everything you need is at your fingertips.  you can write, debug, even publish your software and even develop it for several different platforms.  On the 128, you didn’t have such luxuries.  If you wanted to write quality code, you were basically limited to pure machine language.  Writing machine language wasn’t easy – In fact, without the right software it was nigh impossible!

Today, things are much, much easier.  It’s possible to use modern tools to develop software for the 128.  You can use any text editor you wish, compile your code using a modern compiler, then use special software to create a disk image that can be put onto a disk for use on the 128 (or 64).  Development time can be cut down to a fraction of the time it would historically have taken.

But I’m not going to develop software in the easy way.

The whole point of this adventure isn’t just to develop software.  As I mentioned earlier, I do that for a living.  Obviously, nothing I develop is going to be commercially viable.  This whole excursion into 8-bit land is for one reason only – to have fun reminiscing!  Now, that being said, I do have to make some allowances.  Simply put, I no longer have a C-128. Mine disappeared decades ago, and replacement ones on eBay run in the area of $150-$400 dollars (!). While I’d have no problem spending that much, my wife would kill me.  So instead, I present you with the first item in our tool box:

WinVice 3.x

This cool tool is the best Commodore 8-bit emulator you can get.  With this package you get emulators for the VIC-20, C-64, +4, 16, and the 128.  You also have access to all the different I/O devices, such as the 1541/1571/1581 disk drives and the Datassette tape device.  As an added bonus, many of the cartridges and add-on devices that were available to you as an owner of these computers is also available.  Memory expanders, BASIC language enhancers, even CP/M emulators!

As a developer you’ll really appreciate “Warp Mode.”  Activating this mode makes your emulator run at 4-5x the normal speed of the emulator.  The upshot of this is most things that take forever to run on a 1mhz machine takes a fraction of the time.  You soon learn to truly appreciate this bonus!

Installing WinVice is a breeze.  I won’t go into details here, as the WinVice website helps you out with that, and that’s assuming you even need help.

For the most part my time will be spent almost exclusively on the 128 emulator.  The 128  had a C-64 emulator built in, so there’s no need to run that emulator as well.  Beauty!  Be sure to install WinVice before anything else – you’ll need it to continue along with me.

Merlin 128 Assembler

This software is a disk image that loads and runs on the 128.  It’s the only way you can run this software – trying to run it on Windows or any other modern O/S will just end up with your being depressed and confused.

The Merlin assembler was one of the best available for the 128, and even the 64.  It has all the earmarks of a professional assembler, with features that are common even in today’s assemblers such as labels, full screen editing, debugging, etc.  Everything you need to write whatever software you want is right at your fingertips.  I’ll explain the use of this assembler in a later post, but for now, click on the link to get a copy of it via my Dropbox.

Also within that link you’ll find several PDF-formatted books that you can use (as will I) to learn more about the innards of the system.  The most pertinent of these books are:

  • Commodore 128 Assembly Language, by Mark Andrews
  • Merlin 128 Manual
  • Commodore 128 System Guide
  • Commodore 128 Programmer’s Reference Guide
  • Commodore 128 Peeks and Pokes

Each of these have their own qualities.  The book by Mark Andrews gives an excellent tutorial on the usage of Merlin, as well as a step-by-step guide to Assembly language itself.  I’ve read it through, and continue to use it as a reference guide.  I suggest you do the same.  The other books provide other bits of important information, the key one being the Programmer’s Reference Guide.  Be sure to download all of these books, they’ll come in quite handy!

 

That’s all we need for now.  Next blog post, I’ll cover how to get the Merlin assembler up and going, as well as basic usage of the software.  We’ll even write our very first assembler program!  In the meantime, get your environment set up, do some advance reading, and get ready for some fun.

 

Advertisements

08.21.1978

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.

08.06.1978

Ramp Up

Difficulty:https://retromojo.files.wordpress.com/2017/08/1-star.png?w=85&h=18

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.

 

40 Column Mode for the Commodore 12880 Column Mode for the Commodore 128

 

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.

Merlin128_Menu

 

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.

exampleprogram

 

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.