Jiffydos für Plus4

Schön zu sehen das sich noch jemand mit dem Thema beschäftigt.

Ich denke, ich werde zumindest durch die Analyse des Mitschnittes rausbekommen, ob der Plus 4 die Sachen falsch sendet. Wenn nicht, bleibt ja nur noch übrig, dass er sich beim Empfangen vertut.

Keine Ahnung, ob es was bringt, jedoch habe ich keinen Mittschnitt von einer 1581... Und wenn ich meine Analysesoftware fertig habe, würde es sich ja anbieten, die auch auf einen solchen Mittschnitt laufen zu lassen. Nur um nichts zu übersehen. Könntest Du einen beisteuern - Details zu bekämst Du natürlich?

Edit: Sollte idealerweise auch von einer U2+ sein, damit alle Mitschnitte das selbe Format und die selbe Zeitbasis haben. Ich würde nämlich nicht daruf wetten, dass die Zeitbasis wirklich 1 µs ist und nicht C64 oder Floppy-Takte.

Okay, +4, Jiffy, 1581 und U2+ sind vorhanden. Wenn du mir sagst was ich machen muss bin ich dabei.

Die Debugfirmware werde ich hier nicht verteilen - ich denke, die schicke ich Dir zwischendurch per E-Mail.

Man nehme einen C64 oder C128 (PAL, des gleichen Timings wegen) und stecke dort die U2+ rein. Am IEC Anschluss der U2+ steckt die Floppy, die man ihrerseits mit den +4 verbindet. So ist die U2+ seriell mit dem +4 statt mit dem C64/128 verbunden.

Die Debugversion bietet im F5-Menü die Optionen "Start IEC Trace" und "Dump IEC Trace". Erstes erstet die Aufzeichnung, letzteres speichert alles seit dem Start der Aufzeichnung unter dem Namen "IECDUMP.BIN" im aktuellen Verzeichnis. Bin mir nicht sicher, ob man es muss, aber während der Aufzeichnung ist es zumindest nicht verkehrt, aus dem U2+ Menü rauszugehen.

Ich denke, es ist ein guter Start, das Testprogramm von NLQ zu nehmen (ist ja weiter oben im Thread) und dessen Ausführung mitzuschneiden.

Bei mir - siehe auch oben - hat es nicht geklappt, die aufgetretenen Fehler einer 1571 mit dem Testprogramm von NLQ zu speichern - in dem Fall würde ich sagen, wir wollen die Spalte, die das erwartete Byte und das empfangene Byte zeigt, haben... sind die beiden letzten Zahlenwerte der Zeilen beim Lauf von den Zeilen, wo die ersten Werte nicht alle Null sind.

Ich hoffe nämlich, weiß es aber nicht sicher, damit die Stellen im Mitschnitt wiederzufinden. Das ginge, falls ich den Jiffydos-Protokolldekoder hinbekomme. Ansonsten muss ich damit auskommen, nur die TALK/LISTEN zu haben. Da dort der Fehler vermutet wird, würde das ggf. auch reichen, erschwert aber die Analyse. Das gelesene Byte gibt schließlich Auskunft, wo man im Lauf gerade schaut.

PS: Den CBM-Dos-Protokolldecoder habe ich zu 50% fertig - es fehlt noch der Teil, der nicht unter ATN läuft und die Prüfung der Zeitabstände. Letzteres ist entbehrlich, wenn man nur die Daten dekodieren will - die meisten Teile des Protokolls sind nämlich von der Zeitbasis her unkritisch, wenn man mal von Timeouts absieht und dass eine Hardwareimplementierung natürlich genug Zeit haben muss, die Werte zu sehen - das beim Mitschnitt beides ja kein Problem darstellt.

Edit: Die interne Floppy der U2+ darf abgeschaltet werden, wenn man Geräteadressenkonflikte vermeiden muss. Ist aber nicht notwendig, die darf unter einer anderen Gerätenummer auch gerne laufen. Hauptsache, die Fehler treten auf.

Zitat von markusC64

Ich würde nämlich nicht daruf wetten, dass die Zeitbasis wirklich 1 µs ist und nicht C64 oder Floppy-Takte.

Ich nehme an, dass das bereits Teil des Problems ist. Der C16/+4 hat doch einen anderen Basistakt als der C64, und das Laufwerk wieder einen anderen. Und wenn man von "PAL hat 50 Hz" und "der Videochip erzeugt soundsoviele Zeilen mit soundsovielen Zyklen" ausgeht, hat man immer noch einen Rechenfehler drin, weil die PAL-Videochips ja nicht exakt 50 Hz ausgeben.

Als Berechnungsgrundlage bei der Fehlersuche würde ich daher direkt die verbauten Quarze hernehmen.

Da hast Du Recht. Aber zumindest bei dem Teil, der unter ATN läuft, sind die Toleranzen sehr groß. Sogar so groß, dass Jiffydos eine extra lange Pause zwischen Bit 6 und 7 einlegen kann, ohne das original CBM Protokoll zu stören. Das ist eine Tatsache, die mich dazu bringt, dass die Zeitbasis des Captures nicht ganz so entscheidend ist.

Wenn es beim TALK aber einen Fehler gibt, wäre es wichtig zu wissen, ob der fehlerfrei raus geht... Jener Teil muss die Zeitschranken aus http://www.zimmers.net/anonftp…rogramming/serial-bus.pdf einhalten - und wenn es dabei knapp wird, hat man einen weiteren Anhaltspunkt, was schief geht.

Aber wenn der selbe Code meistens den TALK erfolgreich losschickt und manchmal nicht, dann muss man entweder die C264-Reihe perfekt kennen (damit kann ich nicht dienen) oder man sieht das Symptom an den geseheten Daten... die müssen dann - wenn es ein Problem beim Senden ist - ja anders aussehen als bei den Fällen, die funktioniert haben.

Und selbst "Bad Lines" beim Sendecode kommt man so auf die Spünge: Da selbnige die CPU des Computers ausbremsen, sieht man dann zwischen den Signalen mehr Pausen - und kann die so indirekt beobachten...

Ich hoffe erst mal nur, so festzustellen, ob das Problem beim Senden oder beim Empfangen ist... das würde ja schon mal die Stelle erheblich einschränken, wo das Problem ist.

PS: Ich habe natürlich auch Messungen vom C64/128, damit ich bzgl. der Zeitbasis weiß, wie es sein soll. Falls mal der Vergleich benötigt wird.

Ach ja: Das wäre natürlich ein Gegencheck: Kann man am +4 ähnlich wie beim C64 (dort 53265) den Bildschirm und damit die "Bad Lines" abschalten? Sieht per Beobachtung ja so aus, Jiffydos scheint das beim LOAD ja zu machen.

Ich weiß nur nicht, welche Adresse ich dazu mit welchen Wert versorgen muss. Das wäre es ja glatt mal wert, ins Testprogramm einzubauen, um einen weiteren Fall getestet zu haben... Wenn das einen Unterschied macht, weiß man ja viel mehr als vorher. Und wenn nicht, weiß man immerhin, dass man in der Richtung nicht zu suchen braucht.

Zitat von markusC64

Kann man am +4 ähnlich wie beim C64 (dort 53265) den Bildschirm und damit die "Bad Lines" abschalten? Sieht per Beobachtung ja so aus, Jiffydos scheint das beim LOAD ja zu machen.

Der TED hat immerhin ein passendes Registerbit: Bit 4 von $ff06 ist "display enable" (abgesehen von Bit 7 stimmt $ff06 beim TED mit $d011 beim VIC-II überein).

Wichtig dürfte aber auch Bit 1 von $ff13 sein: "single clock" sorgt wohl dafür, dass die CPU nicht mehr die vom TED ungenutzten Taktzyklen bekommt, was für ein stabiles Timing ebenso wichtig sein dürfte wie das Abschalten der Badlines.

Und dann gibt es noch Bit 5 von $ff07 ("freeze"): "if set, TED stops its counters and screen-generating, only single clock and refresh cycles remain."

Ich hab leider nicht wirklich Ahnung vom C16/+4/TED und kann auch nur mit Halbwissen beitragen...

ich reaktiviere mal diesen Thread ...

habt ihr da noch weiter gemacht oder kann man mit zusätzlichen Messungen o.ä. irgendwo helfen?

Die Bad Lines hatten damals im Test nicht den Unterschied gemacht...

Möglicherweise kann man vorhandene Hardware kreativ kombieren, um das, was beim U64 der Debug Stream ist, zu bekommen... Eine emulierte 1541 vom 1541 U2+ oder U64 darf man dabei durchaus verwenden, damit (U2+) tritt der Fehler am Plus 4 auch auf.

Ja, zugegeben, für Debug Stream auswerten haben wir auch kaum Software, jedoch wenn man die Fehlersituation erst mal in Echttiming aufgezeichnet hätte, würde man vermutlich sehen, was bei den Bytes, wo der Fehler auftritt, anders läuft...

Andere Ansatzmöglichkeit: Ist schon ein bisschen her, wenn ich mich richtig erinnere., lässt sich das Problem aber eingeschränkt im VICE simulieren, nämlich indem man eine 1581 emulieren lässt... dummerweise auch nur sporadisch, aber immerhin...

Nachtrag: Interessant wäre mal, ob das, was man im VICE beobachtet, am Plus/4 auch auftritt: Das der Fehler bei einer 1581 deutlich häufiger auftritt als bei einer 1571. Wobei bei der 1571 der Fehler im VICE deutlich seltener auftritt als bei echter Hardware.

Und wozu das auch immer gut sein mag, ein Mittshnitt der seriellen Bus Leitungen per Logik Analyzer hat Vorteile, weiß die Details nicht mehr, aber leichte Unterschiede im Timing der verschiedenenen Laufwerke waren zu beobachten (SD2IEC, 1541, 1571) - 1581 in der Hinsicht unbekannt, weil ich die nicht habe.

Mir fallen noch zwei Sachen ein, mit denen man versuchen könnte das einzugrenzen:

1. Versuchsweise mal MOS8365 einbauen - also einen anderen TED (anderes Bustiming!?)

2. Frenetic hat IIRC mal einen Clockgenerator gebastelt, der von außen via I2C verändert werden kann.

Eventuell gibt es aufschluss, wenn man den Masterclock minimal erhöht/erniedrigt und vieleicht sieht

das der Fehler häufiger/seltener wird?

Just my2cents

Zitat von androSID

2. Frenetic hat IIRC mal einen Clockgenerator gebastelt, der von außen via I2C verändert werden kann.

das ist ähnlich dem, was Adrian Black hier vorstellt:

Im C64 habe ich mit dem gleichen Prinzip über- und untertaktet... und da kann man sehr weit gehen (als erstes wird es mit den Videofrequenzen Probleme geben)