Hello, Guest the thread was called3.4k times and contains 30 replays

last post from Paradroid at the

Nostalgia Relase von Defender of the Crown mit S-Jiffy 1541

  • Gerätenummer des S-Jiffy Laufwerks ist 8?

    Guter Hinweis. Der Lader verwendet Warteschleifen der folgenden Art, um auf den C64 zu warten:

    Code
    1. ldx #$00
    2. stx $1800
    3. warte: ldx $1800
    4. bne warte

    Das funktioniert nur, wenn die Gerätenummer 8 ist. Andernfalls werden im oberen Nibble von $1800 die Bits der Nummer eingeblendet, so daß die Bedingung BNE stets erfüllt ist. ==> der Lader hängt.

  • Ok, dann ist die Geräteadresse wohl nicht das Problem. Evtl ist's einer der Romeinsprünge? Der Loader nutzt u.a. $f418, $f50a, und die GCR Dekodiertabellen bei $f8a0/$f8c0, vielleicht ist da bei S-Jiffydos was an anderer Stelle.

    Hatte ich mir auch schon angesehen. ^^ Aber $f418 und $f50a sind lediglich Standardaufrufe von "Fehlerausgang" und "Hole Sektorheader", und die Dekodiertabellen werden in zahlreichen Schnellladern verwendet. Dann müßten auch die alle nicht funktionieren. Was mich irritiert ist, daß nichts geladen wird, aber trotzdem die Lampe blinkt. :gruebel Entweder entspricht das Blinken nicht dem Ladeblinken sondern einem Fehlerblinken, oder es wird andauernd versucht, den gleichen Sektor zu laden.
    Meine Fragen in dieser Hinsicht wären daher:
    1.) Wird während des Blinkens der Lesekopf bewegt?
    2.) Hört das Blinken irgendwann auf? Wenn ja, was passiert dann?


    Edit: Gibt es vielleicht eine (einfache) Möglichkeit, S-Jiffy in VICE auszutesten, damit man mal den Fehler reproduzieren kann?

  • Eine erste kleine Analyse erbrachte, daß das Programm zum Warten auf den Sektor bei $61e ins Rom springt nach $f50a, von dort aber nicht zurückkehrt. Stattdessen scheint ein Fehler aufzutreten (welcher kann ich noch nicht sagen), woraufhin über die Fehlerbehandlung schließlich das Programm nach $f361 gelangt, wo der Wert in $45 abgefragt wird. Dort steht (wahrscheinlich noch von vorher) der Wert #$60, der bedeutet: Spring an den Anfang eines Puffers. $3f enthält den Wert #$02, so daß als Ergebnis (zu 2 wird noch die Konstante 3 addiert) über den indirekten Sprung bei $f379 (= $500) an den Anfang des Schnellladers zurückgesprungen wird, wodurch die ganze Schleife erneut startet.
    Da beim normalen Rom die genannten Speicherstellen dieselben Werte enthalten, wird es voraussichtlich daran liegen, daß unter S-Jiffy ein unerwarteter Fehler auftritt. Naja, man sollte aber ruhig dazu anmerken, daß der Lader selbst auch nicht ganz sicher programmiert wurde. Wenn man schon Rom-Routinen verwendet, sollte man auch darauf achten, daß diese stets ein fest definiertes Verhalten zeigen und nicht einfach irgendwohin springen und damit dem Lader die Kontrolle entziehen.

  • Letzter Stand der Dinge, bevor der Tag vorüber ist: Der ganze Bereich von $400 bis $4ff wird unter S-Jiffy nicht korrekt initialisiert, was bedeutet, daß das Scannen bereits nicht funktioniert. Eigentlich sollten hier die Informationen zu der Sektoren-Linkkette hinterlegt sein, doch unter S-Jiffy findet sich an dieser Stelle immer noch oder einfach fälschlicherweise Programmcode. Das hat zur Folge, daß der Lader anstelle der passenden Track-Sektor-Angaben für den nächsten Sektor schlicht Müll als Track/Sektor interpretiert. Für diese illegalen Sektorangaben (Sektor = $a0!) kann natürlich kein Diskettensektor gefunden werden, und das Programm hängt sich in besagter Schleife auf.
    Mögliche Ursachen: 1.) Die Scannroutinen rufen Nicht-Standard-Romroutinen auf, die fehlschlagen. 2.) Die Pufferbelegung ist unter S-Jiffy anders, so daß der Puffer bei $400 nicht wie beabsichtigt verwendet wird.


  • Meine Fragen in dieser Hinsicht wären daher:1.) Wird während des Blinkens der Lesekopf bewegt?
    2.) Hört das Blinken irgendwann auf? Wenn ja, was passiert dann?


    Edit: Gibt es vielleicht eine (einfache) Möglichkeit, S-Jiffy in VICE auszutesten, damit man mal den Fehler reproduzieren kann?

    Zu 1) (Falls noch relevant)
    Der Lesekopf bleibt stehen, im Gegensatz zu Jiffy wo er direkt nach dem Starten des Ladens einmal bewegt wird.


    Zu 2)
    Das Blinken hört nicht auf, wenn aber der Lesekopf Hebel geöffnet wird wird das Blinken schneller, ähnlich wie beim normalen Laufwerk, jedoch ohne Kopfbewegung.


    Das mit VICE würde mich auch interessieren.. geht das?

  • Zu 2) Das Blinken hört nicht auf, wenn aber der Lesekopf Hebel geöffnet wird wird das Blinken schneller, ähnlich wie beim normalen Laufwerk, jedoch ohne Kopfbewegung.

    Das läßt sich wahrscheinlich darauf zurückführen, daß bei geöffnetem Laufwerk überhaupt kein Sektorheader gefunden wird, der auf Übereinstimmung geprüft werden müßte, sondern die Sektorsuche bereits beim Warten auf die Sync aussteigt.

    Aber M.J. wird dazu später bestimmt genaueres sagen können

    Hey, keinen Druck ausüben. ^^


    Also... Weiteres Herumforschen ergab, daß der Lader etwas schlampig programmiert wurde. Der Programmteil für den Diskscanner setzt voraus, daß im Laufwerk ab der Adresse $400..$4ff bestimmte Daten vorab geladen sind. Diese Daten versucht das Programm mit folgendem Code in den Puffer zu kriegen:

    Mit diesem Verfahren wird bei einem Standardrom der Puffer bei $400 mit den Daten des Sektors gefüllt. Wichtig hierbei ist, daß das Programm nicht explizit angibt, in welchen Puffer die Daten geladen werden sollen. Stattdessen vertraut es darauf, daß es brav immer der $400-Puffer sein wird. Übel... Übel... Goldene Programmierregel: Benutzt Du Romroutinen, richte Dich gefälligst auch nach den Definitionen und mach keine falschen Mutmaßungen über irgendwelche internen Abläufe, oder anders gesagt: Respect the API. Bei S-Jiffy wird, wie vermutet, eine andere Pufferbelegungsstrategie verwendet. Der Sektor wird dadurch nicht nach $400, sondern $500 geladen. Überprüfbar ist dies mit einem "break 40f8" im VICE-Monitor.
    Case closed.


    Vielen Dank an Claude Server für die freundliche Hilfe! :bia