Hallo Besucher, der Thread wurde 1,1k mal aufgerufen und enthält 5 Antworten

letzter Beitrag von Mike am

skurrile Fehlersituation - kein blinkender Cursor nach Load

    Ich wollte ein spezielles Format Programm für die 1541 (21st Century Floppy Disk Formatter) testen, welches ich mit cbmwrite und xum1541 auf eine Floppy kopiert habe. Dieses einfache Programm lies sich zwar mit meinem C128 laden (load "21stc*",8), aber nach loadding ready kam das Cursor blinking nicht wieder zurück. Wie kann so etwas sein?

    Zur Eingrenzung des Problems habe ich den C128 durch einen C64 ausgetauscht, sowie auch die 1541 mit einer 1571. Der Fehler trat nur bei der Verwendung des C128 auf, egal ob 1541 oder 1571. Der C128 kann ansonsten andere Programme normal laden. Wenn beim cbmwrite irgend etwas falsch gelaufen ist (inkonsistente Datei/Sektor Verlinkung), warum tritt das Problem nur beim C128 auf und warum gibt es keine Fehlermeldung vom CBM DOS der 1541/71?

    Update: Das Programm lässt sich im C64 Modus des C128 laden, aber nicht im C128 Modus. Verstehe ich nicht. Mir ist klar das ein C64 Programm nicht (immer) im C128 Modus läuft, aber dass schon das Laden (ohne die Option ,1 !!!) zu Problemen führt, war mir nicht bewusst. Bei Programmen, die mit load "*",8,1 geladen werden, ist mir die Sache klar, da hier das Programm an eine spezielle RAM Adresse geladen wird, was bei C64/C128 zu Inkompatibilitäten führen kann.

    Zitat von frank128

    Mir ist klar das ein C64 Programm nicht (immer) im C128 Modus läuft, aber dass schon das Laden (ohne die Option ,1 !!!) zu Problemen führt, war mir nicht bewusst.

    Nach dem Laden an den Basicstart werden die Programmzeilen automatisch neu verlinkt, denn das Programm könnte ja an einer anderen Adresse gestanden haben, als es gespeichert wurde.

    Überlange Zeilen bzw. eine andere Verletzung der "normalen" Basic-Kodierung könnten dann der Grund für den Aufhänger sein.

    Wenn man das Programm nach dem Laden auflistet, sieht man einen klassischen BASIC-Stub:


    2015 SYS2059


    Nun haben die Jungs von Singular den Stub nicht ganz konform verkürzt, der 0-Linkpointer am Ende ist durch ein LDY #0 ersetzt worden. Dem Relinker auf dem C64 reicht es aus, daß das Highbyte des Linkpointers 0 ist, der Relinker vom C128 hängt sich daran auf.


    ...


    Ansonsten fällt für mich der Versuch ein Programm mit so einem BASIC-Stub, welches klar nur für den C64 gedacht ist, auf einem C128 laden und starten zu wollen, ganz klar unter die Kategorie "Mißbräuchliche Verwendung". Es hätte auch dann nicht auf dem C128 funktioniert, wenn der BASIC-Stub sauber implementiert worden wäre. In dem Bereich, den der SYS-Befehl anspringt, befindet sich beim C128 der Runtime-Stack. Es nützt auch nichts, den SYS-Befehl auf die äquivalente Adresse nach 7168 umzubiegen, an die das Programm auf dem C128 mit ",8" geladen wird, da 65xx-Code im allgemeinen nicht relokatibel ist. Selbst wenn das jetzt doch noch gegeben wäre, ist noch fraglich, ob das Programm mit der anderen Speicherstruktur des C128 zurechtkäme, etc. pp.

    Zitat von Mike

    Ansonsten fällt für mich der Versuch ein Programm mit so einem BASIC-Stub, welches klar nur für den C64 gedacht ist, auf einem C128 laden und starten zu wollen, ganz klar unter die Kategorie "Mißbräuchliche Verwendung".

    Wenn es beim Starten des Programms im 128 Mode Probleme gegeben hätte, hätte ich hier sicher keinen Thread eröffnet.


    Danke für die Erklärung, wieder etwas gelernt. :)

    frank128: Bei so skurrilen Sachen, wo es in einem Fall läuft und im anderen Fall unerwartetes Verhalten zeigt (jetzt mal ganz egal wegen C64 <-> C128) ist meine Vorgehensweise typischerweise, das Teil dort zu laden, wo es geht und dann einen scharfen Blick mit einem Monitor in den Speicher zu werfen. Beziehungsweise, die Sache durchaus auch erstmal im Emulator nachzuvollziehen, bevor man die Schuld auf die Übertragungsmethode oder die Hardware schiebt. VICE ist sicher schneller hochgefahren, als diverse Hardware aufgebaut und umgestöpselt. ;)


    Gerade bei BASIC-Stubs wird häufig genug Schindluder getrieben. Entweder die diskutierte, verkürzte Variante (super, spart 2 Bytes! Spart es denn auch einen ganzen Block auf der Disk?) oder das 0-Byte bei $0800 "kommt auch noch mit", wodurch man das Programm mit ",8,1" laden *muß* ... :aerger: ..., obwohl es eigentlich mit dem BASIC-Stub extra dazu vorbereitet worden ist, daß es - die richtige Ladeadresse von $0801 vorausgesetzt - mit ",8" geladen werden könnte und ein einfaches RUN zum Starten ausreicht!