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

    War nur so ein Gedanke, wie die Erweiterung unter Umständen erkennen könnte, dass am C64 was unerwartet auf Ausgang steht.

    Nee, Richtung erkennen geht nicht so einfach - da müsste man einen kontrollierten Strom auf den Pin geben bzw. von da ziehen und messen, wie stark der dadurch beeinflusst wird. Das ist etwas viel Aufwand.

    Zitat

    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.

    Ok, fertig! ;)

    Zitat

    So dürften keine verbundenen Ports je gleichzeitig auf Ausgang gehen.

    In gewissen Grenzen ist das kein Problem - mein Modul kann die Pins nur gegen Masse schalten oder per Pullup auf 1 heben. Beides ist für die I/O-Ports des 6510 kein Problem, auch wenn die gerade auf dem jeweis gegenteiligen Pegel stehen. Protokolltechnisch ist das ganze zudem noch so designt, dass der aktiv-auf-Masse-ziehen-Fall bei "umgedrehter" Richtung höchstens für einige dutzend Mikrosekunden auftreten kann um das ganze noch weiter zu entschärfen.

    Zitat

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

    Mein Ding ist ohne Menü - die Idee war eher was in Richtung Easyflash 1 anzubieten, auf dem sich andere Leute austoben können. Die ursprüngliche Idee war sogar noch weiter eingeschränkt - als möglichst billiger externer Speicher mit 64 KByte Kapazität um den Expansionsport freizuhalten.

    Sehen kann man da nicht viel - die alten Prototypen waren kleine violette Platinen mit Tapeport-Stecker und SMD-Bauteilen, der aktuelle Testaufbau ist ein wenig Chaos auf einem kleinen Steckbrett und die noch nicht gelöteten neuen Prototypen sind wieder kleine violette Platinen mit Tapeport-Stecker und SMD-Bauteilen.

    Wenn gesteigertes Interesse besteht könnte ich auch noch eine SMD-freie Variante entwerfen, die wäre allerdings teurer und 16MBit-SPI-Flashchips im DIL8-Gehäuse sind in kleinen Mengen schlecht beschaffbar - Digikey würde die zB nur in 100er-Stangen abgeben.

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

    Hatte ich zwischenzeitlich mal als "Modul bereit für nächstes Byte"-Marker drin weil zB Schreibzugriffe auf den Speicher etwas länger dauern können, ist aber wieder rausgeflogen. Das Problem mit FLAG1 ist, dass es durch einen Lesezugriff auf das CIA ICR gelöscht wird, was für einige Lästigkeiten beim Umbau schon vorhandener Interrupt-Routinen verursachen könnte.

    Zitat

    -Kann man eigentlich 1 Eingang + 1 Ausgang auf der Erweiterungsseite + 1 Port aus $01 miteinander verbinden?

    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.

    Zitat

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

    Genaugenommen sind es nur 171 freie Byte - in dem Block steht zB noch der Dateiname und ein paar Verwaltungsbytes wie Start- und Endadresse. "Gekürzt" würde ich den Loader auch nicht unbedingt nennen, der kann fast beliebig viele Daten ins C64-RAM laden, so lange die an einem Stück sind und er sich nicht selbst überschreibt. Am Ende werden noch ein paar Vektoren neu gesetzt und der Bildschirm eingeschaltet, damit das zu startende Programm eine möglichst "normale" Umgebung sieht.

    Wegen des 2-Bit-Transfers ist der Platzbedarf allerdings etwas höher als bei einem typischen Tape-Loader: Beim Tape kann man eine Unterroutine zum Einlesen eines Bits anlegen und die 8x aufrufen, der 2-Bit-Transfer braucht "entrollten" Code für ein komplettes Byte. Ich könnte zwar diesen Initialloader auch auf 1-Bit-Übertragung umstellen und evtl. etwas Platz rausholen, aber wozu wenn das Ding alles kann was ich an der Stelle brauche und es so schneller ist?

    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.

    Genau das mache ich auch.

    Zitat

    $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

    Bei einem Hardware-Reset hat sich zu dem Zeitpunkt das Modul schon längst wieder in den "Datasetten-Modus" (heisst in der Doku derzeit "streaming mode") zurückversetzt. =) Wenn der 6510 einen Reset-Impuls erhält, schaltet er seine I/O-Pins auf Eingang und mit der Schaltung im C64 entspricht das einem laufenden Datasetten-Motor.

    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.

    1-Bit-Datenübertragung mit vom C64 vorgegebenem Takt, nach IRQ-Loader-Art: Check.

    Zitat

    Die Motor-Leitung ist sehr langsam, würde maximal zum "Modus-Umschalten" ausreichen.

    Evtl. erinnerst du dich, dass ich Einspruch erhoben habe als dein C64R-Konzept noch einen Schaltregler mit Enable zur Steuerung der Motor-Leitung vorgesehen hat? Der wäre nämlich nochmal langsamer gewesen und meine Modusumschaltung hätte nicht funktioniert.

    Motor-Leitung zur Modusumschaltung: Check - allerdings anders als du es dir denkst.

    Zitat

    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

    Nee... Wenn man sowas in zuverlässig bauen will, muss man bei einem C64-Reset auch auf jeden Fall zurück in den Datasetten-artigen "Stream-Modus" zurückkehren, damit der Benutzer sofort mit Shift+Run/Stop sofort wieder das Starterprogramm laden kann. Meine Lösung besteht darin, die Motor-Leitung zu überwachen - bei einem Reset geht der mindestens so lange an, wie der Reset-Taster gedrückt wird und glücklicherweise ist das EInschalten des Motors die "schnelle" Operation.

    Ein Timeout (keine wackelde Leitung in den letzten x ms) käme zur Reset-Erkennung IMHO nicht in Frage, der Programmierer auf C64-Seite sollte seine wertvolle CPU-Zeit nicht mit solchem Verwaltungskram verschwenden müssen.

    Zitat

    Der Einfachheit halber würde ich write und sense verwenden, weil die beide im Prozessorregister liegen, was mit flotten zeropage-Kommandos bearbeitet werden kann.

    Verwendete Datenleitungen: Check. Ausserdem haben die den Vorteil, dass man die ganze Zeit über den I/O-Bereich abgeschaltet lassen kann.

    Die Read-Leitung finde ich recht unattraktiv, weil sie nur steigende Flanken erkennt und im CIA-ICR landet.

    Zitat

    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.

    Könnte man machen, hatte ich aber aus irgendeinem Grund vermieden.

    Zitat

    Wenn man dann noch die Schleife für ein Byte abrollt, dürfte sich eine recht flotte Übertragungsroutine ergeben.

    Der 2-Bit-Transfer ist dennoch ein gutes Stück flotter, der Code oben kommt auf unter 50 Taktzyklen pro Byte.

    Zitat

    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.

    CBM-Kernal-Format-Loader: Check

    Die Umschaltung ist allerdings noch ein wenig aufwendiger als nur auf Write ein wenig rumzupulsen: Die Motor-Leitung wird als Taktleitung verwendet und bei jeder steigenden Flanke der Zustand der Write-Leitung abgefragt. Wenn die so gelesenen letzten 16 Bits einem von zwei Werten entsprechen, wird entweder in den "Fastloader-Modus" gewechselt, der einen einzelnen Speicherblock zum C64 sendet (erlaubt einen kleineren Initial-Loader im Kernal-Tape-Format) oder in den Kommandomodus, wo voller Zugriff besteht.

    Zitat

    Wer baut's ;-)?

    enthusi hatte die Idee und ich habe das vor längerer Zeit mal zusammengehackt:

    Zitat von git log

    commit 642fcbe535c566d867269c582b068edec5544792
    Author: Ingo Korb <ingo@akana.de>
    Date: Sat Sep 28 12:53:59 2013 +0200

    Initial import

    (falls sich jemand ans Cassiopei erinnert: Als dazu erstmals was im Netz zu lesen war, wartete ich gerade auf die Lieferung meiner ersten Prototyp-Platinen)

    Das ganze ist dann allerdings einige Zeit lang eingeschlafen bis wir es Ende letzten Jahres wieder ausgegraben haben um es etwas zu aktualisieren, polieren und zu kostenoptimieren (kleine ARMs sind inzwischen billiger als kleine AVRs). Ist allerdings noch nicht in einem Release-tauglichen Zustand, mir fehlt noch mindestens ein Feature um später irgendwie Firmware-Updates hinzuwürgen sowie ein UART-Zugriff auf den Kommandomodus, um den Speicher jenseits des C64 etwas flotter programmieren zu können.

    (oder bezog sich das "bauen" auf einen SMD-Bestücker? ;) )

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

    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.

    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.