Hello, Guest the thread was called2.7k times and contains 57 replays

last post from thierer at the

Scramble Inifnity/Sonic auf verschiedener Hardware (OT aus Scramble Infinity)

  • Schade. Mittlerweile glaube ich zwar nicht mehr, dass es was mit dem Steppen zu tun hat, aber dennoch:

    Neues Image an selber Stelle, mit superlangsamem Spurwechsel.

    Als Loader-Laie mal gefragt - kann es denn eventuell etwas damit zutun haben, wie der Floppykopf positioniert ist beim Laufwerk von "root42"? Also dass dies nicht ideal ist, normale Loader da aber noch funktionieren und speziellere (oder sehr schnelle) dann Probleme bekommen?


    Sollte man nicht zumindest testweise, mal ein Floppyhead Justierprogramm durchlaufen lassen auf diesem Floppy und sehen was passiert, oder bist du der Meinung, das bringt eh nichts?

  • Leider Satz mit X.

    Schade. Mittlerweile glaube ich zwar nicht mehr, dass es was mit dem Steppen zu tun hat, aber dennoch:

    Neues Image an selber Stelle, mit superlangsamem Spurwechsel.

    Ne, gleiches Ergebnis.


  • Als Loader-Laie mal gefragt - kann es denn eventuell etwas damit zutun haben, wie der Floppykopf positioniert ist beim Laufwerk von "root42"? Also dass dies nicht ideal ist, normale Loader da aber noch funktionieren und speziellere (oder sehr schnelle) dann Probleme bekommen?


    Sollte man nicht zumindest testweise, mal ein Floppyhead Justierprogramm durchlaufen lassen auf diesem Floppy und sehen was passiert, oder bist du der Meinung, das bringt eh nichts?

    Anders als bei der Datasette ist die Kopf-Justage beim Disklaufwerk eine eher digitale Angelegenheit.

    Aus Programmsicht kann man den Kopf via Schrittmotor nur diskrete Schritte machen lassen, und zwei davon sind eine Spur weiter.

    Die Schrittweite selbst ist fest, es wird "analog" nur die relative Positionierung zwischen den (Halb-)Spuren justiert.


    Das heißt, wenn da was verstellt ist, haben alle Loader gleichermaßen Probleme.


    Diese treten dann auch vorrangig eher beim Einlesen von Disks auf, die von anderen Laufwerken beschrieben wurden (die Formatierung ist ja "soft").


    Die Loader unterscheiden sich dann vielleicht noch in Dingen wie Fehlerdetektion und Neuversuchen/Kopf-Neupositionierung bei Fehlern, aber das zu lösende/umschiffende Problem ist für alle dasselbe. :)

    (Einen größeren Unterschied macht es, wie schnell ein Loader den Kopf von Spur zu Spur bewegt. Zu schnell für ein gegebenes Laufwerk heißt dann, dass der Kopf u.U. woanders als auf der gewünschten Spur ankommt.)


    Aber es wäre durchaus mal interessant, wie sich Transwarp auf dem Laufwerk verhält. Das heißt, mit der spezifischen Laufwerkskombination von root42 - schreibendes und lesendes Laufwerk sind ja verschieden. Transwarp selbst gibt bei Problemen ein Fehlerlog aus (soundsoviele "Retries" und "Slowdowns" mit ner Liste darunter).

  • Schade. Mittlerweile glaube ich zwar nicht mehr, dass es was mit dem Steppen zu tun hat, aber dennoch:

    Neues Image an selber Stelle, mit superlangsamem Spurwechsel.

    Als Loader-Laie mal gefragt - kann es denn eventuell etwas damit zutun haben, wie der Floppykopf positioniert ist beim Laufwerk von "root42"? Also dass dies nicht ideal ist, normale Loader da aber noch funktionieren und speziellere (oder sehr schnelle) dann Probleme bekommen?


    Sollte man nicht zumindest testweise, mal ein Floppyhead Justierprogramm durchlaufen lassen auf diesem Floppy und sehen was passiert, oder bist du der Meinung, das bringt eh nichts?

    Das wäre aber imho dann auch eher ein Problem, wenn ein "verstelltes Laufwerk" Disketten von einem anderen Drive abspielen soll. Wenn es die Disk ja selber geschrieben hat, würden sich ja leichte "Verstellungen" nicht auswirken. Zumindest verstehe ich die Sache auf meinem banalen Level. Aber hier mal meine Hochachtung an Krill ausgedrückt. Was gibt's fähige Leute da draussen, einfach genial.

  • Post by war64burnout ().

    This post was deleted by the author themselves: Wurde ausgelagert, daher überflüssig. ().
  • Anders als bei der Datasette ist die Kopf-Justage beim Disklaufwerk eine eher digitale Angelegenheit.

    Aus Programmsicht kann man den Kopf via Schrittmotor nur diskrete Schritte machen lassen, und zwei davon sind eine Spur weiter.

    Die Schrittweite selbst ist fest, es wird "analog" nur die relative Positionierung zwischen den (Halb-)Spuren justiert.


    Das heißt, wenn da was verstellt ist, haben alle Loader gleichermaßen Probleme.


    Okay, verstehe.

  • Zur Auflösung: Schuld war nur der Star Commander... :-D Also der Warp Mode desselben. Der scheint nicht ganz korrekt oder zumindest unerwartet zu formatieren. Ein Slow Format auf dem C64 respektive ein Umschalten auf den Turbo Mode im Star Commander sorgt dafür, dass magischerweise alle Produktionen, die Krills Loader verwenden funktionieren. Ein fieses, sehr subtiles Problem! Danke an Krill für den Support. Das Perfide ist auch, dass andere Fastloader und "langsam" ladende Programme davon völlig unbeeindruckt waren und einfach trotzdem geladen haben. Allerdings hatte die neueste Version von Sparkle scheinbar das gleiche Problem. Sparta/GP hatte mir ein paar Testreleases geschickt und sie zeigten eine sehr ähnliche Symptomatik.

  • Mal die Ergebnisse von 2 problematischen Laufwerken von mir

    Das untere lädt anscheinend eher langsam (deutet auf Neuversuche durch Lesefehler hin), und das obere hat wohl Lesefehler, die den Prüfsummencheck überstehen.


    Habe das Image noch mal upgedatet.

    Alle Stepping-Einstellungen sind wieder normal (das war ja nicht das Problem bei root42), und es wird jetzt ein Verify gemacht, also jede Datei zweimal geladen und verglichen, ob die Daten identisch sind.


    Wie sieht es damit aus?


    Und was OpenCBM angeht: "The drive routine was taken from the Star Commander ((C) Joe Forster/STA) and highly improved." (cbmformat), aber auch "To date cbmforng should be considered as the more reliable formatter of both; whenever you should encounter any difficulties with cbmformat, go for cbmforng."

    Macht cbmformat vs cbmforng einen Unterschied?

  • Das Perfide ist auch, dass andere Fastloader und "langsam" ladende Programme davon völlig unbeeindruckt waren und einfach trotzdem geladen haben.

    Das hängt womöglich damit zusammen, wie Sektoren gefunden werden.


    Die Originalroutinen laden spezifische Blöcke (Spur x, Sektor y) und bauen sich eine Vergleichsmaske für den Blockheader. Nach jedem vorbeirollenden Sync wird GCR-Byte für GCR-Byte geguckt, ob der Blockheader mit dem gesuchten übereinstimmt, und beim ersten Unterschied wird zurück zum Sync-Warten gesprungen.


    Die schnelleren IRQ-Loader laden Blöcke in der Reihenfolge, wie sie vorbeigerollt kommen, statt spezifisch Block für Block zu laden. Da wird dann nach jedem Sync geguckt, ob es ein Blockheader ist, und wenn ja, dieser erst mal eingelesen, decodiert und überprüft usw., um dann zu entscheiden, ob die Daten geladen werden oder auf den nächsten Block gewartet werden soll.


    Das Problem mit dem schnellen SC-Formatter ist wohl, dass Fragmente des Diskinhalts von vor dem Formatieren zwischen letztem und erstem Block einer Spur übrigbleiben.

    Da können dann also zusätzliche Syncs auftauchen mit ungültigen Blockheadern und sonstwas.

    Der traditionelle ROM-Ansatz ist da robuster und kann das leichter wegturnen, während der letztere Ansatz eine gewisse "Blindzeit" nach jedem Blockheader hat (in der "echte" Syncs usw. überlesen werden), die aber bei sauber formatierten Disketten unproblematisch ist.

    Ich kann mir aber vorstellen, dass der traditionelle Ansatz sich auch unter bestimmten Umständen an Restdaten verschlucken kann, aber mit geringerer Wahrscheinlichkeit als der neuartige.

  • Das Problem mit dem schnellen SC-Formatter ist wohl, dass Fragmente des Diskinhalts von vor dem Formatieren zwischen letztem und erstem Block einer Spur übrigbleiben.

    Ist das eine Theorie oder eine Erkenntnis?. Falls Theorie, dann müsste sich die ja mit einem Nibble-Image der problematischen Diskette überprüfen und ggfs. reproduzieren lassen.