Beiträge von Claus im Thema „Datasettenspiel mit höchster Datenrate“

    Ist die Motor-Leitung nicht sowas wie ein natürliches Erkennungsmerkmal der normalen Tape-Routinen?


    Kann man es nicht durch einen Timeout lösen?

    Wenn Sense durch die externe HW per default gesetzt wird, ergäbe sich m.E. folgendes:

    Speed-Load: C64 setzt Motorsignal und überträgt zeitnah auf Write einen Ladebefehl. Externe HW startet schnelle Übertragung.

    Kernal-Load: C64 wartet auf Sense. Da es bereits gesetzt ist, setzt er das Motorsignal, aber sonst passiert erstmal nichts. Nach einem Timeout (1s?) weiß die externe HW, dass es das Loaderprogramm übertragen muss.

    Oder ist da ein Denkfehler drin? Ich bin auch noch nicht sicher, wie ein C64-Reset dann behandelt wird.

    Und (jetzt gerate ich auch langsam in Fahrt) das coole ist, dass die einzige Voraussetzung zum Betrieb das CBM Tape-Protokoll ist. Wenn man es schafft, einen Loader zu schreiben, der auf jeglicher CBM Hardware läuft (spricht etwas dagegen?), hätte man eine Hardware, die im Gegensatz zu Modulen mit DMA-Load auf allen CBM-Geräten läuft! 8) Den Browser müsste man natürlich abhängig vom CBM-Gerät laden.

    Die Hardware kann weiterhin ein simpler Microcontroller sein, der auch das "Loader-Programm" über die Read-Leitung in Dauerschleife "einspeist", solange er keine write-Impulse erkennt.

    Oha, das bedeutet, dass man per shift+run/stop den Loader (der vielleicht sogar einen kleinen Browser enthält) im Standard-C64 laden kann, mit dem man dann blitzschnell Dateien lädt, oder? Coole Idee! Der Loader/Browser müsste halt möglichst klein sein, da er ja mit Standard-Tape-Routine geladen wird... Statt Loop wäre es vermtulich besser, den Loader dann zu übertragen, wenn die Motor-Leitung angeht, damit man nicht auf den nächsten Loop-Anfang warten muss.

    EDIT: ach, den Browser könnte man ja schon schnell laden, der Loader müsste also wirklich nur minimal klein sein.

    Nebenfrage: Was wäre denn theoretisch eigentlich über den Tape-Port max. möglich?

    Ich hätte getippt, dass es keine physikalische Grenze gibt. Du brauchst einen Software Loop, der halt die Länge der Pulse unterscheiden kann und ein entsprechendes Bit irgendwo hinschiebt. Und Du hast einen gewissen Jitter beim Reagieren auf den Puls. Und ich weiß nicht, wie groß die Gleichlaufschwankungen sein können. Am Ende muss alles robust genug sein, dass es keine Fehler gibt...

    Genau das hab' ich noch nicht verstanden. Warum liegt der nicht genau in der Mitte?

    Ich kann auch nur spekulieren. Die wichtigste Fehlerquelle wäre wohl eine abweichende Bandgeschwindigkeit. In dem Fall ändert sich die Pulslänge ja prozentual, sprich: der kurze Puls wird in absoluter Zeit gemessen weniger verändert als der lange Puls. Damit wäre die Robustheit gegen Bandgeschwindigkeitsschwankungen besser, wenn der Threshold nicht am arithmetischen Mittel sondern am geometrischen Mittel liegt. Glaub ich ?(8|

    Hier gibt es ein paar Infos zu kommerziellen Loadern: Bitte melde dich an, um diesen Link zu sehen.. Nach kurzem Überfliegen habe ich als kleinsten Threshold 263 Zyklen gefunden. Wenn meine naive Rechnung stimmt, dass im Schnitt ein Bit die Dauer des Thresholds braucht (je nachdem ob es gesetzt ist länger oder kürzer), käme man damit auf ca. 3.8 kBit/s, was glaube ich schon Supertape-Geschwindigkeit sein dürfte. Im Allgemeinen sind aber glaube ich die kommerziellen Lader langsamer gewesen, da die Tapes wohl typischerweise mit höherer Geschwindigkeit kopiert worden sind...

    EDIT: genaueres Lesen zeigt, dass meine Rechnung wohl etwas zu naiv ist. Der Threshold liegt wohl meist näher am kürzeren Puls als am längeren und damit ist die Datenrate im Schnitt niedriger.

    EDIT2: wenn ich mich nicht verguckt habe, wäre der schnellste genutzte kommerzielle Loader wohl Turbo Tape 64, unter anderem benutzt von "China Miner", "Great Giana Sisters" und "To be on Top". Da ist der Threshold tatsächlich genau zwischen langem und kurzem Puls und meine Rechnung stimmt. Also 3.75 kBit/s.