Test Drive II - The Duel (Turbo Patch Version)

Zitat von LogicDeLuxe

Wenn man das Chameleon auf Turbo und das d030-bit ausschaltet, dann gibt es dort auch Artefakte. Es ist also wohl eher ein Timingproblem als ein Opcode-Problem.
Mit aktiviertem d030-Bit sind die Artefakte weg, und es ist trotzdem praktisch kein Geschwindigkeitsunterschied zum Dauerturbo bemerkbar. Chameleon läuft in diesem Modus bei ca. 600%.

Tut mir leid, das habe ich nicht verstanden. Wie hängt das C128-Register $d030 mit dem Chameleon zusammen? Im Netz fand ich nur eine Auflistung der TC64-Register ab $d040. Des weiteren: Was bedeutet "Wenn man das d030-bit ausschaltet". Hast Du dafür das Programm gepatcht (s. u.) oder gibt es beim Chameleon eine andere Möglichkeit, das Register zu handhaben?

Zitat von LogicDeLuxe

Evtl. funktioniert das auch mit der SCPU, wenn man alle Stellen, wo d030 beschrieben wird, durch die entsprechenden Turboregister der SCPU ersetzt.

Ich habe mal zu Beginn der Demo das Programm mit dem VICE-Monitor an den folgenden Stellen gepatcht:

Zur Aktivierung bzw. Deaktivierung der Turbokarte braucht man lediglich die $30 von $d030 auszutauschen gegen $7a bzw. $7b, also:

Jetzt befindet sich das Programm nur im Turbomodus, wenn sich der Rasterstrahl außerhalb des darstellbaren Bereichs befindet. Dies beseitigt das Flimmern und auch die Artefakte, ist aber zumindest in der VICE-Emulation noch schnell genug, um eine flüssige Animation zu erhalten. ABER: Wie vorher geschrieben, reicht es nicht aus, allein diese Stellen zu patchen. Wenn man genau hinsieht, erkennt man, daß die Kakteen und auch die Tankstelle nicht korrekt gezeichnet werden. Es ist wohl leider mehr als nur ein Timingproblem.

Hier mal eine Frage an die Chameleon-Besitzer: Was genau wird beim Chameleon beschleunigt? Nur der Prozessor, oder auch gleichzeitig die VIC-Ausgabe, der Timer, die Laufwerke? Leider ist (soweit ich sehen konnte) beim VICE die Prozessoremulation im Programmcode sehr eng verzahnt mit der restlichen Hardware, sprich: der ganze Takt wird vom Prozessorcode aus gesteuert, so daß eine unabhängige vom restlichen System entkoppelte Beschleunigung des Prozessors nicht so einfach möglich ist. (Es gibt wohl nicht ohne Grund extra ein VICE-Programm für die SuperCPU.) Wenn man nun die Geschwindigkeit heraufsetzt, bedeutet dies automatisch, daß auch Timer, VIC etc schneller laufen. Dabei wäre es auch interessant, nur die CPU zu beschleunigen auf 2Mhz etc, ohne daß z. B. die Soundausgabe darunter leiden muß.

Zitat von DATA-LAND

Nach ca. 7...8 Sek. im Intro hört die Musik von alleine auf und es erfolgt ein kurzer Diskettenzugriff. Danach wechselt der Rahmen immer zwischen Hell- und Dunkelblau. Wenn man nun die Tastatur oder den Feuerknopf betätigt, erfolgt ein weiterer kurzer Diskettenzufgriff, danach kommt es zum Crash!

Der Fehler tritt ein, wenn die Introschrift "Accolade" mit der bereits genannten Routine gelöscht werden soll. Da der Befehl "SAX" als "STA abs.l" (4-Byte-Befehl mit 3-Byte-Adresse) interpretiert wird, findet der Prozessor hinter diesen Befehl fälschlicherweise den Befehl "BRA.W" (relativer 16-Bit-Sprung), worauf das Programm ins Nirvana springt. Der Diskettenzugriff resultiert daraus, daß der Stack mit Werten aus $03 etc gefüllt wird und bei einem RTS der Prozessor dadurch in die im Bereich $300..$7ff angesiedelten Laderoutinen springt. Wahrscheinlich wird versucht, irgendeine Datei mit nicht initialisiertem Müllnamen zu laden, die nicht gefunden werden kann, worauf das Blinken ausgelöst wird. Der eigentliche Absturz erfolgte jedoch viel früher.

Zitat von DATA-LAND

Dürckt man stattdessen im Intro frühzeitig den Knopf, wird ca. 7...8 Sekunden eine Datei geladen, die geringfügig länger zu sein schient, als die allererste von N0S - könnte "SL" sein!? Nach Ende des Ladevorgangs kommt nun auch der Crash!

Korrekt. Es wird zunächst die Datei "SL" (Select) geladen, die jedoch den gleichen SAX-Bug aufweist wie das Intro und dadurch zu Beginn schon crasht.

Zitat von DATA-LAND

ist die Originalversion als Vorlage besser

Nein, denn dann müßte man die zuerst wieder cracken und die Module entpacken, was der Neuerfindung des Rads entspräche. Mit bereits entpackten Spielmodulen hat man schon ein Drittel der Arbeit erledigt.

Zitat von DATA-LAND

würde es deine Arbeit erleichtern, während dem Patchen eine reale SuperCPU zu haben?

Bedaure nein. Ich besitze nur einen C128. (Und ob der noch läuft... )

Zitat von DATA-LAND

Wärst du offen für eine Zusammenarbeit mit NOSTALGIA

Die von Nostalgia sind echte Cracks mit langjähriger Erfahrung. Die brauchen mich nicht.

Nun ein paar Worte zu dem Vorhaben, Programme für die SuperCPU und andere moderne Hardware verwendbar zu machen. Vorab: Das soll jetzt keine Kritik sein, sondern nur ein paar Überlegungen meinerseits, was auch wieder bedeutet, den advocatus diaboli zu spielen.

Schauen wir einmal, welche Anforderungen an das Spiel "Test Drive II" gestellt werden müssen, damit es wie verlangt auf allen C64-Rechnern mit allen möglichen Erweiterungen funktioniert:
1.) Es soll die Turbofunktion der SuperCPU unterstützen.
Das Spiel unterstützt bereits die Turbofunktion des C128, indem es $d030 im Bildschirmrahmen einschaltet. Ein Patch müßte also a) zu Beginn erkennen, welcher Rechnertyp vorliegt (C128, C64 mit SuperCPU, eventuell TC64) und die Stellen entsprechend anpassen, da den Besitzern eines C128 ihre bereits eingebaute Turbofunktion nicht genommen werden sollte. Das ist aufwendig, aber vielleicht machbar.
2.) Es soll über Kernal-Load geladen werden, damit das Spiel von allen Geräten aus startet. Alternativ man fragt vorher ab, ob ein Schnelllader verwendet werden soll, oder aber der Lader erkennt, welcher Laufwerkstyp vorliegt und stellt sich darauf ein. Klingt gut, ist aber tatsächlich alles ein schlechter Kompromiss.
Dummerweise ist der beste Schnelllader der, der ohne den Kernal und ohne das übliche Dateisystem (mitsamt Sektorlink in den ersten beiden Sektorenbytes) die Daten direkt aus den Sektoren lädt. So könnte das Programm "Test Drive II" nochmals mit vierfacher Beschleunigung laden, doch leider ist das Verfahren inkompatibel mit moderner Hardware. In der Praxis heißt das, man kann entweder
a) einen Lader einbauen, der auf einer Standard 1541 superschnell lädt, dafür aber bei anderen Medien entweder nicht anwendbar oder aber extrem langsam ist (Block-Read über Kernal. Brrr..)
b) einen Lader einbauen, der mit moderner Hardware zusammenarbeitet, aber dafür die Fähigkeiten des C64 grob vernachlässigt.
Ein Kernal-Load bedeutet immer die Amputation des C64, sei es das Abschalten von Graphik mit Splitscreens oder das Aussetzen von SID-Musik, also genau die Fähigkeiten, die den C64 ansonsten aus der Menge der Rechner herausheben, von nervenden Wartezeiten auf Standard-Rechnern gar nicht zu sprechen. Das Festhalten am Kernal ist so eine Sache, die ich persönlich nicht nachvollziehen kann. Mit Neid schaue ich da auf die AppleII-User, für die es kein Hindernis darstellte, mindestens drei verschiedene Betriebssysteme auf ihren Disketten zu haben: DOS 3.3, ProDos und das UCSD-System. Keiner hat da erwartet, daß unbedingt irgendwelche veraltete Routinen verwendet werden müssen.
Kurz gesagt: Würde ich Programme anpassen an eine Turbokarte oder das Chameleon? Möglich, tut ja nicht weh. Würde ich die Spiele dann so umschreiben, daß sie mit Kernal-Load laden? Nein, im Gegenteil. Ich würde sie so schreiben, daß sie die Fähigkeiten des C64 in Verbindung mit der 1541 genauso voll ausreizen wie in allen anderen Fällen auch (VIC, SID...), und das bedeutet "Ade Kernal" und her mit einem vernünftigen Lader, der auch gleichzeitig IRQs erlaubt.

Zitat von Superingo

Ja ich gehe mit dem Thema TC64 schwanger...
Bin nur noch am ùberlegen wie ich der mitspracheberechtigten Person im Haushalt die Nötigkeit einer solche Anschaffung erläuterte.

Spoiler anzeigen

Arme Socke sag ich da nur. Verkauf doch deine 1541 U.Das Teil ist dann eh überflüssig

Zitat von Superingo

Bin nur noch am ùberlegen wie ich der mitspracheberechtigten Person im Haushalt die Nötigkeit einer solche Anschaffung erläuterte.

@Superingo, Fenris64, Fulgore, Lysosom, MickyP und Thunder.Bird:
Ach, was habt ihr aus diesem schööönen Thread gemacht! Ihr seid ja voll gemein!
M.J. war auf besten Weg aus diesem Projekt einen Jahrhundertcrack zu machen...
Aber wenn wir schon beim Thema sind: Behalte bitte auch das Jocopod mit Lenkrad und Gaspedal im Hinterkopf! Sähe dann also so aus: Mach doch einen Rundumschlag und sag du brauchst 300,- € oder lass dich zum Haushaltsvorstand wählen!

Wahr ist aber, dass Hardware für den CeVi Investitionen für's Leben sind. Microsoft-Jünger hingegen sind, bzw. waren es gewohnt, ständig aufzurüsten. Um dann wenige Jahre später wieder alles neu kaufen zu müssen, da Windows zu sich selber mal wieder ganz zufällig inkompatibel wurde.

Zitat von Superingo

Ich denke da gibt es noch einige Perlen die vom Turbo deutlich profitieren sollten.
Ich denke da an Grand Prix Circuit oder REVS+....

Jep - Grand Prix Circuit kommt zwar schon im Original flüssiger rüber, trotzdem täte ihm wohl ein Turbo gut. Bitte freu dich auf REVS nicht zu früh - hier muss außer Joystick/Paddles/Lenkrad/Gaspedal auch noch die Tastatur bedient werden, was den Fahrer evtl. überfordert!?,

Zitat von M. J.

Würde ich Programme anpassen an eine Turbokarte oder das Chameleon? Möglich, tut ja nicht weh.

Ich mach jetzt am besten mal 'ne Zusammenfassung von den letzten Tagen:

- Wir sind uns glaube ich alle einig, dass "Test Drive II - The Duel" ein tolles Spiel ist und vom Turbomodus sehr profitieren würde - sich eine vernünftige Anpassung also lohnt
- Wahrscheinlich ist die Lage aber so, dass es schon jetzt mehr TC64- als SuperCPU-Besitzer gibt
- Das wäre aber egal, denn eine etwaige kompatiblere Software könnte ja dann von ALLEN benutzt werden, ohne wenn und aber
- Tommes hatte aber in meinen Augen recht weise argumentiert, dass es beim 65816 Professor der SCPU eher Inkompatiblitäten gäbe, als beim emulierten und getunten 6510 im TC64
- Hinzu kommen noch Eigenheiten wie bspw. das korrekte Rechnen des 65816 im Dezimalmodus (der 6510 hingegen löscht nicht das N-Flag, wenn zu #$99 1 dazuaddiert wird!)
- DJ SID hatte bemerkt, dass im Turbo Modus des TC 64 2, 3, 4, 5 oder 6 MHz gewählt werden kann, die SCPU aber 20 MHz hat, wobei sie bei Zugriffen auf den VIC auf etwa 10 MHz gedrosselt wird
- Manche TC 64 Besitzer sagen, sie würden keinen Turboeffekt merken oder hätten auch Artefakte
- Immerhin wurde bestätigt, dass auch das D64 Image des N0S Cracks mit dem Turbomodus des TC 64 läuft, sodass tatsächlich eine echte Diskettenversion verfügbar ist
- M.J. befürchtet, dass der illegale Ocode im ACCOLADE Intro wohl nicht der letzte ist und mit weiterem Ärger gerechnet werden muss
- Einen optionalen KERNAL LOADER hatte ich ins Gespräch gebracht um auf Nr. Sicher zu gehen, für diejenigen, die andere Laufwerke als die 1541 benutzen wollen
- Tom-Cat von N0S hat mir heute mitgeteilt, dass sie sich nicht an einer Kooperation beteiligen möchten, da sie einfach zuviele andere Projekte in der Pipeline haben
- Einen Zeitaufwand von 5...10 Stunden für den gewünschten Turbo-Crack empfand ich anfangs als zumutbar, nach Lage der Dinge wird dieser Aufwand wohl aber um einiges größer
- Ich könnte noch versuchen Malte Mundt "Mac Gyver" mit ins Boot zu holen - er hatte für die GO64 in den ersten 8 Ausgaben einen SuperCPU Kurs geschrieben und wäre hier bestimmt ein guter Ratgeber in Fragen des 65816
- Alles in allem spricht überhaupt nichts gegen eine überarbeitete Software, die von allen Usern genutzt werden könnte. Gemessen am Aufwand, da es ja eben nicht nur eine einzige Kleinigkeit ist, und der Anzahl der SuperCPU Nutzer, überlasse ich M.J. die Entscheidung das Projekt abzubrechen oder es bei Bedarf auch mit Mac Gyver fortzuführen
- Wichtig ist aber, dass das Spiel (insbesondere auch das D64 Image) auf jedem TC64 im Turbomodus OHNE zusätzliche Probleme läuft!

Wie gesagt, die Software ist offensichtlich NICHT 100%ig und der Turbomodus eher ein Glücksfall. Noch sind die Rückmeldungen des TC64 User aber nicht einheitlich positiv. Wenn das Projekt nun gecancelt werden sollte, müssen künftige Probleme unbedingt ausgeschlossen werden

Also bitte nicht zu früh und aus Euphorie urteilen, nur weil sich das Spiel die ersten paar "Meter" korrekt verhält! Wir hätten evtl. dank M.J. die Chance auf ein professionelles Update für ALLE!

Nachtrag:
Im Spielmodul findet sich eine Routine zum Zeichnen der Kakteen etc ab Adresse $7a87:

Blöderweise handelt es sich hierbei um eine unrolled Loop, d. h. die gleiche Anweisungsfolge folgt zigmal nacheinander. Das zu patchen, dürfte nicht so einfach werden. Da müßte man genau gucken, wieviel freie Bytes irgendwo dahinter frei sind. Schlimmstenfalls müßte man große Teile des Codes disassemblieren, mit Labels versehen und damit relokatibel machen und anschließend neu assemblieren. Keine Sache, die man mal eben so zwischendurch erledigt.