Prince of Persia source code released (Apple II assembly)
github.com
github.com
Sounds like fun!
It would be interesting to analyze early Apple ][ game images and see which didn't use assembly. Wizardry was a notable example for using USCD Pascal, essentially running in a VM. Infocom games of course used Z-code. Applesoft BASIC was fine for some text adventures (Eamon for example).
There were also programs like Microsoft's TASC that compiled Applesoft to binary, much of the speedup gained by converting floating point values to integer.
The SWEET16 interpreter was also built-in to ROM, but I don't know if any titles used it.
But almost every game relied on some kind of special graphics technique to wow the player, and that usually meant at least one neato routine hand-optimized in assembly. Drawing a sprite to the Apple's frame buffer was actually much more complex than blasting RGB values like we do today.
Very fast.
I had heard of assembly and thought it was inherently "scary" and obtuse. But this PoP code is pretty easy to follow, and I probably should have taken the plunge way earlier.
Neat.
1. not having the confidence to talk to the 3 or 4 older kids at school who clearly knew about this stuff. 16 & 17-year olds were terrifying to my 10-year-old self. They of course graduated secondary school soon after, so there was a small window and I missed it.
2. I really wish I hadn't believed any adults claiming this stuff was "hard" or "scary". None of them did any real programming, so how would they know? I should have just pestered my parents to find me an x86 instruction and architecture reference - I'm sure I could have worked everything out from there, after all I had enough spare time. I started with BASICA on an 8088 and eventually was given a 486 after my parents got fed up with me hogging their computer; alas, it took years before I picked up C & C++ and assembly language shortly after. As a 10-year old in rural Austria, my possibilities for obtaining this kind of information myself were pretty limited, and everyone (parents, teachers) was constantly encouraging me to focus on science (physics) instead of programming.
Still, I shouldn't harp on too much about #2. I was into electronics before I heard about programming and was obsessed with wanting to build my own computer, and tried to get hold of information on doing so, only to be told it was "impossible". (a 6502 plus some manuals would almost certainly have done the trick, and in 1993 couldn't have been that expensive - but I guess by that point the "kit" computers were long dead) So clearly being more assertive about wanting programming information would not have helped much either.
I hope I don't fuck this part up if I have kids of my own.
The hard part is the "thing to learn" may not be computers and programming, it may be something entirely new. That's why your elders seem like they were out of touch- tech was so new and all. It looks like a great choice from 2012, but from 1990 it was more of an unknown, and there will be similar developments in the future in other fields that challenge new parents to allow their kids to explore fledgeling prospects.
Thanks for the code btw. PoP is a landmark in the history of computer games.
It's been posted before but Jordan, the creator of both Karateka and Prince of Persia, has a wonderful series of journals documenting his travails with video games and the movie industry. [2] As part of this he has a detailed description of his trek out to California and a lot of details on technical obstacles that make you thankful to live in the second decade of the third millennium.
[1] http://jordanmechner.com/wp-content/uploads/1989/10/popsourc...
(Which technically means we don't have permission to do anything with the source at all, though I doubt that's what Jordan intended.)
love the sound code. Having to write your own "tone" routines to tweak a sound out of the speaker...
I wonder how the PC version (which I've played and fondly remember) and Apple 2 version differ.
This is going to be the definitive version of Prince of Persia. With VGA and a sound card, on a fast machine, it'll blow the Apple away. (In contrast, none of the Karateka conversions was as good as the Apple original)
* Most of the machine code books here: http://www.bombjack.org/commodore/books-generic.htm
As for Apple-II specific details (graphics chipset etc.) someone else will need to chip in - never even saw an Apple-II during my childhood, Norway like much of Europe was Commodore dominated.
http://en.wikipedia.org/wiki/Apple_II_graphics#Video_output_...
Stuff like that seems like it might explain some of the mutual disdain that Chuck Peddle and Woz seems to have ended up with after their early encounters (when Peddle was on his 6502 "sales tours"; though maybe interviews and books have exaggerated it).
I can totally see this being the type of hack that would excite someone like Woz to pull off but that would make Peddle's straight laced inner formal engineer rage... Combine Commodore / MOS engineerings early problems getting a decent color graphics chip together but cultural refusal to go for something more hacky (the did plenty hacky stuff but only when Tramiel put jobs on the line) to get out the door quicker, with plenty of blame being put allocated to Peddle on a regular basis, and I can see lots of ego getting caught up in it..
IIRC, things were even better. There were two (740 byte, IIRC) buffers from which samples were taken at every horizontal refresh.
The sound driver used one to get samples to send to the speaker; the disk driver used the other to control the rotation speed of the disk drive (using pulse-width modulation).
http://www.bombjack.org/commodore/books/pdf/A2_Hyde_6502_Asm...
See also http://www.callapple.org/cat/ap0010.htm and http://www.amazon.com/Using-6502-assembly-language-program/d...
For Apple II details, supplemented that with a number of patterns books like Beagle Bros Big Tip Book: http://beagle.applearchives.com/books/big_tip_book_ocrpdf.zi...
Thanks to Jason Scott and Tony Diaz for successfully
extracting the source code from a 22-year-old 3.5" floppy
disk archive, a task that took most of a long day and
night, and would have taken much longer if not for Tony's
incredible expertise, perseverence, and well-maintained
collection of vintage Apple hardware.
I'm sure they could, but unless they also have a book to promote, it's probably not worth their time. Well, I think it would be, simply as a contribution to the history/record of the era... but they likely aren't going to recoup the time or effort other than in goodwill. (I also suspect there's probably legal, copyright, and ownership issues involved as well.)
Deleted comment
And sure, x86 might be easier to understand, but it's not the original PoP. That's what this is about, not just the code.
I happened to be in the office of someone who was doing language translation on the PC version of PoP at the time; He had a copy of the source code for that, and it was C.
That was twenty years ago. I only got a glimpse of one screenful of code, but I remember feeling special for that nonetheless :)
In other words, I don't agree that 16-bit real mode is much better. Now, mdern x86_64 code is starting to get tolerable, with more orthogonal register, for example. But I'd rather chew off my own hand than be forced to write any large amount of 16 or 32 bit x86 assembly....
Then again, I'm horribly opinionated about programming language syntax...
It's that it's horribly ugly and full of warts.
The biggest issue I have with x86 is not even trying to make things orthogonal (until x86_64, which does a tolerable job cleaning up a lot of the mess).
Some of it could probably be improved simply by ditching the syntax, and renaming stuff and pretending a lot of the rest simply doesn't exist, but you'd be left with something that looks very different from a typical x86 assembly listing..
But some stuff you don't avoid unless you go 64 bit: The registers alone gives me gives me hives, starting with the naming convention, where the M68k for example is straight forward: D0 through D7 = data registers. A0- A7 = address registers. For a lot of things they can even be used entirely interchangeably.
No addressing parts of the registers with special names, or mumbo jumbo restrictions on what can be done with different registers (that was excusable when the 6502 was a viable competitor, but even that followed clear and simple rules (Arithmetic on the accumulator (A), indexing with the X and Y registers) and didn't layer complexity on top of complexity. Bank switching / segments? Nope, we don't clutter the CPU with junk like that. Either you use a memory address or IO lines (or, as it happens, on the 6510 in the C64, IO lines mapped to a memory address).
Maybe I'm just still sore the M68k lost the performance race and I "had to" get a PC.
As you noted, the x86_64 sorted out some of the mess.
Personally, I think a big issue is the whole backwards-compatibility thing. It causes all sorts of nastiness, and a complete overhaul of the architecture is impossible because everything depends on it! (Which is one of the reasons the IA-64 never really became a hit.)
I vote we design our own processors, and write a new kernel to boot. ;)
Everything has warts (and x86 more than most). But don't pretend that ARM is clean. Or VAX (integer polynomial instructions? Non-IEEE floating point what now?). Or MIPS (A branch delay what? Multiply outputs to a separate register?). Or even 68k (let me puke garbage on your stack, I'll just tell you how much room you need).
(IIRC, the 6502 decoded instructions by bitmasks; say bit 7 meant "load" and bit 6 meant "move" or some such thing. So you could trigger combination instructions that'd still execute in 3 cycles but perform the work of two instructions that'd normally take 6. This might have been 6510-only, but I don't think it was.)
I actually had to rewrite some code because of that. I remember the comments in the source code were less than kind towards the engineers responsible. I may even have the listings somewhere.