Jordan Mechner gaat broncode Prince of Persia publiceren

De vader van Jordan Mechner, bedenker en programmeur van de originele Prince of Persia, heeft de broncode teruggevonden van de platformgame die in 1989 verscheen voor de Apple II. Mechner gaat de broncode online zetten.

Mechner werd onlangs gebeld door zijn vader, met de mededeling dat die bij het opruimen van een kast een doos met oude software had teruggevonden. Vader Mechner vond het zonde om de doos weg te gooien en dus verstuurde hij het geheel aan zijn zoon. Die ontdekte bij aankomst dat in de doos de broncode zat van Prince of Persia, de platformgame uit 1989 die destijds opzien baarde door de vloeiende animaties van de Perzische prins. Mechner was al jaren op zoek naar de broncode en had bij iedereen die heeft meegewerkt aan de game al navraag gedaan. Kennelijk had hij daarbij niet gedacht aan zijn vader, terwijl die toch de muziek voor de game gecomponeerd heeft.

Mechner is nu van plan om de broncode te publiceren, al stelt hij zelf dat het wel even kan duren voordat alles online staat. Zo zoekt Mechner nog naar een manier om Apple ProDOS-schijven van 3,5 inch over te zetten naar een formaat dat op hedendaagse apparatuur leesbaar is. Mechner heeft weinig illusies over het nut van de onderneming, want er zijn maar weinig mensen die de 6502 assembly-code kunnen lezen en begrijpen.

De game waarvan Mechner de broncode online gaat plaatsen was goed voor een hele reeks opvolgers, waarvan de laatste, The Forgotten Sands, in 2010 verscheen. De rechten op de serie zijn inmiddels in handen van uitgever Ubisoft. In hetzelfde jaar verscheen ook een film die gebaseerd is op de serie. Mechner werkte mee aan het script van de film.

Reacties (73)

[satoer]

Als het toch in zo'n lage programmeertaal geschreven is, kan je de gecompileerde versie dan niet net zo goed "de-complimeren"?

[Verwijderd]

Ja, alleen heb je dan geen variabele namen en label namen meer. En een naam als prince_direction zegt toch meer dan 0x340 (om maar wat te noemen)

[Xiphalon]

Om nog maar te zwijgen van commentaar in de code. Daarin staat meestal beschreven wat en waarom de code doet. Vooral in assembler is dat nogal handig

[SKiLLa]

Met als kleine aanvulling dat labels toendertijd maar max 6 karakters lang mochten zijn in de meeste 'compilers' . En na disassembly heb je wel labels, maar dan alleen genummerd; dus niet prince_direction (p_dir ?) of 0x340 (= fout 16 bits voorbeeld !) maar lab_001

[leuk_he]

Als speelbaar spelletje heeft het toch geen nut meer. Dan kun je de oude release op een emulator goed draaien. Het is meer documenteren hoe het er 30 jaar geleden aan toe ging.

[Verwijderd]

Het zal wel 5.25" zijn, zoals op de foto. Maar dan nog, je kan toch vrij eenvoudig het filesystem van prodos gebruiken in linux? Of hebben deze schijven een afwijkende density dan de gebruikelijke 360kb?

[Technomania]

Als ik mij goed weet te herinneren was er vroeger een tooltje die je moest laden en daardoor was je in staat om floppies op meer capaciteit te formatteren én te lezen.

Overigens een stukje van Wiki

Door Sony werd hiervan een 90 mm versie ontwikkeld. Amerikaanse fabrikanten rondden dit af op 3½" (hoewel 3½" eigenlijk 88,9 mm is) en deze naam werd algemeen overgenomen, zelfs in landen die het metriek stelsel hanteren. Gebruikmakend van de laatste technische ontwikkelingen en de eigenschappen van de eerder genoemde 3" disk werd de capaciteit vastgesteld op 720 kB (double-sided, double-density). 720 kB was het formaat voor MS-DOS-systemen, voor Amiga-systemen bevatten dezelfde floppy's 880 kB en eerdere Apple-systemen kwamen tot 800 kB. Ruw kon de diskette 1 MB bevatten;

bron: http://nl.wikipedia.org/wiki/Diskette

Maar als antwoord op uw vraag... 800KB dus

[Verwijderd]

Zoals je op de foto wel kan zien, zijn dit backup-tapes, geen floppies (behalve die paar floppies die in die enveloppes zitten, maar die hebben niets met PoP te maken)

[MossMan]

Weet je het zeker? Als dat foto echt is lijkt het eerder een hoop retail versies in hoesjes met daarbij een paar 5 1/4" floppies en *iets* in plastic dozen. De text spreekt duidelijk over 3.5" disks, dus zou ik gokken dat die in de plastic dozen liggen. De grootte klopt ongeveer - het zouden anders best grote backup tapes zijn; groter dan ik mij herinner van die tijden.

[jfversluis]

Het waren toen natuurlijk hele andere tijden, maar ik vraag me echt af hoe je de broncode daarvan kwijt kunt zijn!

Wel leuk dat het nu weer terug is en hij het gaat openbaren, hoewel misschien weinig mensen er iets aan zullen hebben zal het voor dat kleine groepje toch leuk zijn om eens in te zien!

[Da_maniaC]

Nou, geloof mij maar dat je zojuist voor 90% van de gevallen hebt benoemd waarom de source code niet meer te vinden is. Dit geld voor erg veel 'juweeltjes' uit dat tijdperk. Daar moet wel bij gezegd worden dat ondanks het succes van sommige...niet altijd het belang van de source code volledig werd gesnapt (men stond er toen niet bij stil dat wij hier nog zoveel waarde aan zouden hechten).

De rede dat ik dit weet is omdat ik voor een oud hobby project ooit in contact ben gekomen met de makers van de game Blake Stone (jam productions). Na wat onderhandelen had ik geregeld dat we de source code mochten krijgen voor gebruik bij het Winwolf3d project.
Na maanden van stilte moest men ons helaas vertellen dat bij beide coders, de source welke op floppies stond...ten onder was gegaan aan het welbekende bit-rot syndroom.

Overigens vind ik het daarom wel altijd leuk om dit soort berichten te lezen.

[SuperDre]

Zo moeilijk is dat niet, gewoon vergeten op welk schijfje je het had staan, en dan na een tijdje vergeten om backups te maken van die schijfjes naar andere media.. Is mezelf ook al helaas al overkomen met bv graphicsfiles van games waar ik mee bezig was in het verre verleden.. en dan al helemaal niet te vergeten over bv programma's die op andere media zoals de kleine tapejes van de P2000T enzo..

[Dreamvoid]

Er was destijds ook een x86 versie, daarvan zal de broncode iets meer bruikbaar zijn.

[Maurice v/d Zwaan]

Doe mij dan maar de 6502 broncode, qua machine taal was die indertijd mijlen vooruit op intel met x86 (ook met de spirituele opvolgers als de 680x0 serie). x86 met alle speciale register ipv general usage registers was een ramp

[no-sense]

Hoewel ik zelf veel liever met de 6502 werk (doe ik nog wekelijks) ga ik toch wel stellen dat de 8086 instructieset stukken voor liep op de 6502. Om maar even op te sommen:
- 1Mbyte (20 bits, weliswaar via segmenten) address space op de 8086 tegen 64Kb (16-bits) voor de 6502
- 16-bits registers op de 8086 tegen 8-bits only voor de 6502 (m.u.v. Program Counter)
- Veel betere stackinstructies op de 8086, op de 6502 kon je alleen de acc en de flags op de stack zetten.
De 6502 heeft maar 3 registers, A, X en Y en de meeste instructies kunnen slechts met 1 van die registers werken (met name de diverse vormen van indirecte addressering)

De x86-ellende is volgens mij pas later gekomen met de 80286 en verder omdat Intel maar backwards-compatible probeerde te blijven

Aansturen van graphics en geluid is geen feature van de 6502. Dit was een feature op 6502 apparaten die memory-mapped sound&video chips hadden. De 8086 PC had ook gewoon memory-mapped graphics hoor.

Verder ben ik het met allebei eens dat ik de 6502 vele malen leuker vind dan de x86

[SKiLLa]

Helemaal mee eens; we vergelijken eigenlijk een 16-bits CPU architectuur met een 8 bits variant (die slechts 1 16-bits register had !). De 6502 vergelijken met de 8080 of de Z80 was beter geweest.

Maar on-topic: ProDOS-floppies lezen moet toch geen probleem zijn als je nog een 3.5" drive hebt (en de floppies geen gatenkaas zijn) ? Zat nerds die het kunnen converteren ...

PS: Check ook die Amstrad CPC cassettes; dat is waarschijnlijk ook een Z80 versie ?

[Mathieu_Hinder]

De reden dat x86 zo'n boeltje is, is vooral om compatibel te blijven met het verleden. Om het zo te zeggen; Intel kan hier weinig aan doen, het is het publiek dat dit wil. Intel kan echt wel een processor maken zoals het hoort, moesten ze willen, maar ze kiezen er nu eenmaal voor om het zo te doen, met alle voor- en nadelen vandien. Eens je eraan gewend bent, heeft een en ander toch zijn voordelen qua gebruik vind ik. En vind je het niets, kan je de eerste 32 overslaan en beginnen bij R32

[Krokant]

Meer nog, het is enkel door het publiek dat Intel zo hamert op de backward compatibility. Intel heeft namelijk initieel in hun 64-bit architectuur volledig gebroken met de x86 architectuur, en de Itanium processoren uitgebracht. Dat was maar zeer beperkt een succes, en toen AMD hun x64 extensies uitbrachten op de x86 chipset (waardoor het draaien van 32-bit code nog native mogelijk was op de processor), is Intel noodgedwongen moeten volgen door de grote navolging van de AMD64 architectuur.

De poging van Intel om dus radicaal te vernieuwen op het 64-bit platform is dus eigenlijk op niets uitgedraaid (ok, Itanium wordt nog gebruikt, maar nu ook Microsoft (naast een resem andere ISV's) besloten heeft om geen nieuwe Windows Server OS's op dat platform uit te brengen, is het nog maar een kwestie van tijd...).

[Dreamvoid]

Dat, en een architectuur als Sandy Bridge-E veegt de vloer aan met Itanium 2. x86 is al zo vaak afgeschreven (door de concurrentie voornamelijk), maar Intel en AMD blijken toch elke keer weer moeiteloos bij te blijven.

[Mathieu_Hinder]

Foute conclusie eigenlijk. Dat Sandy Bridge sneller is dan Itanium 2 heeft hier niets mee te maken. Itanium is nl. een groter proces, ouder, en wordt veel minder ontwikkeld en gebruikt. De reden dat ze "bijblijven" is gewoon omdat ze daar ontwikkelen. Had Intel beslist om te stoppen met x86 en enkel Itanium te maken, hadden ze zonder problemen een processor afgeleverd die minstens even snel is als SB. Het is namelijk zo dat er allerhande kunstgrepen zijn ingevoerd die historisch in de processor zijn gegroeid onder allerhande druk van buitenaf. Nu zit men met heel wat legacy hardware en lelijke oplossingen die de processor enigzins terughouden.

[johnbetonschaar]

Dat is misschien wel ietsje te rooskleurig gesteld, 6502 assembly was erg elegant en leuk om in te programmeren, vooral vanwege de manier waarop je super simpel de graphics en het geluid kon aansturen via memory-mapped IO, maar 'mijlen ver vooruit op intel' was het zeker niet. De x86 instructieset is altijd rommelig, inconsequent en onnodig complex geweest, maar de 6502 was dan weer het tegenovergestelde, met zeer weinig instructies, slechts een stuk of vier 8-bit registers, geen load-store instructies, etc. Zeker niet makkelijker te programmeren dan x86 assembler.

Edit @no-sense:
Je hebt gelijk ja, ik ken 6502 assembly alleen van de C64, vandaar .

Overigens gebruikten volgens mij alle x86 PC's met DOS alleen programmed I/O via poorten, en zag/zie je MMIO nog steeds eigenlijk vooral op hele specifieke hardware platforms zoals consoles en dergelijke. Ik kan me uit mijn DOS/VGA tijd in ieder geval nog hele ritsen poortnummers herinneren, en ook als je iets naar de Gravis Ultrasound of de SoundBlaster wilde sturen moest je dat met poorten en DMA doen.

[Reactie gewijzigd door johnbetonschaar op 22 juli 2024 21:50]

[SuperDre]

vooral vanwege de manier waarop je super simpel de graphics en het geluid kon aansturen via memory-mapped IO
Dat had meer te maken met de externe chips dan de 6502 zelf, want ook bij x86 kun je gewoon graphics en geluid aansturen via memory-mapped IO..
De x86 instructieset rommelig en inconsequent? het enige lastige was het segmented deel, maar dat was voorbij tentijde van de 386 (of was dat al bij de 286, hmm het is al zo lang geleden) waarbij je ook via extended mode gewoon zonder segmenten kon werken.. zelf had ik nooit echt moeite met de instructieset van de x86, vond het toendertijd zelfs simpeler als werken met pascal/c, LOL.. maar dat is allemaal al weer zo lang geleden, toen was het nog leuk en werd hardware nog vaak veel beter benut als nu (daarmee bedoel ik dus dat men de hardware veel beter kende en gebruikte omdat het toen ook langer duurde voordat er weer een nieuwe generatie op de markt kwam)..

[Reactie gewijzigd door SuperDre op 22 juli 2024 21:50]

[Hoopje]

Overigens gebruikten volgens mij alle x86 PC's met DOS alleen programmed I/O via poorten, en zag/zie je MMIO nog steeds eigenlijk vooral op hele specifieke hardware platforms zoals consoles en dergelijke. Ik kan me uit mijn DOS/VGA tijd in ieder geval nog hele ritsen poortnummers herinneren, en ook als je iets naar de Gravis Ultrasound of de SoundBlaster wilde sturen moest je dat met poorten en DMA doen.

Bij PC's was het videogeheugen van het begin via het gewone geheugen te bereiken, ik meen dat het in tekstmode vanaf segment $B800 was, ofzo. Voor tekstmode-applicaties werden echter vaak inderdaad langzame DOS-calls gebruikt. Voor een beetje vloeiend beeld moest je echter gewoon direct het videogeheugen aanspreken (wat op VGA best makkelijk was, omdat een byte precies met een pixel overeenkwam). Pas toen verschillende grafische kaarten met elkaar incompatible 2D- en 3D-acceleratie introduceerden werd het gebruikelijk drivers aan te roepen, maar toen was het Windows-tijdperk eigenlijk al aangebroken.

DMA staat trouwens voor "direct memory access". Ook je soundblaster kon dus gewoon het normale werkgeheugen aanspreken.

[sKweezr]

Beetje off-topic, maar heeft het tegenwoordig zin om in assembly te programmeren?

Zo heb je bijvoorbeeld het Menuet operating system, 64 bit en past op een floppy disk.

Is het dan met name het (kleine) formaat dat een voordeel is van assembly, of zijn er nog andere voordelen?

[Mathieu_Hinder]

Het heeft voor 'normale' programmeurs weinig zin. Het is zeer moeiiljk om enigzins complexere programma's te schrijven, onoverzichtelijk, en zeer rudimentair. Je kan beter in C schrijven en dan de compiler het laten omzetten in assembly. Deze doet dan optimalisaties die je eventueel met de hand zou kunnen doen, maar waar je je hoofd over breekt, en zeer veel tijd insteekt. De meeste 'native' code en apparatuur ondersteunt programmeren in C.

Anderzijds is assembly nog een behoorlijk niveau dichter bij de hardware dan C. Als men drivers wil schrijven of in de branche van besturingssystemen zit, heeft met vaak toegang nodig tot de hardware zelf, registers in processors, specifieke bits hier en daar. Hiervoor is assembly geschikt.

[roy-t]

Een compileer vertaald jouw code (C++ bijv.) gewoon naar Assembly en wel op een hele gestructureerde manier. Als je alle code van hedendaagse projecten gaat finetunen zou je misschien op betere assembly code kunnen komen en dingen in minder code kunnen doen, maar de kans daarop is vrij klein. Daarom optimaliseren programmeurs die werken aan systemen die echt snel moeten zijn vaak kleine stukjes kritieke code met de hand maar laten de rest zoals het uit de compiler komt en ook dit gebeurt steeds minder omdat compilers steeds beter worden.

[SKiLLa]

Ja, raketsnel. Maar in veel gevallen is het veel praktischer (en ruim voldoende snel/efficient) om C++ of zelfs nog 'hogere' talen te gebruiken.

[no-sense]

Assembly wordt nog meer gebruikt dan je denkt. Niet (meer) in PCs maar veel apparaten bevatten kleine processoren en software om 't ding aan te sturen (denk aan koelkasten, koffie- snoep- en frisdrankautomaten, parkeerautomaten e.d.)
Verder is de (vhdl) code van die simpele processortjes gratis of bijna gratis te verkrijgen en ze worden dus veel gebruikt in FPGA- en ASIC designs. (voorbeeld, bij mij op 't werk hebben we FPGAs met ingebouwde 8051 die dienst doet als programmeerbaar digitaal filter)
Voor een heleboel van dit soort apparaten is een ARM chip o.i.d. te kostbaar en/of neemt te veel ruimte in.

Voor die ultrakleine toepassingen is zelfs een taal als C te lomp. Ik kan software in assembly altijd kleiner en sneller krijgen dan de beste embedded C compiler.

edit: beroerd taalgebruik

[Reactie gewijzigd door no-sense op 22 juli 2024 21:50]

[leuk_he]

Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it .

Torvalds, Linus (1996-07-20).


6502 assembly? Er is een hele generatie groot geworden daarmee toch? C64 / Vic20 / Apple II / BBC B . Dat kennen denk ik meer mensen dan je zou verwachten. Ja, maar 1 op de 100 mensen die een computer had kon dat, mar dat zijn nog steeds heel veel mensen.

[Iblies]

Maar als je boven de 50 bent dan tel je niet meer mee in deze maatschappij.
Dus wat dat betreft kan ik de veronderstelling begrijpen dat niemand er meer is die deze code kan ontleden. Wil niet zeggen dat ik het er mee eens ben

[SKiLLa]

Hmmmzz, ik ben pas 32 hoor

[Krokant]

Ja, idem ditto, zelf 33 ... mensen vergeten soms dat de 6502 nog maar 25 jaar geleden was, en geen 40-50 jaar. Straks worden we nog op dezelfde hoop als de veteranen van '14-'18 gesmeten .

(/me herinnert zich nog levendig de Vic20 die hij als 5-jarig jochie kreeg en vooral de UREN tijd die in het intypen van source code ging... zonder tape of floppy backup was de stroom afzetten namelijk hetzelfde als alle code kwijt zijn ).

[RRRobert]

Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it .

Torvalds, Linus (1996-07-20).

In de tijd dat de broncode werd geschreven (1989) waren alleen de grootste geluksvogels in het bezit van een modem en een BBS-aansluiting. Met 'snelheden' van max. 9600 baud (effectief ongeveer 0,8 kB/s) was zelfs het uploaden van een 3½" floppydisk (max. 1,44 Mb aan data) als gauw een half uur werk.

[RVW]

Hoop dat die floppies van 20+ jaar oud nog überhaupt leesbaar zijn?

(alhoewel de floppies in die tijd nog wel van aardige kwaliteit waren, tweede helft van de jaren 90 gingen die dingen echt zwaar achteruit qua houdbaarheid).

[proatjeboksem]

http://media.techeblog.com/images/magnets_1.jpg

[Ikke_Niels]

There is nothing that can't fix a good chkdsk /f

[Verwijderd]

Ik wist niet dat de reparatiefunctie van ckdsk een fix nodig heeft. Interessant.

[sKweezr]

Beetje flauw van je, maar taaltechnisch best wel scherp ;-)

[SKiLLa]

chkdsk is zinloos in dergelijke gevallen, veel te primitief en 'high level'. Je hebt specialisitische low-level IO tools nodig om data echt te 'recoveren' i.p.v. alleen bad-sectors te markeren.

[cavey]

Hmmmm, misschien moet Jordan Mechner eens praten met Mr.Sid die een [url=http://popc64.blogspot.com=]c64[/url] port heeft gemaakt recentelijk van Prince of Persia, op basis van de dissassembly van de Apple versie (op easyflash uitgebracht).
http://noname.c64.org/csdb/release/?id=102540

Genoeg mensen die 6502 nog kunnen lezen, schrijven en voor een groot deel ook ademen. Die chip zit overal (zeker als embedded chip, van random LCD-keychain tot iets anders)

[no-sense]

en waarom ook niet? Een koffiemachine hoeft niet op een I7-Quadcore te draaien

De Z80 en zelfs de 8051 worden ook nog heel veel gebruikt (weliswaar ietwat opgevoerd, maar toch) en er zijn zelfs mensen (zoals ik) die er hun dagelijks brood mee verdienen

[leuk_he]

Prince of Persia op je koffiezetapparaat

[GemengdeDrop]

altijd al geweten dat koffie een magische drank is

[Perkouw]

Erg leuk dat hij dit online wilt plaatsen, maar kan hij hierdoor geen gezeur krijgen van Ubisoft omdat deze nu de rechten beheerd ?

[Verwijderd]

Ubi heeft de uitgeefrechten voor de nieuwere PoP's, maar Mechner heeft nog steeds zelf het recht voor de eerste PoP om de source code openbaar te maken.
De software is ook al meer dan 20 jaar oud, dus ik verwacht niet dat er iemand zal beginnen klagen

[Technomania]

1989 alweer?

Zie me nog zitten achter mijn Vendex Headstart met Hercules scherm

OT: Het spel is op diverse manieren te downloaden. Kan dat dan niet terug gecompiled worden?

[Nilrem]

Die had ik ook, je kon hem nog terugzetten van 8 naar 4 MHz, om de spelletjes langzamer te spelen...

[Technomania]

totally Offtopic maar IDD

Set477.exe of set800.exe

Good old memories *zwijmel*