Gibt es von Prince of Persia eine Disketten Version, oder kann man aus dem Easyflash CRT file eine Basteln?
Hallo Besucher, der Thread wurde 10k mal aufgerufen und enthält 58 Antworten
letzter Beitrag von Diddl am
Prince of Persia Disk Version ?
- Ernie76
- Erledigt
-
-
Nein, das geht aber auch nicht. Prince of Persia läuft nur auf dem Easyflash, irgendwo wurde das mal genauer beschrieben, warum das so ist.
EDIT:
Gefunden, steht im C64 WIKI:Diese inoffizielle C64-Version benötigt das EasyFlash, weil das Modul sowohl als Speichermedium als auch als RAM-Erweiterung dient. Laut dem Entwickler der C64-Version hätte er das Projekt nicht ohne das EasyFlash fertigstellen können, da der normale RAM des C64 einfach nicht ausreichend gewesen wäre, um eine genaue Umsetzung produzieren zu können. Dies war möglicherweise damals eines der wichtigsten Hindernisse für eine offizielle Portierung.
-
...Das Spiel nutzt das Easy Flash als eine Art Arbeitsspeicher oder genauer: Zwischenspeicher (RAM). Geht sicherlich noch etwas genauer, wofür genau das nochmal war.. (codetechnisch).
-
es werden explizit Routinen eingeblendet und dort ausgeführt. So eine Art Speedcode Verzeichnis. MrSid ist ein sehr versierter Coder. Ohne das wird man es schwerlich hinbekommen.
-
Ach ja genau, speedcode. Wie geht das aber btw. eigentlich (?), die CPU selbst vom C64 kann da in dem Ram eher -abseits vom Rechner eigenen Ram- nichts ausführen (liegt ja nicht im Adressraum usw.), oder doch ? Vermutlich wird das irgendwie im vorhinein dem Easy Flash so 'beigebracht'. Wie auch immer, bin neugierig auf eine noch speziellere Antwort.
-
Die EasyFlash bledet den angeforderten Bereich als ROM ein.
Die CPU kann dann sofort darauf zugreifen.
Theoretisch könnte man das auch auf Disk auslagern.
Warscheinlich hätte man dann üble Nachladezeiten oder Abstriche das Gameplays
Das ist dann ähnlich wie bei Toki.Oder es geht gar nicht, wenn ständig unterschiedlicher Programmcode eingeblendet wird
-
Ok damit ist meine Frage ja dann beantwortet. Danke an alle
-
Speedcode nennt man auch "loop unrolling". Auch hierzu hat die Wikipedia einen recht guten Artikel: https://de.wikipedia.org/wiki/Loop_unrolling
Weil dadurch der Code erheblich größer wird, liegt es auf der Hand, warum das Spiel auf das große Easyflash-ROM angewiesen ist. -
Ich versuche das nochmal genauer zu erklären
Mal angenommen, du hast ein Spiel programiert und der ganze Ram von $0000 bis $ffff ist belegt.
Nun benötigst Du noch einige Programmteile für das Spiel. Doch wohin damit ?.Ganz einfach. mittels $01 kann das Ram ausgeblendet werden und (wenn ein Modul mit den Programmteilen im Schacht steckt)
das ROM $8000 bis $bfff eingeblendet werden.Das geht blitzeschnell.
Bei der EasyFlash stehen außerdem je nach größe des Spiels entsprechend mehrere Bänke zur verfügung.
Die Einblendung dieser Bänke funktioniert dabei mit Adressen ab $de00Speedcode
-
Aber theoretisch müsste es ja auch aus der REU gehen. Natürlich nicht ohne Anpassungen.
Das Problem wäre nur das vorherige befüllen der REU von Disk aus. Evtl. mit SD2IEC und JD?
Oder liege ich da falsch? -
Die Reu Blendet nichts ein.
Daher geht es nicht.Arbeitsspeicher einblenden, das ist ja schon c128 ähnlich
Könnte man die EasyFlasch mit RAM ausstatten ?
und dahingehen anpasssenMit der Georam "könnte es vielleicht gehen"
und mit der SCPU mit Sicherheit
REU programierung
-
Die Reu Blendet nichts ein.
Daher geht es nicht.Dafür kann sie aber sehr schnell kopieren. Ich kann mir vorstellen, daß das Spiel zwar damit etwas langsamer, aber grundsätzlich umsetzbar wäre.
Daß das noch keiner versucht hat, dürfte wohl daran liegen, daß die meisten REU-Nutzer entweder eine 1541U oder ein Chameleon nutzen, und darauf läuft bereits die EasyFlash-Version. -
Hier müsste dann der entsprechende Bereich einmal gesichert werden.
Z.B. $a000 bis $bfff in die REU schreiben. Angeforderten Code aus der REU nach $a000 bis $bfff schreiben
kurz anspielen,den in der REU gesicherten Bereich $a000 bis $bfff wieder in Arbeitsspeicher uswIch denke,dafür ist selbst die REU zu langsam.
-
Geht das nicht mit „swap“?
Die Kopiergeschwindigkeit beträgt ja 1Byte / Tz., d.h. rd. 8192 tz für 8 KiB zzgl. die paar für den Initialisierungscode für die REU.
Meinst du, das würde nicht reichen?
-
Macht vielen auch einfach weniger Spaß.
Easyflash ist da genau wie ein x-beliebiges Modul. Ocean zB.
REU ist mit DMA eher schon wie ein Copro -
Klar, verstehe ich auch. Mir geht es eher um die theoretische Möglichkeit.
PoP reicht mir ja für Easyflash -
Geht das nicht mit „swap“?
Die Kopiergeschwindigkeit beträgt ja 1Byte / Tz., d.h. rd. 8192 tz für 2 KiB zzgl. die paar für den Initialisierungscode für die REU.
Meinst du, das würde nicht reichen?
Code
Schau mal, das Beispiel.
Und nun versuche das mal mit der REU in entsprechender geschwindigkeit.Ich sage nicht das dass unmöglich ist, nur aufwendiger
-
Hab mir den Code nie angesehen, dachte aber immer, dass (auch) Animationsphasen eingeblendet werden..?Das wäre auf Disk unzumutbar umzusetzen.
Die REU braucht nur 1 Cycle pro Byte plus ein paar für's Aufsetzen des Fetch. Von daher müßte das umsetzbar sein. Aber eben auch recht witzlos, wie weiter oben bereits erwähnt...
-
Gerade überlegt,
Wenn es immer derselbe Bereich ist, z.B. $a000 bis $bfff , dann könnte man
es mit einigen Anpassungen tatsächlich hinbekommen. -
Okay, ich hab jetzt (endlich) verstanden
Das einblenden ist erheblich schneller als das kopieren per DMA mit der REU.
Problematisch wäre REU also hauptsächlich dann, wenn man kaum noch Rasterzeit übrig hat.