Beiträge von M. J. im Thema „Nostalgia Relase von Defender of the Crown mit S-Jiffy 1541“

    Nimm mal an du hast 20 Files, die im jeweils letzten Sektor nur 1 Byte belegen, dann hast du 20*253 = 5060 Bytes verschwendet, wenn du die auf herkömmliche Art speicherst. Diese IFFL-Dinger quetschen das üblicherweise so in ein File zusammen, dass bis auf den letzten Sektor alles voll ausgenutzt wird. Ok, n paar Byte gehen dann wieder dafür drauf, wo in welchem Sektor man was von welchem File findet, aber u.U. macht das schon Sinn.

    Schon klar. ^^ "Die drei Musketiere" funktioniert auch nach diesem Prinzip, sonst hätten die Daten nicht auf drei Disketten gepaßt. Im konkreten Fall liegt aber bereits eine große 577 Sektoren lange Datei vor. Es ging mir darum, zwecks schnellem Zugriff und ohne Scanner diese direkt ohne Dateisystem in Diskettensektoren abzulegen. Wozu IFFL, wenn man es viel einfacher haben kann? Das Dateisystem ist eh nicht das beste, besonders das sequentielle Lesen drückt die Geschwindigkeit. Bei einem direkten Sektorenlesen könnte man zumindest einen partiellen Trackloader verwenden. Dabei wird ein gefundener Sektor überprüft, ob er zur Datei gehört, und falls ja übertragen. Dadurch erhält man gleich drei große Vorteile: 1.) Das Lesen wird massiv beschleunigt. 2.) Man benötigt kein spezielles Interleave mehr. 3.) Der Lader paßt sich dynamisch an die Ladegeschwindigkeit des C64 an. Werden dort z. B. umfangreiche Aktionen im IRQ abgewickelt, wird die Ladegeschwindigkeit nur minimal verzögert und bricht nicht gleich komplett ein.

    Und es ist mit nem Filecopier kopierbar1elf

    Öhm. nein. ^^ Mit einem normalen Filekopierer ist die Diskette auch schon nicht mehr kopierbar, weil der Verzeichnistrack angeknabbert wurde.

    Hintergrund der ganzen Aktion ist meine Idee dies hier zu realisieren:

    IFFL und Jiffy schließen sich (soweit ich weiß) aus. IFFL benötigt beschleunigten Zugriff auf einzelne Sektoren der Diskette. Die LOAD-Routine von Jiffy kommt hierbei nicht zum Einsatz. Wenn überhaupt, müßte in Jiffy ebenfalls eine beschleunigte Version von Block-Read eingebaut sein, das wäre dann aber nicht mehr kompatibel zu anderen Systemen. Kurz gesagt: Geht nicht.

    Alle Games sollen, um den max speed zu erhalten, (s)-jiffy gesaved sein.

    Und hier hätten wir das nächste Problem. Ich gehe mal davon aus, daß S-Jiffy zur Beschleunigung des Ladevorgangs einen speziell angepaßten Interleave einsetzt. Da aber die Version von "Defender of the Crown" nicht auf S-Jiffy zurückgreift, sondern einen eigenen Lader verwendet zusammen mit Musikroutinen im IRQ, könnte dies dazu führen, daß der Sektorenabstand zu kurz ist für den Lader und die Sektoren nicht mehr wie gewollt direkt nacheinander gefunden werden. Stattdessen müßte die Leseroutine eine ganze Rotation warten, um den nächsten Sektor aufzuspüren, was drastische Einbußen bei der Ladegeschwindigkeit zur Folge hätte.
    Das gleiche passiert übrigens auch, wenn die Sektorenaufteilung einer IFFL-Diskette an den eingebauten Lader angepaßt wurde, aber dann bei einem simplen Filekopierer dieses Interleave nicht mitkopiert wird. Auch dann geht die Ladegeschwindigkeit ruckzuck flöten. Auf realer Hardware reicht es eben nicht aus, nur die Daten an sich zu kopieren, sondern auch das Aufzeichnungssystem muß mit übernommen werden, und das gelingt nur mit einem Diskettenkopierer. Filekopieren lohnt sich eigentlich nur bei moderner(er) Hardware, aber nicht bei der 1541.

    Zusammengefaßt: Wie man es dreht und wendet, steht man beim C64 am Ende immer vor dem gleichen Dilemma:
    Entweder
    a) entwickelt man Programme so, daß sie mit Kernal-Load laden und dadurch mit gewisser moderner Hardware kompatibel sind. aber verzichtet dabei während des Ladens auf IRQs etc
    oder
    b) man verwendet schnelle Lader, die kompatibel sind mit der Originalhardware und gleichzeitig IRQs erlauben etc, aber dafür mit gewisser moderner Hardware nicht zusammenspielen.
    Leider ist dieser Konflikt nicht einfach bzw. billig zu lösen. Wofür man sich letztendlich entscheidet, ist Geschmackssache. Mich erstaunt in dieser Hinsicht allerdings schon, daß große Teile der Retroszene wiederholt für die Verwendung dieser gewissen modernen Hardware plädieren, aber in anderen Hardwarefragen (bzgl. CPU, RAM, SID...) immer gerne davon sprechen, daß dies dann nicht mehr C64-like sei. :gruebel

    Naja, der Vorteil an diesem "Dateigerümpel" ist ja u.a., dass es keine nur teilweise genutzen Sektoren mehr gibt, sonst hätte das vmtl. nicht auf eine Seite gepasst.

    Äh.. Sorry.. Das habe ich nicht ganz verstanden. :nixwiss: Läßt man das Dateisystem weg. ändert man ja an der inneren Dateistruktur nichts. :gruebel Im Gegenteil werden durch Weglassen der Sektorenlink-Bytes sogar ganze 577 * 2 = 1154 Bytes, also mehr als ein ganzes KB eingespart. (Wow! :D ) Und paßt man den Sektor-Interleave an die Ladergeschwindigkeit an, erhält man auch recht brauchbare Diskettenzugriffszeiten.

    also Platz ist Prinzip genug da. :)

    Na denn, Freiwillige vor. ^^

    Hast du zufällig irgendwas Easyflashartiges am C64 angeschlossen?

    Das wäre dann wohl die bessere Lösung. :dafuer:

    Cool Danke!, ist das irgendwie zu patchen?

    Leider nicht mit vertretbarem Aufwand. Das Problem ist wie folgt:
    1.) Meine Vermutung geht dahin, daß der falsch geladene Datensektor die Anfänge der Ladeabschnitte enthält, die den Originaldateien entsprechen, welche zu einer großen Datei zusammengefaßt worden sind. Dieser Sektor ist essentiell für den Scannvorgang. Die Frage ist daher: Wie bekommt man ihn sicher in den Laufwerkspuffer bei $400?
    2.) Dazu gibt es zwei Möglichkeiten: a) Man lädt mittels Block-Read diesen Sektor direkt in den Puffer. b) Man überträgt diesen Sektor zusammen mit dem Scanner vom Programm aus ins Laufwerk. (Das hätte eigentlich die erste Wahl sein müssen. Warum das nicht gemacht wurde? Keine Ahnung.)
    3.) Sofern man dem Diskettenverzeichnis vertrauen kann, ist die Diskette bereits überbelegt (666 Sektoren), d. h. es wurden schon Sektoren der Verzeichnisspur (Track 18) herangezogen. Trotzdem sollte sich dort noch ein freier Sektor vorfinden, in dem man die Daten für einen B-R (U1) ablegen kann. Das würde jedoch mit dem von Nostalgia gewählten Prinzip brechen, daß die Dateien an sich auf jedem Laufwerk abspielbar sein sollen und der Datenträger folglich keine versteckten Sektoren aufweisen darf. Ansonsten könnte man genauso gut auf das ganze Dateigerümpel verzichten und gleich einen vernünftigen Schnelllader einbauen. Dann bräuchte man auch keinen Scanner mehr. (Wäre meine persönliche Wahl gewesen.)
    4.) Bliebe dann nur die zweite Möglichkeit: Das Ladeprogramm muß so gepatcht werden, daß es am Ende neu hinzugefügt den Sektor beinhaltet, der dann mit dem Scanner ins Laufwerk geladen wird. Auch hierfür müßte ein (noch hoffentlich freier) Sektor im Verzeichnistrack herangezogen werden, diesmal jedoch eingebunden in einer Datei und damit übertragbar.
    Das wäre vielleicht machbar, aber der Aufwand ist recht hoch.

    Hmh schade, scheint n Trackloader zu sein und ausgerechnet einer der wenigen N0S-Releases, bei denen man nicht die Option KERNAL Load hat.

    Das liegt daran, daß Kernal-Lader nun einmal keine IRQs erlauben, also keine Musik, Splitscreens etc. (Nebenbei: Der Unterschied zwischen einem Trackloader und einem Sektorloader besteht darin, daß bei einem Trackloader nicht nur ein einzelner Sektor übertragen wird, sondern gleich der ganze Track. Dieses Verfahren gibt es hardwarebedingt standardmäßig auf dem Amiga. Auf dem C64 findet man es nur sehr selten, da hierfür ein entsprechend großer freier Platz (21 Sektoren = $1500 Bytes) zur Aufnahme des Tracks im Arbeitsspeicher des C64 bereitgestellt werden muß. "Most Access" von Oliver Stiller ist solch ein Fall.)

    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

    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.

    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.

    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?

    Gerätenummer des S-Jiffy Laufwerks ist 8?

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

    Code
    ldx	#$00
    		stx	$1800
    warte:		ldx	$1800
    		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.