Jiffydos für Plus4


  • AREA51HT
  • 9398 Aufrufe 117 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Unseen schrieb:

    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?
  • Gerrit schrieb:

    Unseen schrieb:

    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?
    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.
  • Gerrit schrieb:

    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.

    Quellcode

    1. ; *******************
    2. e7db Jiffy_ACPTR ; $e7db
    3. ; *******************
    4. e7db 78 SEI
    5. e7dc 24 a6 BIT R2D2 ; test to see if the device is a JiffyDOS drive
    6. e7de 50 f6 BVC JiLO_85 ; nope, back to normal ACPTR routine
    7. e7e0 ad 13 ff LDA TED_CLOCK ; load TED register $13
    8. e7e3 85 a7 STA TPBYTE ; save register value
    9. e7e5 09 02 ORA #%0000 0010 ; set bit 2 : slow / variable CPU speed
    10. e7e7 8d 13 ff STA TED_CLOCK ; enforce slow CPU mode 0.885 MHz
    11. e7ea a5 01 JACP_10 LDA R7501
    12. e7ec c9 40 CMP #$40 ; data & clock ?
    13. e7ee 90 fa BCC JACP_10 ; wait until data (7) or clock (6) = 1
    14. e7f0 29 38 AND #%0011 1000 ; mask bits 3,4,5 (not used for IEC)
    15. e7f2 85 a8 STA BSOUR1 ; save bits 3-5
    16. e7f4 09 01 ORA #%0000 0001 ; $01 IEC DATA OUT = 1
    17. e7f6 48 PHA ; push data=1 clock=0
    18. e7f7 29 fe AND #%1111 1110 ; $fe IEC DATA OUT = 0
    19. e7f9 48 PHA ; push data=0 clock=0
    20. e7fa 38 JACP_20 SEC
    21. e7fb ad 1d ff LDA TED_VL_LO ; current raster line
    22. e7fe ed 06 ff SBC TED_VP ; minus fine scroll register
    23. e801 29 07 AND #%0000 0111 ; modulo 8
    24. e803 f0 f5 BEQ JACP_20 ; at bad line -> loop
    25. e805 c9 06 CMP #6 ; at line 6 or 7
    26. e807 b0 f1 BCS JACP_20 ; at or before bad line -> loop
    27. e809 68 PLA ; mask data=0 clock=0
    28. e80a 85 01 STA R7501 ; set data=0 clock=0
    29. e80c 48 PHA ; [3: 3] wait
    30. e80d 68 PLA ; [4: 7] wait
    31. e80e 24 a8 BIT BSOUR1 ; [3:10] clear carry and overflow flag
    32. e810 a5 01 LDA R7501 ; [3:13] get bit 0 & 1 <--- < 13 >
    33. e812 4a LSR A ; [2:15] shift right
    34. e813 4a LSR A ; [2:17] data in bit 5 & 4
    35. e814 ea NOP ; [2:19] wait
    36. e815 45 01 EOR R7501 ; [3:22] get bit 2 & 3 <--- < 22 >
    37. e817 45 a8 EOR BSOUR1 ; [3:25] combine with bits 0 & 1
    38. e819 85 f5 STA CHKSUM ; [3:28] store bits 0-3
    39. e81b ad 01 00 .BYTE $ad,$01,$00 ; [4:31] get bit 4 & 5 <--- < 31 >
    40. e81e 4a LSR A ; [2:33] shift right
    41. e81f 4a LSR A ; [2:35] data in bit 5 & 4
    42. e820 45 a8 EOR BSOUR1 ; [3:38] combine with bits 0-3
    43. e822 45 01 EOR R7501 ; [3:41] get bit 6 & 7 <--- < 41 >
    44. e824 85 a8 STA BSOUR1 ; [3:44] store result
    45. e826 68 PLA ; [4:48] mask data=1 clock=0
    46. e827 24 01 BIT R7501 ; [3:51] handshake: S=data V=clock < 51 >
    47. e829 85 01 STA R7501 ; [3:54] set data=1 clock=0
    48. e82b 08 PHP ; push flags S=data V=clock
    49. e82c a5 a7 LDA TPBYTE ;
    50. e82e 8d 13 ff STA TED_CLOCK ; Restore TED clock
    51. e831 a5 a8 LDA BSOUR1 ; combine nibbles of received byte
    52. e833 29 f0 AND #%1111 0000 ; bits 4-7 from BSOUR1
    53. e835 85 a8 STA BSOUR1
    54. e837 a5 f5 LDA CHKSUM ; bits 0-3 from CHKSUM
    55. e839 4a LSR A
    56. e83a 4a LSR A
    57. e83b 4a LSR A
    58. e83c 4a LSR A
    59. e83d 05 a8 ORA BSOUR1
    60. e83f 85 a8 STA BSOUR1 ; received byte complete
    61. e841 28 PLP ; pull flags S=data V=clock
    62. 17116,0-1 65%
    Alles anzeigen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Bit Shifter ()

  • Bit Shifter schrieb:

    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?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Gerrit ()

  • Gerrit schrieb:

    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.
  • Gerrit schrieb:

    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 ?)
  • Bit Shifter schrieb:

    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.
  • Gerrit schrieb:

    Bit Shifter schrieb:

    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.
    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.
  • Bit Shifter schrieb:

    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 Homepage

    Quellcode

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

    sd2iec Homepage
  • NLQ schrieb:

    Ich habe mir mal das JiffyDOS-Bit-Timing angesehen:
    forum64.de/index.php?thread/81…ostID=1245982#post1245982
    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 @markusC64 :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:
    Dateien
    Restore-Store - Platinen, Bausätze, Zubehör und Ersatzteile für Commodore Computer - Offizieller JiffyDOS Reseller
  • Bobbel schrieb:

    Ich habe aus gegebenem Anlass und nach einem Anstupser von @markusC64 :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 @Bobbel 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.
    Dateien
    • 1541ii.d64

      (174,85 kB, 5 mal heruntergeladen, zuletzt: )
    • 1541ii2.d64

      (174,85 kB, 5 mal heruntergeladen, zuletzt: )
    ---
    Meine Github-Projekte: github.com/markusC64/
    1541 Ultimate II / Ultimate 64 Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von markusC64 ()

  • 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 PRINT#-Befehl auch fehlerhaft ist. Beim Auslesen des (falschen) Files mit GET# gab es keine Fehler.
    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.
    forum64.de/index.php?thread/81…ostID=1245982#post1245982
    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.
    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???
    So weit ich weiß, hat @Bobbel mit einem SD2IEC getestet. Das mag es begründen.
    Bestimmt; Bobbel hatte mir dies auch schon per E-Mail mitgeteilt.
    @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
    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: github.com/markusC64/
    1541 Ultimate II / Ultimate 64 Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki
  • 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.
    Dateien
    • IECTEST.d64

      (174,85 kB, 7 mal heruntergeladen, zuletzt: )
    Restore-Store - Platinen, Bausätze, Zubehör und Ersatzteile für Commodore Computer - Offizieller JiffyDOS Reseller
  • NLQ schrieb:

    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 PRINT#-Befehl 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: github.com/markusC64/
    1541 Ultimate II / Ultimate 64 Firmware Releases: github.com/markusC64/1541ultimate2/releases
    1541 Ultimate II Update instructions: github.com/markusC64/1541ultimate2/wiki
  • Benutzer online 1

    1 Besucher

  • Tags