Monday, October 17, 2011

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.".

That made me all warm and fuzzy inside. But soon I had to find out that what he meant was the version of Prince of Persia for the SAM Coupe computer. Although an outstanding technical achievement, it was not a direct port of the original game, but rather a fan-made recreation, which was close to Jordan Mechner's classic, but also different in lots of ways. And it was for a Z80-based architecture, which I personally never worked on and have little passion for.

FreePrince project

But the idea stuck with me. Is there someone who has done the reverse-engineering work of Prince of Persia? Something that I could just take and port to the C64 quickly?
I kept digging and immediately came across the FreePrince project. This is your typical open-source version of a classic game, created by a group of enthusiasts, using the trusted SDL framework. I thought that I had struck gold. Although it seemed unmaintained and it was hard to find the source code, it was a somewhat working version of Prince of Persia using the original game's graphics and level data. It had a complex animation state machine and lots of things working, so I assumed that it was based on disassembly of the PC or Amiga version. Plus it pointed me towards the Princed project and their tool "PR", a Prince of Persia resource extraction tool.
The latter can be used to unpack the data files that came with the DOS version of Prince of Persia to get the individual images, sounds and palettes that make up the assets of the game.
So, without further ado, I started hacking away. I took the 216 animation frames of the Prince extracted by PR, and first converted them to C64 resolution and colors.

The C64 features a multi-color mode that is using two bits to represent one pixel. This means you can use four colors, which you can select from the sixteen available colors. Since the memory storage size for graphics is the same in single-color and in multi-color mode, the graphics chip has to halve the horizontal resolution of 320 pixels in order to use two bits per pixel instead of one. So the effective resolution for multi-color graphics is 160x200, which is also half of the resolution of the DOS game. And since one of the 4 colors has to be the transparent color that meant that only 3 colors are available for the Prince character. I quickly settled on white for the clothes, light red for the skin and brown or orange for the hair. Using semi-automatic conversion tools I came up with this:

Original image from DOS version
Automatic conversion to C64 resolution and colors
Yes, that's a lot of detail lost, but it was inline with other C64 games. I was sure I'd be able to find some graphics artist who could polish that up later.
Doing this conversion for all the 216 animation frames quickly gave me a complete set to be used on the C64.
So at this point I fired up my source code editor. I took at look at the source of Freeprince, and started to implement its animation state machine in assembly code. I laid out the Prince animation frames as sprites in memory and immediately noticed that it's gonna be tight. Those animations sure need a lot of memory. But that would be for later to worry about.
Within a couple of days I had a simple working version. Basic animations states were implemented, such as running, jumping, crouching, etc. On June 15th 2009 I captured a video and showed it to one or two people.

Download a C64 .prg file of the work in progress version from 15-Jun-2009.

The response was a bit muted. Not enough of the game there yet. Also the animations looked dodgy. The positioning of the frames used in FreePrince was not based on the original game. Someone must've redone that manually, and so the locations were wrong.
So I kinda went off in the wrong direction. FreePrince certainly wouldn't be good enough for a faithful conversion. It was also incomplete and not fully playable.

Back to square one. I had to look for better source material. Disassemble the DOS version?
In the meantime I found Jordan Mechner's blog. He had the courage and insight to post all of his old journals from the 1980s. He meticulously kept a log of his daily work. What a great read that was. Just a few days before I started looking for Prince of Persia information Jordan also posted this article on his blog. It contained a link to a PDF, which turned out to be the Prince of Persia source code documentation.

I was amazed. The source was lost on Apple II disks, but the document written just a few days after the release in 1989 was there, with all kinds of juicy little details about the graphics engine, the data structures, lists of images, and more. It was like someone had handed me the key to a long lost treasure. I didn't even know that there was an Apple II version of the game, and that it was the original version. I learned that all others were ports (or ports of ports) of that one original. And it was all in perfect 6502 code, which I could read and which would run fine on the 6510 (a 6502 variant) of the Commodore 64. Sure it said it would need 128KB of RAM, but at that time that seemed like a small challenge. I imagined it to be very inefficient code and easy to optimize. Piece of cake, right?

So how do you go about reverse-engineering 128K of code and data? It's all just a big pile of binary data. It's like one really big crossword puzzle.Where do you start?
I'll cover that in my next post.


  1. Wired reported that the C64 version of this game was made "using the original Apple II code". That seemed unlikely. From this blog post, I gather that you used the graphics and level data but not the code. Is that correct? If so, it makes much more sense, without diminishing the amazing effort!

  2. This is just the first part, in part two I'll write about how I started to use the Apple II code...

  3. Great achievement! looking forwards to part 2

  4. By iteratively splitting it into its contituent parts, assigning the correct datatype to each segment. At least that's how I start :) Can't wait to hear your method, everyone's different.

  5. Or just optimize the inefficient parts properly and other nasty ways like we usually do on C64. Great work!

  6. I am getting shivers reading this Andreas. Amazing, thanks for sharing!

  7. if i remember correctly the c64: there can be used 8 sprites either in hires or lowres, right? when in lores 2 bits are combined to form a color index with 0 as background?
    i don't remember the prince of persia pc-game very well, but are there a lot of moving objects simultaniously on the screen?
    if not - can one combine multiple hires-sprites to one hires-sprite with more colors?
    so that you use all 8 sprites for the 'prince' in hires? does that hack work?

    1. No, you can't do that, specifically.
      But you can have more than 8 sprites, by reusing them after they have been drawn by the graphics chip.
      None of that is necessary for PoP though, the prince is using 4 sprites and the enemies are using 4 sprites. Other moving objects (which are part of the background) are drawn into the screen bitmap. They need to have different colours anyway, and there's not much overlap between background and character colours here.

  8. Great article!! Pop is a great game, after all these year it lost nothing of its fashion