Hallo Besucher, der Thread wurde 8,1k mal aufgerufen und enthält 33 Antworten

letzter Beitrag von RetroJeck am

Fixed JiffyDos for 1571 im DCR

    Hi,


    wo hier mal wieder was los :) , ist:


    Im C128 DCR gibt es ja wie bekannt aufgrund der sehr kurzen Signalwege zwischen Computer und Onboard-Floppy Timingprobleme mit JiffyDos auf PAL Systemen.
    Laden und Speichern funktioniert, jedoch gibt es Probleme bei Progammen die CHRIN (Zeichenweises lesen) nutzen. Zum Beispiel @$ aus JiffyDos oder OPEN mit INPUT# oder GET#.
    Das äussert sich in Übertragungsfehlern (Displayfehlern im Direktory).


    Gibt ers dafür fixes?


    Hardwaremässig: irgendwas, das die die Signal verzögert?
    Softwaremässig: Evtl ein PAL Fixed JiffyDos für die 1571DCR?


    cya

    Guten Morgen


    Zitat von JMP$FCE2

    Quoted from "abraXxl"
    Im C128 DCR gibt es ja wie bekannt aufgrund der sehr kurzen Signalwege zwischen Computer und Onboard-Floppy Timingprobleme mit JiffyDos auf PAL Systemen.


    Zitat von JMP$FCE2

    Das ist absoluter Schwachsinn.


    Zitat von JMP$FCE2

    [X] Du möchtest Dich mal über Laufzeiten in Medien informieren.


    Mag sein, dass es absoluter Schwachsinn ist.
    [x] du möchtest mir dies erklären! Ich bin ganz Ohr. Oder du gibts ggf. eine alternative Erklärung.


    Fakt ist, dass Load/Save idR funkt. Jedoch bei Open ab und zu mal Bits kippen, sieht man sehr schön, wenn man mal mit @$ oder open1,8,1,"$" das Direktory laed.
    Es gab irgendow bie ledger einen Thread im Forum, der dies mal dokumentiert hat (Suche ich raus). Vermutlich kippen immer Bit 6 oder/und Bit 7 - aenhlich wie beim DTV (ja dort ist die CIA-Emul schuld) - Ich seh aber in meinen beiden DCR keinen emulierten Chip...

    Zitat von NLQ

    Das Verzögern des 1541U-Timings um weniger als 1µs löste das Problem


    Elektrische Signale breiten sich mit ca. 300.000Km /s aus. Also pro Meter ca. 3,33 ns.
    Das mag schon sein, aber das Verkürzen des Kabel um ein paar Zentimeter macht noch lange keine µs aus ... ;)


    Das mit dem Timing (Zeitverzögerung) wegen Kabellänge halte ich für Bullshit! Viel eher glaube ich an andere Dinge wie Flankensteilheit, Pegelprobleme etc.


    Vielleicht hat der DCR andere Pullups, oder andere Kapazitäten oder andere Anpassungen.

    Zitat von Diddl

    Elektrische Signale breiten sich mit ca. 300.000Km /s aus. Also pro Meter ca. 3,33 ns.


    In Kabeln langsamer, Pi mal Daumen und ohne Kenntnis des Kabeltyps kann man überschlägig 2/3 c annehmen.


    Zitat

    Das mit dem Timing (Zeitverzögerung) wegen Kabellänge halte ich für Bullshit!


    Parasitäre Kapazität des Kabels

    Ich habe jetzt nochmals auf dem 1541U-Forum nachgesehen (wegen des ganauen Werts der Verzögerung):
    http://www.1541ultimate.net/co…func=view&id=2545&catid=9 ab Seite 6 (Man muss sich allerdings anmelden, was aber schnell und problemlos geht). Der Timingunterschied zwischen Problemen und ok beträgt 0,25µs. Gideon hat digitale Filter zwischendurch deaktiviert, wodurch das Problem entstand. Um es wieder zu beheben, hat er das Timing um eben diese 0,25µs verzögert. Die JiffyDOS-IEC-Bus-Routinen in C128/1571 und C64/1541 sind absolut identisch. Der einzige Unterschied ist die Länge der Verbindung zwischen Computer und Floppy (und evtl. noch Verzögerung durch unterschiedliche Treiberchips dazwischen). Tatsache ist, dass die gleichen Routinen beim C64/1541 gehen, bei PAL-C128/1571 nicht. Ob es jetzt an der Länge des Kabels direkt, an der Kapazität zwei zueinander parallel-verlaufenden Leitungen oder irgendwelchen Chips dazwischen liegt, weiss ich auch nicht.
    Im GO64-Forum (Start der Diskussion am 11.09.2002) hat Nicolas Welte am 20.09.2002 das Problem dadurch gelöst, dass er in einen IEC-DIN-Stecker je einen 470pF Kondensator and die Data- und Clockleitung gelötet hat.

    Zitat von NLQ

    Im GO64-Forum (Start der Diskussion am 11.09.2002) hat Nicolas Welte am 20.09.2002 das Problem dadurch gelöst, dass er in einen IEC-DIN-Stecker je einen 470pF Kondensator and die Data- und Clockleitung gelötet hat.


    Ich vermute je zwischen Data bzw. Clock nach GND? (Alles andere macht keinen Sinn...)


    Sowie ich aus dem Ultimate Thread schliesse ist die 1571 ein Stück schnneller als sein Kommunikationspartner. Die Floppy sendet schon die Synchronisation für das nächste Byte während der Rechner noch bit 6 und 7 lesen möchte.
    Hat jemand mal gemessen um wieviel zu schnell das bei der C128D combo im Gegensatz zum C64/1541 das ist? (Ich hab kein Werkzeug dafür)


    Warum ist das Laden nicht betroffen? Koennte hier der DTV IECIN Path helfen? Und das lesen auf C128/C64 Seite um ein Cycle vorzuziehen?

    Code
    1. .C:fbd3 05 A4 ORA $A4


    Damit würden dann aber wahrscheinlich NTSC 128D Blech rausfallen.


    Eine Anpassung der C128D-Routinen könnte bewirken, dass der C128 dann wieder zu langsam sein könnte, wenn vier weitere externe serielle Geräte angeschlossen sind. Dies könnte bei einem PAL-C128 schon gehen, bei einem NTSC-C128 aber Probleme machen. Man hätte dann evtl. zwei JffyDOS-Versionen, eine für PAL und eine für NTSC.


    Die Kondensatoren wurden zwischen Data bzw. Clock und Reset (als Ersatz für +5V) gelötet. Ich hätte aber auch Ground gemacht.


    Das zu messen ist mit dem C128 schwierig, weil der zu langsam ist (Mit dem AVR kamen bei der 1541U Werte von 0,25µs raus) .


    Den DTV-Patch kannte ich noch nicht, aber das sieht sehr passend aus. aus zwei NOPs (4Takte) wird ein ORA $a4 (3Takte). Damit wird das C64/C128-Timing 1Takt schneller und der Computer würde die letzten beiden Bits zum richtigen Zeitpunkt lesen. Das könnte dann aber evtl bei NTSC-C64/C128 zu spät sein.

    Hier mal ein Zwischenstand zu dem JiffyDos DCR Problem:


    Im Anhang befidnet sich ein Basic-V2-PRG, welches den Floppy-Speicher einmal mit einer 8bit Maske und deren Inversen beschreibt. Anschliessend werden diese Bits zurück aus dem Floppyspeicher gelesen und mit dem Sollwert verglichen.


    Folgende Masken habe ich getestet:
    Bit Maske 85(=$55=%01010101) / 170(=$AA=$10101010)
    Bit Maske 51(=%00110011) / 204(=%11001100)
    Bit Maske 102(=%01100110) / 153(=%10011001)
    Bit Maske 15(=%00001111) / 240(=%11110000)


    Bitmasken die Fehler geworfen haben:
    85=%01010101 kippt zu
    21=%00010101


    204=%11001100 kippt zu
    140=%10001100


    102=%01100110 kippt zu
    38=%00100110


    240=%11110000 kippt zu
    176=%10110000


    - Dabei fällt auf das überwiegend das Bit6 (angefangen von 0) anfängt zu kippen. Es kippt von 1 nach 0.
    - Das Problem tritt auf dem DCR im 128er und im 64er Modus auf mit aktiviertem JiffyDOS auf und nur mit der Internen 1571DCR ohne weitere Geräte angeschlossen.
    - 240 sehint gefühlt seltener zu 176 zu kippen. Stichprobe 30000. ca 1 Fehler/600 Bytes vs. 1. Fehler/900bytes, und diese Schätzung ist noch nicht 100% aussagekräftig, zu kleines n.


    Da auf C128 Seite und C64 Seite immer folgender Code benutzt wird um zwei Bit vom Bus zu fetchen und Bit7 nicht kippt scheint das Problem nur Bit6 der CIA im 4. Fetch zu sein also die Clock-Leitung.

    Code
    1. eor $dd00
    2. lsr
    3. lsr


    Sorry, das Programm konnte ich nicht als Text anhängen, da petcat es leider nicht vollständig umwandeln wollte.

    Zitat von abraXxl

    Sowie ich aus dem Ultimate Thread schliesse ist die 1571 ein Stück schnneller als sein Kommunikationspartner. Die Floppy sendet schon die Synchronisation für das nächste Byte während der Rechner noch bit 6 und 7 lesen möchte.
    Hat jemand mal gemessen um wieviel zu schnell das bei der C128D combo im Gegensatz zum C64/1541 das ist? (Ich hab kein Werkzeug dafür)


    Lustig wie meine alten Untersuchungen und Entdeckungen wieder auftauchen :)


    Der eigentliche Grund, warum das Problem auftritt, ist ja die unterschiedliche Taktfrequenz von C64/128 auf der einen Seite und 1541/1571 auf der anderen Seite. Nun sind die Jiffydos Routinen für NTSC Rechner entwickelt worden, die ja etwas schneller laufen als die Floppies. PAL Rechner aber laufen langsamer als die Floppies. Dass Jiffydos hier funtkioniert ist Zufall.


    Mich persönlich würde ein PAL only patch nicht stören. Allerdings wurde mir mal gesagt das geht nicht. Warst nicht du das NLQ?


    Ach ja, das Problem tritt auch nicht auf wenn man einige externe Geräte am seriellen Bus hat. Dadurch kam ich auf die Idee mit den Kondensatoren im Stecker :)

    Zitat

    ...Mich persönlich würde ein PAL only patch nicht stören. Allerdings wurde mir mal gesagt das geht nicht. Warst nicht du das NLQ?...


    Ich weiss es jetzt auch nicht mehr. Ich wüsste nicht, wie man es machen könnte, dass das Timing der ertsen drei Doppelbits gleich bleibt und nur das des vierten Doppelbits früher erfolgt. Aber der DTV-Patch sieht gut aus. Er liest alle vier Doppelbits früher, aber ich denke, dass dies beim ersten Doppelbit trotzdem nicht zu früh sein sollte. Ich denke, dass der DTV-Patch in PAL-C128 funktionieren sollte.

    Zitat

    Elektrische Signale breiten sich mit ca. 300.000Km /s aus. Also pro Meter ca. 3,33 ns.
    Das mag schon sein, aber das Verkürzen des Kabel um ein paar Zentimeter macht noch lange keine µs aus ... ;)


    Das mit dem Timing (Zeitverzögerung) wegen Kabellänge halte ich für Bullshit! Viel eher glaube ich an andere Dinge wie Flankensteilheit, Pegelprobleme etc.


    Vielleicht hat der DCR andere Pullups, oder andere Kapazitäten oder andere Anpassungen.

    Ich glaube inzwischen auch nicht mehr, dass das Problem von der Kabellänge verursacht wird. Ich vermute vielmehr, dass der VIA-Ersatz-Spar-Chip minimal schneller ist als eine richtige VIA.
    Bei der 1541U liegt die Differenz zwischen JiffyDOS-geht und JiffyDOS-geht-nicht bei 0,15µs.

    Zitat von NLQ

    Ich vermute vielmehr, dass der VIA-Ersatz-Spar-Chip minimal schneller ist als eine richtige VIA.


    Tja, dummerweise hat die integrierte 1571 des C128DCR zwei echte 6522-VIAs. Der "Ersatz-Spar-Chip" ersetzt lediglich den MFM-Controller und das Schieberegister der CIA.

    Zitat von Unseen


    Tja, dummerweise hat die integrierte 1571 des C128DCR zwei echte 6522-VIAs. Der "Ersatz-Spar-Chip" ersetzt lediglich den MFM-Controller und das Schieberegister der CIA.

    Mist, ich habe keinen C128DCR und auch keinen Schaltplan. Dann weiss ich auch nicht, wo diese etwa 0,15µs zwischem C128D und C128DCR herkommen.

    NLQ lass doch die Bombe mal platzen. Ich mach morgen mal die restlichen Tests. Das Prog hier im Thread kann ich dann auch testen.


    Die Schaltpläne gibts bei Zimmers. Und nen 128DCR kann ich dir schon mal leihen.