Posts by thierer

Eben zufällig gefunden:

https://github.com/eriks5/C128_MiSTer

Ich kenne mich da auch nicht besonders gut aus, aber wenn sonst keiner antwortet

Das rote ist m.E. nicht Drain, sondern das Gate (Drain ist das gelbe rechts davon). Wenn das Gate high ist, dann war der Eingang (das, was du mit "low" gekennzeichnet hast) wohl high, als es vom Takt gelatcht wurde.

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

Quote from berni

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

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

Quote from berni

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]

Quote from Pusti64

Unter Vice geht das halt nicht so einfach.

Ein anderes Laufwerk als "Host file system device" einrichten und dann dahin speichern bzw. kopieren?

Quote from Krill

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

Quote from Krill

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

Quote from Krill

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.

Quote from Krill

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.

Quote from Krill

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

Quote from Krill

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.

Quote from Krill

Coole Sache!

Danke!

Quote from Krill

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.

Quote from Krill

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:

• Merry Twistmas (fies bzgl. Ausstieg, weil es die Datei nochmal öffnet, dann aber nie (?) daraus liest)
• Attitude #21 Diskmag (harmlos, aber ein D81)
• Super 16
• Thir(s)ty

Quote from Krill

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

Quote from strik

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.

Quote from GI-Joe

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.

Quote from GI-Joe

Quote from thierer

(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?

Quote from GI-Joe

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

Quote from GI-Joe

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

Quote from GI-Joe

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

Quote from GI-Joe

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.

Quote from GI-Joe

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?

Quote from Krill

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.

Quote from levty

hat schon irgend jemand über den USER IO Port eine 1541 Floppy betrieben?

Ja, funktioniert einwandfrei. Das Mapping der IEC-Leitungen auf die User-I/O Pins steht in der Anleitung zum C64 Core, welchen FPGA-Pins das entspricht in sys.tcl.

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.

Quote from amigasith

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.

Quote from strik

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

Quote from Stephan Scheuer

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