Hallo Besucher, der Thread wurde 1,3k mal aufgerufen und enthält 7 Antworten

letzter Beitrag von Unseen am

SD2IEC .. D64 schneller übertragen ?

    Ich hatte eine Idee zum schnellen Übertragen von D64 in beide Richtungen. Jetzt weiß ich allerdings nicht, ob das auch technisch umsetzbar ist. Der C64 hat seinen 8-Bit Userport mit Handshake-Leitungen. Der AVR ist sicher schnell genug, um jeweils ein Shift-Register zu lesen oder zu beschreiben.
    Wenn man per Software das SD2IEC so patched, mit z.B. diesen zwei Befehlen:


    D64W : es soll ein D64 geschrieben werden
    D64R: es soll ein D64 gelesen werden


    in eine passenden Modus umschaltet, wäre eine Umleitung auf einen anderen Port möglich ? - Also zwei Portbits lesen oder schreiben dann in Shift-Register. Ein drittes Portbit wird dann für die Umschaltung der Richtung benötigt. Meine C-Kenntnisse reichen dazu leider nicht aus.




    Z.B. C64 liest ein D64:

    Code
    1. _h___ _______ ______ byte_clock ( gesteuert vom c64)
    2. |_| |_|
    7. byte byte
    8. ___ ___
    9. _l___| |_____| |___ byte_ready vom AVR


    Der C64 müsste den Transfer mit dem Seriell-Parallel-Dongle dann wahrscheinlich steuern. Ist im Prinzip dann auf der C64-Seite wie der gewöhnliche Speed-DOS Parallel-Anschluss und auf der AVR-Seite wird dann mangels freier Portbits geshiftet.



    Wenn das machbar ist, kann jemand die SD2IEC-Software dahingehend anpassen ? - Auf der C64-Seite und beim Bau des Adapters wäre ich dann behilflich.

    Zitat von cbmhardware

    Der C64 hat seinen 8-Bit Userport mit Handshake-Leitungen. Der AVR ist sicher schnell genug, um jeweils ein Shift-Register zu lesen oder zu beschreiben.

    Aber.... Wozu ein Shiftregister? IIRC sollten genug Pins am AVR frei sein um ein übliches 10-Leitungs-Parallelkabel zu realisieren und das hätte nebenbei noch den Vorteil, dass dessen Datenrichtung einfacher umschaltbar ist. Möglicherweise wäre es dafür sinnvoll, mal die Pinbelegung aufzuräumen um einen kompletten 8-Bit-Port am AVR für die Datenleitungen zu nutzen, aber das scheint mir unproblematischer als an vorhandene Platinen noch irgendwas lose dranzudengeln (was in diesem Forum schonmal abgelehnt wurde).


    Zitat

    D64W : es soll ein D64 geschrieben werden
    D64R: es soll ein D64 gelesen werden

    Wenn das spezifisch nur für D64 und Spezialsoftware sein soll frage ich mich, warum man das überhaupt braucht: Die Daten müssten dann ja von einer 1541 kommen bzw. dorthin geschickt werden und da bremst wieder der serielle Bus mit 2-Bit-Protokoll. Wenn von einem Parallelkabel in der 1541 ausgegangen wird frage ich mich stattdessen, wieso die Daten erst vom AVR zum C64 fliessen sollen und nicht direkt zum Laufwerk.

    Ich bin von der aktuellen Pin-Belegung meiner "sw-2"-Version ausgegangen. Wenn man die ganzen Pinbelegungen in der Software neu anordnen würde, braucht man dann aber auch eine komplett neue Platine.


    Ich hatte sogar zwei Shift-Register :) deshalb im Sinn. Jeweils eines für jede Richtung, die dann auf einer Userport-Platine untergebracht würden. Da stellt sich dann natürlich die Frage, ob man dann nicht doch gleich die ganze Platine mit dem AVR neu entwirft.

    Warum die Befehle unbedingt auf D64 zuschneiden? Das finde ich unnötig speziell und einschränkend. Wenn man eine schnellere Übertragungsmöglichkeit hinzufügt, wären Befehle wie "aktiviere Parallelverbindung" und "deaktiviere Parallelverbindung" deutlich universeller verwendbar, oder meinetwegen auch "sende jetzt alle Daten des Kanals mit Sekundäradresse X über die schnelle Verbindung" bzw. "alles was jetzt über die schnelle Verbindung kommt, schreibe in Kanal mit Sekundäradresse X". Das ließe sich dann für jede Art von Datei anwenden.


    Zumindest für die Richtung vom SD2IEC zum 64er könnte man auch das serielle Schieberegister der CIA verwenden, mit Bitbanging auf Atmel-Seite. Das reduziert den Hardwareaufwand noch weiter und ist auch nicht langsamer als Parallelbetrieb.


    Aber wie Unseen schon schrieb: Was will man mit einem kompletten D64 im 64er? Wenn Du die Hintergründe erläuterst, kommen evtl. bessere Vorschläge.

    Zitat von Mac Bacon

    Aber wie Unseen schon schrieb: Was will man mit einem kompletten D64 im 64er? Wenn Du die Hintergründe erläuterst, kommen evtl. bessere Vorschläge.


    Ich habe mich noch nie speziell mit Floppy-Programmierung beschäftigt. Ist es aber nicht so, dass die Floppy dafür umfangreiches Programm braucht ? - Einerseits zum Empfang der parallelen Daten und auch dessen Verwendung.
    Wenn es wie beim Star-Commander in ca. 40 Sekunden pro Diskseite erledigt wäre, hätte man dann die Idealverbindung, ohne dass noch zusätzliche Hardware gebaut werden muss.


    Bei direktem SPI mit dem C64 Shiftregister muss der AVR aber Slave werden ? - Ist per Software natürlich machbar. Die Idee finde ich gar nicht so schlecht, auch wenn es neues Programm braucht.


    Ich habe mir die Portbelegungen zur Shadow Wolf 2-Version (sw2) mal etwas genauer angeschaut. Da wird es mit einem freien Port und zwei Handshake-Leitungen schon schwierig. Wenn man "softi2c" und "wp" raus nimmt, könnte man klar kommen.

    Beim CIA-Schieberegister gibt es kein Master/Slave-Konzept: Wer die Daten erzeugt, erzeugt auch den Takt. Daher wäre die Richtung vom Atmel zum C64 auch sehr einfach per Bitbanging machbar. Man muss nicht einmal besonders aufs Timing achten, da die CIA einfach nur acht Taktbits zählt. Natürlich darf man nicht schneller senden als die CIA empfangen kann, aber Interrupt-Pausen zwischendrin wären kein Problem. Ich benutze diesen Übertragungsweg bei meinem Slave2CBM-Projekt vom PC-Parallelport zum 64er.
    Die andere Richtung ist dafür entsprechend schwieriger; um per Bitbanging empfangen zu können, muss der Empfänger schon schnell genug sein (und daher nutze ich für diese Richtung eben nicht das Schieberegister). Vielleicht ließe sich mit einer SPI-Slave-Komponente etwas machen, das käme auf einen Test an. Es ist allerdings softwareseitig bedeutend einfacher, das Schieberegister nur für eine Richtung zu benutzen, dann kann es nämlich nie für die falsche Richtung konfiguriert sein... :whistling:

    Zitat von Mac Bacon

    Vielleicht ließe sich mit einer SPI-Slave-Komponente etwas machen

    Das ist aber die gleiche SPI-Komponente, die aktuell schon im Master-Modus zum Ansprechen der SD-Karte verwendet wird...