Prince of Persia

[Julian]

Somewhat off-topic but potentially of interest here to those that like their classic 80's coding.

Jordan Mechner - creator of the original Prince of Persia on the Apple II has posted the source code on github after finding tucked away in the back of a closet.
It's all in 6502 assembler but any self-respecting coder should be able to get a grip on what's going on and you can find the complete code here: https://github.com/jmechner/Prince-of-Persia-Apple-II
He's even gone so far as to publish his developer journals for it: http://jordanmechner.com/wp-content/upl ... rce009.pdf

Differences? The Apple II screen is 40 bytes wide instead of 32 and rather importantly the game requires almost 128k of memory in native form - 32k of that is the animation of the main character (iirc this was motion captured)

So how long before someone tries to translate it? Of course no-one can distribute it as Prince of Persia belongs very much in Ubisoft's pocket these days...

[Alastair]

I see someone has managed to port Prince of Persia to the C64 by creating a cartridge [1] of the game (http://popc64.blogspot.co.uk/2011/10/pr ... 64128.html), could such a scheme work on the Dragon?

[1] For the pedantic it's actually a cartridge image for use on a flashable C64 cartridge.

[prime]

I see someone has managed to port Prince of Persia to the C64 by creating a cartridge [1] of the game (http://popc64.blogspot.co.uk/2011/10/pr ... 64128.html), could such a scheme work on the Dragon?

[1] For the pedantic it's actually a cartridge image for use on a flashable C64 cartridge.

Well might be possible to do a multi-load or a disk based game, then again well written 6809 should be denser than 6502, so it may be possible to reduce the size somewhat.

Cheers.

Phill.

[Julian]

The actual game code is quite compact already in terms of volume - the bulk of the game and data (some 250k) is graphics, sound and level design. Each level is actually very compact using large tiles so not much to save there. The sound could be thinned out both in terms of the number of different samples and the quality. The graphics again could be reduced in size. First of all the Apple II used a 320 pixel width screen so straight off some of the original design has to be lost to fit in plus the relatively meagre graphics capabilities of the dragon mean another saving. As I already mentioned the bulk of the graphic data is the animation of the main character, some 32k of it. I think this could be condensed quite significantly without seriously harming the experienced quality. Either through simplification or reducing the number of frames.

Either way you are still looking at a fairly large game - it would have to be disk based and if you're going to do that then you may as well not bother with too much of the slimming exercise as it becomes load-on-demand anyway. The only requirement is keeping the bulk of the reused game and data in memory.

From what I've read it took a good few years to write this game and by the time it was published it was pretty refined and fairly well optimised. I agree that 6809 code would prove a fairly big advantage over the original 6502, a good conversion there is worthwhile at the very least as an exercise in 6809 dominance

[Alastair]

Dragon Answers in the March 1988 issue of Dragon User has some information about creating a cartridge based RAM extension. So is it possible to to create a cartridge that contains both RAM and a stored program (or programs), and where the program can make use of the additional RAM?

[Sarah]

Dragon Answers in the March 1988 issue of Dragon User has some information about creating a cartridge based RAM extension. So is it possible to to create a cartridge that contains both RAM and a stored program (or programs), and where the program can make use of the additional RAM?

Yes, certainly. It's possible to map as much RAM and/or ROM into the cartridge area as you desire!

All you need are the appropriate logic chips to decode the addressing and it works just fine. I used a latch together with 2 x 128K static RAM chips to expand my Dragon 32 with 256K of paged RAM. The page at $C000 was fixed, whilst pages at $D000 were selectable in software. The latch (or possibly a second one) also provided a read-only mechanism under software control, so that together with a rechargeable battery backup it effectively behaved somewhat like Flash memory. A simple "ramdisk operating system" utility booted from page 0 at cold start (or on demand) that utilised the extra memory as mass storage, allowing Dragon 32 software to be easily saved, retrieved and executed, or deleted from the paged RAM. As an exclusively tape-based user, my management utility was basically designed and implemented as a kind of tape substitute in hardware/firmware, so "save" would unlock the extra RAM, copy the last file loaded from tape (using the details remaining in the loaded header block & $7E-$7F) and then lock it again. The catalogue of titles stored in the paged RAM could be browsed using the user interface and items restored back to main memory again, almost instantly.

This was something I made just for fun in the early 1990s, however the cost of so much static RAM would probably have been somewhat prohibitive back in the 1980s... when something similar might have actually been a useful device to produce and sell to Dragon owners, so I guess that's why the market wasn't flooded with cartridge based memory expansions at the right time!

[robcfg]

That sounds amazingliy interesting, do you have by any chance any schematics or pictures of that cartridge-based Ram expansion?

[Sarah]

That sounds amazingliy interesting, do you have by any chance any schematics or pictures of that cartridge-based Ram expansion?

Let's see... yep, found my 20 year old notes!

They're horribly messy - everything is hand scribbled - however I've scanned and attached them all for you anyway. They also remind me that I originally tested 1 x 32K before going up to 2 x 128K of RAM. I don't have time to redraw or make sense of these right now, sorry. Nevertheless, I've removed the worst blemishes so they're at least more legible than the paper originals!

I did also convert the "ramdisk operating system" source from tape back in 1994 to preserve it and allow for the possibility of adding support to an emulator, so I've built and attached that too!

Here you go!

[Sarah]

I had to go into the loft this morning, so hunted down my Dragon (still the only one I've ever owned) whilst up there and snapped some pictures.

Here's a preview - higher resolution photos can be found in the attached zip file.



Incidentally, although my ramdisk project was a success, the battery that I used was really a bit too weak for the task and would only keep the RAM contents error free for a few days without mains support.

As noted within the scribble posted yesterday, the wire colour scheme is: yellow (address lines), brown (data lines), green (control lines), red (+5V) and black (0V).

The chips are (from left the right, upper row followed by lower row):

SN74HC08N (AND GATES) x 3
SN74HCT373N (LATCH)
SN74HC14N (NOT GATES)
SN74HC00N (NAND GATES)

ICL7673 (BATTERY BACKUP CONTROLLER)
TC551001PL-85 (128K STATIC RAM) x 2

The reason for using several SN74HC08N in the design was driven by a cost efficiency IIRC. The red/grey block in the lower right corner is a 10 segment display that visually indicates the currently selected RAM page number, write enable flag and power. The bank of switches above simply allow it to be disconnected from the latch when not required. Additional switches on the side of the machine provide a physical way to keep the ramdisk read-only (overriding the software mechanism) and an 'economy' mode that isolates the RAM so that without mains power the battery only keeps the RAM alive rather than the entire machine draining it!

Did anyone else build stuff like this?

[zephyr]

Unfortunately, in the 80's I never had any spare money to spend on projects like this. I was always very interested though...

Thanks for taking the time to share this with us.

Regards,
Steve