6502.org

Does anyone knows how many lines in total the source code of the original (1989) Prince of Persia is?

Mechner says in his book (page 90) "The making of Prince of Persia" "My most concrete achievement today was to print out the entire source code - all 1000 pages of it"

Does anyone knows something about it?


By the way, for anyone wondered about what type of assembler Mechner used to create Prince of Persia, the answer lies in page 38...."January 31, 1987.....Got to Broderbund around 8:30 and put in another solid eight hours. Converted BUILDER over to Merlin/Pro, but it's not working. Give me another day or two to get all the bugs out."

Cheers




P.S. Karateka was made in S-C Assembler (but he doesn't mention which exact version....)

Looks like 92871 lines to me (checking the .S files in the source). Including comments and declarations.

Edit: Typo

Okay. Thank you Tor for your answer.

I'm sure you're aware, but the official source code is here:

https://github.com/jmechner/Prince-of-Persia-Apple-II

I know!

I'm just too lazy to count!

One short command line is all it takes

Depends on your definition of "source code".

Sure, which is why I had 'Including comments and declarations.' in the post where I had counted the lines. Not that it would be much more difficult to at least ignore comments.

Okay. So one last question....

How on earth a person can write so many lines of assembly code?

I finished reading all the basics about 6502 and it just terrifies me that someone (i.e. Jordan Mechner) had the courage (?) to write such a long-long-(really long) source code.

I mean, currently I'm reading the explanation of that simple snake game made in assembly language found in "easy 6502" (by Nick Morgan) and HONESTLY the distance between what I've read so far and that game example (which makes use of the theory I've read so far and nothing more), feels like I'm travelling by boat from America to Europe, crossing the Atlantic.

It's not as hard as you think. It just takes determination. Also keep in mind that Jordan Mechner did this on an Apple II. Today, we have nice keyboards with great editors, etc.

Back then, you used what you had and your desire to code on these machines far outweighed whatever "inconvenience" that we label them today. Including long assembly. It was "just the way it was" back then.

Even today, coding or understanding large programs like that is done in the same way you eat an elephant...one bite (byte) at a time.

Right. Sometimes you look at the forest, sometimes you look at the trees. Or even at individual leaves. But after you've "built" a tree (analogous to a function or subroutine) the individual leaves (ie, lines of assembly language) cease to concern you. The tree is a functional unit. And with enough trees you can build a forest. Point being: it's not necessary for you to hold a mental image of what millions of individual leaves are doing.

> How on earth a person can write so many lines of assembly code?

Bear in mind that not so many have ever written something as complex as Prince of Persia: you're looking at an outlier. You're looking at a world-class athlete as you try to choose your first pair of running shoes. Enjoy the run, that's the thing.

However, Jordan Mechner has stated before that he's no expert programmer. Modesty, I guess.

OT: I actually spoke with Mechner years ago on Twitter. I had mentioned something about compiling PoP so that I can run it on my real Apple IIe. He saw my tweet and was amazed that I still had a running Apple IIe that I actually used. I guess he never heard about the whole "retro" computer movement.

He later stated that he gave up programming many years ago.

Each line of assembly code is very simple. Read a byte, perform an ALU op, branch, etc. When thinking of some technical concept, and spinning out all those steps required to carry it out, it's not difficult to have churned out hundreds to thousands of instructions.

I would also say that asm-level expert programmers do more with fewer instructions, while a more naive approach ends up being straightforward but larger. The complexity of code is the challenge to wrangle, not the absolute size. Lots of instructions does not necessarily indicate greater complexity.

The biggest headache I struggle with other developers (both new and seasoned) is separation of concerns. I've seen code where one file, say "Customer.java" will literally have email string manipulation, order creation, SMS notification, etc. All rolled into one gigantic file. It starts out innocent enough but grows into a monster of code that is both complex and large.

For me, it's much easier to analyze (and build) code from a top-down perspective. Starting with basic objects that are separated and agnostic of other objects (as much as possible). Then drill down to the details within each.

Assembly is no exception. However, assembly sometimes gets a "free pass" because if the goal is pure optimization (say a fast drawing loop on a 16K machine), then normal business logic and design patterns become less important. Self-modifying code comes to mind.

But normally, when code is cleanly separated, I find it much easier to understand.