Prince of Persia on the PicoComputer 3

The most comfortable frame budget of any port so far, attached to the largest body of code

Prince of Persia is not a performance problem. It is a transcription problem, and an unusually well-posed one, because what was released is the actual source — labelled, commented, and structured into named modules — not a reverse-engineered disassembly. Against that, it is the biggest body of game logic we have looked at: roughly 20,000 lines of 6502 across 29 files, of which about 12,000 lines are game behaviour that has to come across.

The decisive number is in the game’s own timekeeping. SPECIALK.S defines a game minute as 725 frames and its author annotated the constant with a note that the actual frame rate is approximately eleven a second. That is 83 milliseconds a frame. Thrust had 30 ms and Exile 40 ms. We have more than twice Exile’s budget for a game that, once the Apple II’s memory-banking and disk machinery is stripped out, does considerably less per frame than Exile does.

The renderer is cheap, because the PicoMite already has the primitive the original spends a third of its code emulating. Prince of Persia’s HIRES.S is 1,293 lines of shift tables, carry bytes, five opacity modes and a “peel” buffer, all of it there to move a masked bitmap across a screen whose bytes hold seven pixels apiece. BLIT FLASH with a transparent colour does the same job in one call, and the RAM image slots added in b11 hold every image the game owns with room to spare.

The risk is not the frame rate and not the memory. It is volume, and it is the two subsystems that were never released: the music, and the artwork’s provenance.

The source is public. The game is not.

Mechner’s README is unusually direct about this, and it is worth taking at face value rather than treating it as boilerplate. He released the code as a historical artifact, says he has no objection to anyone studying, modifying or running it, and then states plainly that this grants no rights to Prince of Persia itself, and that Ubisoft alone has the right to make and distribute Prince of Persia games.

That is a materially different position from the ones behind the earlier ports. The Thrust and Exile disassemblies carried no licence at all, which is a grey area; this carries an explicit reservation, which is not. It also lands differently because of what the assets are.

When Arkanoid became Picanoid, the artwork could be replaced in an afternoon by a Python script, because the artwork was bricks. Prince of Persia’s identity is 290 rotoscoped character images traced from film of a real person running, jumping and falling. Re-drawing those as original work is not a scripting job; it is an animation project of its own, and a port with different animation is not recognisably the same game. The engine can be made original. The thing people would want to see cannot, cheaply.

This is a judgement for you, not for me. It is placed first only because it changes the shape of the work: Option B implies building the engine against placeholder art from day one, which is a different Phase 1 from Option A.

What the PC3 gives us

Only one row of that table is tight, and it is the program memory. Twelve thousand lines of 6502 do not become twelve thousand lines of MMBasic — a great deal of it is register shuffling and bank switching that collapses to nothing — but this is the first port where the tokenised size cap is a live concern rather than a footnote. Every table stays out of the program text from the first line written, and the CSUB-in-the-library route is held in reserve.

Six subsystems, and only four of them are ours to port

The animation system is the game

Everything that makes Prince of Persia feel like Prince of Persia lives in two tables and an interpreter, and all three are small. FRAMEDEF.S holds 415 frame definitions in five bytes each: the image to draw, which sword image goes with it, how far the character moves in x and y that frame, and a packed collision descriptor. SEQTABLE.S holds 114 named sequences — the run cycle, the hanging drop, the block-to-strike, the stair climb — written in a byte code of fifteen instructions that can jump, turn the character round, change floor level, alter x or y, set the action class, trigger a fall, test weightlessness, kill, and advance the level.

That is a virtual machine, and porting a virtual machine is the most reliable kind of transcription there is: the interpreter is perhaps 150 lines of MMBasic, and the sequences themselves are data that a Python script converts once and never touches again. Get the interpreter exactly right and every movement in the game is exactly right, including the ones nobody can describe in words.

The world is a blueprint, not a bitmap

A level is 24 screens of 30 blocks, ten across and three down. Each block carries a type from a list of 30 — floor, spikes, gate, loose floor, pressure plate, torch, mirror, exit, slicer — and a one-byte modifier. Alongside that sits a link table saying which screen lies left, right, above and below each screen, a 96-byte map, and 256 bytes of starting information: where the Kid begins, which way he faces, where the sword lies, and the block, facing, position and behaviour program for each of up to 24 guards.

The whole thing is 2,304 bytes, and the layout in the released equates accounts for all of it with nothing left over. That is a format you can trust without a single guess, which is not something we have had before. Across the fifteen levels only 28 of the 30 block types are ever used, and 42 guards are placed in the entire game.

A block draws in five pieces

The reason the original’s renderer is more complicated than it looks is that a block is not one image. It is up to five, drawn in a fixed order: a back section, a middle section, a front-of-middle section, a floor section, and a foreground piece that draws over the character. Each has its own image number, its own vertical offset, and in two cases its own mask. This is how a character walks behind a pillar and in front of the back wall on a machine with no sprite priority hardware, and it has to be reproduced exactly or the depth reads wrong. A block’s appearance also depends on the block to its left and the row below, which is why the draw loop carries the preceding block’s identity forward.

The measurements that shape the port

Architecture for the port

Redraw everything, every frame

The largest single file in the game exists to avoid work we no longer need to avoid. FRAMEADV.S maintains eight redraw buffers, tracks which of the 30 blocks changed, saves the background behind each character before drawing it and peels it off afterwards — all so the Apple did not have to repaint 8 KB at 1 MHz. With 83 ms and a framebuffer, the port clears the F buffer, walks the 30 blocks drawing their five sections in order, draws the characters, draws the foreground pieces over them, draws the meters, and copies. The peel machinery, the redraw buffers and the dirty-block bookkeeping all go.

What must survive from that file is the order, not the optimisation: the plane model of background, middle, objects, foreground and messages, and the rule that a block’s appearance depends on its neighbours. Those are correctness, not speed.

The cost is roughly 150 BLIT FLASH calls a frame for the background plus a handful for characters. Exile measured a full frame — one tilemap draw and sixty sprites — at about 5 ms, so this should land in the low tens of milliseconds against an 83 ms budget. That is an inference from a different workload, not a measurement, and it is the first thing Phase 0 should settle.

Twelve frames a second, exactly

At 378 MHz the PC3 runs 640×480 at 60 Hz, and presenting one frame in five gives exactly 12.000 fps against the original’s 12.083. A sixty-minute game would run about twenty-five seconds long, which nobody can perceive and which keeps the interpreter at its fastest clock. The alternative — 315 MHz for a 75 Hz display — divides to 12.5, which is further out and costs interpreter speed.

As with Thrust and Arkanoid, the per-frame constants are integers and must not be rescaled. The sequence byte code moves a character by whole pixels per frame; the timers count frames. Change the tick rate and every one of them is wrong together, which is the failure mode that is hardest to see because nothing looks broken — the game just plays wrong.

Artwork in PSRAM image slots

The b11 RAM image slots land exactly where this port needs them. Everything the game owns, both facings pre-mirrored, is 571 KB — four of the five PSRAM slots, leaving the three flash slots free and the library slot untouched. Nothing needs loading between levels, which deletes the whole of the original’s set-management logic and the disk track tables that feed it.

Slots are volatile, so the installer writes them once per run from a bitmap on the A: drive, the same pattern Arkanoid uses. A 320×240 image loads into a RAM slot in 28 ms, so a cold start costs well under a second.

One pixel grid, no scaling

280×192 centred in 320×240 is the authentic grid at 1:1. The 20-pixel side borders and 24-pixel top and bottom are roughly what an Apple II displayed into an overscanned television. Resist the temptation to stretch it: the artwork was drawn for pixels of this shape, and MODE 2 pixels on the PC3 are close enough to the Apple’s that the proportions come out right by doing nothing.

Getting the data across

Four converters, all offline Python, all validated before a line of game logic is written. This is the pattern that worked for Thrust, Exile and Arkanoid and there is no reason to depart from it.

What we delete, and what is simply missing

Deleted — about 4,400 lines of Apple II plumbing

• The blitter (HIRES, HRTABLES, HRPARAMS, 1,560 lines). Shift tables, carry tables, mirror tables, mask tables, five opacity modes and the peel buffer. Replaced by one firmware call.
• The bank-switching layer (GRAFIX, 1,292 lines). The game runs in auxiliary memory and reaches main memory through a jump table; every graphics call in the game is really two calls and a pair of soft-switch writes. All of it evaporates.
• Disk everything. The custom 18-sector format, the loader, the track tables, the side-two prompts. Also the two folders of disk routines and the entire copy-protection tree, which are not game logic at all.
• The title-screen decompressor (UNPACK, 577 lines), which unpacks double hi-res images the repository does not contain.

Missing from the release — decide what to do about each

• The music. The player is in the support tree, credited to Kyle Freeman’s Music System II of 1986 and adapted in July 1989, and it contains no songs. The sixteen game tunes and the title music were loaded from disk tracks and are not in the repository in any form. They would have to be recovered from a disk image or re-transcribed by ear.
• The title and cutscene screens. The attract sequence unpacks double hi-res images by address, and those images are not here either. The artist’s working files in the support tree hold a great deal of packed material but not, on inspection, the finished title screens.
• The sound effects. Present as code, but as speaker-toggle loops with hand-counted delays. They have to be re-created as PLAY SOUND effects by ear. Thrust and Arkanoid both hit this and it was a day’s work each; twenty effects here rather than seventeen.

Worth keeping that you might not expect

The demo and attract playback in AUTO.S is a recorded input stream replayed through the normal control path. That is free once the control path works, and it doubles as the best regression test the port could have: record a run, replay it, and any divergence in the state machine shows up as the Kid walking into a wall.

Phases

Roughly four weeks of evenings, against Thrust’s seven phases and Exile’s larger plan. The estimate is honest about volume and optimistic about nothing except the renderer, which genuinely is easy here.

What could go wrong

Decisions

Where this came from

• The released repository, jmechner/Prince-of-Persia-Apple-II: 582 files, of which the 29 assembler sources, the sixteen image tables and the fifteen level files under 01 POP Source are the game proper. Everything measured in this document was measured from those.
• The README’s statement of what the release does and does not grant, which drives the rights section above.
• Fabien Sanglard’s code review of the same source, useful for context on the 6502 and the module structure, though it does not cover the formats measured here.
• Our own precedents: the Thrust port, the Exile design review, the Arkanoid port plan and the Elite port plan, for the phase structure, the converter-first discipline and the platform figures.
• The firmware itself for every PicoMite figure quoted: configuration.h for the slot and memory limits, graphics/Blit.c and graphics/Sprite.c for what the drawing primitives actually take.