Posts by Krill

    Dann ist es ja nur noch ein kleiner Schritt, um ein funktionierendes Exception-Handling für C++ umzusetzen.

    *gd&r*

    Das ist eher was in Richtung C-Style setjmp & longjmp, und ohne das Speichern und Wiederherstellen des gesamten Registersatzes. :)

    Weitere Aufräumarbeiten wie Aufrufe diverser Destruktoren gibt's ja auch nicht zu erledigen.


    Aber ja, in Quelltexten pflege ich das auch oft "Exception" zu nennen, weil es ja semantisch gar nicht so weit entfernt ist.

    Man trennt regulären Programmfluss und Fehlerbehandlung, ohne an jeder Ecke Rückgabewerte überprüfen zu müssen.

    Eine gängige Praxis ist, auf der obersten Ebene vor beliebig tief verschachtelten Unterroutinenaufrufen den Stackpointer zu speichern (TSX : STX SPBUFFER) und dann bei Abbruch in einer beliebigen Unterroutinenebene den Stackpointer wiederherzustellen und zur obersten Ebene nach dem JSR zurückzuspringen.


    In etwa so:

    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.

    Ist eine Theorie, die bisher von den Beobachtungen konsistent untermauert wurde.


    Die Diskette habe ich nicht im persönlichen Zugriff, und sie wurde ja schon sauber überformatiert, sonst hätte ich schon längst genauer raufgeguckt. :) (Aber am ehesten mit einem nativen Tool wie dem "GCR Format Editor" von Maverick/Renegade.)

    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.

    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?

    Transwarp wegen Befangenheit mal ausgenommen (kam übrigens 2020 erstmalig raus), würd ich sonst aber auch keine Innovation des Jahres 2021 als am innovativsten auf ein Siegerpodest stellen wollen. :)


    Persönlich aber tendiere ich dazu, moderne Hardware-Neuentwicklungen und dergleichen zwar nett und brauchbar zu finden, am meisten aber beeindrucken mich dann Innovationen in Software, auf der Originalhardware der 80er Jahre selbst.


    Da wären dann wohl Freespin (vom Spezial-Drahtverhau mal abgesehen) und Sonic (vom Spiel an sich mal abgesehen) am nächsten dran.


    Bei Transwarp, so technisch toll das auch ist, ist der größte Knackpunkt aktuell, dass man die Disk Images am PC "vorkonfektionieren" muss. Das Trübt das ganze dann schon ein wenig für den Alltagsgebrauch. Aber mal sehen was da noch so kommt in der Richtung.

    Wo genau ist der Unterschied, ob man eine Datei eines Diskimages nun im Standard- oder Transwarp-Format rauftut bzw. auf dem echten System speichert? :)

    Da geht's ja nicht darum, das Arbeiten auf dem C-64 selbst zu beschleunigen (vom Start eines Programms und etwas Nachgelade abgesehen), sondern eben Dinge einmal zu speichern und deutlich öfter schnellzuladen.


    Transwarp soll als Schnelllader künftig bei Superfluid integriert werden, ist dann also per Modul verfügbar. Aber ob das ootb annähernd so schnell sein kann wie speziell präparierte Disks?

    Man wird dann ja weiterhin im Standard-Format oder im Transwarp-Format speichern können. Das Ganze soll ein Ersatz für Action Replays Fastload+Warp*25-Kombination werden, nur eben schneller.

    Was den noch zu erfindenden Standard-Format-Fastloader für Cartridge-Benutzung angeht, so erwarte/erhoffe ich eine Geschwindigkeit von um die 30x. (Eine Standalone-Benutzung ohne Cartridge sollte möglich sein.)

    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).

    Das ist kein Problem, eine neue Diskette ist mit dem SC in wenigen Minuten geschrieben.

    Sehr schön! :) (Gibt es einen besonderen Grund für die sehr altschulige Lösung 486+X1541+SC? Meine Go-To-Lösung ist Warpcopy über RRnet. =D)


    Hier ist jedenfalls ein Testimage.


    Das Programm lädt einfach nur 2 Bilder (gepackt und ungepackt) endlos im Kreis, in dieser Inkarnation von der vermuteten problematischen dichtesten Dichtezone der Spuren 1 bis 17.

    Mit VICE/emulierten 1541 dürfte es keine Probleme geben, da kann man sehen, wie es gemeint ist.

    Während Tastendruck wird die Konsole gezeigt und pausiert, mit Shift oder Shift-Lock wird die Konsole gezeigt und normal weitergeladen.


    Also Frage ist erst mal, ob da auf den "Problemlaufwerken" auch Probleme auftreten. Also Hängenbleiber, Abstürze, Grafikfehler (der komprimierte Bitsalat im unteren Bildbereich beim Laden von gepackten Dateien, der dann mit guten Bitmapdaten überschrieben wird, ist normal) usw.

    Das Laufwerk knackt.

    Hmmhmm, ok *notier*. =)

    So ein einzelnes Knacken durch nen kleinen Spurwechsel, richtig? Vielleicht noch ein, zwei weitere, aber kein Rattern?


    Die restliche Software, die ich laufen lasse scheint etwas resilientere Loader zu verwenden, die mit meinen Laufwerken weniger Probleme machen. Das ist dann okay.

    "Resilient" ist glaube nicht ganz das passende Wort, aber ich weiß, was Du meinst. :)

    Blöderweise ist das bei dieser alten Technik mit beweglichen Teilen immer so eine Gratwanderung zwischen Kompatibilität und Performance.

    Aber ich bin immer hinterher, echte Laufwerke bestmöglich zu unterstützen, wenn ich von Problemen erfahre.


    Insofern, könntest Du mir etwas helfen und ab und zu mal Test-Images ausprobieren und mir sagen, was passiert? Dasselbe gilt auch für Pyramidenkopf und alle, die Ladeprobleme mit Scramble Infinity (1.2) oder Sonic auf echten 1541/II haben. :)

    Ich hatte mich gewundert, dass das nicht als Transwarp-Release rauskam.

    Entweder hast Du so viele tolle Loader erfunden, dass alle mal dran kommen *g*

    Oder es gibt ein anderes Argument gegen TW - Platz auf der Floppy? Entwickler wollten keine Bildschirm-Abschaltung? Platz im RAM?


    Ist eine meiner Vermutungen richtig oder zumindest nahe dran? :)

    Habe nicht nachgefragt, aber ich vermute, das hat mit Kompatibilität zu tun.


    Transwarp unterstützt nur 1541 und 1571, der IRQ-Loader dagegen auch noch zusätzlich 1581/CMD FD/HD und bei eingeschalteter KERNAL-Fallback-Option (die irgendwie nie jemand anknippst) SD2IEC, IDE64, IEEE788-Laufwerke und sonstige exotische Hardware, die Dateien laden kann (dann allerdings je nach Gerät verschieden eingeschränkt, was Laden im Hintergrund und mit Sprites angeht).


    Ansonsten würde es nur bei Sonic Sinn bringen, Scramble Infinity dagegen lädt ja im Hintergrund während des Spiels nach (und das Startprogramm ist zu klein, als dass sich das mit Transwarp lohnen würde).


    Eigentlich sollte es aber gehen, per Transwarp alle Sonic-Dateien nach dem Start in die REU zu laden (vielleicht von 3 Diskseiten dann).

    Finde nicht sehr wahrscheinlich, dass da was falsch geladen wird. Das ist ja vorschriftsmäßig prüfsummenbewehrt, und bei wackligen Laufwerken dürfte dann die Ladegeschwindigkeit durch viele Neuversuche ziemlich weit einbrechen, während ab und zu Blöcke reintröpfeln (die dann auch mit geringer Wahrscheinlichkeit eine falsch-positive passende Prüfsumme haben können).


    Die Prüfsummen greifen nicht beim seriellen Bus, aber über den wird ja auch der Spielcode geladen, und abstürzen tut es ja nicht.