Part Eight - Everything comes to him who waits

After having put the Prince of Persia project on hiatus, I went on to do other things. One of them was a GameBase64 browser for Mac OS X (for my own personal use) and the other was a conversion of the Flash/iOS game Canabalt for the C64 (not to be confused with C64anabalt, the other Canabalt version for the C64 by Paul Koller).

A port of Canabalt, the popular one-button jump'n'run, was an interesting diversion

But Prince of Persia was still at the back of my mind, mostly because it's such a great project and I got so far already. I still intended to finish it some day, but I didn't have the energy and most of all, I couldn't see the light at the end of the tunnel. I had no plan how to continue.

Part Seven - Hitting the memory and motivation barrier

Throughout September and October of 2009 I worked tirelessly to implement all the various gameplay features. I went through all the transitional objects and implemented them one by one.
Unfortunately I quickly ran into problems due to the fact that I didn't have a double-buffered drawing system.

Part Six - Playing hide and seek with pixels

At the beginning of August 2009, I had already progressed quite far. In the previous two months I got to the point where I could run with the Prince through the first level, except that none of the interactive elements of the game worked yet.
And there was one big visual problem. Walking behind the pillars in the level didn't cause the character to be occluded. The prince was simply a set of sprites on top of the level background graphics. Not good enough.

Part Five - Painting a pretty dungeon

It's now late July 2009, and I finally had to really start looking into that interesting drawing that Jordan put in his document:

Jordan Mechner's sketch of the sections of a block and their drawing order

Part Four - To bitmap, or not to bitmap, that is the question!

Now that I had a somewhat basic understanding of the way the game handles the player animations, controls and collision detection, there was a big unknown area left. How does it draw the background graphics? How does it handle the visibility of the Kid when he goes behind a pillar?

Thankfully the document explains quite a bit about the drawing system.

First, let's have a closer look at how the level data looks like. Each level consists of 24 screens, and each screen is divided into three rows of 10 blocks each. So 30 blocks in total per screen. Blocks can be identified by their X and Y coordinates or by their block index, e.g. the block in the bottom right corner has X/Y of 9/2 or a block index of 29 (we start to count at zero).

Block indices

Part Three - Making the Kid come to life

After having successfully found my way into the animation code of Prince of Persia, my top priority was to take all of the information I gathered and integrate it into my current test program. I decided that I'm just gonna take the relevant parts to be able to animate the character and make him run around the screen, with all the right actions, climbing, jumping, etc.
So I had to completely dissect the code from the controls down to drawing the sprite onto the screen. I didn't plan to lose any time.

The first thing I noticed from looking at the sequence table parsing were the zero-page locations that it's using. CHX is modifying $41, CHY is modifying $42 and so on. At the end of that code, if the byte from the sequence table is not any of the instructions, it does this:

l4a2a:
                sta l40
                rts

So if it's not an instruction, but a frame number, it gets stored directly into $40.
Now it was very plain to see that these memory locations must be the "character data" variables mentioned on page 17 of the PDF.

Part Two - In the beginning there was a binary data blob

If you haven't guessed yet, it's going to become more technical. You've been warned.

So there I was on June 19th 2009. A printed copy of Jordan Mechner's PoP source code documentation in one hand, and Virtual II (an excellent Apple II emulator for Mac OS X) running the original Prince of Persia game.

Running the Apple II version of Prince of Persia in the Virtual II emulator

Part One - Why the hell would anyone want to do that?

So how and when did I start to work on a C64 version of Prince of Persia? And for the love of god, why?

In October of 2008 I visited the X party, a Commodore 64 demo scene event in the Netherlands. This sparked my interest in actively doing C64 programming again, something I haven't really done in the 15 years before that, even though I still kept up with the developments in that community.
At this point I actively started looking for a C64 project, and a game conversion seemed like a good idea, given my background as a game developer. I was rusty and needed something bordering on the trivial to get my 6502 assembly juices flowing again.

Prince of Persia preview by Poharai Attila and Varga Viktor from Hungary

So in May of 2009 I found the Prince of Persia preview on CSDb. It's an attempt from the 1990s at converting Prince of Persia, that unfortunately only produced a slide show of some of the level graphics. But the comment beneath, by Mikael "Twoflower" Backlund got my attention: "A C64 version of this game would sure be something.". I immediately had the same feeling. And then he wrote: "Furthermore, the sourcecode to one of the 8-bit versions is out there.".

Prince of Persia for Commodore 64/128 released

The C64 conversion of Prince of Persia, based on the original Apple II code by Jordan Mechner has been released today.
It requires a Commodore 64 or 128 (or maybe even a C64GS if you own one) and an EasyFlash (or 100% compatible) cartridge.
You can download the cartridge image from this CSDb page

Here are some screenshots and a few movies of the game:

During the next couple of weeks I will post my development diary. Details about the work on this conversion, pitfalls and little success stories. In short, pure C64 coder drama. Don't miss it!