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)
volgens mij heb ik nog een dos versie liggen op 3,5" floppydisk
Dat gaat niet helpen voor 6502 assembler voor de Apple II. Maar vermoedelijk bestaat er voor die machine ook wel een emulator.
MAME
Multiple Arcade Machine Emulator
Daar zit iig die cpu in zie ik.
Multiple Arcade Machine Emulator
Daar zit iig die cpu in zie ik.
Niet in MAME, well in MESS.
Het gaat niet om het compileren en draaien; het gaat om het begrijpen van de code 
Dat is onzin. Assembly code van diverse processoren lijkt heel veel op elkaar. Als je er 1 kent, dan is een andere processor een eitje. 99% van de code is dingen berekenen, data verplaatsen en (conditioneel) naar andere adressen springen.
Klopt gedeeltelijk. De processor-instructies zijn het probleem niet, maar je moet ook wel weten hoe alle hardware werkt die aan de CPU hangt, vb: welke IRQ wordt genereerd door het toetsenbord, wat is het adres van het videogeheugen etc ...
Om nog maar te zwijgen van het feit dat bepaalde zaken enorm werden geoptimaliseerd voor de toen beschikbare hardware, met als gevolg dat je in de assembler code soms rare constructies aantreft, waarvan weinig mensen nog weten waarom het zo gedaan is.
Om nog maar te zwijgen van het feit dat bepaalde zaken enorm werden geoptimaliseerd voor de toen beschikbare hardware, met als gevolg dat je in de assembler code soms rare constructies aantreft, waarvan weinig mensen nog weten waarom het zo gedaan is.
6502 is toch iets anders dan x86. met name de linairiteit van de adresspace, de wijze waarop met integers en words wordt omgegaan. 6502 en 6809 code lijken veel op 680x0 code en zit reatief simpel in elkaar (alle assembler trouwens). Heb er zelf veel in geprogrammeerd, op apple en comodore. Heerlijk taaltje 
Ooit zelf een 6502 computertje gebouwd, heb de componenten nog liggen
Ga zeker kijken of ik wat met de code kan doen en misschien een Apple ][ emulatortje schrijven in c++. Leuk om te doen
Ooit zelf een 6502 computertje gebouwd, heb de componenten nog liggen Ga zeker kijken of ik wat met de code kan doen en misschien een Apple ][ emulatortje schrijven in c++. Leuk om te doen
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!
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!
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.
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.
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..
en @ slickRick
er is daarvoor een feedback forum voor.....
---
OT : VET, als het op internet staat zal ik het zeker gaan doornemen, assembly is een leuke taal.
er is daarvoor een feedback forum voor.....
---
OT : VET, als het op internet staat zal ik het zeker gaan doornemen, assembly is een leuke taal.
en niet iedereen weet dat, en wat maakt het nu uit of dat hier gemeld wordt of in dat andere forum, behalve dan dat als het hier vermeld wordt het natuurlijk wel duidelijk is dat de redactie niet zo zorgvuldig te werk gaat..
Er was destijds ook een x86 versie, daarvan zal de broncode iets meer bruikbaar zijn.
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
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.
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 maandag 2 april 2012 14:53]
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)..
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 maandag 2 april 2012 16:18]
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.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.
DMA staat trouwens voor "direct memory access". Ook je soundblaster kon dus gewoon het normale werkgeheugen aanspreken.
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
- 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
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 ?
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 ?
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
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...).
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...).
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.
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.
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.
. 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.
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
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
Hmmmzz, ik ben pas 32 hoor
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).
.(/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
).
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.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).
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?
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?
Die had ik ook, je kon hem nog terugzetten van 8 naar 4 MHz, om de spelletjes langzamer te spelen...
totally Offtopic maar IDD
Set477.exe of set800.exe
Good old memories *zwijmel*
Set477.exe of set800.exe
Good old memories *zwijmel*
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).
(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).
There is nothing that can't fix a good chkdsk /f
Ik wist niet dat de reparatiefunctie van ckdsk een fix nodig heeft. Interessant.
Beetje flauw van je, maar taaltechnisch best wel scherp ;-)
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.
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?
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
Maar als antwoord op uw vraag... 800KB dus
Overigens een stukje van Wiki
bron: http://nl.wikipedia.org/wiki/DisketteDoor 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;
Maar als antwoord op uw vraag... 800KB dus
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)
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.
Als het toch in zo'n lage programmeertaal geschreven is, kan je de gecompileerde versie dan niet net zo goed "de-complimeren"?
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)
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
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
. 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_001Als 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.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Prijzen
Prince Of Persia, PC
- Prince Of Persia, PC
- Prince of Persia, Xbox 360
- Prince Of Persia, PlayStation 3
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
