Hello, Guest the thread was called1.7k times and contains 22 replays

last post from TheRealWanderer at the

Final Cartridge III mit sd2iec

    Tach,


    gerade habe ich die erste Datei mit dem Fastloader des FC3 von meinem sd2iec geladen. Leider geht im Moment nur alles bis ein Block Länge :-) Hab wohl am Protokoll was noch nicht richtig verstanden.


    Mann, war das ein Krampf. Hab gefühlte tausend mal die Taktzyklen im Transfer-Code nachgezählt, bis ich den Copy-Paste-Fehler im High-Level-Code gefunden habe... Schade, wenn man keinen Logic-Analyzer hat.


    Es kann noch ein paar Tage dauern, bis das Ding fertig wird. Wegen Familie und so. Aber dann lass ich Unseen einen Patch zukommen.


    Noch eine gute Nachricht: Der FC-3-Speeder synchronisiert alle 4 Bytes, könnte also auch auf Hardware ohne Quarz funktionieren. Und evtl. geht der auch auf NTSC, ich meine zwei Empfangsroutinen im C64 gesehen zu haben, und das Timing hat auch noch etwas Spiel. Weiß jemand, ob das FC3 für PAL und NTSC gleich war?


    Bis dann

    Quote from skoe

    Gerade habe ich die erste Datei mit dem Fastloader des FC3 von meinem sd2iec geladen. Leider geht im Moment nur alles bis ein Block Länge :-) Hab wohl am Protokoll was noch nicht richtig verstanden.


    Juhu, endlich implementiert jemand mal einen weiteren Softspeeder. =)


    Ohne das FC3-Protokoll zu kennen kann ich nur einen Hinweis geben woran es haken könnte: Sowohl die CIAs im C64 als auch die VIAs der Floppy geben Werte mit einem Takt verzögerung aus und IIRC lesen sie auch mit einem Takt Verzögerung ein - steht auf jeden Fall im Datenblatt der Chips drin.


    Quote

    Schade, wenn man keinen Logic-Analyzer hat.


    PC-Parallel-Port nehmen? TFLA und Digitrace sind zwar beide auf ihre eigene Art sch****, aber 8 Leitungen (SRQ lässt sich nett als Markierung verwenden wenn die Teile bestückt sind, auf dem mega644 sind Pins togglebar indem man in das zugehörige Bit im PIN-Register(!) eine 1 schreibt) mit ca. 1MHz Samplerate helfen doch manchmal weiter.

    Quote

    Sowohl die CIAs im C64 als auch die VIAs der Floppy geben Werte mit einem Takt verzögerung aus


    Ahh, interessant, merk ich mir. Das ist es aber nicht, hab mir nur die Übertragung mehrerer Blöcke noch nicht genauer angesehen - bin also nicht wirklich verwundert, dass es noch nicht geht. Hab noch nie was mit'nem AVR gemacht, deshalb bin ich über das erste Erfolgserlebnis froh.


    Quote

    PC-Parallel-Port nehmen?


    Ich war auch kurz davor, mir genau sowas zusammenzubauen. Aber den Zeitaufwand für die theoretische Fehlersuche habe ich geringer eingeschätzt... Wahrscheinlich mach ich das trotzdem mal. Vielleicht gibt's schon ne fertige Software für sowas, am besten unter Linux. Muss mal googlen.

    So, den Patch hab ich an Unseen abgeschickt.


    Eigentlich ist mir der zusätzliche Geschwindigkeitsvorteil durch das sd2iec nicht sooo wichtig. Hauptsache, es ist nicht langsamer als das Original :-) Aber weil 1570 gefragt hat: Kurz angetestet mit 130 Blocks und geschieltem Blick zum Sekundenzeiger:
    ca. 5,5 s FC3 + sd2iec
    ca. 55 Sekunden sd2iec pur.
    Gemessen von <Return> bis READY. Also inkl. Hochladen des Drive-Codes.


    Da das sd2iec pur ca. 1,7-fach schneller als eine 1541 ist, ist FC3 + sd2iec jetzt 17x. Milchmädchenrechnung korrekt?


    Das liegt natürlich an der fehlenden Mechanik. Außerdem konnte ich das Timing im Protokoll noch etwas straffen.

    Danke, sehr cool!


    130 Blocks sind rund 33kBytes, das in 5,5 Sekunden sind rund 6kB/Sek; ein C64+1541 schafft normal ca. 400 Bytes/Sek, macht also rund 15fach. Also rund 1,5mal so schnell wie FC3+1541 in Original. Ist doch nett - insbesondere wenn man sich vor Augen hält, dass es das selbst für z.B. 1541 Ultimate-Besitzer so nicht gibt (sondern "nur" Originalgeschwindigkeit ;-).

    Ich habe zwar noch keine Ahnung wann das nächste Release kommt, aber die Vorfreude möchte ich an dieser Stellen schonmal dämpfen: ;-)

    • Der Patch implementiert nur den Fastloader, aber nicht den Fastsaver -> Speichern hängt
    • Das FC3 beschleunigt nur die Geräteadressen 8 und 9
    • Von unbeschleunigten Adressen kann ich mit meinem FC3 fehlerfrei laden, aber beim Speichern wird ein falscher Dateiname übermittelt (einbuchstabige Namen werden als 0xff gesendet) - passiert auch mit einer 1541 mit Orginal-Dos.
    • Es sind noch Bitfehlerprobleme zu beseitigen
    Quote

    Es sind noch Bitfehlerprobleme zu beseitigen


    Hast Du tatsächlich Bitfehler bemerkt oder meinst Du die Sache mit dem mdelay(20)? Ich habe gestern viele Dateien geladen und heute auch noch mal einige. Da die üblicherweise komprimiert waren, hätten sich Bitfehler sicher bemerkbar gemacht.


    Wegen des mdelay habe ich Dir meine Vermutung ja schon geschrieben, aber ich prüfe das mal.


    Quote

    Der Patch implementiert nur den Fastloader, aber nicht den Fastsaver -> Speichern hängt


    Ooookaaayyy, wenn hier jemand was speichern will, schaue ich mir das doch mal an.


    Quote

    passiert auch mit einer 1541 mit Orginal-Dos.


    Na dann ist ja alles gut ;-)


    Quote

    Das FC3 beschleunigt nur die Geräteadressen 8 und 9


    Da ich nie mehr als zwei Laufwerke hatte, hab ich das noch nie bemerkt :-)


    Trotz Deines Dämpfers finde ich's toll, den FIBR in zwei Sekunden drin zu haben...

    Tatsächlich. Bei $9b1c wird $d011 geschrieben. Und ein paar Taktzyklen später, bei $9b3d, wartet der C64 schon auf den Handshake von der 1541. Und weil das sd2iec so schnell ist, ist u.U. der VIC-DMA noch aktiv.


    Das mdelay(20) ist also begründet. (Obwohl es ohne die Überlegung einen Hauch von Weihwasser hat :-)

    Quote from skoe


    Hast Du tatsächlich Bitfehler bemerkt oder meinst Du die Sache mit dem mdelay(20)? Ich habe gestern viele Dateien geladen und heute auch noch mal einige. Da die üblicherweise komprimiert waren, hätten sich Bitfehler sicher bemerkbar gemacht.


    Echte Bitfehler, die verschwinden wenn ich die 12us zwischen Sync und ersten Bitpaar auf 11us verringere. Vielleicht spielt da auch die Kabellänge mit rein, die beiden sd2iec (einer zum beschleunigten Laden, einer zum langsamen Speichern) hängen hinter ca. 2m Leitung.


    Über einen einzelnen Testlauf (26* Laden/Speichern) gerechnet sind zwar nur 0,015% aller Bytes falsch, aber auf Dateien bezogen sind es 18 von 26 mit einem bis 16 fehlerhaften Bytes.


    Quote

    Trotz Deines Dämpfers finde ich's toll, den FIBR in zwei Sekunden drin zu haben...


    So lange dauert doch fast schon die Übertragung des Fastloaders wenn man CONFIG_UART_DEBUG aktiviert hat. ;-)

    Mhh, mein Kabel ist ca. 50 cm. Spielen solche Effekte bei den Längen und Geschwindigkeiten schon eine Rolle?


    Bei der Implementierung habe ich versucht mich in der Mitte von dem zu halten, was der C64 erwartet und die Original-1541-Implementierung tut. Siehe Timing-Diagramm ORIGINAL.



    Was mir dabei auffällt: Bei der Original-Implementierung liegt das Signal im Extremfall nur ca. 1..2 µs vor dem frühsten Lesen auf dem Bus. Durch Deine Änderung werden es 2..3. Klingt nach einer guten Maßnahme.


    Quote

    So lange dauert doch fast schon die Übertragung des Fastloaders wenn man CONFIG_UART_DEBUG aktiviert hat. ;-)


    Och, nu lass mir doch mal meine rhetorischen Übertreibungen :juhu:


    Mhh, jetzt denke ich über die Verzögerung beim Lesen und Schreiben durch die CIA/VIA ein. Aber das ist ja dann beim ersten Sync auch so. Da es eine pure one-way Synchronisation ist, sollte das hier nicht ins Gewicht fallen. Relativitätstheorie und so ;(

    Quote from skoe

    Mhh, mein Kabel ist ca. 50 cm. Spielen solche Effekte bei den Längen und Geschwindigkeiten schon eine Rolle?


    Beim Jiffy-LOAD gibts eine Stelle an der das Laufwerk eine Leitung auf High setzt und dann darauf wartet dass der Rechner sie wieder auf Low zieht. In sd2iec ist dazwischen eine 1us-Verzögerung weil es sonst nur an kurzen Kabeln funktioniert hat - die Streukapazität muss erst über die Pullups geladen werden.


    Im FC3-Floppyteil sehe ich allerdings nichts vergleichbares und leider habe ich vor einiger Zeit mein 10cm-Kabel durch ein 1m-Kabel ersetzt.


    Quote

    Mhh, jetzt denke ich über die Verzögerung beim Lesen und Schreiben durch die CIA/VIA ein. Aber das ist ja dann beim ersten Sync auch so. Da es eine pure one-way Synchronisation ist, sollte das hier nicht ins Gewicht fallen. Relativitätstheorie und so ;(


    Dadurch war ich auf die Idee gekommen das Timing um 1us zu verschieben, obwohl es eigentlich nicht der Grund sein kann.

    Erst fragt da monatelang keiner nach, heute schon zwei. Wie man das CRT bzw. das BIN patched, habe ich heute bereits beantwortet:


    HowTo: FC3 und FC3+ ohne Maus (z.B. für SwinSID Nano)