Datasettenspiel mit höchster Datenrate

Es gibt 33 Antworten in diesem Thema, welches 5.648 mal aufgerufen wurde. Der letzte Beitrag (5. März 2016 um 15:52) ist von Unseen.

  • Hallo,

    weiß zufällig jemand, welche Datasettenloader bei kommerziellen Spielen die höchste Datenrate hatten?

    SuperTape dürfte für den Hausgebrauch so mit die höchste Rate gehabt haben, jedoch stellte sich mir die Frage, wie weit sich die Spielehersteller getraut haben, die Datenrate zu erhöhen, weil sie bei höherer Datenrate ja potenziell mehr unzufriedene Käufer durch de- oder nicht exakt justierte Datasetten hätten befürchten müssen.

    Datenrate bezieht sich natürlich auf die Nutzdaten (mir ist klar, dass sich die Datasette per Software nicht schneller drehen kann; das Weglassen der redundaten Zweitaufzeichnung im Gegensatz zum Commodore-Format z.B. erhöht die Nutzdatenrate ebenso wie kürzere Zeitabstände zwischen den Impulsen).

    Danke im Voraus!

  • 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.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

    3 Mal editiert, zuletzt von Claus (4. März 2016 um 21:59)

  • Lt. hier: Bitte melde dich an, um diesen Link zu sehen.

    der 'Evil Dead'-Loader. Da ist wohl von von bis zu 4.100 baud die Rede.

    Bitte melde dich an, um diesen Link zu sehen.

    Da komme ich rechnerisch auf ca. 3.400.

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • Der Threshold liegt wohl meist näher am kürzeren Puls als am längeren und damit ist die Datenrate im Schnitt niedriger.

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

    Hier ist dazu auch einiges zu lesen:

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Verstanden hab' ich's trotzdem nicht... :gruebel


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

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • Oh stimmt, der ist ja auch auf meiner verlinkten Seite ganz unten. Hab ich ganz übersehen :/ . Jo, wenn man den Mittelwert aus langem und kurzem Puls nimmt, kommt man sogar auf phänomenale 4.4 kBit/s! =O

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Wow, danke für eure Antworten!!

    The Evil Dead mit dem besagten Loader scheint wohl tatsächlich der schnellste kommerziell eingesetzte Loader zu sein. Schade dass die so rar sind, ich hätte es gerne als Verifikation der Justage genutzt.

    Ich habe nämlich vor, mit einem kalibrierten Test-Tape für ein Referenz-Kassettendeck diesen Kopf optimal einzustellen, damit dann eine Kassette mit C64-Daten zu beschreiben, mit welcher ich anschließend Datasetten auf die optimale (objektive) Justage justieren kann. Das dann mit Schraubensicherungslack fixieren und dann sind die wieder top justiert.

    Das Ergebnis wollte ich dann insofern quervergleichen, indem ich ein kommerzielles Tape mit hoher Datenrate zu laden versuche; dies müsste dann ja weiterhin möglich sein, ansonsten wäre etwas grob falsch.

  • 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|

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • wie weit sich die Spielehersteller getraut haben, die Datenrate zu erhöhen, weil sie bei höherer Datenrate ja potenziell mehr unzufriedene Käufer durch de- oder nicht exakt justierte Datasetten hätten befürchten müssen.

    Frage am Rande: Ist eigentlich je ein Hersteller auf die Idee gekommen, auf die A-Seite des Tapes die Schnelladerversion zu packen und auf die B-Seite eine ohne Schnellader? Dass bei vielen Kassetten ja beide Seiten bespielt sind, weiß ich. Aber die Idee, eine Turbo- und eine Standardversion anzubieten finde ich so gar nicht übel...

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. :böse Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

    „Vor dem Himmel kommt das Leben auf Erden, und da gilt es, eine soziale Gesellschaft aufzubauen.“ – Heinz Nixdorf (1986)

    Bitte melde dich an, um diesen Link zu sehen. :beer:Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • 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...

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

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

    Mit Datasette oder mit "beliebiger" externer Hardware? Wenn letzteres: 9500 Byte/s sind auf jeden Fall machbar.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Welche Bitrate hat den im Vergleich die 1st CD Edition?


    Zitat: Die Ladezeit [pro Spiel] beträgt ca. 20 bis 50 Sekunden.

    Das klingt doch schon mal ganz flott. Dürfte Richtung Faktor 20-30 gehen.

    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.

    Klingt einleuchtend.

    Mit Datasette oder mit "beliebiger" externer Hardware? Wenn letzteres: 9500 Byte/s sind auf jeden Fall machbar.

    Beliebig.

    Wirklich BYTE/s?

    Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?

  • Wirklich BYTE/s?

    Ja

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.


  • Frage am Rande: Ist eigentlich je ein Hersteller auf die Idee gekommen, auf die A-Seite des Tapes die Schnelladerversion zu packen und auf die B-Seite eine ohne Schnellader? Dass bei vielen Kassetten ja beide Seiten bespielt sind, weiß ich. Aber die Idee, eine Turbo- und eine Standardversion anzubieten finde ich so gar nicht übel...

    Ja das gab es z.B. beim CPC Spiel "Sorcery". Auf der A: Seite befand sich ein Flashloader mit knapp 4000 Baud und ohne Header also am Stück. Und auf der Rückseite eine Blockweise Speicherung mit knapp 2000 Baud.

  • 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.

    Another workaround? Stay a while... STAY FOREVER!!

    Einmal editiert, zuletzt von Hoogo (5. März 2016 um 00:37)

  • Ich weiß jetzt nicht, ob der Datasettenport auch 2 Bit Eingang zulässt.


    Lässt er, die Sense- und Write-Leitungen hängen direkt am I/O-Port der CPU und können daher problemlos als Eingang oder Ausgang verwendet werden.

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


    Das wären dann ~25 kByte/s.


    Meine Lösung musste noch in den Kassettenpuffer passen und die 9500 Byte/s sind gemessene Rate inkl. Schreiben der Daten ins C64-RAM mit Vergleich, ob die Endadresse erreicht wurde - die reine Datentransferrate wäre noch höher. Codeausschnitt:

    Funktioniert im Prinzip so wie ein Floppyspeeder mit 2-Bit-Datentransfer. Wenn die Sendeseite einen ausreichend genauen Takt hat und man im C64 nicht auf den Platz achten muss, könnte man auch mehr als ein Byte pro Handshake übertragen, um das ganze noch weiter zu beschleunigen.

    Zitat

    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.


    Nö, die dafür notwendige Hardware beschränkt sich auf einen billigen Mikrocontroller mit halbwegs genauem Takt - der interne RC-Taktgeber eines AVRs ist mit +/-10% dafür zu ungenau, aber schon mit einem billigen Keramikresonator (oder einen Controller mit genauer spezifiertem internen Taktgeber) ist das kein Problem.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • 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.

  • 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

    Bitte melde dich an, um diesen Link zu sehen. - Das offizielle iComp Supportforum ist online.

  • 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.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

    2 Mal editiert, zuletzt von Claus (5. März 2016 um 10:40)

  • 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.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

    Einmal editiert, zuletzt von Claus (5. März 2016 um 11:05)