Beiträge von Mike im Thema „LOAD wohin?“

    [...] folgende Strategie, die deinem an- und ausschalten ähnelt: Da ein Hardware-Resetbutton angelötet werden konnte [...]

    Sorry, wat? Beim C16/C116/+4 war ein Reset-Button ab Werk eingebaut.

    Und mit Aus- und wieder Einschalten hatte das auch nichts zu tun, bzw. damit war nichts gedient: zumindest bei meinem C116 war der RAM-Inhalt auch schon nach kürzestem Ausfall der Versorgungsspannung Matsch.

    Die Methode, die ich beschrieben hab' greift zudem zu einem wesentlich früheren Zeitpunkt an, eben dann, wenn der Code zwar vollständig in den Speicher geschrieben aber noch nicht ausgeführt worden war. Ansonsten hat man eben das Problem, daß man nach kürzester Zeit nicht mehr den Originalzustand des Spiels wegspeichern kann ... besonders kritisch ist es dann, wenn das Spiel unmittelbar nach seiner Initialisierung eben genau diese Init-Routinen mit Nullen überschreibt.

    Zitat

    ... kann der Loader überhaupt die Zeropage überbügeln?

    Klar konnte so ein (Fast-)loader das. Ein großer Teil des Loaders wurde durch einen Trick (mit einem "überlangen" Dateinamen) in den Tapebuffer geladen, ein anderer Teil überschrieb in der "erweiterten" Zeropage einige Vektoren und löste so den Autostart aus.

    Zitat

    Ich meine schon, ich meine mich zu entsinnen, das Games nicht auf Hardwarereset reagierten, also zumindest nach Start des Games der Resetvektor beschrieben wurde!?

    Wenn die CPU-Zugriffe im TED auf RAM gesetzt werden, dann ist halt das ROM ausgeblendet und die CPU sieht auch nach einem Reset erstmal nur den Reset-Vektor im RAM. Das BASIC 3.5 schreibt darum ans RAM-Ende eine kleine Routine, die bei "Reset während RAM ein" erstmal wieder das ROM einblendet und dann in die eigentliche Reset-Routine durchstartet.

    Ein Spiel, welches dauerhaft das ROM ausblendet (da nicht benötigt) kann sich so dann natürlich gegen einen Reset wehren, indem der Reset-Vektor im RAM auf eine Routine umgebogen wird, die entweder das Spiel neu startet oder in eine "Absturz"-Routine verzweigt. Letzteres hat z.B. das Spiel "Gullwing-Falcon" gemacht.

    Aber auch von dem Spiel konnte ich eine Kopie auf Disk anfertigen, mit meiner zuvor beschriebenen Methode. :)

    Zitat

    Kann man im 264-TEDMON echt nicht an eine gewollte Adresse laden??

    Ich hab' jetzt gerade die Syntax des L-Kommandos nicht parat.

    In jedem Fall nutzt TEDMON aber die KERNAL-Loadroutine. Und wenn im Tape-Header das Flag für "force absolute" gesetzt ist, dann schert sich der KERNAL einfach nicht darum, daß der User gerne relativ laden wollte. Da muß man schon härtere Geschütze auffahren, sprich: erst den Header einzeln für sich laden (geht mit einem SYS), den Header im Speicher manipulieren (heißt: Type-Flag von 3 auf was anderes setzen, ggfs. die Ladeadresse woanders hin legen, Originaladresse notieren, etc.), den Payload laden (geht mit einem weiteren SYS), den Payload an der anderen Stelle im Speicher analysieren und dann das ganze so umbauen, daß es anstatt das Spiel zu starten den relevanten Speicherinhalt nach dem laden "jungfräulich" auf Diskette wegschreibt.

    Dann muß man nur noch die zuvor aus Tape-Loader ermittelte Startadresse hernehmen und mit einem Lader das Spiel wieder von Disk in den Speicher laden und dann vom selbstgeschriebenen Disklader eben an diese Adresse springen. Und schon läuft das Spiel von Disk. :D

    (Mit ein wenig Geschick reicht's gerade beim C16/+4 auch aus, mit STOP+Reset kurz nach Laden des Fastloaders in den Monitor zu springen. Dann steht der Fastloader im Speicher und man kann ihn dort auch manipulieren und wieder neu starten. Bei HEKTIK auf dem C16 war das aber besonders eklig: das bestand aus (IIRC) 4 Teilen wobei der letzte im "alten" Text- und Farb-RAM geladen wurde - da mußte man die Speicherroutine für den Komplettdump regelrecht rein injizieren und "blind" ausführen lassen ... 8| )

    Da geht nichts vorzugaukeln.

    Ein *.tap File ist das Abbild eines Datasetten-Bandes, eine *.d64 Datei ist das Abbild einer Diskette auf Sektor-Ebene. Diese zwei Dateitypen stellen also etwas völlig unterschiedliches dar.

    Den INHALT dieser Abbilder kannst Du möglicherweise umkopieren. Das geht aber - speziell von Tape auf Disk - nur dann, wenn auf Tape eben kein Autostart+Fastloader vorliegt und dann eben die Programme von Tape mit LOAD geladen und auf Disk mit SAVE gespeichert werden KÖNNEN. Genauso wärst Du dann auch auf Originalhardware vorgegangen. Zudem muß das Programm dann auch noch damit zurechtkommen, daß bei einem Mehrteiler die zuletzt benutzte Geräteadresse weiterverwendet wird. Macht das Programm das nicht, und will einfach die nächste Datei von Tape weiterladen, dann kannst Du als nicht-Programmierer nichts daran ändern.

    Außerdem bekommst Du das Spiel doch geladen, wenn auch im Emulator und halt eben von Tape.

    Wenn Du jetzt genau wissen willst, wie man davon eine (kopierbare) Disk-Version erstellt - kleiner Tip: das ist genau das, was Cracker damals™ schon gemacht haben, wenn sie einen Kopierschutz auf Tape geknackt haben. Ohne Assemblerkenntnisse geht da gar nix. ^^

    Zitat von GuteAlteZeit

    Obwohl angebliches Basic 3.5 scheint das DLOAD nicht zu kennen!

    Falls Du nur DLOAD für sich eingegeben hast, kommt der SYNTAX ERROR daher, daß DLOAD defaultmäßig auf Geräteadresse 8 zugreift, und daher zwingend einen Dateinamen erwartet.

    Im Gegensatz zu Tape ist bei Diskettenzugriffen die Angabe eines Dateinamens erforderlich, da sonst nicht klar ist, welche der Dateien von der Diskette geladen werden soll (und das gilt auch dann, sollte sich nur eine Datei auf der Diskette befinden... denn mit "$" könnte man ja auch das Directory laden wollen).

    Beim normalen LOAD-Befehl kommt in diesem Fall die Meldung MISSING FILENAME ERROR, was *irgendwie* etwas nachvollziehbarer ist.

    Zitat

    [...] "Tom". Kann ich super als Tape anbinden.

    Mit Tape geht eben nur LOAD. DLOAD läßt sich nicht auf Tape "zurückstellen".

    Um noch auf die ursprüngliche Frage zurückzukommen: im Regelfall (sprich: als nicht-Programmierer) muß es dich gar nicht kümmern, wohin mit LOAD geladen wird. Besser gesagt, es gibt zwei Varianten:

    1. Mit LOAD"...",1,1 oder LOAD"...",8,1 wird an die ursprüngliche Adresse geladen. Falls das Programm einen Autostart hat, brauchst Du anschließend auch nichts weiter anzugeben.

    2. LOAD"...",1 oder LOAD"...",8 lädt an den BASIC-Start. Das kannst Du dann probieren, wenn das Anhängen des ",1" als dritter Parameter - nach Dateiname und Geräteadresse - nichts zu bewirken scheint. Im Regelfall startet das Programm dann nach Eingabe von RUN.

    Bei Tape hat das abgespeicherte Programm die Möglichkeit die Angabe von ",1,1" zu erzwingen - was dann für gewöhnlich mit einem Autostart und einem Tape-Fastloader zusammenhängt. Da LOAD zudem defaultmäßig auf Tape zugreift, reicht in diesem Fall das Eingaben von LOAD alleine für sich schon aus.