Beiträge von Stephan Scheuer im Thema „Prince of Persia Disk Version ?“

    Ach, einfach so aus Spass.

    Ich mache da jetzt nicht den großen Aufriss

    Ich wollte einfach mal wissen ob das wirklich zu realiaieren ist.

    und zudem noch ob eine EasyFlash mittels SCPU emuliert werden kann.

    Die SCPU hat das BasicRom ab $01a000 stehen und den Kernal ab $01e000.

    Wenn man dort etwas verändert,sagen wir mal den "ready promp", bleibt das solange bis man die Hardware neustartet.

    Die EasyFlash ROM-Bänke kann man einfach nach $018000-$01BFFF kopieren.

    Ich habe einen Artikel dazu auf einer US-Seite gelesen. Es ging allgemein darum Module zu Emulieren.


    Lade und starte mal die Datei "pppatch" mittels SCPU von dem angehangenen D64

    und kopiere mittels paste & copy das kleine Programm in den Bildschirm

    nun sagt dir der C64 "HALLO"


    10 poke 107384,72
    20 poke 107385,65
    30 poke 107386,76
    40 poke 107387,76
    50 poke 107388,79

    Danke für die Info. Das richtige setzen von $01 habe ich schon bei anderen Projekten vergessen. Ergebnis = Grafikmüll oder Abstürze.

    Das SCPU-Projekt war eigendlich nur eine fixe Idee von mir.

    Nun denke ich, das ich es doch mal versuchen werde. Mehr als scheitern kann ich auch nicht.

    Ich habe gerade alle Bänke des EasyFlash Moduls ausgelesen. Von Bank 00 bis Bank 31 (Dezimal).

    wobei die letzte Bank wohl Savestates sind.

    Alle Bänke zusammengelinkt ergibt ein Ramfile von 2065 Blocks das liegt dann ab $020000 im SCPU-Ram

    Gruß: Stephan

    PrinceOfPersia und TrapThem64 haben die selben Probleme. Nur ich habe die Mühe einer Diskettenversion gemacht.

    Ja, auch ich habe eine REU Version ausprobiert. Nur kann ich es nicht selber testen außer im Emu. Der Trick ist wie eine Diskette die REU nutzen, nachdem sie im REU endlich geladen ist.

    An einer REU bzw SCPU Ramdisk arbeite ich seit gestern

    Die SCPU-Ramdisk (im moment nur für sektorbasierende lader zu gebrauchen) funktioniert. Einfach das d64 in das SCPU-Ram ab $020000 laden.

    Den Code habe ich in "Borrowed Time" eingebaut.

    Das hätte ich sowiso vor.

    Der Code ab $d300 ist von mir gewählt worden, weil:

    z.b.

    • lda #$05
    • sta $0100
    • jsr $d300 ; ursprünglich sta $de00

    Ich könnte da jetzt kein jsr $125000 einsetzen,weil der op-code 4 bytes hat.
    Deshalb ist die EasyFlash Emulations-Routine ab $d300.

    Diese Routine kopiert nun per mvn befehl (bedeutend schneller als die REU)
    die entsprechenden Bänke aus dem SCPU-Ram ab $020000 nach $8000-$bfff

    gruß: stephen

    Ich bin da schon am überlegen.

    Die SCPU hat ab $D300-$D3FF Arbeitsspeicher.

    Alle STA $de00 dahin umleiten

    Nichts tolles nur mal kurz nachgedacht.

    Naja, Illegale OP-Codes habe ich öfter in Kopierprogramme und dort in den Schnelllade- und Saveroutinen gehabt. Diese musste ich dann doch tatsächlich mittels 256 Byte
    Tabelle ersetzen um es an die SCPU anzupassen. Filecopier von Prism Soft war das. Grand Prix Circuit von Accolade bedient sich auch diverser illegallen OP-Codes.

    Manchmal stosse ich auf soetwas

    ldx #$00
    stx $ffa0,x (01)
    inx
    bne (01)
    rts

    Das Bechreiben der Zeropage funktioniert mit dem c64.
    Mit der SCPU überschreibt man jedoch den C64-Kernal der ab $01e000 zu finden ist.

    Gruß: stephan

    Sehr schöne Ausführung.

    So wie Du das beschrieben hast, ist es eigendlich sogut wie nicht möglich,
    das Spiel an die REU anzupassen. Ich hatte mir sowas auch schon gedacht.


    Schade.


    Eine C128 Umsetzung währe auch mal etwas.

    Gibt es grundsätzlich mit dem EasyFlash am 128er Probleme oder nur bei dem Spiel ?


    Eine SCPU Anpassung sollte normalerweise kein Problem sein. Es sei denn, Illegale OP-Codes wurden verwendet.


    Vielen Dank für die Ausführung


    Gruß: Stephan

    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?


    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

    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 usw

    Ich denke,dafür ist selbst die REU zu langsam.

    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 anpasssen

    Mit der Georam "könnte es vielleicht gehen"

    und mit der SCPU mit Sicherheit

    REU programierung

    Bitte melde dich an, um diesen Link zu sehen.

    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 $de00

    Speedcode

    Bitte melde dich an, um diesen Link zu sehen.

    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