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

    Könnte man, aber wozu? Mikrocontroller-Pins sind üblicherweise einzeln in ihrer Richtung umschaltbar und wer die Leitung wann in welcher Richtung verwenden darf legt man im Protokolldesign fest. Das muss natürlich berücksichtigen, dass der C64 jederzeit geresetted werden könnte und dann so schnell wie möglich/sinnvoll die Orginal-Richtung wieder herstellen oder zumindest Pegel ausgeben (Low ist unkritsch, aktives High problematisch), bei denen der 6510-Port nicht zerstört wird.

    War nur so ein Gedanke, wie die Erweiterung unter Umständen erkennen könnte, dass am C64 was unerwartet auf Ausgang steht.
    Dann wäre es bei einem 1Bit-Protokoll mit Screen und anderem Schnickschnack sicher gut, Data als Takt und Sense für die Daten zu verwenden. So dürften keine verbundenen Ports je gleichzeitig auf Ausgang gehen.

    Ist Dein Ding mit Menü oder ohne? Wo kann man das denn mal sehen?

    Man kann die Motor-Leitung auch als eine Art Reset-Leitung für die externe Hardware sehen: Falls irgendwie die Hardware im Sendebetrieb ist würde Motor alles abbrechen und wieder auf Empfang von Kommandos umstellen.

    $FDA3 ist die Init-Routine, die bei Reset und Restore läuft.
    FDD5: A9 E7 LDA #$E7 ; xx10 0xxxFDD7: 85 01 STA $01 ; 6510 On-chip 8-bit Input/Output RegisterFDD9: A9 2F LDA #$2F ; xx10 1xxxFDDB: 85 00 STA $00 ; Motor + Data out

    Ich will es nicht schwören, aber ich meine, während des Resets brummt der Datasettenmotor mal kurz, muss man mal prüfen. Wäre jedenfalls gut, um mit dem Motor-Signal die Hardware auf Empfang und durch diese dann Sense auf "Taste gedrückt" zu setzen. Bin mir jetzt aber nicht sicher, ob 1 in Motor wirklich heisst, das der dann läuft, oder ob das genau umgekehrt ist.

    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.

    Ist die Motor-Leitung nicht sowas wie ein natürliches Erkennungsmerkmal der normalen Tape-Routinen? Wenn die externe Hardware Sense richtig setzt, dann wir beim Laden im Kernal-Modus der Motor angehen. Wäre auch gleich ein Prima Zeichen, um abgebrochene Übertragungen zu resetten.
    Noch ein paar Gedanken:
    -Blockweise übertragen, nach jedem Block kann dann wieder ein Kommando gesendet werden.
    -Die Read-Leitung an FLAG1 in $dc0d ist glaub ich nicht mit anderen Sachen verbunden. Ich sehe zwar grad keine Anwendung, aber vielleicht kann sie doch noch irgendwie für ein Signal an den 64er benutzt werden.
    -Kann man eigentlich 1 Eingang + 1 Ausgang auf der Erweiterungsseite + 1 Port aus $01 miteinander verbinden? Wenn $01 auf Eingang steht würde aus Sicht der Erweiterung alles normal funktionieren, was sie sendet kommt auch an ihrem Eingang an. $01 auf Ausgang müsste die Erweiterung bei bestimmten Werten feststellen können. Auch hier seh ich grad keinen Bedarf, nur so ein Gedanke...

    Minimum sind der 192 Byte lange Tape-Header, der netterweise komplett im Kassettenpuffer landet und fast vollständig leer ist plus ein 2 Byte langes Programm, welches einen Vektor zwecks Autostart überschreibt und in den schon im Header geladenen Code reinspringt.

    In 192 Bytes lässt sich schon einiges mehr als nur ein gekürzter Loader unterbringen.

    ...Es gab also nicht nur einen Threshold, sondern drei, so dass es vier mögliche Längen gab, was zwei Bit pro Puls entspricht....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?

    Ja, inklusive Mappen der 2Bit-Längen je Block, beschleunigt ungemein. Das ganze Bestand aus einem Java-Programm, dass ein .prg in ein .wav umgerechnet hat, dem Loader dazu, und als Adapter diente der "übliche", der einen Kanal mit FLAG1 verbindet.
    Wollte noch einen besseren Adapter für $01 und Stereo basteln, aber das überstieg schon meine Hardware-Kenntnisse.
    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?

    Hübsch. Wie nennt sich das Ding?
    Würde auch "Motor" für den Handshake gehen? Wenn die Laufzeit bekannt ist könnte man das Ende auch per Timer prüfen lassen
    Die Gedankenspiele bezogen sich auf ein Gerät, das sich den Takt vom 64er holt und somit 100%ig synchron wäre.

    Bei "beliebiger Hardware" kann man sich ja was denken, was sich mit dem C64-Takt synchronisiert, auf die übliche und dazu perfekt auf den Loader abgestimmt ist. Nach einem kurzen Synchronisieren zum Start könnte die extreme Ladeschleife dann so aussehen:

    Das sind fast 20 kByte/s.
    Ich weiß jetzt nicht, ob der Datasettenport auch 2 Bit Eingang zulässt. Falls ja:

    Code
    loop ldx $01
         lda tab0,x
         ldx $01
         ora tab1,x
         ... 7*4Tz=28

    Das wären dann ~25 kByte/s. Ich kann mir aber vorstellen, dass die entsprechende Hardware aufwändig genug ist, dass sie die Daten auch gleich per DMA ins RAM schieben könnte. Wäre imho also Quatsch, sowas zu bauen.

    Etwas weniger "beliebige Hardware" käme wohl eher in Frage.
    Vielleicht was Intelligentes, das einen Handshake macht?
    Oder was ganz Dummes, das Daten mit ~44.100 Hz rüberdudelt?
    ...aber da bricht das Tempo dann doch was ein.