Chameleon64 und JiffyDOS

Es gibt ein Problem mit JiffyDOS (JD) und PAL-C64 / PAL-C128. Der PAL-C64 läuft mit 0.985MHz, der NTSC-C64 mit 1.023MHz und die 1541 mit 1MHz. Der PAL-C64 ist also langsamer als die 1541. Das Problem ist beim Senden von IEC-Bytes von der JD-1541 zum JD-C64. Der C64 liest manchmal Bit 7 und 6 des übertragenen IEC-Bytes wenn die 1541 das Senden dieser Bits bereits beendet hat und das Bitpaar danach sendet. Somit liest der C64 ein falsches Byte, oft ist Bit7 high obwohl es low sein sollte. Oft ist ein angezeigtes Byte im Dir dadurch revers. Dieses Problem war bei der 1541U, ist bei einem PAL-C128D mit der internen 1571, beim C64DTV und bei der intern-verbundenen emulierten Chameleon-1541. Ich habe ein Programm geschrieben, mit dem man die Verzögerung auf dem IEC-Bus messen kann. Der C64 aktiviert eine Leitung des seriellen Busses, worauf die 1541/1571 reagiert und ihrerseits eine (andere) Leitung des seriellen Buses aktiviert. Leider dauert die Warteschleife in der 1541 7µs, sodass man die Verzögerung des seriellen Buse nicht direkt messen kann. Das Programm macht deshalb 10 mal 1000 Messungen und errechnet daraus die Relativverzögerung des seriellen Geräts. Das Programm ist angehängt. Ich habe folgende Messungen gemacht:

Drive - - - Relativverzögerung
echte 1541: 2.94µs
intern verbundene Chameleon-1541: 2.47µs
extern verbundene Chameleon-1541: 3.23µs

Die intern verbundene Chameleon-1541 ist 0,47µs schneller als eine echte 1541. Ich denke, dass dies die Probleme mit JiffyDOS bewirkt. Ich denke, dass eine Vergrößerung der IEC-Bus-Verzögerung um 0,47µs das Problem beheben könnte.
Die extern verbundene Chameleon64-1541 ist 0,29µs langsamer als eine echte 1541. Falls dies keine Probleme verursacht (besonders mit einem JD-NTSC-C64 und 5 seriellen Laufwerken, wobei die Chameleon-1541 die letzte in der Kette ist), dann würde ich es so lassen.
(Nebenbefund: Ich habe auch die Zeitdifferenz gemessen, die besteht, einmal wenn nur 1 1541 angeschlossen ist und zum anderen wenn die 1541 das letzte von 5 angeschlossenen Geräten der Kette ist. Der Zeitunterschied beträgt nur 0,1µs.)

Quote

>Der C64 aktiviert eine Leitung des seriellen Busses, worauf die 1541/1571 reagiert und ihrerseits eine (andere) Leitung des seriellen Buses aktiviert.

Fallende oder steigende Flanke? Warum nicht beide?

Ich habe sowohl im C64 als auch in der 1541/1571 nur fallende Flanken benutzt, also nur wenn die Leitung des IEC-Buses vom Ausgangstreiber aktiv nach 0V gezogen wird. Dies habe ich gemacht, weil ich denke, dass das aktive Ziehen nach 0V exakter ist als das passive Ziehen nach 5V durch die 1kOhm-Pullup-Widerstände. Ich befürchte, dass beim Messen der passiv steigenden Flanke die Streuung noch größer ist. Ich könnte allerdings auch noch eine Version machen, die mit steigenden Flanken arbeitet.

Quote

wo liegt denn das genaue problem? ich meine du hattest das schonmal ausgetüftelt, dass nur das bzw die letzten bits betroffen sind, die von einem byte über den bus gehen. in welcher richtung sind die falsch? falsch H falsch L oder beides?
kann man nicht im 1571D und cham1541 ROM nen Zyklus einflicken, bevor die letzten bits gesendet werden? du bist doch der patchmeister

Ich selbst habe keinen C128(D). Somit kann ich auch nichts über die Richtung sagen, außer dass ich bei einem Bekannten gesehen habe, dass Zeichen im Dir oft revers sind. Ich habe mir das 1571-intern-JiffyDOS angesehen und will es patchen (aus ldx $4b will ich ldx $004b machen). Das Problem ist, dass JiffyDOS und S-JiffyDOS nicht mit dem intern verbundenen Chameleon-1541 Laufwerk läuft.

Quote

Die steigende Flanke fände ich auch äußerst interessant - wenn Du das Programm noch so ändern könntest, dass es beide Flanken abtestet und noch in einer statischen Anzeige dazu schreibt, was denn die "Standardwerte" für einen PAL- bzw. NTSC-C64 sind, kann man das prima als Emulator-Testprogramm benutzen.

source wäre an der stelle toll.

Momentan benutzt sowohl der C64 als auch die 1541 die fallende Flanke. Wie meint ihr das genau mit der steigenden Flanke? Soll der C64 weiterhin die fallende benutzen, die 1541 aber die steigende? Oder sollen C64 und 1541 beide die steigende nehmen? Oder soll es vier Durchgänge nehmen, in denen alle Möglichkeiten benutzt werden?
Standardwerte für meinen PAL-C64 könnte ich dazuschreiben. Es wären dann aber die Werte von meinem System, das evtl. von der CIA, von der Kabellänge usw. abhängt. Präziser wäre es, wenn der Tester an seinem individuellen System einmal eine echte 1541 anschließt und dann genau an dieses System lediglich an Stelle der 1541 die Chameleon-1541 anschließt. Mangels Hardware kann ich NTSC-Werte gar nicht angeben.
Source werde ich noch angeben (ist aber eh nicht viel und kann noch bis zum Wochenende dauern).

Ich habe mal eine Version gemacht, die alle vier Möglichkeiten testet. Hier ist der Quellcode:

Der C64 ändert die Clock-Leitung, woraufhin die Floppy die Data-Leitung ändert. Leider dauert die Floppy-Clock-Abfrage-Routine 7µs. Somit kann die Antwort von der Floppy zum C64 um diese 7µs variieren, sodass es nicht möglich ist die Zeit von Aussenden des Signals bis zum Messen der Floppy-Reaktion direkt zu messen. Also macht der C64 10000 Messungen und berechnet daraus die Wahrscheinlichkeit, wie oft die Floppy geantwortet hat. Aus diesen Wahrscheinlichkeiten (, die bei 10000 Messungen auf etwa 0,01µs exakt sind,) berechnet der C64 die relative Verzögerung, also die relative Zeit vom Aussenden des C64-Signals bis zum Erhalten der Floppy-Antwort. Man kann nur die Zeit am C64 vom Aussenden bis zum Empfangen des Signals messen; es ist nicht möglich die Zeit vom Aussenden des Signals vom C64 bis zum Erhalt durch die Floppy zu messen, was aber auch nicht notwendig ist. Der erhaltene Wert ist kein absoluter Wert, sondern nur ein relativer zum Vergleich mehrerer serieller Geräte. Meine Werte sind auch im Programm angegeben. Hier meine Ergebnisse:

Aus a - c erkennt man, dass schon reale Floppys eine Differenz von 0,2µs haben. Das ist einerseits schlecht, weil man keinen absoluten Referenzwert hat, hat aber andererseits den Vorteil, dass das Timing einer Floppyemulation auch in diesem Bereich variieren kann.
Der Zeitunterschied zwischen einer einzigen angeschlossenen Floppy und fünf angeschlossenen Floppys, wobei die gemessene Floppy die erste aus Sicht des C64 ist (a und d), beträgt -0,03µs bis 0,13µs, im Schnitt 0,05µs. Das ist sehr wenig, scheint aber zu reichen um das C128D-Problem zu lösen.
Der Zeitunterschied zwischen einer einzigen angeschlossenen Floppy und fünf angeschlossenen Floppys, wobei die gemessene Floppy die letzte aus Sicht des C64 ist (a und e), beträgt 0,08µs bis 0,14µs, im Schnitt 0,11µs.
Die extern angeschlossene TC64-1541 ist etwa 0,4µs langsamer als die Vergleichs-1541-2 (a und f, e und g). Hier könnte man (evtl. ich?) prüfen, ob dies bei einem NTSC-C64 mit vier zusätzlich angeschlossenen Floppys zu Problemen führt.
Die intern angeschlossene TC64-1541 ist 0,05µs bis 0,46µs schneller als die Vergleichs-1541-2 (Durchschnitt aus a,d,e und h). Ich denke immer noch, dass dies das Problem mit JiffyDOS ist. Evtl. könnte man die steigende Flanke in C64 und in emulierter 1541 um jeweils 0,025µs verlangsamen und die fallende um jeweils um 0,2µs.
Mangels Hardware kann ich den C128D mit interner 1571 und C64DTV nicht messen. Falls jemand diese Hardware hat, würde es mich freuen, wenn er das Testprogramm mal startet und mir die Werte mitteilt, wobei wichtig wäre, dass absolut kein zusätzliche Floppy angeschlossen ist.

Quote

Ich war so frei Deiner Bitte nachzukommen.
Einmal im 64' er Modus und einmal im 128´er Modus.
Es handelt sich um einen C128 DCR

Vielen Dank, Stefan75.
Im C128 Modus stimmt irgendetwas nicht. Im Bild 9948 kommt jedesmal der gleiche Prozentwert raus, unabhängig vom Delay.
Wenn der C64 fallende Flanken erzeugt, dann ist alles sehr langsam, sodass es am PAL-C64 keine Probleme geben dürfte. Ich frage nur nochmal zur Sicherheit: Hattest du das serielle Kabel zu deinen anderen Floppys ausgesteckt? Wenn der C64 mit steigenden Flanken arbeitet, dann ist es allerdings mit 2,67µs nochmals 0,05µs schneller als meine schnellste Vergleichsfloppy. Da die Differenz nur 0,05µs ist, man aber die 1571-Routinen nur in 1µs-Schritten verlangsamen kann, muss man mal sehen, ob der Patch läuft. Auf alle Fälle nochmals vielen Dank.

Quote

äh, bei aller liebe - quellcode wäre das was vorne in den assembler gesteckt hinten dein testprogram erzeugt.
ansonsten würde ich die verzögerung in minimum und maximum cycles anzeigen, ein mittelwert ist da eher nicht so hilfreich - die extreme will man wissen.

Das geht leider nicht. Es handelt sich um ein Basic-Programm und die winzigen Maschinensprache-Teile habe ich ohne Assembler, nur mit einem Monitor geschrieben. Auch die Angabe von minimum und maximum cycles ist nicht möglich, weil der C64 nur in ganzen 1,015µs-Schritten messen kann. Wie man aus der 1571intern-Messung sieht, ist aber schon eine Differenz von 0,05µs entscheidend. Das geht halt nur über Wahrscheinlichkeit.