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

    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.

    Das beißt sich mit meiner Idee, die Motor-Leitung als "Umschalter" zwischen Kommando- und Datenmodus zu verwenden, denn sie wird von den normalen Tape-Routinen natürlich auch verwendet. Wahrscheinlich muss man sich etwas Ausgefeilteres überlegen, um vom "Browser-Loader"-Modus in den schnellen Übertragungsmodus zu kommen - vielleicht so etwas wie eine magic-sequence auf der write-Leitung.

    Wenn man es schafft, einen Loader zu schreiben, der auf jeglicher CBM Hardware läuft (spricht etwas dagegen?)

    Dagegen spricht, dass die externe Hardware "wissen" müsste, an welches Gerät sie angeschlossen ist. Man bräuchte also DIP-Schalter, Jumper oder eine Taster+LED-Kombination, die es erlauben, das jeweilige Zielgerät einzustellen. Das wäre aber wieder recht kompliziert in der Bedienung und schreit formlich nach einer komplett abgefahrenen Forschungsarbeit die da lautet: Wie erkenne ich automatisch, an welchem Datasettenport ich angeschlossen bin? Irgendwelche Unterschiede zwischen C64, VC20, PET und 264-Serie wird es sicher geben...

    Allerlei Timing-Diagramme und die Programme müsste ich noch haben, machen meiner Meinung nach aber heute keinen Sinn mehr. Wozu noch ein Signal auf 44.100 Hz beschränken, wo es doch diese kleinen Micro-Controller gibt?

    Richtig; heute ist ein Microcontroller und eine SD-Karte billiger als die Hardware die man bräuchte, um sich mit einem gängigen Smartphone zu verbinden (da bleibt oft nur Bluetooth). Und da wir hier ohnehin von einem Kopfschussprojekt reden, welches vor Feature-creeping nur so triefen wird, wenn man einmal angefangen hat (siehe die Idee "automatisches Erkennen der Host-Maschine), kann man auch nie genug Rechenleistung haben.

    Jetzt wo Raspi3 und die neue Odroid-Generation raus sind, liegen ganz sicher viele Raspi-Boards ungenutzt in der Ecke herum. Die bringen schon alles mit, was man für das Projekt bräuchte: GPIOs, reichlich Rechenleistung und einen SD-Kartenslot. Und viel Platz für feature-creeping! "The internet is my tapedrive", anyone?

    Jens

    Jetzt kommt Fahrt in diesen Thread - klasse!

    Mal ne ganz andere Idee für die Aufzeichnung, die wir beim Catweasel für das "XTRA HD" Format verwendet haben. Damit haben wir nicht nur eine höhere Geschwindigkeit, sondern auch eine höhere Datendichte erreicht, aber die Grenzen der Diskette NICHT überreizt: Es war alles innerhalb der 1,44MB-Spezifikation, aber wir haben 2380KBytes auf einer DIsk untergebracht.

    Die Grundidee war, mit einem Impuls nicht nur ein Bit, sondern zwei Bits zu speichern. Es gab also nicht nur einen Threshold, sondern drei, so dass es vier mögliche Längen gab, was zwei Bit pro Puls entspricht. Da sich dadurch die Gesamtlänge eines Tracks je nach Daten verändert, mussten wir die noch umsortieren, damit die häufigste Bitkombination auch auf den kürzesten Puls gemapped wird - das braucht man bei der Datasette nicht.

    Hat mal jemand sowas programmiert?

    Gedanke "bliebige Hardware":
    Da würde ich gar nicht so sehr auf Syncronisation achten, sondern ich würde den C64 zum "Master" machen, und die externe Hardware bitweise auf Clock-Pulse warten lassen. So würde der C64 mit seiner ganz eigenen Geschwindigkeit auf den Datasettenport zugreifen, man könnte Screen und IRQs an lassen um Fortschritt anzuzeigen und Lalla zu spielen, und hätte trotzdem eine annehmbare Datenrate.

    Die Motor-Leitung ist sehr langsam, würde maximal zum "Modus-Umschalten" ausreichen. Wie wäre es mit:

    - Motor aus = Datenmodus, also Daten werden vom oder zum C64 übertragen
    - Motor an = Kommando-Modus, also Informationen über "welchen Block will ich denn lesen/schreiben" werden ins Gerät übertragen

    Für die Übertragung der Daten können drei Leitungen verwendet werden, nämlich read, write und sense. Der Einfachheit halber würde ich write und sense verwenden, weil die beide im Prozessorregister liegen, was mit flotten zeropage-Kommandos bearbeitet werden kann. Die externe Hardware wird so gebaut, dass sowohl eine steigende Flanke, als auch eine fallende Flanke als "nächstes-Bit-Impuls" akzeptiert wird, was einen Schreibzugriff pro Bit spart.

    Wenn man dann noch die Schleife für ein Byte abrollt, dürfte sich eine recht flotte Übertragungsroutine ergeben. 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.

    Wer baut's ;-)?

    Jens