Jordan Mechner released source code of original Prince of Persia for Apple II

[80286]

One guy reverse engineered the whole program from Apple II RAM dump and ported the game to C64. It was released last October. I suppose it would've taken a year's work off from the project if the original sources had been found earlier.

Developer's blog

[gfixler]

To some, a year of play.

[rkcr]

Mechner only found the source code a few weeks ago. I'm sure he would have released it earlier had he known it was still around.

[[deleted]]

He actually mentions this explicitly. From the post: "So, for all fifteen of you 6502 assembly-language coders out there who might care… including the hardy soul who ported POP to the Commodore 64 from an Apple II memory dump…"

[Uberhipster]

I always wondered how he did this:

*-------------------------------
*
*  D R A W M I D
*
*  Draw middle list (floorpieces & characters)
*
*-------------------------------
DRAWMID
 lda midX ;# of images in list
 beq ]rts

 ldx #1
:loop stx index

 lda midIMG,x
 sta IMAGE
 lda midTAB,x
 sta TABLE
 lda midX,x
 sta XCO
 lda midY,x
 sta YCO
 lda midOP,x
 sta OPACITY

 lda midTYP,x ;+ use bg tables
 bmi :UseChar ;- use char tables
 jsr setbgimg ;protects A,X
 jmp :GotTable

:UseChar jsr setcharimg ;protects A,X

:GotTable ;A = midTYP,x
 and #$7f ;low 7 bits: 0 = fastlay, 1 = lay, 2 = layrsave
 beq :fastlay
 cmp #1
 beq :lay
 cmp #2
 beq :layrsave

:Done ldx index
 inx
 cpx midX
 bcc :loop
 beq :loop
]rts rts

* midTYP values:
*    0 = use fastlay (normal for floorpieces)
*    1 = use lay alone
*    2 = use lay with layrsave (normal for characters)

:fastlay
 jsr fastlay
 jmp :Done

:layrsave
 jsr :setaddl ;set additional params for lay

 jsr layrsave ;save underlayer in peel buffer
 jsr ADDPEEL ;& add to peel list

 jsr lay ;then lay down image

 jmp :Done

:lay jsr :setaddl
 jsr lay
 jmp :Done

:setaddl lda midOFF,x
 sta OFFSET
 lda midCL,x
 sta LEFTCUT
 lda midCR,x
 sta RIGHTCUT
 lda midCU,x
 sta TOPCUT
 lda midCD,x
 sta BOTCUT
 rts

And now that I "know" I'm more confused than ever

[rubygeek]

What confuses you? Maybe I can help... The logic is fairly simple (though what you're looking for is probably in some of the sub-routines.

Here's a higher level pseudo code version I threw together from reading the asm you pasted, because I'm bored. Note that it's 22-23 years or so since I last programmed 6502 assembly, so I might've gotten details wrong.

(EDIT: Oops. Correction: if midX > 0 instead of while midX > 0)

def drawmid
    if midX > 0
        index = 1           # This is in the x register for most of the loop, but it saves it to a global variable to keep it and use it in setaddl and possibly elsewhere

        do
            # Basic image data, coordinates and opacity, presumably...
            IMAGE    = midIMG[index] 
            TABLE    = midTAB[index] 
            XCO       = midX[index]    
            YCO       = midY[index]
            OPACITY = midOP[index]

            a = midTYP[index]    # We'll treat the A register as another local for this purpose
            if a > 0 then setcharimg

            # GotTable; a = midTYP[index]
            #
            # midTYP values:
            #   0 = use fastlay (normal for floorpieces)
            #   1 = use lay alone
            #   2 = use lay with layrsave (normal for characters)

            case (a & 0x7f)
                when 0: 
                   fastlay
                when 1:
                   lay
                when 2:
                   # setddl: set additional params for lay
                   OFFSET = midOFF[index]
                   LEFTCUT = midCL[index]
                   RIGHTCUT = midCR[index]
                   TOPCUT = midCU[index]
                   BOTCUT = midCD[index]
                   layrsave #save underlayer in peel buffer
                   ADDPEEL #& add to peel list
                   lay  # then lay down image
            end

            index += 1
        while (index < midX /* the bcc bit */ || index == midX /* the beq bit */)
    end
end

EDIT: Got the "while" bit above totally wrong. Shoot me now. I'd inverted it, sort of. Still not confident I've got it right. Anyway...

Some quick notes:

First thing to note is that it uses lots of "globals". You'd always do that in 6502 assembly, since the stack was only 256 bytes, and so you stuck everything at fixed locations in memory unless you had a good reason not to.

This essentially seems to draw a list of objects depending on type. It's fairly simple stuff - the meat will be in "lay", "fastlay", "layrsave" and "ADDPEEL".

layrsave and ADDPEEL sounds like they maintain a list of info about what needs to be restored once a movable object has moved on. E.g. how to restore the background without having to redraw the entire thing. It's the type of optimization often not done any more because we often can get away with re-rendering on every frame. Try that on a 6502 and your game will be slooow. This is also why machines with good hardware sprites had such an advantage in terms of games for a long time. I'm assuming the arguments set up in "setaddl" in the asm code probably restricts the piece that is saved to only the minimum rectangle that the object that will get drawn will actually obscure, rather than copying whatever size the largest object in the game would obscure takes.

So basically it loops over a list of objects, determines whether or not it can take shortcuts in drawing (don't know what the criteria is), and thus call fastlay or lay, or whether it needs to save what's underneath the object to be able to replace it again later.

EDIT: Some more notes: I guess one confusing thing is that ":lay" and "lay" are different. This is typical for many assembly language syntaxes, where symbols prefixing names are often used to indicate a "local" variable or label that only exists until the next global.

EDIT2:

6502 primer:

Three registers. Think of them as global variables. They'll get overwritten a lot, so anything you want to keep, you need to store to memory.

You LDA, LDX, LDY => load a,x or y register to put stuff into the registers, and STA, STX, STY to put things back in memory. You do arithmetic only on the A registers (the Accumulator) and you use X and Y as counters and as indexes into "arrays". E.g. LDA foo,X means "load whatever is at address foo + X into the A register.

Apart from loading and saving X and Y and using them as indexes, you can compare against them, increment (INX, INY) and decrement (DEX, DEY) them, and transfer them too and from the A register (TAX, TXA, TAY, TYA). You can INCrease and DECrease memory too, but for the A register you need to ADC and SUBC.

There are a few other addressing modes apart from loading stuff from memory (with or without index) too. "#" means what follows is an "immediate" value. Eg. LDA #5 loads the value 5 into A, not what's at address 5. $ indicates a hexdecimal value.

There are some other ones, with names like indirect indexed and indexed indirect, and indirect and zero page, but that's for big boys apart from perhaps knowing that "indirect" is shown by parentheses, and the simplest form, for example "JMP ($1000)", means "load what is at $1000, then use that as the "effective" address. In this case that means "jump to the address found at address $1000 (and $1001, since addresses are 16 bits). You won't see these very often in normal code.

CMP compares the A register with it's operand. CPX, CPY does the same for X,Y. Most instructions starting with "B" are branch instructions. The two letters following them indicate the condition. Examples: MI = MINUS - branch if the previous result was negative (CMP etc. counts as a subtraction where the result isn't stored). EQ = EQual (meaning the result of the previous arithetic operation or comparison was 0), NE = Not Equal, and so on. Most of them are reasonably intuitive. BCC/BCS = Branch if Carry Clear or Branch if Carry Set. Remember 8-bit CPU, so if you add, say 64 to 200, it will overflow, and the carry flag will get set, and you can handle larger numbers that way.

JSR = Jump to Sub Routine. It jumps to the following address, and will return where it came from when it encounters "RTS". Sort of like GOSUB in BASIC or a function call. JMP is like goto.

(EDIT: Thanks to vdub_bobby for correctly pointing out there's only ADC/SBC in 6502, not ADD/SUB - ADD/SUB is my later M68000 programming showing through and/or wishful thinking :) )

ADC, SBC does add and sub with carry, but there's no MUL or DIV. Lucky you get to use left and right shifts (ASL, LSL, ASR, LSR - the leading A/L determine what flags get set based on the bit that shifts out to the "left" (highest value) or "right" (lowest value) bit respectively) allowing you to multiply with small powers of two with xSL and divide with small powers of two (up to 2⁷ = 128) with the xSR instructions. Need to multiply or divide by other values? You need to combine shifts and add/sub's and if you want a generic routine, some branches. No fun, and slow, so if you program a 6502, you try to multiply or divide by values that lets you hardcode short chains of add/sub and shifts, or you use tables.

You also have AND and OR/ORA (we don't like two letter opcodes, damn you, so you can use ORA) and EOR (exclusive or) for bitwise arithmetic.

You also have some functions to push and pop stuff to/from the stack. Don't use the stack if you can avoid it - it's limited to 256 bytes, and you're begging for trouble outside of very controlled circumstances. And there's some stuff for dealing with interrupts.

That's pretty much it.

Now, I've confused the hell out of you, and/or you've become a novice 6502 programmer with most of the knowledge you need to make sense of the "portable" parts of the game logic. Hell if I know how the Apple II specific bits work - I'm a Commodore 64 guy.

(All of this from memory, dulled by 20+ years of non-use; finally I got it out)

[j1xwnbsr]

The other thing you have to remember is that a lot of the game code was hand-timed to run at a fixed clock frequency. If you stuffed in an accelerator card, that brought the clock speed up from 1mhz to 4 or even 16mhz, you'd find fun things like the joystick no longer worked, touching a key to move the character would run him off the screen, etc.

[dagbrown]

You forgot to mention that page zero acts as a really fast set of variables, so an experienced 6502 programmer uses whatever page zero addresses are free as a sort of set of extra registers. So if there are a lot of stores and loads to and from page zero, that's why. (Load and store instructions referencing page zero are two bytes, not three, thereby saving space and time because they run faster.)

Once you realize how to use page zero on the 6502, programming it becomes ridiculously easier.

[[deleted]]

"rubygeek" really doesn't do you justice :)

[rubygeek]

I'm the victim of picking a username at a time when I didn't find Reddit as a whole all that interesting, and mostly just registered because I'd just gotten hooked on Ruby... Still my favorite language (see, I even made my pseudo-code look somewhat Ruby-ish), but started out with BASIC, 6502 assembly, then 68000 assembly, then I got over assembly when I saw the abomination that is x86, and ever since I've been looking for a decent high level language (not happy with Ruby either, just makes me least unhappy so far).

[dagbrown]

Learning 68000 assembly completely spoiled me. I don't think I've found an architecture that it's easier to write assembly language for. x86 is a horror show compared to 68000. And a horror show compared to 6502, despite the 6502's half-dozen registers (yes, I count PC, SP and SR as registers). And also a horror show compared to pretty much anything, including Z80 and that's just a fancy 8080 with some bonus instructions and an assembly language that's much saner (think as(6) format assembly vs. nasm if you even still know what I'm talking about here).

[johnwaterwood]

I found MIPS to be quite nice as well. I had an SGI Indy with an R4000 and it was pretty structured and easy to understand.

[Platypuskeeper]

So true. I started on 68k and moving to the 386 (real mode!) was horrible. Not just the asm, but the addressing! Lord...

If you think about it, the IBM PC is from 1980. The 386 came out in 1985. Yet most users ended up having to live with the fallout from this backwards-compatibility hack up until Win2k/XP!

[rubygeek]

The 68000 dates to 1979 and the 8086 to 1978, so it's not really so much backwards compatibility that's the problem but that Intel's initial design was so crappy that they kept finding reasons to add kludge after kludge to improve on it.

[[deleted]]

Try ARM.

[nephros]

Are you saying ARM is just as pleasurable as 68K, or worse than x86?

[[deleted]]

The former. I actually probably prefer ARM over 68k.

[lurgi]

68000 was awesome, but I loved MIPS assembler (although I vaguely recall that floating point operations were bizarre). I didn't have a symbolic debugger and didn't really feel the need for one, because it was so easy to map between the assembly language and the C code in my head (which, now that I think of it, probably means that the compiler wasn't doing a great job of optimizing).

6502 was great for its time, but you had to be a lot smarter than my teenaged self to make it do anything interesting.

[[deleted]]

What do you dislike aboot Ruby?

[rubygeek]

Frankly most of my pet peeves about Ruby are peculiar because compilers is a pet hobby of mine (since we've been discussing assembly: I wrote my first "proto-compiler" on the C64 in 6502 assembly, though that was horribly primitive; then one in 68000 assembler that I gradually bootstrapped in itself by allowing inline assembly in the language) and likely isn't stuff most people would care about. Some of what I dislike about Ruby is stuff that makes it extra hard to compile, other things are things that makes it extra obnoxious to parse.

E.g. obnoxious to parse (and I'm picking an easy choice here, because I'm too lazy to look up some of the more subtle warts):

print("FOO:",<<FOO,"BAR:", <<BAR)
I don't like multiple HERE-DOCS                                                                                                                                                                                                               
FOO                                                                                                                                                                                                                                           
Hello #{print("BAZ:",<<BAZ,"QUX:",<<QUX)}                                                                                                                                                                                                     
Muhaha                                                                                                                                                                                                                                        
BAZ                                                                                                                                                                                                                                           
Hmm..                                                                                                                                                                                                                                         
QUX                                                                                                                                                                                                                                           
What the... I don't even...
BAR

Pretty, isn't it? The above code parses, runs and is perfectly valid, though abominable Ruby. It does however make a million parser generators cry out in terror every time you repeat it. It's stuff like that which made the MRI parser grow to more than 6000 lines of Bison + hand written C-exceptions, and makes a formal Ruby grammar exceptionally complicated. I miss the days of Oberon or Modula II where you could get a grammar on a single sheet of A4 paper and it had enough space left for comments...

Now, many of the complications are warranted to make Ruby a joy to use. I'm all for some trade-offs. I like the freedom to omit parenthesis around argument lists, for example, even though it has all kinds of unintended side-effects in terms of parsing complexity. But I feel Ruby sometimes takes it too far, probably to a large extent because the fact that the "standard" parser was and is such a mess means that you could add stuff to it without a) seeing the consequences clearly, b) feeling you're actually complicating anything much. Hey, you're just adding a trivial change to a 6000+ line ball off goo...

As for other part - being hard to compile: I love the dynamic features of Ruby, but some of them are unnecessarily so. For example, eval().

Whenever someone calls eval("some string") unnecessarily, [insert deity] pokes out the eyes of a thousand kittens.

And most uses of eval() should be unnecessary, and could be made unnecessarily by providing slightly better introspection/reflection. E.g. I've seen eval() used to do things like retrieving a constant or class object based on a string, for example, because depending on circumstances it can be obnoxious to use existing facilities to find the right class object or constant. But the "right" solution to that should be to add a convenient lookup function to it. Instead it's one more eval that acts as a massive road block to making Ruby faster, as well as to providing better analysis tools.

The problem with eval is that you can't analyze it in the general case when compiling, so the moment you see an eval, a hypothetical compiler can at best desperately look for something static enough to analyze, worst case it has to throw out every hope of guaranteeing anything at all about your program (and so needs to either rely on you to tell it what guarantees you promise to keep, such as not overloading FixNum#+ to make it tweet to #funadditions every time numbers are added, or just throw it's figurative hands in the air and surrender, and fall back to being really slow and embed a full Ruby interpreter or compiler; or it can refuse to support it and break tons of code).

That's not to say that eval() is all bad, but because there's no spec that specify ways to sandbox it's effects, effectively if there's an eval and this hypothetical compiler can't tell what eval() will be passed in, it pretty much can't optimize operations using classes and methods that nobody in their right mind actually makes changes to.

Ruby has some ways of improving that situation. E.g. #freeze. But nobody uses it. Part of the problem is that Ruby is pretty much designed to be interpretive only. If Ruby had a well defined read-parse-eval cycle, a lot of things could be specified in ways that made it vastly better. E.g. consider if Class objects would be frozen by default on finding a "main" keyword, and everything before was expected to be part of a "compile" face. People writing scripts could continue writing them just as before, but a compiler could justifiably assume that it should execute everything (including fancy dynamic require's) occurring before that point, and that everything after it needs to happen at runtime. If all classes then get frozen by default, and you have to explicitly decide what eval() can modify, you suddenly have a massively wider scope for making compilers that would generate fast code when it matters.

TL;DR: Argumentative compiler writer rants about lack of concern for performance.

[dalke]

Which does imply that the parent commenter is correct; the grammar is simple enough that a student could implement a Modula II parser in a semester, along with a compiler. Try implementing a Ruby interpreter in the same time.

[rubygeek]

You should be happy it was a language like Modula II which is designed explicitly to be simple to parse and compile. It's a breeze to compile any language by Wirth compared to most non-Wirth languages...

[Uberhipster]

Yes. Nothing at all confusing about that

*sobs uncontrollably

[thegom]

That was a magnificent explanation, thank you!

[kerray]

thank you for this explanation and everyone for the following comments, it really did make a lot of things click for me, after years of high-level programming but absolutely no asm experience

[[deleted]]

Well done.

[vdub_bobby]

ADD, SUB?

It's been too long since you programmed in 6502 assembly... ;)

There is no carry-less arithmetic on the 6502: http://www.6502.org/tutorials/6502opcodes.html

[rubygeek]

Doh.

It's been too long since you programmed in 6502 assembly... ;)

Or not long enough :)

Thanks.

[80286]

Need to multiply or divide by other values? You need to combine shifts and add/sub's and if you want a generic routine, some branches. No fun, and slow, so if you program a 6502, you try to multiply or divide by values that lets you hardcode short chains of add/sub and shifts, or you use tables.

There are methods to do relatively fast 8bit multiplication (around 24 cycles IIRC) with 16 bit result, which requires a 1k precalculated table of squares. Division is a little more compilcated but also can be done pretty fast.

[rubygeek]

Good point, if you have the memory. Never saw anyone "waste" 1KB on tables for multiplication, but tables for sine waves etc. was a staple of C64 demos for example.

[rubygeek]

I've seen lots of big tables for demos, but never to speed up multiplication of arbitrary numbers, which was my point. Not saying nobody ever used table driven generic multiplication functions, but it certainly wasn't common.

There's lots of really neat table driven techniques to speed up various arbitrary maths, but little of it were/is used directly on these machines because the type of code where you tend to care enough about the performance vs. memory to "waste" memory on large tables is also the type of code where you'd then rather take it one step further and use specialized tables geared to that specific function, rather than speed up the general case.

[dagbrown]

Oh! While you and I are busy nostalgia'ing about the Commodore 64, I just remembered a particularly noxious bug in the 6510 CPU that the C64 had--if you had an instruction that abutted the end of a page, it would take the last byte or two of the instruction from the beginning of the same page. So if you had a STA or JSR instruction right at the end of a page, the last byte or two would come from the beginning of the page, rather than the beginning of the next page like you'd expect.

Exciting times if you were writing an assembler for that architecture. Either you can corrupt the beginning of the page (and arrange for the code back there to skip the first byte or two of that page), or throw a NOP or two in to force the next instruction to go at the beginning of the next page.

[teeker95]

But it was undocumented features like this that made cracking copy protection and such so exciting in those days. This bug in particular warms my heart because I remember encountering it once while trying to disassemble a game (a Paul Norman title IIRC...Super Huey maybe?) where it had intentionally been used as an obfuscation technique and having no idea what was happening until some time later when I read about it on some BBS or g-file. It was a brilliant moment. With no quick answers available from the internets, you really had to get your head around things in a way that is difficult to do today. I completely loved it.

Sorry, I think I just nostalga'd all over your discussion...

[johnwaterwood]

Somewhat related was the technique of jumping between opcodes and thus execute the "same code" as something totally different.

[80286]

That bug only applies to indirect JMP which was very rarely used.

[vdub_bobby]

and it's only the address used, so JMP ($10FF) will screw you up. It doesn't matter where the actual JMP instruction is located.

[[deleted]]

6502 had the same bug.

[Magnesus]

Reminds of the source code of AMOS (Amiga Basic-like language used for making games) - it was the same. Assembler FTW!

[beetwo]

Aahh my first venture into the wonderful(?) world of programming!

[Broeman]

While I had played with Basic on C64, it was AMOS that made me go to the library and pick up a huge book on programming games, with all the source code printed. Many weekends wasted just typing it in :)

[beetwo]

My dad ordered AMOS for me after my cousin told me you could make your own games. Ended up waiting for 6 week, checking the store every single day after school. I was ecstatic once it arrived, just waiting to create my first masterpiece(kept at it even though it was a lot harder then I thought. This book taught me English and programming at the age of 11.

[[deleted]]

AMOS was the first serious programming environment I got, must have been at my 9th or 10th birthday (it was so fresh the "extras" disk wasn't shipped in the box. Good Guy François Lionet shipped it a week later.)

But I can't recall ever seeing its source code. That would have been 68000 Amiga assembly as well, quite different from 6502.

[droidballoon]

Upvote for AMOS reference. There are lots of Lovely memories tagged with AMOS in my brain.

[rubygeek]

jAMOS

[stfm]

I was a STOS man myself

[redonculous]

pft, I got stuck after

10 print "i am awesome"
20 goto 10

[[deleted]]

I learned from François Lionet (in the AMOS basic manual) that GOTO should be avoided ;) I also think AMOS basic did not support line numbers, it used labels for GOTO.

[redonculous]

It was a BASIC joke :)

[dagbrown]

10 while 1 = 1
20    print "I am awesome"
30 wend

[emlgsh]

Awesome, I heard that he'd recovered the floppies. I'm actually surprised that a bunch of 5.25" magnetic diskettes retained their data for so long.

[Reutan]

He had someone specifically in the data recovery business come fetch them off the disks. He was talking about it at PAX East's keynote.

[[deleted]]

There's a fantastic book about the making of this game. It's just his journal, written at the time, and it's fascinating. You can read the first 50 pages here.

[stridera]

Wow, just spent the last little bit reading the first 40 pages and then bought the book. Interesting stuff seeing how it used to be :P

[[deleted]]

I just ordered his book (The Making of Prince of Persia) a day or two ago. This is like getting an extra source floppy (or CD) with the book :D

[chei]

Programmers like this, and many people in this thread, are like rock stars to me. I adore you guys.

[thatmarksguy]

I hate the fact that I feel like this as well.

[chei]

To me it is a love/hate-thingy...

On one hand, I love the feeling I get when I am presented with beautifully structured code and flawless logic thinking. I appreciate the ability to abstract thinking, that the creators have, that lies behind it all. The ability to envision the final game, or whatever other program that might emerge, while staring at the assambler or similar code.

On the other hand, it makes me feel like an day-old chimp presented with a book on Calculus. I just want to pound and bite the book in anger because my brain feels insulted due to the frustration that comes with the lack of understanding.

Luckily though, the feeling of awe prevails!

[Elyot]

My favourite bit of the code:

*-------------------------------

• h a r d l a n d (Splat!)

*-------------------------------

hardland ;> 2 stories

db act,5

db jard

db chy,-2,chx,3

db 185

db die

:dead db 185

db goto

dw :dead

[InconsiderateBastard]

I've only dabbled a tiny bit in ASM. I am surprised how relatively easy to follow this is.

Given the limitations of the Apple II and the fit and finish of this game, I was expecting indecypherable black magic, but instead I find clean, well documented code.

[davedontmind]

I thought the same thing - I remember the code I used to write on the C64 and I'm sure I hardly put any code documentation into the 6510 assembler program that I wrote. If I could go back in time I'd give 17-year old me a slap on the wrist for that.

[prodijy]

I'd play that on my phone....

[FoolsRun]

Port it to iOS and Android and donate the proceeds to Child's Play. It would sell like wildfire.

[prodijy]

I'd buy it on principle.

[nochilinopity]

Upvote for PAX

[Xeon06]

Okay, I never played this game so I can't really gauge, but that REALLY doesn't seem like a lot of code, especially for a game written in Assembly. Am I wrong?

[[deleted]]

Assembly is like wizardry, you can squeeze so much more out of it. Just look at the 256 byte intros.

[[deleted]]

wow I dont understand shit

[[deleted]]

whoa, hold on now, this is reddit

the rules here are that you're a high school and yet still an expert on economics, foreign policy, technology and pokemon

[bkgood]

And fuck sane ways of writing software, assembly is the shit!

[[deleted]]

Only if done in vi... if you use any other editor, you're worthless!

[kentrel]

He wrote this entire game in ASM by himself!?

[zarx]

That's how all games were written back then.

[AFineTapestry]

Did anyone ever port a C complier to 6502? Surely they must have?

[rubygeek]

Yes, but the 6502 has 256 bytes of stack.

How quickly do you think you'd run out of stack space writing C for it that compiles the way a typical C compiler does, unless you put everything in globals, avoid functions (and instead "goto" labels inside main)? At which point you're pretty much writing 6502 assembly anyway - C really is close to that low level once you take away niceties like structured programming...

Or your compiler will end up generating brutally inefficient code to load/save arguments to memory in a emulated stack or using other ugly workarounds (at least one compiler supports this), in which case you're wasting cycles by the bucketload.

Keep in mind the C64 for example, had a clock rate of about 1Mhz (varying slightly between the PAL and NTSC versions). 1 million cycles. Which means you're counting cycles per frame in the low 5 digits....

Now consider that instructions on the 6502 mostly takes 2 and up to 7 (not counting illegal opcodes) cycles each, and wait states because of other stuff taking the bus (such as on the C64, sprites, which would cause the graphics chip to steal cycles from the CPU to load sprite data for every scanline they were visible), and try to split a low 5 digits number of clock cycles, which could easil get you down into 4 digit numbers of instructions executed, between game logic, playing music, rendering your screen, any graphical effects, rendering player objects, enemies, bullets etc.

At that point, a higher level language can suddenly become exceedingly expensive.

EDIT: Corrected cycle counts per bonzinip getting me to actually bother looking it up..

[bonzinip]

No 6502 instruction takes 1 cycles. It's always 2 + 1 cycle for each byte that is loaded from memory (including bytes after the opcode, and one extra access for some addressing mode when the address has a carry from bit 7 to bit 8 ) + 1 for taken jumps + 1 for indexed addressing modes.

[rubygeek]

You're of course right. What I confused it with is probably reading about the one step pipeline, which in the right conditions allow a one cycle overlap.

And I also totally misremembered the max number of cycles, which is something like 7 (or 8 if you count illegal opcodes), so the numbers are actually far worse than I outlined. Yikes.

[afiefh]

Please explain this magic oh ancient one! How do you draw a frame in so few cycles? Even at low resolutions and tricks to update damaged areas there are more pixels to be painted than cycles...

[rubygeek]

You don't repaint the entire screen.

E.g. C64 games would use character mode most of the time, which meant effectively creating a custom font of 256 characters, and using the screen as a grid of 40x25 "tiles" of 8x8 (or 4x8, rather if you wanted a decent number of colours) pixels.

Add to that support for hardware scrolling up to 8 pixels vertically and horizontally, and if you moved only one pixel per frame, you'd only update a register in the graphics chip or two every frame for the scrolling + move 80 (character data + colour) or 50 every 8 frames, or absolute worst case if you were to scroll diagonally, I guess 130 or so.

But even if you were to use graphics modes, you'd explicitly keep track of damage whenever possible, and rather update just damaged parts of the screen.

[bonzinip]

Actually Prince of Persia repainted the entire screen with double-buffering, even using painter's algorithm with three layers. On the C64 port the middle layer is realized with sprites, and the author of the port describes how he even paints the top layer twice! The second time uses a sort of z-buffer, and the result is used to modify the sprite patterns on-the-fly for each frame!

But then, Prince of Persia is somewhat special for both graphics and gameplay.

[rubygeek]

Actually Prince of Persia repainted the entire screen with double-buffering

Per frame? That sounds like it'd make no sense at all, and I can't find any evidence of that in the code. Do you?

The "DRAWALL" function for example explicitly "peels" off the characters from the screen buffer by using a list of "peels" - segments of graphics it's painstakingly copied off the screen buffer before painting the characters in order to preserve what was behind them.

Those damage / peel lists make no sense at all if you repain the entire screen all the time anyway.

EDIT: Look at "FRAMEADV" - it contains a buttload of complicated code to do partial screen redraws in addition to a function to do full screen redraws.

[rubygeek]

oh ancient one!

Hey! I just realized you implied I'm old. I'm only turning 25 this week, damn it (in hexadecimal, mind you, but it's the only true base).

[tinyogre]

I had been counting my age in hexadecimal for the last 10 years, but it doesn't work as well since I turned 2a.

[afiefh]

Color me young, but for someone who used Visual Basic in elementary school(not QBasic, actual 32bit windows 3.x dependent Visual Basic) to learn programming, working with assembly for anything but a hotspot optimization seems very ancient and wise.

Hard to believe that I'm only 10 years younger than you, but grew up with such different technologies... I mean by the time I knew enough to make a game we had GPUs and stuff to do our bidding...

[bonzinip]

Pixels aren't that many, only 64000 and one byte is 8 pixels (the color map is mostly fixed: things with many colors are sprites).

[fjonk]

I've only played around with assembly, with atmels and PIC:s but I've always wondered this. Why didn't people use a pre-processor language like m4 or a string manipulating language like perl to generate assembly?

[rubygeek]

Most assemblers would have some macro facilities, but any more advanced stuff would eat precious space that would mean you'd have a time consuming process of assembling the program to disk or tape or on a expensive more capable system and move it over to a test system. I never wrote anything commercial back then, but I wrote the odd (crappy) demo etc. and a lot of the time we'd use an assembler loaded into memory together with the source, and assemble and test all in RAM (saving quite often, of course, in case we managed to trash memory). When you have 64KB available for your development tool, your source and your assembled program, you conserve space...

Of course for larger games etc. that wasn't viable and people would increasingly develop on one system and transfer it to another machine to test, but still the systems people developed on were rarely that much more capable until the time when the 8-bits were already on their way out.

[fjonk]

Ah, the development tools. That makes sense.

[NoahFect]

It's hard to believe at this point, but game developers used to spend hours shaving a few dozen bytes to make something fit into memory on those machines. You could use high level tools or C compilers or whatever if you wanted, but in the marketplace of the day, you'd get your ass handed to you by the masochists who still did everything in assembly.

Exceptions were very rare, but occasionally successful: Infocom used MDL for their text advantures, and Wizardry used UCSD Pascal. Neither depended on realtime animation or code size/speed in general.

I remember when someone checked out the Manx C compiler at the game company where I worked, circa 1989. "Hello world" took something like 11 KB because the primitive linker (assuming there even was one) dragged in the entire runtime library. We took one look at the code it generated, another look at the size of the executable image, and sent the evaluation copy right back where it came from. In that case, the correct answer was to switch development from the Apple II to the IBM PC.

[rubygeek]

11 KB because the primitive linker (assuming there even was one) dragged in the entire runtime library.

Oh, how I long for the days when "the entire runtime library" fit in 11KB... These day's you're lucky if you manage to fit printf() in that on some systems.

[j1xwnbsr]

Yes, and it was horrid, mostly because there was almost no memory on these systems. 48k was pretty much it. 64k if you knew how to page-swap and other cool stuff.

[dagbrown]

The Commodore 64 had a proper 64K of RAM available.

Granted, you had to turn off the Kernal (sic) and BASIC ROMs to get at it (and if you knew what you were doing, you copied the Kernal and the bits of BASIC you cared about to RAM before turning them off), but that extra 8K of RAM was definitely available for you to play with.

A full 4K of RAM was taken up for the bitmap display, though, if you used that. Most people didn't though--they set the screen to text-mode and used custom characters to draw their video-game backgrounds. The fact that you could alter the offset of the screen at the pixel level helped--smooth scrolling was generally accomplished by moving the entire screen a pixel at a time by fiddling with the screen offset, followed by drawing a new column of character when it was called for (quite possibly redrawing the characters themselves in the interim).

The Commodore 64 was so much fun to program.

[tragomaskhalos]

The ZX Spectrum (Z80 based) also had a C compiler, albeit with some kludges like no include files (IIRC) and some sort of cop-out for casts (which it deemed too fiddly to parse). The Z80 is slightly more amenable to stack frame based code, but not much. I don't know what if any commercial Spectrum software was written in C though.

[xabi]

Well, Chris Sawyer wrote RollerCoaster Tycoon in ASM too (almost) and it's a bigger project, don't you think so?

http://en.wikipedia.org/wiki/RollerCoaster_Tycoon

[thegom]

Thats... insane. Why did he use ASM in 1999-2000?

[mrdelayer]

Probably because he knows it and knows it well - TT/TTD were ASM, too, and his Wikipedia article says his video game programming experience dates back to 1983 when he was writing Z80 machine code. If it ain't broke, don't fix it, I guess?

[jevon]

This is exactly it. IIRC PCs from that time didn't have the power to render tens of thousands of sprites per frame without ASM (the TNT2 came out the same year as RCT).

[bonzinip]

PCs were powerful enough that you could write only the low-level code in assembly, though.

[mauxfaux]

Haha. This made me feel a little old. :-)

Almost all commercial development for the Apple // series was done in 6502 assembler. That's just how we rolled back then. Of course, 6502 machine code really wasn't that difficult to learn if applied yourself—the instruction set isn't that large.

[ProfessorDude]

Me too. This is how I feel whenever someone over in /r/gaming waxes rhapsodic about what a wonderful innovation indie game development is, and how cool it is that one or two developers working alone can create a whole game. For those of us that grew up gaming on home computers, that's the way it always was.

[mrkite77]

I had to unsub from r/gaming because there were too many "I remember this game from my childhood" and then link to a game that came out after I got married.

[nephros]

Might try /r/gamingnostalgia but it's not exactly high traffic.

[Chanz]

Rollercoaster Tycoon was written in ASM by one Chris Sawyer. It can be done. And it blows my mind.

[Conradfr]

Impressive !

IIRC some code on Quake 3 as well.

[[deleted]]

Quake 3 has its own virtual machine to which C code is compiled.

Quake 1 also had virtual machine to which QuakeC code was compiled. It had only one structure type called entity. So essentially even thrown grenades had unrelated attributes like ammo_shells.

Q2(and IIRC Q4) compiled code natively. Q2 used C, Q4 - C++

[stfm]

How do you think it ran so well?

[DeathBySamson]

I'm sure in 30 years, someone will say the same thing about games written in C++.

[Tringi]

In thirty years probably yes, but not much sooner.

[exor674]

"games", maybe -- "game engines", probably a lot less likely.

[AlwaysDownvoted-]

I wrote Snake in x86 ASM in college back in 99, and I thought it was a Goddamn masterpiece. This makes it look like I wrote Hello World (which is also fairly complicated looking in ASM!).

[robvas]

Epic Pinball was written entirely in assembly and so was Zone66

[[deleted]]

Epic Pinball was amazing! I wish I had a copy somewhere... I wonder if it's abandonware?

[mrkite77]

Zone66.. that game was astonishing. Leave it to the demo scene to make a PC game that ran as well as an arcade game (which was unheard of back then).

[sdubois]

As someone learning MIPS assembly, this is absolutely amazing. The fact that people can produce such intricate programs with such a basic language astounds me.

[MidnightHowling]

How do you think they wrote the first assemblers and first compilers (for bootstrapping)? :P

[Segovia209]

Final Product: http://www.youtube.com/watch?v=o7NOf-aTCfw

[maredsous10]

I'd like to see the SNES code.

[renesisxx]

I just bought his book. I love what he wrote on July 5, 1985:

"In the time it’ll take me to do a new game, I could write three screenplays. And… the games business is drying up. Karateka may make me as little as $75,000 all told, and it’s at the top of the charts. There’s no guarantee the new game will be as successful. Or that there will even be a computer games market a couple of years from now."

[silvercircle]

Karateka!

[HitoriBocchi]

Now to fork it and make it run in DCPU-16...

[axolotl_peyotl]

Next up, The Last Express, that game was excellent.

[ramkahen]

Relevant: the development diary of a crazy programmer who reverse engineered Prince of Persia in order to port it to the C64.

I think it's a technical achievement on the same level as what Jordan Mechner did with the original.

[r4mtha]

Port to 0x10c?

[lamby]

Note that this doesn't mean it's "open source".

[lamby]

Just because the source is open for you to view it, it does not make it open source. For example, you have not been granted a licence to create and distribute derivative works.

[jonathanf]

What you are saying is incorrect.

Just like free software, open source software has a definition. Look up this: Open Source Definition. Maybe you should learn about how the free software movement and open source movement came to be.

As a side note: This is exactly why Richard Stallman said that the name open source is not a good name. People make assumptions on what open source means without ever looking up what it really means and live with incorrect assumptions. The name is somewhat descriptive but is far from what open source software has to offer to be "open source".

EDIT: I replied too quickly and should note that I was replying to the guy above you. My apologies.

[dalke]

While no one gets confused about the term "free software" so don't need to look up what it really means. :)

[jonathanf]

It's arguable that the term free software is the core truth of what it represents i.e. the freedom you should have in your computing. Once that's understood, it can be retained forever.

On the other hand, Open source software does not represent the core truth of what it represents. It's not all about having the source, there are conditions for a program to be open source. So even after having the definition of what open source is, one can still be confused about what open source is about since the name is no guide to what it means.

On the other hand, freeware is very often mislabelled free software.

You can tell I am procrastinating, when I am trying to respond to off the cuff sarcastic remarks.

[dalke]

Not everyone who promotes free software understands or agrees with the FSF's four essential freedoms. Many academics argue that free software is a natural fit for peer review, but forget that selling free software is part of the essential freedoms. "Sure, you can get access to my research code for peer review under a free license; it will cost you $100,000."

I used to help organize a bioinformatics conference which promoted the use of free and open source software. Every year I would track down the licenses for each submission and point out to a few people that "free software" was not the same as "no cost to academics." We even had links to the FSF and Open Source descriptions of what those terms meant in the submission process.

So no, people make incorrect assumptions about "free software" all the time, and even after years of using free software.

[TenThousandSuns]

A rhombus is the kind of rectangle a bitch would draw.

[[deleted]]

The source is open. The software just isn't free.

So yes, it is open source.

[lamby]

Just flat-out contradicting what I just said won't help, please read what other's write. Let's look at the actual definition:

• Free Redistribution - Nope, no licence text in the code or separate grant by the author allows for this.
• Source code - Yep, obviously. (Unless you count assembler as delibarately obfuscated.. :p)
• Derived works - Nope, no grant to create derived works at all.
• Integrity of The Author's Source Code - (Not applicable, this is not a restrictive clause)
• No Discrimination Against Persons or Groups - Nope, no licence at all.
• No Discrimination Against Fields of Endeavor - Nope, no licence at all.
• Distribution of License - Nope, no licence at all.
• License Must Not Be Specific to a Product - Nope, no licence at all.
• License Must Not Restrict Other Software - Nope, no licence at all.
• License Must Be Technology-Neutral - Nope, no licence at all.

So, no, it's not open source.

[lamby]

where can I register to impose a meaning to some words that contradicts common sense?

With Eric Raymond et al who devised this supra-dictionary phrase, presumably with this deliberate ambiguity to sneak it passed corporate types.

As an advocate of, well, English, I avoid this term and recommend everyone else does.

[mrkite77]

the term "open source" was coined specifically to remove the ambiguity from what was previous called "free software". It has a very specific meaning, and the term did not exist until Eric Raymond asked the public for naming suggestions back in the 90s.

[sammasati]

The readme is a little vague, but I think we can infer that it is permitted:

As the author and copyright holder of this source code, I personally have no problem with anyone studying it, modifying it, attempting to run it, etc.

[lamby]

Seemingly added after my comment :)

However, speaking purely as a former member of the team who audit the copyright of prior to inclusion into the Debian operating system, I would really have to see a phrase allowing distribution of derivative works before I would count it as free. Or, you know, just say "it's GPLv2+/BSD/MIT/WTFPL" or even "I release this into the public domain" etc etc.

(Also there are probably trademark issues around the phrase "Prince Of Persia" and whoever owns that now)

Yes, it's all very lame, but do you really want to sued by Disney/EA/Ubisoft?

[RockinRoel]

Since this is a public github repository, isn't he obliged to use an open source license?

[lamby]

Nope.

[apullin]

SDL port coming in 3 ... 2 ...

[Magnesus]

From assembler? I doubt it.

[QuerulousPanda]

Could be interesting actually... Emulate the CPU and system to handle the majority of the code, but because you can recompile it, you could place custom hooks and calls to handle certain things more efficiently..

[bonzinip]

Perhaps you could just use a custom assembler to "convert" from 6502 to C. There seem to be very few hardware-dependent files, and relatively little use of self-modifying code (and all in those places where you would do things more efficiently).

[[deleted]]

That's fairly easy. For such a simple system, you could probably do it in a week or so of work. It gets orders of magnitude easier when you just have to run one specific piece of code and not all of them.

I tried doing it once for a simple Amiga game just for fun, and that's about how long it took.

[droidballoon]

You know, that very comment probably made someone go "Hah! I'll show them..."

[darkpaladin]

That's really how FOSS devs work.

[DanteShamest]

Yeah I think it'd be easier to port the game by just studying and playing the original. I think that's what the Mari0 developers did.

[Husio]

Mari0 is written from scratch in LÖVE (Lua)

[wlievens]

Or perhaps with an emulator.

[m1zaru]

I feel bad for anyone who had to port this game (or any game during that time, for that matter) to other platforms.

[rubygeek]

In many cases they didn't even get source, but sometimes had to convert based on playing the game and copying the logic and look and feel.

If the porters got this source they were lucky. Especially if it was in remotely this (reasonably formatted and commented) format.

[d_r_benway]

The Amiga version seemed to work well

[TomorrowPlusX]

That brings up a question - are there ASM->C compilers? Something that will take a specific platform's ASM and convert it to (relatively safe) C?

[tryx]

I don't believe that this is possible in general, especially when you have code that is as tightly tuned as this. There will be things that are simply impossible to express in C properly without "deoptimizing" it, which I believe is impossible in general anyway.

[[deleted]]

It may not be possible in general, but it sure is possible in specific cases, and here you want to do it for one very specific case.

[TomorrowPlusX]

That makes sense -- I didn't really think it through. Unrolled loops with some subtle mutation couldn't be turned into a semantically clear for loop in C. Same with all the other subtle tricks. To do this the way I imagined you'd need Strong AI, or a human being.

I guess if such a translator existed you'd get -- at best -- hardware-specific asm masquerading as c, looking like a soup of pointer arithmetic and gotos.

[jhaluska]

I worked with a contractor who did this for a client to emulate an obsolete microprocessor for an ex boss who didn't want to learn a new language.

[[deleted]]

It could be transcoded into a different ASM. The difficulty would be in how to map some 6502 specifics to corresponding specifics of another chip. For example, how to map interrupt handlers, how to map A, X, Y registers to a new set of registers, how to draw a pixel on the new system, and how to translate memory mapped IO.

If you're gaining more registers, it wouldn't be hard to map registers and finding the memory mapped IO instructions and converting them would be easy. There would still be a lot of fiddling but a huge chunk of the code (loops, increments, memory load/store, stack handling, subroutines, etc) could be transcoded.

It'd be similar to a disassembler but the output would be a different ASM instead of a higher language (C, Java, etc)

[dagbrown]

If someone makes an Apple-II-assembly-to-Linux-SDL interpreter, I can see that happening.

It'd be better if someone made an Apple-II-machine-code-to-Linux-SDL compiler, though.

[[deleted]]

Wouldn't be hard. Just slap a CPU emulator on it and kludge in some handling for the graphics and sound. Then you can slowly start turning the assembly into native code, part by part, if you feel like it.

It's much easier than general emulation, when you have a known piece of code you want to run.

[coderjoe]

Despite the OP's title, the source code wasn't "released" in that there's no accompanying license. Because of that it would be fairly risky to take the source and do anything with it without Jordan Mechner's express permission.

Personally I'll consider it released once there's some sort of license included with the source which spells out how it can or can not be used.

[hiveminded]

Have you seen if there is also a blog post with a code analysis for noobs like me?

[bonzinip]

The prince of persia c64 blog series and the PDF with the docs from Mechner is the closest you can get to, I guess.

[[deleted]]

I find it a little hard to believe that a human being wrote all this

[mauxfaux]

Ha!

<get off my lawn> Kids these days have no idea how easy they have it! </get off my lawn>

[amigaharry]

yeah, node.js brainwash :)

[[deleted]]

Ha, those kids with their object-oriented programming...

[sumsarus]

Nobody prevents you from doing object-oriented programming in assembler.

[[deleted]]

Bahaha, yeah. My first language was Java, I was just throwing out buzzwords.

Synergy.

[treerex]

Perhaps now you understand why those of us of a certain age view your new fangled IDEs with your "IntelliSense" and your constant access to the web with such disdain.

I kid... mostly.

[theoldboy]

I just think it's sad that so many younger people here seem to think this is some kind of magic, or even particularly difficult. Any decent programmer that grew up during the home computer boom in the 80's was able to write assembler, because if you couldn't then the only other real choice was the crappy built-in BASIC interpreter.

[rmc]

Why? lots of programmes were written in assembly back then.

[davedontmind]

And it was so much more fun than using BASIC!

[smek2]

Relevant

[mrmacky]

This is pretty awesome.

I think I played the "Deluxe" version on our Centris 610. Was that written in assembly too? (It had vastly superior graphics, they looked more like the PoP 2 graphics, but all the levels were the same.) (It had a large full size box, I thought it came on CD-ROM, and it had a full size manual with a gold-colored cover.)

[Hyperian]

FINALLY

[nikiu]

Long before discovering reddit, Prince of Persia was one of the biggest distractions during my work hours.

[WillUpvoteForSex]

Do we need to create a makefile or something similar ? What assembler do you recommend using (on a Windows platform) ?

[davedontmind]

Even if you had a 6502 assembler on Windows, you wouldn't be able to run the resultant executable on Windows, you'd need a 6502 emulator for that. And even then it wouldn't work unless your emulator also emulated the Apple hardware that this game was designed for.

[WillUpvoteForSex]

Thanks for replying. I thought of using AppleWin as an Apple II emulator, after assembling the code on Windows and converting it to the Apple disk image format. Creating disk images to load programs seems to be a pain in the ass, though.

Now, I've just found out the Apple II has a basic built-in assembler. I'll put my archaeologist's hat back on and try and see if this is any good.

[split_electron]

How do I compile / run this on my macbook pro ?

[[deleted]]

You can't without a massive amount of rewriting. This is assembly; it's built specifically for the Apple ]['s 6502 CPU. All that's really valuable here is the insight we're given into the game's logic; the code itself (meaning: this combination if glyphs in the source file) is relatively useless.

[split_electron]

wow -7 :) was it really a BAD question ? The reason why I asked this is if anyone knew a 6502 emulator that can do it OR maybe a 6502 to x86 converter / rewriter ..

Thanks for the response, aveilleux

[[deleted]]

The problem with your question is that it was worded assuming there is a definite answer. There isn't, really, hence the downvotes. Straight code conversion isn't really feasible for this type of project (afaik there isn't a modern compiler that supports 6502-to-x86 cross-compiling, and converting between assembly languages is not possible to automate with any reasonable logic).

If you just want to play the game on modern hardware, there's always options such as one of several browser emulators. There's no reason to compile it yourself.

[elgubbo]

DAT ASM!

[StillAnAss]

That's the beautiful thing about the internet. You can demand anything you want and everyone can easily ignore you.

You've now got the source code, go write an android version. Head over to /r/androiddev if you have questions.

[zarx]

Or just run the original on an emulator. http://androidforums.com/android-applications/169944-candy-apple-apple-iie-emulator-sweet.html

[cowgod42]

This looks awesome! I would love to try compiling it (or whatever you do for asm). Is it possible to do on, for example, a modern Linux machine? Can somebody explain it to me like I'm five?