Apple ][ Source FOUND!

[Norbert]

It seems the scr/SS/ directory contains some images (PAC.SS11.png and SS10.png-SS14.png) of the missing room that's also visible on the back of the game's packaging.
I like how PHP was your 'weapon of choice'.

[Edit: And scr/F/DBS.png is a highscore table of deathbounce.]

[Edit on July 6, 2015: Also, David mentioned "the princess in fighting stance" (PAC.MOUSE).]

[David]

[Edit: And scr/F/DBS.png is a highscore table of deathbounce.]

It can be downloaded here: ftp://ftp.apple.asimov.net/pub/apple_II ... 057_DB.dsk
Or you can play it online here: http://www.megidish.net/deathbounce/ (Apple II emulator in JavaScript)
See also here: http://jordanmechner.com/blog/2012/04/deathbounce/

[David]

Looks like somebody else also figured out how to compile the game:
https://github.com/adamgreen/Prince-of-Persia-Apple-II (Click the "How to Build" link.)
He also included everything needed for this, including a custom-made assembler (snap), a disk image maker (crackle) and a Makefile to put all this together.
He also figured out how to make 18-sector-per-track disk images.

[Norbert]

Someone posted a (so far) three-part code review in June 2013.

http://www.fabiensanglard.net/prince_of_persia/
http://www.fabiensanglard.net/prince_of ... p_boot.php
http://www.fabiensanglard.net/prince_of ... _boot2.php

[Norbert]

David, do you happen to know why, if I run the Apple ][ version in Kegs, it looks like this...


(mirror)

...instead of what I see in, for example, YouTube videos, where the text looks much more readable:


(mirror)

[David]

Perhaps they used a different emulator, or a real Apple II.
The problem is that the colors on Apple II were created by artifacting: the dense sequence of black-and-white pixels tricked the TV into displaying colors.
This is hard to reproduce in an emulator, and different emulators may do it differently.

[Norbert]

Oh, I never knew that. Now that you've mentioned that, I see that Wikipedia also goes into this at:
http://en.wikipedia.org/wiki/Apple_II#D ... d_graphics

[David]

Yes, the raise/drop buttons don't work yet (on any level), [...]

They do work in level 1.
You can reach the sword, take it, go all the way back, fight the guard, and enter the level exit door.

Yes, but it seems to me that any button will open all the doors.

[_Zaphod_]

So where's the windows bug compatible native source port with high resolution?

If i had the mad skillz i'd do it myself...

[David]

I already ported the room-drawing code: viewtopic.php?p=13927#p13927 (from the DOS disassembly, though)
I can't promise when (or whether) I will continue with the other parts.

[David]

So where's the windows bug compatible native source port with high resolution?

I can't promise when (or whether) I will continue with the other parts.

As you may know, I continued and the result is SDLPoP.
___

I found this: http://zombiesatemyxbox.com/2012/04/19/ ... de-online/

The best part is:

It’ll be interesting to see what platforms it does crop up on, I can see new versions coming out just as homebrew projects, and I’m guessing Prince of Persia mods could become quite a fun distraction given how many DOOM mods there are out there and that is similarly open source.

The author obviously does not know about our community...

[Norbert]

I've added a comment to that page ("Your comment is awaiting moderation.").

[David]

Some more goodies:

The "Z" file in the DRAZ folder is a drawing program.
I placed it onto a disk image so you can try it.
I included a text file with the functions of the keys.
Saving does not seem to work.

About the name: The sample from the "Making of PoP" book mentions "DRAX" and "DRAY" on pages 24 and 34.
Probably the first version was "DRAW", and Mechner incremented the last letter with each version.

draz.zip

(17.87 KiB) Downloaded 255 times

I compiled the POPBOOT0.S file by itself.
This file contains the effects of the "Secret Keys" that are mentioned in some text files that come in PoP downloads.
You can use this disk image to call each routine directly.

popboot.zip

(9.22 KiB) Downloaded 255 times

[Norbert]

In 64-bit xkegs under Linux, DRAZ.dsk shows:

Code: Select all

DISK VOLUME 254

 A 002 HELLO
 B 045 Z
Type BRUN Z to start image editor

Then, when I enter BRUN Z (in capitals), it shows a black rectangle with "Line 60 Byte 14 Offset 00 STA" underneath it, and a small blue flickering dot inside it. I got spr/I/IMG.BGTAB1.DUN/123.png from this package, and opened it with "U". But then the emulator says "Emulated system state probably corrupt". I'm sure there's a solution, but... it's so complicated... [Edit: I probably need to try a BMP, right?]

[David]

[Edit: I probably need to try a BMP, right?]

No, you need an image in the original format from the DRAZ folder.
PAC.* should be loaded with "U" (unpack picture from disk) and IMG.* with "I" (load image table from disk).
When the editor says "without extension", it means without the "PAC." or "IMG.".
But I didn't try loading yet, so it might not even work.

The files must be placed onto the disk image.
For this I am using a utility called CiderPress.
For correct file types, append the following tags at the end of the filenames:

Code: Select all

type    tag to add   example new name
IMG.*   #066000.BIN  IMG.BGTAB1.DUN#066000.BIN
PAC.*   #064000.BIN  PAC.MOUSE#064000.BIN
others  #062000.BIN  DRINK#062000.BIN

($6000 and $4000 come from the DRAZ source, and $2000 is the address of the hi-res screen.)
When you add the file to the disk image, check "Use file attribute preservation tags".

I tried them now, but:
"I" seems to corrupt the drawing program:
(The program itself is also loaded to $6000, maybe that's why...)
When I want to draw lines, the numbers at the bottom become inverted symbols, and the lines appear at wrong places.
"U" switches to a text screen with blinking characters.

The raw images (not IMG and not PAC) can be displayed outside the editor with these commands:

Code: Select all

HGR
BLOAD filename,A$2000

(CiderPress can also display these files.)