Ich habe mal wieder das JiffyDOS-Bit-Timing analysiert.
Die GIF-Dateien musste ich packen, damit sie beim Hochladen nicht automatisch komprimiert wurden.
Die GIF-Dateien muss man ausdrucken. Die Computer-Ausdrucke muss man direkt am rechten Textende abschneiden. Dann kann man sie passend an die 1541-Ausdrucke anlegen und sich das Timing ansehen.
Die TIF-Dateien sind solche Anlagerungen.
JiffyDOS-Bit-Timing
-
NLQ -
23. März 2018 um 23:00 -
Erledigt
Es gibt 12 Antworten in diesem Thema, welches 3.179 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Hier ist das JiffyDOS-IECOUT-Bittiming zwischen C64 und 1541.
Das IECOUT-Bittiming ist in Bezug auf die Busverzögerung unproblematisch, da nur der C64 (und nicht auch die 1541) das Startflag und die Datenbits sendet. Wenn die Signale auf dem IEC-Bus beispielsweise 1µs benötigen, dann kommt das Startsignal zwar 1µs später bei der Floppy an, die Datenbits aber genauso 1µs später, sodass sich die Buslaufzeit, Busverzögerung ausgleicht.
Das Timing passt sehr gut, bei NTSC/PAL und bei early/late. -
Hier ist das JiffyDOS-IECIN-Bittiming zwischen C64 und 1541.
Das IECIN-Bittiming ist in Bezug auf die Busverzögerung kompliziert, da der C64 das Startflag, die 1541 jedoch die Datenbits sendet. Wenn die Signale auf dem IEC-Bus beispielsweise 1µs benötigen, dann kommt das Startsignal 1µs später bei der Floppy an und die Datenbit nochmal 1µs später beim C64 an. Diese Busverzögerung ist von einigen Faktoren abhängig, beispielsweise Floppy, Anzahl der Floppys...
Diese Busverzögerung ist in den Ausdrucken nicht enthalten.
Bei PAL-early erkennt man, dass der C64 die Datenbits7&6 liest (fbe9), wenn die Floppy bereits das EOI-Flag sendet (ffdb).
Das Timing stimmt nur, weil es die Busverzögerung gibt. -
Hier ist das JiffyDOS-LOAD-Bittiming zwischen C64 und 1541.
Das LOAD-Bittiming ist in Bezug auf die Busverzögerung kompliziert, da der C64 das Startflag, die 1541 jedoch die Datenbits sendet. Wenn die Signale auf dem IEC-Bus beispielsweise 1µs benötigen, dann kommt das Startsignal 1µs später bei der Floppy an und die Datenbit nochmal 1µs später beim C64 an. Diese Busverzögerung ist von einigen Faktoren abhängig, beispielsweise Floppy, Anzahl der Floppys...
Diese Busverzögerung ist in den Ausdrucken nicht enthalten.
Bei PAL-early erkennt man, dass der C64 die Datenbits7&6 liest (fb71), wenn die Floppy bereits das EOI-Flag sendet (ffdb).
Das Timing stimmt nur, weil es die Busverzögerung gibt. -
Hier ist das JiffyDOS-IECOUT-Bittiming zwischen PLUS4 und 1541.
Das IECOUT-Bittiming ist in Bezug auf die Busverzögerung unproblematisch, da nur der C64 (und nicht auch die 1541) das Startflag und die Datenbits sendet. Wenn die Signale auf dem IEC-Bus beispielsweise 1µs benötigen, dann kommt das Startsignal zwar 1µs später bei der Floppy an, die Datenbits aber genauso 1µs später, sodass sich die Buslaufzeit, Busverzögerung ausgleicht.
Das Timing passt sehr gut, bei NTSC/PAL und bei early/late. -
Hier ist das JiffyDOS-IECIN-Bittiming zwischen PLUS4 und 1541.
Das IECIN-Bittiming ist in Bezug auf die Busverzögerung kompliziert, da der PLUS4 das Startflag, die 1541 jedoch die Datenbits sendet. Wenn die Signale auf dem IEC-Bus beispielsweise 1µs benötigen, dann kommt das Startsignal 1µs später bei der Floppy an und die Datenbit nochmal 1µs später beim PLUS4 an. Diese Busverzögerung ist von einigen Faktoren abhängig, beispielsweise Floppy, Anzahl der Floppys...
Diese Busverzögerung ist in den Ausdrucken nicht enthalten. -
Hier ist das JiffyDOS-LOAD-Bittiming zwischen PLUS4 und 1541.
Das LOAD-Bittiming ist in Bezug auf die Busverzögerung kompliziert, da der PLUS4 das Startflag, die 1541 jedoch die Datenbits sendet. Wenn die Signale auf dem IEC-Bus beispielsweise 1µs benötigen, dann kommt das Startsignal 1µs später bei der Floppy an und die Datenbit nochmal 1µs später beim PLUS4 an. Diese Busverzögerung ist von einigen Faktoren abhängig, beispielsweise Floppy, Anzahl der Floppys...
Diese Busverzögerung ist in den Ausdrucken nicht enthalten. -
Danke für diese ausführliche Analyse!
Schade, daß für IECIN kein erweitertes Handshaking implementiert wurde - also: C64 oder +4 stoßen das Byte schon noch an (durch physikalisches Runter- und Hochziehen einer Leitung, DATA oder CLK), das Timing kommt aber von der 1541 (Antwort ebenfalls durch Runter- und Hochziehen und danach arbeiten CLK und DATA wieder als 2-Bit-Parallelbus). Dann wäre das Protokoll zwar etwas langsamer geworden, dafür aber noch robuster.
Note to myself: bei den TED-Maschinen wird die CPU auf beständig niedrige Taktfrequenz geschaltet. Sonst wäre das Timing wohl abenteuerlich ...

-
Zitat
Schade, daß für IECIN kein erweitertes Handshaking implementiert wurde - also: C64 oder +4 stoßen das Byte schon noch an (durch physikalisches Runter- und Hochziehen einer Leitung, DATA oder CLK), das Timing kommt aber von der 1541 (Antwort ebenfalls durch Runter- und Hochziehen und danach arbeiten CLK und DATA wieder als 2-Bit-Parallelbus). Dann wäre das Protokoll zwar etwas langsamer geworden, dafür aber noch robuster.
Der C64 muss zuerst berechnen, ob die Zeit zur Übertragung eines Bytes bis zur nächsten Badline reicht. Da ist nicht viel Zeit. Ich denke, dass erweitertes Handshake zu zeitintensiv wäre.
ZitatNote to myself: bei den TED-Maschinen wird die CPU auf beständig niedrige Taktfrequenz geschaltet. Sonst wäre das Timing wohl abenteuerlich ...

Das denke ich auch.
-
Wie bereits erwähnt ist das theoretische Bus-Timing mit einem PAL-C64 bei C64-IECIN und bei LOAD so, dass Datenbits zur falschen Zeit gelesen werden. Es funktioniert nur weil es die Busverzögerung gibt. Die absolute Busverzögerung kann man nicht mit einem C64-Programm messen, allerdings die relative. Mit dieser relativen Busverzögerung kann man Laufwerke vergleichen und einem Wert ermitteln ab dem es Probleme gibt.
Ich habe die mit IEC-BUS-DELAY3 bisher ermittelten Werte sortiert:Code
Alles anzeigengekippte Bytes: z.B. reverse Zeichen bei @$ (Bit6 = low statt high) sortiert C64=fall C64=stei C64=fall C64=stei fallend: 5V -> 0V I -> A 41=fall 41=fall 41=stei 41=stei steigend: 0V -> 5V A -> I 2,58µs 2,57µs 2,60µs 2,60µs 1541U1 V1.5,1.6 2,49µs 2,64µs 2,68µs 2,83µs TC64 beta-8c internal (Kabel unklar) 3,04µs 2,64µs 3,07µs 2,67µs C128DCR gekippte Bytes ----------------- 3,07µs 2,67µs 3,09µs 2,69µs C128DCR fehlerfreie Bytes 2,75µs 2,72µs 2,77µs 2,74µs 1571extern 1. von 1 seriellen Geräten 2,74µs 2,72µs 2,76µs 2,75µs 1541U1 V1.2,1.3 2,78µs 2,77µs 2,80µs 2,80µs 1541U1 V1.61,1.7b,1.71b,1.72b,2.0- 2,81µs 2,81µs 2,83µs 2,83µs TC64 beta-8d- internal ohne IEC-Kabel 2,86µs 2,83µs 2,89µs 2,86µs 1541-2 1. von 1 seriellen Geräten 2,99µs 2,85µs 2,97µs 2,83µs 1541-2 1. von 5 seriellen Geräten 3,00µs 2,94µs 3,01µs 2,94µs 1541-2 5. von 5 seriellen Geräten 2,97µs 2,94µs 3,01µs 2,98µs 1541alt 1. von 1 seriellen Geräten 3,06µs 3,11µs 3,42µs 3,47µs TC64 beta-8d- internal mit IEC-Kabel 3,24µs 3,24µs 3,27µs 3,27µs TC64 beta-8d- 1. von 1 seriellen Geräten 3,27µs 3,27µs 3,28µs 3,27µs TC64 beta-8c 1. von 1 seriellen Geräten 3,38µs 3,29µs 3,38µs 3,29µs TC64 beta-8c 5. von 5 seriellen Geräten 3,49µs 3,49µs 3,48µs 3,48µs TC64 beta-8d- 5. von 5 seriellen GerätenProbleme bei IECIN wegen des Bus-Delays gibt es bei:
- C128DCR
Bitte melde dich an, um diesen Link zu sehen.
Läuft problemlos seit dem 1541intern-JiffyDOS-Patch
- 1541U
Läuft problemlos seit V1,61
- Turbo Chameleon 64
Bitte melde dich an, um diesen Link zu sehen.
- Läuft problemlos seit Beta-8d
-C64DTV
Bitte melde dich an, um diesen Link zu sehen.
- Läuft problemlos mit C64DTV-JiffyDOS-Kernal-PatchFalls jemand eine C64DTV hat und darauf das Programm IEC-BUS-DELAY3 ausführen kann (nur die emulierte interne 1541 angeschlossen), dann würden mich die ermittelten Werte interessieren.
Ebenso hätte ich Interesse an den Werten mit einer UK1541.
Mit einer realen Floppy ist eine steigende C64-Flanke schneller als eine fallende (beim C128DCR sogar 0,4µs).
Die steigende Floppy-Flanke (einer realen Floppy) ist (fast immer) langsamer als eine fallende (beim C128DCR 0,03µs)Der Fehler beim JiffyDOS IEC-IN macht sich beispielsweise im Directory mit @$ bemerkbar: Buchstaben werden revers dargestellt.
Der PAL-C64 / PAL-C128 hat 0,98MHz und ist somit langsamer als eine Floppy.
Bei C64-IECIN startet der C64 das Übertragen eines Bytes mit einer steigenden (physikalischen) Flanke (0V -> 5V) (fbcb), sodass in der Tabelle oben die 2. und die 4. Spalte entscheidend ist. Aus der zweiten Spalte erkennt man, dass ein relativer Busverzögerungswert von 2,64µs zu Problemen führt, während ein relativer Busverzögerungswert von 2,67µs keine Probleme verursacht.
(Kleine) Buchstaben haben ASCII-Werte von $40-5f. Ein (kleines) a hat den ASCII-Wert 65 = $41 = %01000001. Der C128DCR liest bei IECIN Bit7&6 ein, wenn die 1571 bereits die EOI-Bits sendet. Dieses EOI-Bitpaar ist %10. Dieses %10 wird anstelle von %01...... gelesen, sodass aus %01000001 %00000001 wird, was dem entsprechenden reversen Zeichen entspricht.
Auf den ersten Blick merkwürdig ist, dass Bit6 low statt high gelesen wird, Bit7 jedoch korrekt als low, und das obwohl beim EOI-Bitpaar Bit7 high ist. Bei C64-IECIN startet der C64 die Übertragung eines Bytes mit einer steigenden (physikalischen) Flanke (0V -> 5V) (fbcb). Somit sind in der Tabelle oben die 2. und die 4. Spalte entscheidend. Hier sieht man, dass die fallende 1541-Flanke mit 2,64µs schneller ist als die steigende mit 2,67µs. Somit wird bei Bit7, eine (langsamere) steigende Flanke, gerade noch der alte, korrekte Datenbitpaarwert gelesen, während bei Bit6, eine (schnellere) fallende Flanke, bereits der neue, falsche EOI-Bitpaarwert gelesen wird.
Große Buchstaben haben ASCII-Werte %110....., welche genauso zu %100..... werden, sodass auch diese revers dargestellt werden.
Satzzeichen und Zahlen haben ASCII-Werte %001....., also Bit6 ist sowieso low, sodass diese immer korrekt dargestellt werden.C64-IECIN ist fehlerhaft, LOAD nicht
C64-IECIN und LOAD benutzen in der 1541 die gleiche Routine und im C64 verschiedene Routinen, die allerdings exakt das gleiche Timing haben. Bei beiden ist in der 1541 und im C64/C128 der Abstand von Datenbitpaar7&6 zum EOI-Bitpaar 11µs. Trotzdem gibt es bei C64-IECIN Probleme, bei LOAD nicht. Bei LOAD werden 253 Bytes eines Blocks innerhalb einer Schleife übertragen, in der die 1541 Datenbitpaar7&6 33µs hält, also viel länger als die 11µs am Schleifenende, sodass es innerhalb der Schleife nie Probleme geben kann. Das 254. Byte am Schleifenende wird bei LOAD aber genauso kurz gehalten wie bei C64-IECIN (11µs). Somit müsste es bei jedem 254. Byte bei LOAD zu den gleichen fehlerhaften Bytes kommen wie bei C64-IECIN, was aber nicht der Fall ist. Der Grund ist, dass bei C64-IECIN der C64 das Übertragen eines Bytes mit einer steigenden (Data-) Flanke startet (fbcb), während es bei LOAD eine fallende (Data-) Flanke ist (fb51). Wenn man die C64-IECIN-Tabellen (die 1. und 3. Spalte) mit denen für LOAD (die 2. und 4. Spalte) vergleicht, dann sieht man, dass das Timing bei LOAD (fallende C128DCR-Flanke) 0,4s langsamer sit als bei C64-IECIN (steigende C128DCR-Flanke), was erklärt, warum bei Load das Timing passt. -
Hier die Messergebnisse vom Ultimate 64, Firmware 3.2a:
Emulierte Floppy:
Bitte melde dich an, um diesen Anhang zu sehen.
Echte 1541 II extern angeschlossen:
Bitte melde dich an, um diesen Anhang zu sehen.
-
Zitat
Hier die Messergebnisse vom Ultimate 64, Firmware 3.2a:
Das sind aber sehr schnelle Werte. Hast du schon mal unter JiffyDOS den @$-Befehl getestet. Wenn meine Analyse stimmt, dann müsste dies gekippte Bytes ergeben.
-
Völlig korrekt. Jiffydos funktioniert mit der Firmware auch nicht zuverlässig. Bugreport liegt Gideon vor (wenngleich nicht von mir).
Tipps für Gideon zur Abhilfe sind nattürlich willkommen - eigentlich ging es hier jedoch darum, die sehr schnellen Werte mal dokumentiert zu haben.