Jiffydos für Plus4

Es gibt 131 Antworten in diesem Thema, welches 37.439 mal aufgerufen wurde. Der letzte Beitrag (12. Mai 2021 um 12:12) ist von Frenetic.

  • Waren das nicht eher 10% für PAL und fast 15% für NTSC?

    Wobei man hier nicht vergessen darf, das beim 264er der Takt nicht stabil ist sondern wechselt. Wenn der Bildschirm angezeigt wird sind es Quarzfreuenz/20 (bei PAL) und wenn der Rahmen angezeigt wird (abzüglich der 5 Refreshzyklen pro Zeile) sind es Quarz/10 (PAL). Man kann TED auch dazu bringen die CPU immer mit Quarz/20 zu takten, aber dann verschenkt man einiges an Geschwindigkeit.

    Wie behandelt JiffyDOS den wechselnden Takt?

  • Wobei man hier nicht vergessen darf, das beim 264er der Takt nicht stabil ist sondern wechselt. Wenn der Bildschirm angezeigt wird sind es Quarzfreuenz/20 (bei PAL) und wenn der Rahmen angezeigt wird (abzüglich der 5 Refreshzyklen pro Zeile) sind es Quarz/10 (PAL). Man kann TED auch dazu bringen die CPU immer mit Quarz/20 zu takten, aber dann verschenkt man einiges an Geschwindigkeit.
    Wie behandelt JiffyDOS den wechselnden Takt?

    JiffyDOS schaltet den Takt während der Übertragung auf Quarz/20 damit er konstant bleibt.

  • Dann läuft die CPU mit 886 kHz statt beim C64 mit 985 kHz, das ist ein Unterschied von mehr als 10%.

    Vom Ausgangstreiber her sind der IEC-Bus des C16 und des C64 identisch, ein 7406 mit 1 kOhm Pullups. Allerdings wird beim C16 eine Leitung auch noch für die Datasette benutzt was bei angeschlossener Datasette diese Leitung stark verlängert. Hast du eine angeschlossen? Wenn ja, teste mal ohne.

    BTW: Benutzt JiffyDOS eigentlich den BIT-Befehl zum Einlesen der Daten? Von der Belegung des CPU-Ports her würde er sich wegen seiner Eigenheit Bit 6 und Bit 7 direkt in die CPU-Flags zu transferieren wirklich gut eignen.

  • Dann läuft die CPU mit 886 kHz statt beim C64 mit 985 kHz, das ist ein Unterschied von mehr als 10%.

    Vom Ausgangstreiber her sind der IEC-Bus des C16 und des C64 identisch, ein 7406 mit 1 kOhm Pullups. Allerdings wird beim C16 eine Leitung auch noch für die Datasette benutzt was bei angeschlossener Datasette diese Leitung stark verlängert. Hast du eine angeschlossen? Wenn ja, teste mal ohne.

    BTW: Benutzt JiffyDOS eigentlich den BIT-Befehl zum Einlesen der Daten? Von der Belegung des CPU-Ports her würde er sich wegen seiner Eigenheit Bit 6 und Bit 7 direkt in die CPU-Flags zu transferieren wirklich gut eignen.

    Zum Zugriff auf CLOCK IN (bit 7 von $0001) und DATA in (bit 6 von $0001) wird sowohl der BIT Befehl, als auch LDA und EOR benutzt.
    Siehe anhängender Assembler Code.

    Laut TED System Hardware Manual ist die PAL Quarzfrequenz 17.734475 MHz +/- 70 ppm
    Geteilt durch 20 ergibt das 0.887 MHz. Damit kann der JiffyDOS Code eigentlich nicht funktionieren, wenn die Floppylaufwerke mit 1 MHz arbeiten.
    Irgendwo gibt es da noch entweder eine falsche oder fehlende Information um das ganze schlüssig zu erklären.

    Ein Cassetten Laufwerk habe ich übrigens nie angeschlossen, von daher können keine Seiteneffekte kommen.

  • Laut TED System Hardware Manual ist die PAL Quarzfrequenz 17.734475 MHz +/- 70 ppm
    Geteilt durch 20 ergibt das 0.887 MHz. Damit kann der JiffyDOS Code eigentlich nicht funktionieren, wenn die Floppylaufwerke mit 1 MHz arbeiten.

    In der 1541 läuft der 6502 mit 1 MHz, in der 1551 der 6510T hingegen mit 2 MHz. Aber die benutzt ja einen eigenen Port und nicht den im 8501.

    Bei einem NTSC-C16 ist der Quarz 14,318 MHz und die Teilerfaktoren müssten 8 und 16 sein. Damit ergäbe sich ein einfacher Takt von 895 kHz.

    Im Listing oben sehe ich den Opcode AD nicht korrekt übersetzt. Ist das Absicht? Und warum wurde da LDA $0001 und nicht LDA $01 (A5) benutzt? Timing?

    Nachtrag: Unterscheidet JiffyDOS zwischen PAL und NTSC?

  • Im Listing oben sehe ich den Opcode AD nicht korrekt übersetzt. Ist das Absicht? Und warum wurde da LDA $0001 und nicht LDA $01 (A5) benutzt? Timing?
    Nachtrag: Unterscheidet JiffyDOS zwischen PAL und NTSC?

    Wenn ich den Befehl als "LDA R7501" schreibe, macht der Assembler daraus einen 2-Byte Befehl mit 3 Zyklen.
    Das Jiffy Protokoll braucht aber hier einen Befehl mit 4 Zyklen. Deshalb habe ich den Befehl als Bytefolge
    geschrieben (AD 01 00) statt LDA R7501 ode LDA $0001 um die automatische Assembler-Optimierung
    auszuschalten. Ich könnte natürlich auch den Assembler ändern und ein Feature hinzufügen, dass einen
    die 16 Bit Adressierung erzwingen lässt, aber das schien mir für diesen einzelnen Sonderfall nicht notwendig
    zu sein. Die JiffyDOS Routinen für NTSC und PAL unterscheiden sich nicht. Es sind nur deshalb zwei
    verschiedene ROM Images weil die Byte-Tabellen für die TED Initialisierung auch das PAL/NTSC Bit enthalten.

  • Das könnte also schon einen Unterschied machen da ein NTSC-System einen Tick schneller ist als ein PAL-System.

    Das ist korrekt. Jetzt brauchen wir wahrscheinlich das Code-Gegenstück aus einem Laufwerk,
    um beurteilen zu können mit welchen Toleranzen das Jiffy Protokoll arbeitet. Wenn die bisherigen
    Frequenzüberlegungen stimmen, muss es ja sogar den 10%igen Unterschied zwischen C64 und PLUS/4
    verkraften können. Da der entsprechende Jiffy-Quellcode eines Laufwerks wohl nicht aufzutreiben ist,
    muss ich den wohl selbst erstellen, seufz. (oder kennt jemand eine Quelle ?)

  • Wenn die bisherigen
    Frequenzüberlegungen stimmen, muss es ja sogar den 10%igen Unterschied zwischen C64 und PLUS/4
    verkraften können.

    Ich hab eben das Oszi angeworfen und das hat einen Frequenzzähler... Auf Single-Clock geschaltet läuft ein PAL-C16 mit 886,73 kHz. Ohne Single-Clock werden etwas über 1,2 MHz angezeigt.

  • Ich hab eben das Oszi angeworfen und das hat einen Frequenzzähler... Auf Single-Clock geschaltet läuft ein PAL-C16 mit 886,73 kHz. Ohne Single-Clock werden etwas über 1,2 MHz angezeigt.

    Ja, das passt perfekt. Weiter oben hatte ich ja die gerundete Frequenz 887 kHz genannt.
    Jetzt bin ich noch mehr auf den Jiffy-Code im Laufwerk gespannt.

  • Da der entsprechende Jiffy-Quellcode eines Laufwerks wohl nicht aufzutreiben ist,
    muss ich den wohl selbst erstellen, seufz. (oder kennt jemand eine Quelle ?)

    NLQ hat Codeausschnitte der Transferroutinen auf seiner Bitte melde dich an, um diesen Link zu sehen.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ich habe mir mal das JiffyDOS-Bit-Timing angesehen:
    Bitte melde dich an, um diesen Link zu sehen.
    Auf den ersten Blick finde ich es ok.
    Vielleicht könnte mal jemand das angehängte Programm ausführen und mir das Ergebnisfile mailen?

  • Ich habe mir mal das JiffyDOS-Bit-Timing angesehen:
    Bitte melde dich an, um diesen Link zu sehen.
    Auf den ersten Blick finde ich es ok.
    Vielleicht könnte mal jemand das angehängte Programm ausführen und mir das Ergebnisfile mailen?


    Ich habe aus gegebenem Anlass und nach einem Anstupser von Bitte melde dich an, um diesen Link zu sehen. :zeig: das Programm mal laufen lassen. Ich packe das Ergebnis als ZIP in den Anhang. Ich finde es klasse wie du dich mit Jiffy auseinandersetzt. :thumbup:

  • Ich habe aus gegebenem Anlass und nach einem Anstupser von Bitte melde dich an, um diesen Link zu sehen. :zeig: das Programm mal laufen lassen. Ich packe das Ergebnis als ZIP in den Anhang. Ich finde es klasse wie du dich mit Jiffy auseinandersetzt. :thumbup:

    Ich denke, dass du keine Probleme mit deinem System hast. Ich vermute, dass du am Ende des Programms
    ERRORS: 0
    ...
    NO ERROR
    erhalten hast.
    Dies bedeutet, dass alle Bytes fehlerfrei empfangen wurden und es somit nichts zu analysieren gibt. Ganz wichtig ist, dass das Programm jemand ausführt der
    - einen PLUS4
    - eine JiffyDOS-1541 (keine 1551)
    - Probleme mit diesem System beim IEC-IN
    hat. Vielen Dank an dich fürs Testen.

  • Heute so gekommen per DHL: Ein Plus/4... Jetzt, wo ich also die Gelegenheit habe, Dein Testprogramm auszuführen, bin ich gerne bereit, mit Resultaten zu dienen:

    In der Datei 1541ii.d64 ist mein erster Versuch mit einer 1541 II am Plus/4 enthalten.

    Danach wollte ich einen Versuch mit meiner 1571 am Plus/4 machen. Jedoch gab es dabei immer recht früh ein Device not present error als Resultat einer fehlerhaften Übertragung - meistens bereits beim Fehlerkanalauslesen. Manchmal passiert der Fehleraber auch erst beim Speichern der Ergebnisse.
    Jetzt aber: Schalte ich die 1571 in den 1571 Modus per "@u0>m1", so läuft der Test fehlerfrei durch.

    Nun denn, die so angelegte Testdatei "iec-in-testfile" habe ich dann nochmal meiner 1541 II vorgelegt (genauer: die ganze Diskette, wo die drauf ist) und so die 1541ii2.d64 erhalten. Es sollte sich zeigen, dass beide "iec-in-testfile" verschieden sind.

    So weit ich weiß, hat Bitte melde dich an, um diesen Link zu sehen. mit einem SD2IEC getestet. Das mag es begründen.

    NLQ: Von einem Durchlauf, wo die 1571 mal etwas weiter kam, habe ich ein MP4-Video angefertigt - wenn Du es brauchen kannst. Eine Ergebnisdatei zu speichern hat ja nicht geklappt.


    Nachtrag: In den beiden Floppies war und ist Dein (NLQs) aktuelles Jiffydos drin, die ich mit Bobbel gerade teste.

  • Zitat

    In der Datei 1541ii.d64 ist mein erster Versuch mit einer 1541 II am Plus/4 enthalten.

    Ich glaube die Sache wird noch komplizierter: Das IECIN-TEST-FILE wurde falsch erstellt. Es enthält vier #$00-Bytes, die nie vom C64 ins File geschrieben wurden. Dies müsste eigentlich bedeuten, dass der PRINTBitte melde dich an, um diesen Link zu sehen. auch fehlerhaft ist. Beim Auslesen des (falschen) Files mit GET# gab es keine Fehler.

    Zitat

    Danach wollte ich einen Versuch mit meiner 1571 am Plus/4 machen. Jedoch gab es dabei immer recht früh ein Device not present error als Resultat einer fehlerhaften Übertragung - meistens bereits beim Fehlerkanalauslesen. Manchmal passiert der Fehleraber auch erst beim Speichern der Ergebnisse.

    Merkwürdig; die 1571 hat die selben IEC-Routinen wie die 1541 und schaltet dabei auf 1MHz um. Allerdings ist meine 1571 auch etwas schneller als meine 1541.
    Bitte melde dich an, um diesen Link zu sehen.

    Zitat

    Jetzt aber: Schalte ich die 1571 in den 1571 Modus per "@u0>m1", so läuft der Test fehlerfrei durch.

    Bei einer JiffyDOS-1571 schaltest der Befehl @u0>m1 auf die CBM-IEC-Bus-Routinen um.

    Zitat

    Nun denn, die so angelegte Testdatei "iec-in-testfile" habe ich dann nochmal meiner 1541 II vorgelegt (genauer: die ganze Diskette, wo die drauf ist) und so die 1541ii2.d64 erhalten. Es sollte sich zeigen, dass beide "iec-in-testfile" verschieden sind.

    Das File ist korrekt. Die Fehler werden etwas genauer angezeigt: Der Fehler entsteht beim Senden der Sekundäadresse-nach-Talk. Davor ist das Statusbyte ok (0), danach ist es gesetzt (3). Ich muss mal schauen, ob dies bei der Analyse weiter hilft.
    Nachtrag: Merkwürdig; mir fällt gerade ein, dass die Befehlbytes, also auch Sekundäradresse-nach-Talk, im CBM-Modus über den IEC-Bus übertragen werden. Somit sollte der Fehler weniger im JiffyDOS-Bit-Timing liegen???

    Zitat

    So weit ich weiß, hat Bitte melde dich an, um diesen Link zu sehen. mit einem SD2IEC getestet. Das mag es begründen.

    Bestimmt; Bobbel hatte mir dies auch schon per E-Mail mitgeteilt.

    Zitat

    NLQ: Von einem Durchlauf, wo die 1571 mal etwas weiter kam, habe ich ein MP4-Video angefertigt - wenn Du es brauchen kannst. Eine Ergebnisdatei zu speichern hat ja nicht geklappt.

    Ja, würde mich mal interssieren. Meine E-Mail-Adresse ist NLQ@gmx.de

    Zitat

    Nachtrag: In den beiden Floppies war und ist Dein (NLQs) aktuelles Jiffydos drin, die ich mit Bobbel gerade teste.

    Prima; die IEC-Routinen sind 100% identisch zum Original-JiffyDOS.

  • Ich bin mir noch nicht sicher, ob folgendes hilft:

    Ich habe gerade meinen Plus/4 mit der 1541 Ultimate II+ via seriellen Kabel verbunden und dort tauchen die Probleme genauso auf.

    Nun ist es weniger bekannt, aber im Quelltext der 1541 Ultimate II+ existiert ein normalerweise deaktivierter Logic-Analyzer - der gänzlich undokumentier tist und alle Signale auf dem IEC-Bus einmal pro Takt aufzeichnet zur Analyse (bei welchen Takt ist unbekannt, die Ultimate hat ja auf mehrere Takte Zugriff). Wenn die Vermutung bestehen sollte, dass uns eine solche Busaufzeichnung weiterhelfen könnte, würde ich mir eine passende Firmware bauen.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Von mir auch noch ein File mit Protokolldateien. Dieses Mal habe ich auch ein JD Plus4 mt einer JD 1541-II benutzt. Bei jedem Ausführen des Testprogramms sind Fehler aufgetreten.

  • Ich glaube die Sache wird noch komplizierter: Das IECIN-TEST-FILE wurde falsch erstellt. Es enthält vier #$00-Bytes, die nie vom C64 ins File geschrieben wurden. Dies müsste eigentlich bedeuten, dass der PRINTBitte melde dich an, um diesen Link zu sehen. auch fehlerhaft ist. Beim Auslesen des (falschen) Files mit GET# gab es keine Fehler.

    Per Vergleich mit meinem zweiten IECIN-TEST-FILE, welches NLQ als korrekt erstellt klassifiziert habe, stelle ich fest, dass jene Datei bei Dir (Bobbel) auch fehlerhaft erstellt worden ist... Somit ist bestätigt, dass jene Datei öfter mal falsch erstellt wird.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.