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