Posts by thierer

    Ich bin mir nicht sicher, ob ich das Problem verstanden habe, aber ich antworte trotzdem mal :)

    Meist würde ich es bevorzugen, wenn das Fenster dabei offen bliebe.

    Settings -> Host -> Monitor -> Keep monitor open?

    Den Monitor im Terminal laufen zu lassen ist für mich keine Lösung, weil das Terminal regelmäßig von anderen VICE-Ausgaben überflutet wird.

    Das dürfte aber doch nur passieren, wenn VICE auch aus diesem Fenster gestartet wurde? Alternativ: "Enable remote monitor" auf der oben genannten Settings Seite und aus einem Terminal per telnet verbinden?


    [edit]Ist mir jetzt erst aufgefallen: Wieso "x" und nicht "g" zum Fortsetzen? Bei "e(x)it" würde ich erwarten dass der Monitor geschlossen wird?[/edit]

    Bei der Übertragung des Drivecodes wird ATN für die Taktung benutzt.

    Nein, doch nicht? Ich meine die Übertragung des ersten Drivecodes? Die wird doch über DATA getaktet (mit CLK als Datenleitung)? (Ich glaube nicht, dass es für das eigentliche Argument relevant ist, ich frage mich nur, ob wir aneinander vorbei reden?)

    KERNAL-Routinen? Eigentlich nicht. Wieso? Weil es nicht maßgeblich schneller ist? :)

    Nein :), ohne C128 kann ich das sowieso nicht beurteilen. Ich hatte nur einen kurzen Blick in die Sourcen geworfen und da tauchen in dem Umfeld eben verdächtig oft Labels mit "KERNAL" auf. Aber ja, im GET_BURST_BYTE Makro sieht man, dass alles handgemacht ist :)

    Wenn der ID-String existiert, damit weiterarbeiten, ansonsten auf Prüfsummen zurückfallen (die ja eh für andere Loader benötigt werden).

    Ja, ok, das sollte dann funktionieren. Und wenn sichergestellt ist, dass 1. der Drivecode ohne Unterbrechungen übertragen wird und 2. der Host darauf nicht sofort (bzw. erst nach einer definierten Zeit) eine Antwort erwartet, dann sollte es auch mit dem Timeout funktionieren. Das probiere ich mal aus.

    Beim C-128-Build wird im 1571- und 1581-Drivecode dann ein Fast-Serial-basiertes Protokoll benutzt, also "Burst"-Transfers.

    Das scheint aber die Kernal-Routinen zu verwenden, oder wird da die Übertragungsrate noch erhöht? Da bin ich vermutlich sowieso raus, weil ich keinen C128 im Zugriff habe. Vermutlich könnte ich mir was zusammenfaken, aber ob das den Aufwand wert ist, weiß ich noch nicht.

    Ab v186 (Scramble Infinity 1.2) gibt es aber einen ID-String, der initial ans Laufwerk gesendet wird:

    Ich habe mich im Wesentlichen aus 2 Gründen dagegen entschieden, darauf zu setzen: 1. sind m.E. wesentliche Informationen nicht enthalten (klar, könnte man ergänzen) und viel wichtiger 2. hätte ich damit (von den von mir getesteten) nur Scramble 1.2, Super 16 und Thir(s)ty unterstützt (noch nicht einmal Sonic 1.2). Die Anzahl der Releases *ohne* diesen String wird wohl auf absehbare Zeit die *mit* deutlich übersteigen. Auch unabhängig davon fände ich es schade, alles vorher einfach außen vor zu lassen (immer vorausgesetzt, dass sich der Aufwand im spezifischen Fall lohnt).

    Damit sollte ein versionsanfälliger Check auf Hash-Werte unnötig werden, und die drei Optionen sind auch die einzigen, die den Laufwerks-seitigen Code ändern.

    Das mag für das eigentliche Protokoll stimmen, aber ich denke für andere relevante Größen nicht unbedingt, wie z.B. die Länge des Drivecodes. Dessen Empfang muss ja schließlich auch simuliert werden und dafür ist es nützlich, die Länge zu kennen (speziell dieser Punkt ließe sich vermutlich auch über einen Timeout lösen). Aber m.E. stimmt es noch nicht einmal für das Protokoll: Wenn z.B. der Watchdog ausgeschaltet wird, dann wird das schon aus dem Grund passieren, dass der Host die Zeiten nicht einhalten kann. D.h. dann müssten auch die sd2iec Timeouts deaktiviert werden, damit es funktioniert. Inwieweit andere Build-Optionen (z.B. die C128 und C16 Versionen) einen Einfluss haben kann ich aktuell nicht beurteilen.


    Aus den genannten Gründen kann man den ID-String (oder auch sein Fehlen) ggfs. als *einen* Datenpunkt nehmen, aber an einer CRC-basierten Erkennung führt m.E. aktuell kein Weg vorbei. Dass die in ihrer aktuellen Form vermutlich nicht ausreichen wird, ist mir klar, nur wollte ich keinen großen Aufwand reinstecken so lange ich gar nicht weiß, welche Ausprägungen denn "in the wild" tatsächlich vorkommen.

    Coole Sache! =)

    Danke!

    Lass uns mal per PM ein paar Dinge wie [...] auskaspern, und mal Unseen anhauen, was alles zu tun wäre, damit das auch in die Mainline Einzug halten kann.

    Gerne, vielen Dank für das Angebot! Ich schlage vor, dass ich die Fragen und Anmerkungen, die ich habe (die stehen nicht alle im Code :)), mal zusammen schreibe und mich bei dir melde.

    Und letztendlich bin ich auch daran interessiert, ein paar ältere Versionen mitzusupporten, mindestens die offiziellen.

    Ich habe in meinem Post auch insofern etwas untertrieben, als ich mir schon ein paar der letzten über csdb findbaren Releases mit deinem Loader angesehen habe; konkret die folgenden, die (bei mir) alle funktionieren:

    Das sollte kein sehr großer Aufwand sein, denn so grundverschieden sind die Protokolle nicht (sondern nur inkrementell verbessert worden).

    Ich sehe das Problem auch weniger in verschiedenen Versionen des Loaders (ohne mir irgendwas vor v166 angesehen zu haben...), sondern die potentiell unterschiedlichen Konfigurationen, in denen sie ggfs. eingesetzt wurden.

    Ich habe mich der sd2iec Firmware angenommen: https://github.com/thierer/sd2iec/tree/krills_loader


    Hauptsächlich entwickelt für Scramble Infinity, Sonic scheint aber auch zu funktionieren. Für andere Releases wird aber ggfs. noch Nacharbeit notwendig sein (falls je nach Einzelfall überhaupt sinnvoll).


    Zur Umsetzung musste ich auch Anpassungen am sd2iec Unterbau vornehmen. Kann sein, dass ich da Bugs eingebaut habe. Wer also gerade seine Promotionsarbeit mit Vizawrite schreibt und auf einem sd2iec speichert, der sollte entsprechende Vorsicht walten lassen :)


    Wichtig fürs Compilieren: Damit der Loader funktioniert, muss im Config-File CONFIG_LOADER_KRILL (und ggfs. CONFIG_BUS_SILENCE_REQ für den ATN-Responder, wird fürs Laden vom eingesetzten sd2iec aber nicht benötigt) gesetzt sein (das ist auch bei den bei sd2iec enthaltenen Configs nicht der Fall).

    Zeilen 1-19: Wieso wird DATA als aktiv gelesen, obwohl es nicht gesetzt ist (und es auch keinen Grund dafür gibt)?

    Du meinst vermutlich CLOCK, nicht DATA? Das muss m.E. nichts bedeuten. Das Bild, das cbmlinetester -i direkt nach dem Start unter "own" vermittelt ist immer unvollständig. Ich kenne es nur vom xum1541, da ist es aber auch so, dass der Adapter u.U. einen Zustand steuert, der im Programm nicht ersichtlich ist. Das wird bei dem Gerätetreiber vermutlich nicht anders sein. Es stimmt erst, wenn man die Leitung einmal getoggelt hat (sieht man ja auch, dass CLOCK verschwindet, nachdem es explizit gelöscht wurde).


    Bei den anderen beiden Punkten stimme ich aber zu. Speziell müsste bei ATN auch DATA gesetzt werden.

    Ich bin etwas ratlos. Mein Verdacht ist, dass es eigentlich gar kein USB-Problem ist, sondern sich die Firmware sich aus irgendeinem Grund aufhängt und der Fehler nur in der Zoomfloppy-Version steckt und ich ihn deshalb nicht nachvollziehen kann. Ich habe aber keine Idee, was das sein könnte.


    Sorry, dass ich deshalb etwas im Nebel stochern muss.


    Probierst du bitte bei Gelegenheit mal die Firmwares aus der angehängten Datei aus? Am besten mit der "-3d012ae7" starten. Das ist die älteste, wenn es mit der auch nicht funktioniert, dann liegt es vermutlich nicht (nur) an der Firmware.

    Achso, angeschlossen ist eine 1571 mit JiffyDOS aber mit CBM-DOS gehts auch nicht.

    Das ist auch noch eine interessante Info. Eine 1541 zum alternativ Testen hast du nicht zufällig? (Es könnte sein, dass die SRQ-Leitung angesteuert wird und ich weiß nicht auswendig, was die 1571 dann macht).


    In diesem Zusammenhang könntest du auch mal ausprobieren was cbmlinetester -i macht (Bleibt es auch hängen oder funktioniert es? Reagiert DATA wenn du ATN mit den Tasten 'a'/'A' ansteuerst?)


    [Edit]Nein, das mit der 1571 hat vermutlich keinen Einfluss. Eben probiert, meiner ist es egal ob SRQ gesetzt ist oder nicht, cbmctrl status funktioniert trotzdem.[/Edit]

    [Edit 2]Gerade gesehen dass "3d012ae7" und "0589b674" identisch sind. Eine davon kannst du dir also sparen.[/Edit 2]

    Vielen Dank, das ist hilfreich.

    (Ich nehme an, eine neue Firmware hast du nicht geflasht?)

    doch, in 2020 - die Verion 8.

    Zumindest die Version die jetzt drauf ist, ist ziemlich aktuell (Oktober 2021). Hast du das dann heute doch noch geflasht?

    [XUM1541] firmware git revision is 3ef4fc0d

    Ich kann mit der gleichen Version das Problem aber auch nicht nachvollziehen. Ich muss mir das Protokoll mal genauer ansehen.


    Bei mir sieht der relevante Teil (da, wo es bei dir dann hängen bleibt), so aus:

    Hast du die Firmware selber compiliert oder ist die auch aus dem Repository? Ich hänge mal das Hexfile an, das bei mir für die entsprechende Version für die Zoomfloppy rauskommt. Ggfs. kannst du das ja auch mal testen.

    einfach das tar.gz hier heruntergeladen und entpackt. Da gibts aber nur die .99 und die .103

    Ok. Ich habe eben zur Kontrolle auch genau diese Sourcen heruntergeladen und gebaut -> funktioniert bei mir (mit einem Pro-Micro basierten Gerät, eine ZF habe ich nicht, ich glaube aber auch nicht, dass das hier einen Unterschied macht).

    hab jetzt mal das git geclont und gebaut und installiert und mein XUM1541 angequatcht mit folgendem Ergebnis:

    Nein, sorry, ich meinte schon den Befehl so eingeben, wie ich es geschrieben habe, also alles in einer Zeile. Und auch wirklich mit "cbmctrl status".

    Die Frage ist, ob es die Richtige für mein Gerät war, es gibt ja 3 Firmware-Hexfiles:

    Das Gerät kenne ich gar nicht. Wenn die ZF Firmware bisher funktioniert hat (bzw. mit .99 immer noch funktioniert) dann wird es schon passen. Zumindest ist ja wohl auch ein 32u2 MCU Mikrocontroller drauf.

    Wie auch immer - die 0.4.99.103 bekomme auch ich nicht zum Laufen - auf keinem Rechner. Das Comilieren und Installieren läuft ohne Fehler, aber das Device lässt sich nicht ansprechen.

    Hängst du bitte mal die Ausgabe von XUM1541_DEBUG=9 LIBUSB_DEBUG=9 cbmctrl status 8 mit der .103 an? (Ich nehme an, eine neue Firmware hast du nicht geflasht?)


    Wie bist du denn an die Sourcen gekommen? Aus git ausgecheckt (468084f8)? Falls ja, probierst du dann bitte mal, ob sich mit der .102 (eedaa3f1) was ändert?


    Läuft der Desktop auch unter Arch Linux?

    Ich habe in der Zwischenzeit auch noch das tatsächliche Laden von mit Ultraboot behandelten Images implementiert (entsprechende D64 Images von Diskette zu erzeugen kann aber u.U. etwas umständlich sein, siehe unten). Das Installieren von Ultraboot in ein auf dem sd2iec gemountetes Image mit "Ultraboot Maker" funktioniert auch (prinzipbedingt nur bei Images in der "D41" Variante):


    https://github.com/thierer/sd2iec/tree/more_fastloaders


    Weitere Änderungen:

    • Da ich gerade dabei war, habe ich aus nostalgischen Gründen (der Nutzen hält sich in Grenzen) auch gleich noch Unterstützung für "Hypra-Load" eingebaut.
    • Wenn kein Image gemountet ist, dann kann jetzt mit "N:" ein neues D64 Image angelegt werden: "N:TEST DISK.D64,TD" erzeugt ein neues, leeres Image im "D41" Format mit dem Dateinamen "TEST DISK.D64", dem Disklabel TEST DISK" und der Disk-ID "TD". Das funktioniert analog auch mit ".D71" und ".D81". Außerdem kann auch ein Pfad angegeben werden: "N/SUBDIR/:TEST DISK.D64,TD" legt das Image im Unterverzeichnis "SUBDIR" des aktuellen Verzeichnisses an. Falls schon ein Image mit dem entsprechenden Dateinamen existiert, dann wird dieses formatiert, so als ob es schon gemountet wäre.


    Anmerkungen:

    • Da beides doch eher Nischen-Anwendungen sind, sind beide Loader per Default in den enthaltenen Config-Dateien deaktiviert.
    • UB formatiert die Tracks >35 je nach benötigter Kapazität ggfs. mit bis zu 21 Sektoren. Das ist im D64/D41 Format nicht vorgesehen, das bei diesen Tracks immer von 17 Sektoren pro Track ausgeht. Deshalb ignorieren die mir bekannten Programme zum Einlesen von D64 die vorgeblich überzähligen Sektoren (wenn das Lesen aufgrund der unerwarteten Schreibdichte überhaupt funktioniert).

      Ich habe deshalb "nibconv" von den "nibtools" so angepasst, dass es D64-Images erzeugt, die mit den Änderungen von oben auf dem sd2iec funktionieren:

      https://github.com/thierer/nib…nstandard_extended_tracks

      Zurückschreiben von auf dem SD2IEC erzeugten UB-Images auf eine echte Diskette funktioniert mit dieser Version auch (mit der offiziellen Version nicht, falls mehr als 17 Sektoren/Track!).
    • Ich habe keines der offiziell unterstützten Boards, deshalb kann ich nur über Bande testen. Für LPC habe ich nicht einmal das SDK, deshalb kann ich nicht 100%ig einschätzen, ob es sich dafür überhaupt übersetzen lässt (falls nicht sollte das aber einfach zu korrigieren sein).
    • Da mein einziges AVR-Board, das für die Firmware leistungsfähig genug ist, einen atmega2560 hat, musste ich auch die Delay-Berechnungen bei den Fastloader-Routinen anpassen. Falls ich dabei Fehler gemacht habe, dann könnte es sein, dass andere, von mir nicht testbare Fastloader, jetzt nicht mehr funktionieren. In diesem Fall bitte ich um Info.

    Was würde der Test denn für zusätzliche Erkenntnisse bringen? Würde es nicht mehr Sinn machen, strik gleich alle Tests durchführen zu lassen, die nötig sind?

    Ich hatte mir Hinweise erhofft, wie einfach sich das Problem unter "Laborbedingungen" reproduzieren lässt. So eine richtige Vorstellung, was schief gehen könnte, habe ich nämlich noch nicht. Wenn es tatsächlich so ist, wie Pete oben schreibt, dass der Fehler nur in bestimmten speed zones auftritt, dann deutet das auf ein subtiles Timingproblem hin, weil die eigentliche SRQ-Übertragung immer mit der gleichen Geschwindigkeit läuft.


    Wenn es sich mit nibsrqtest *nicht* reproduzieren lässt, dann wird es u.U. recht aufwendig (aber natürlich nicht unmöglich) das zugrunde liegende Problem zu finden und zu analysieren. Aber du hast schon recht, das kann auch warten, bis der Chip bei strik ist.

    thierer, was denkst du? Oder würdest du den lieber haben? ;)

    Ich möchte ungern die Verantwortung für jemand anderens CIA Chip übernehmen.


    amigasith Kannst du bitte bei Gelegenheit mal ausprobieren, ob sich das Problem auch mit nibsrqtest von den nibtools reproduzieren lässt?


    Falls ja, dann ist das aber leider auch nur so halb aussagekräftig, weil dort die oben angesprochenen Änderungen an der SRQ-Kommunikation nicht nachgezogen wurden. Falls du in der Lage bist die nibtools selbst zu compilieren, dann wäre es deshalb nützlich auch diesen Stand zu testen, bei dem ich die entsprechenden Änderungen auch für nibsrqtest nachgezogen habe: https://github.com/thierer/nib…ree/srq_fix_fuer_srq_test

    Ist der Anhang vielleicht das ASSI-M für den c64. Das Programmpaket ist aus dem Jahr 1983.

    Damit habe ich es immerhin geschafft aus einem simplen 10 PRINT "HALLO": GOTO 10 etwas lauffähiges zu erzeugen ("TEST2" / "TEST2OUT" im angehängten Archiv).


    Der gleiche Versuch mit den "HILBERT" Dateien schlägt mit einem (m.E. unberechtigten) "Undefined Symbol Error" fehl.


    Außerdem habe ich noch versucht eine manuell angepasste Version der "HILBERT" Dateien mit dem ACME zu übersetzen, da kam auch etwas ausführbares raus, das Programm läuft dann aber nach Abfrage der "Tiefe" in eine Endlos-Fehlerschleife. Vielleicht habe ich da bei der Anpassung noch einen Fehler gemacht. Allerdings läuft das Basic-Programm selbst bei mir auch nicht. Es schaltet in den Grafikmodus, aber dann scheint nichts mehr zu passieren (vielleicht habe ich aber auch nur nicht lange genug gewartet).

    Files

    • bass.zip

      (95.91 kB, downloaded 5 times, last: )