LOAD wohin?

Es gibt 19 Antworten in diesem Thema, welches 4.582 mal aufgerufen wurde. Der letzte Beitrag (19. Juni 2016 um 16:27) ist von Mike.

  • Moin liebe Retrogenossen,

    ich bin irgendwie infiziert von meiner Vergangenheit in Sachen C16 und C64 8o
    Also, hallo liebes Forum!
    Okay, Emoticons gab es noch nicht, schade, ich mag die Dinger... ;(

    Frage, Plattform hauptsächlich C16, eventuell gleiche Geschichte auf C64:
    Wie kann ich einen LOAD ausführen und dabei die Startadresse des zu beschreibenden Speichers angeben, und auslesen,
    was eigentlich die ursprüngliche war?
    Ich erinnere mich nicht. Bevor ich jetzt übelst die ROM-Listings durchforsche hoffe ich auf euch!

    Danke für Frischzellen im Hirn!

  • Schonmal Bitte melde dich an, um diesen Link zu sehen. angeschaut?

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wäre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom:

  • Okay, danke, und wie war das nun mit der Startadresse? Woher weiß ich die originale Startadresse?
    Merci! Oder vielleicht sollte ich schreiben: Die erste Adresse, die beschrieben wird.

  • C64:
    Bitte melde dich an, um diesen Link zu sehen.
    LOAD"FOO",8,1 lädt automatisch an die in den ersten beiden Bytes enthaltene Adresse
    (Welche Adresse dies ist, kannst du mit einem Disk-Monitor rausfinden, wenn es dich interessiert)
    LOAD"FOO",8 lädt an den BASIC-Start IIRC

    Und wenn das nicht genau genug ist, muss man doch ins KERNAL-ROM schauen :)
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Dann schau mal unter BLOAD oobdoo hat die den falschen Befehl geschikt. DLOAD läd immer zum Basicanfang und Bload an die gespeicherte Adresse bzw. wenn man ,P Adresse Eingibt dann dahin.

    Wem es beim Bit zählen schwindelig wird, der hat zuviel davon.

    Alt werden ist schön, das Altern nicht.

  • Danke, aber jetzt stehe ich dann echt auf dem Schlauch...
    die Hardware ist schon lange weg und so dachte ich mir für de C16, nimmste Yape 0.74.
    Okay, das Spiel was ich mal anschauen wollte ist "Tom".
    Kann ich super als Tape anbinden. Das Spiel läuft auch. Aber nun wird's lustig: Obwohl angebliches Basic 3.5 scheint das DLOAD nicht zu kennen!
    Vielleicht ist das eher was für die Gemeinde der virtuellen Antiquierten, kann das mal wer ausprobieren auf der Plastikbox?
    TheRyk, angeblich ist aber vom Basic des C16 her DLOAD = LOAD... oh bitte nicht. Kein ROM-Listing, oh möge mir das erspart bleiben....
    Eine einfache Lösung brauche ich! :thumbup:

  • 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.

  • Danke Mike, das ist mega logisch. Dieses Problem hatte ich vor mehr als 30 Jahren, da ich nur eine Datasette hatte, als Teeny. Insofern kam mir die Diskette nicht in den Kopf und kannte den Mechanismus nicht.
    Aber nun die Masterfrage und die mag lächerlich sein: Wie gaukel ich dem System vor, das Tape wäre eine Diskette? Wie wird aus einer *.tap Datei etwas adressierbares? :|

  • 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. ^^

  • Dann schau mal unter BLOAD oobdoo hat die den falschen Befehl geschikt. DLOAD läd immer zum Basicanfang und Bload an die gespeicherte Adresse bzw. wenn man ,P Adresse Eingibt dann dahin.

    BLOAD ist aber BASIC 7.0 = C128 wenn ich das richtig sehe. ;)
    Außerdem sind die Parameter DLOAD und BLOAD eh die gleichen.

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wäre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom:

  • Außerdem sind die Parameter DLOAD und BLOAD eh die gleichen.

    Nein.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Danke für die ausführliche Antwort! :thumbup:
    Aber wegen Assembler: Das "Vater unser" habe ich wesentlich schlechter drauf als
    die Befehle der 6502-Serie. Man denke an den Film "Terminator", hab ich gelacht, und du weißt bescheid! ^^

  • BLOAD ist aber BASIC 7.0 = C128 wenn ich das richtig sehe. ;) Außerdem sind die Parameter DLOAD und BLOAD eh die gleichen.

    Nein, nur die Schreibweise ist die gleiche. Mit Dload kannst du nur an den Basicstart laden und entspricht daher dem ,8. Mit Bload kannst du auch an jede belibige stelle im Ram Laden und ist eine erweterung von ,8,1.
    Die Befehle Dload und Bload sind aus dem Basic 3,5 Passt also für den C16. Für Basic 7.0 wurde der Bload Befehl noch erweitert um in jede belibige Ram Bank laden zu können, ,onb0 ist da für Rambank 0.
    Du kannst es ja mal unter Vice ausprobieren.

    Wem es beim Bit zählen schwindelig wird, der hat zuviel davon.

    Alt werden ist schön, das Altern nicht.

  • Woher weiß ich die originale Startadresse?
    Merci! Oder vielleicht sollte ich schreiben: Die erste Adresse, die beschrieben wird.

    Geht scheinbar nur über Umwege (oder?):

    - Programm normal laden und im TEDMON-Monitor die Adressen $2D/$2E angucken (= Ende des Programms) (Im BASIC: "MONITOR", dann "M 2D").

    - Programm an den BASIC-Start laden (wohl mit "XYZ",8), dann wieder Adresse gucken. Aus der Differenz der jetzigen Adresse minus $1001 (BASIC-Start), kann man die Länge in Bytes errechnen

    - Endadresse von 1. abzgl. Länge = Start

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

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • 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| )

  • Die Befehle Dload und Bload sind aus dem Basic 3,5 Passt also für den C16.

    Soso. Welches Token hat BLOAD auf dem C16?

    Du kannst es ja mal unter Vice ausprobieren.

    Eine ausgezeichnete Idee.
    :popkorn:

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Mike: Kann ich jetzt nicht alles ganz nachvollziehen, aber wird wohl stimmen :D .

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


    So wie ich das vorhin nachgelesen habe, gibt es wohl beim 264er nur L "XYZ",8 (=Originaladresse) und erst beim 128er L"XYZ",8,$$$$ :nixwiss:

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • Mike, Respekt! 8o
    Es gab auch wohl folgende Strategie, die deinem an- und ausschalten ähnelt: Da ein Hardware-Resetbutton angelötet werden konnte und man den C16 auf 64k aufrüsten konnte war es wohl easy going: Reset-Vektor umbiegen auf Kopier-Routine die ab Zeropage (glaube ich) alles hochlädt auf definierte Adresse, Speicher war satt da. Ich weiß nicht mehr, welcher Speicherbereich für die Mini-Kopierroutine der beste war. So drüber grübelnd würde ich sagen, einfach ins höhere RAM setzen, wo eh nichts reingeladen wird... kann der Loader überhaupt die Zeropage überbügeln? Ich meine schon, ich meine mich zu entsinnen, das Games nicht auf Hardwarereset reagierten, also zumindest nach Start des Games der Resetvektor beschrieben wurde!?

  • Soso. Welches Token hat BLOAD auf dem C16?


    Na, $42 $93 natürlich, $42 für "B" und $93 für LOAD. :D

    Was quasi bedeutet: BASIC 3.5 kennt zwar DLOAD (Token $F0) und LOAD (Token $93), aber kein BLOAD.

    BASIC 7.0 hat für BLOAD das Token $FE $11.

  • [...] 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. :)