Ich habe gerade festgestellt, dass das Nostalgia Relase von Defender of the Crown nicht mit S-Jiffy in der 1541 läuft.
Mit original ROM oder auch mit dem original Jifft läuft das Game ohne Probleme. Alles im single Drive Betrieb.
Könnte das mal einer gegen testen?
Hallo Besucher, der Thread wurde 6,1k mal aufgerufen und enthält 30 Antworten
letzter Beitrag von Paradroid am
Nostalgia Relase von Defender of the Crown mit S-Jiffy 1541
- InsertDisk2
- Erledigt
-
-
Wenn du CMDs "JiffyDOS" meinst, kann ich es gerne testen. Gib mir dazu bitte den Link mit der identischen Version des Spiels. Persönlich spiele ich von "Defender Of The Crown" allerdings nur die deutschsprachige Version.
-
Ich meine das von Jochen Adler alias NLQ verbesserte JiffyDOS von CMD:
S-JiffyDOS für 1541 bzw auch S-JiffyDOS für C64Die Version die ich meine ist in der Gamebase64 oder aber auch hier:
http://csdb.dk/release/?id=19181
zu finden. -
Tut mir leid, dann muss ich leider passen! NLQs "S-JiffyDOS" habe und kenne ich nicht.
-
Kein Problem, dann beschäftige dich doch mal damit, die Verbesserungen sind mal richtig gut!
Ich würde es nicht mehr gegen das "normale" Jiffy tauschen wollen. -
Hmh schade, scheint n Trackloader zu sein und ausgerechnet einer der wenigen N0S-Releases, bei denen man nicht die Option KERNAL Load hat.
-
Tja, bleibt noch die Frage wieso es nur mit S-Jiffy den Dienst verweigert.
Sonst konnte ich mit allem was ich sonst noch so habe das Game laden. -
Gerätenummer des S-Jiffy Laufwerks ist 8?
-
Gerätenummer des S-Jiffy Laufwerks ist 8?
Guter Hinweis. Der Lader verwendet Warteschleifen der folgenden Art, um auf den C64 zu warten:
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.
-
Aha, gute Detektivarbeit! Ich hatte es nur kurz im Emulator ausprobiert und dabei festgestellt, dass es nach dem Scannen bei Device# > 8 hängt, obwohl der Drivecode im richtigen Gerät landet und dort auch ausgeführt wird.
-
Das Laufwerk hat die ID 8 und verweigert nach dem Scannen unter S-Jiffy den Dienst.
Die LED blinkt auch im Takt jedoch wird offensichtlich nicht geladen. -
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.
-
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. 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?
-
Hast PN
-
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?
-
Das mit VICE würde mich auch interessieren.. geht das?
Vice mit S-Jiffi-Romimage für die 1541 zeigt die gleichen Symptome wie dein echtes Gerät, es scheint also eine Inkopatibilität vorzuliegen, möglicherweise wegen unlöblicher Romeinsprünge im Scannerteil des Loaders. Aber M.J. wird dazu später bestimmt genaueres sagen können
-
Ich habe noch versucht (S)-Jiffi Softwaremässig abzuschalten, bringt jedoch keine Änderung.
-
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:
Code- .40dd: ldx #$f0
- jsr .41ab ; ==> Listen
- ldx #$0f
- .40e4: lda $402d, x ; '- OF THE CROWN -'
- jsr $ffa8 ; OUTPUT SERIAL BYTE
- dex
- bpl .40e4
- jsr $ffae ; UNLISTEN
- ldx #$e0 ; diese Vorgehensweise hier ist haarsträubend
- jsr ,41ab ; ==> Listen
- jsr $ffae ; UNLISTEN
- Jetzt sollte der Sektorpuffer bei $400 gefüllt sein, blöderweise nicht bei S-Jiffy.
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!