Hallo Besucher, der Thread wurde 15k mal aufgerufen und enthält 84 Antworten

letzter Beitrag von cbmhardware am

Arduino am Userport

  • Das ist aber kein Problem. Wie oben schon geschrieben schreibt der TapecartFlasher vom PC über Arduino Uno/Nano in das Tapecart-Modul 2 MByte in 7 Minuten.
    Bei einem Arduino Pro Micro sogar in nur 4 Minuten.
    Das Schreiben von SD-Karte dauert auch 4 Minuten. Beim Pro Micro spielt die PC-Kommunikation also kaum eine Rolle.
    Für meine Zwecke ist das ausreichend schnell.

    Ich suche eher die direkte Lösung fürs CrossDev, also Programm übertragen und ausführen. Dafür muss man auch die Übertragungsgeschwindigkeit nicht ausreizen.



    Das ist jetzt eine Kommunikation zwischen Arduino und PET - ohne PC nehme ich an.


    Eher alter Käse mit einem uralten AVR. Aber ja, so schnell könnte es vom statischen Stein kommen. :)

  • ch suche eher die direkte Lösung fürs CrossDev, also Programm übertragen und ausführen. Dafür muss man auch die Übertragungsgeschwindigkeit nicht ausreizen.

    Ja, genau das ist auch meine Idee.


    Also schauen wir mal, wie wir mit unseren unterschiedlichen Ansätzen voran kommen.


    Falls du von deinem Shield welche übrig hast, würde ich vorsorglich 1-2 Stück abnehmen. Falls ich mit meiner Idee scheitern sollte.

  • Ich werde erst noch mal ausmessen, wie schnell die Programme vom Tapecart-Modul geladen werden.

    Die reine Datenübertragungsgeschwindigkeit liegt beim 2-Bit-Protokoll bei ca. 9500 Byte/s, ohne den Overhead für Aktivierung des Command Mode und Senden des Ladebefehls.

  • Ja, genau das ist auch meine Idee.
    Also schauen wir mal, wie wir mit unseren unterschiedlichen Ansätzen voran kommen.


    Falls du von deinem Shield welche übrig hast, würde ich vorsorglich 1-2 Stück abnehmen. Falls ich mit meiner Idee scheitern sollte.


    Lese ich da eine Unsicherheit ? :o)


    Ich habe jedenfalls alles am Start, muss den C64 nur noch mit dem Arduino verkuppeln. Mal sehen was so geht ...


    arduino4c64.jpg

  • Nach Tausch der wohl teildefekten Arduino-Platine war erstes Programm schnell fertig. Der Arduino lauscht dem C64 und baut sich aus den eingehenden Nibbles (pb0-3,pc0-3) ein Byte. Das wird im Moment zur Endkontrolle auf dem LCD ausgegeben.


    Es wäre wohl sinnvoll, wenn der C64 dem Arduino auf einfache Weise mitteilt, in welche Richtung die Datenübertragung gehen soll. Meine Idee: als erstes Byte $00 für Empfangen oder $ff für Senden zum Arduino übertragen. Danach für beide Seiten ausreichend (ms) Zeit, damit die Ports entsprechend konfiguriert werden können.
    Und danach könnte man dann vom C64 zum PC oder andersherum transferieren.



    c64.jpgc64_arduino.jpg

  • Es wäre wohl sinnvoll, wenn der C64 dem Arduino auf einfache Weise mitteilt, in welche Richtung die Datenübertragung gehen soll. Meine Idee: als erstes Byte $00 für Empfangen oder $ff für Senden zum Arduino übertragen. Danach für beide Seiten ausreichend (ms) Zeit, damit die Ports entsprechend konfiguriert werden können.
    Und danach könnte man dann vom C64 zum PC oder andersherum transferieren.

    Warum kein(e) Handshaking bzw. Signalisierung? Am Arduino ist sicher noch was frei, und am Userport wären PA2 und /FLAG da:


    /FLAG -> löst Interrupt aus -> Anforderung: Arduino will senden
    PA2 -> Richtungsanzeige oder Sendefreigabe oder was auch immer:

    • PA2=1 -> Arduino darf senden, C64 ist bereit.
    • PA2=0 -> C64 sendet, Arduino muss hören. (Interrupt beim Arduino auslösen -> sofort auf Empfang schalten!)

    Oder so. (Nur so eine Idee. :) )

  • Im meinem letzten Post kann man auf dem Foto erkennen, dass ich mit PA2 geclocked habe. ;) FLAG ist auch schon längst eingeplant als Steuerleitung. Der C64 bekommt PA2 und empfängt auf FLAG.


    Wenn es eine zusätzliche Leitung werden soll, wäre da höchstens die beiden Shift-Register.

  • Ah, OK, dann bin ich eh schon wieder still. :D

    Nur 8 Bit auf den Bus legen wird nichts, da gehören auch zwei Steuerleitungen dazu. Werde wohl erst mal das Empfangen mit dem C64 testen. Ist teilweise vom 1551USB übernommen, aber gesamt noch nicht getestet.


    Aber so könnte es aussehen (Auszug):


    Für die zwei Funktionen dürfte ein Case reichen.

  • Für mich sieht das so aus, als wenn ihr gerade das Übertragungsprotokoll vom XLink nacherfindet...

    Tools zur parallelen Übertragung gibt es schon ein paar Jahrzehnte länger. Meine erste Version für den damaligen Druckerport schrieb ich vor über 15 Jahren.
    XLink ist leider nicht für den Arduino zu gebrauchen, schlecht nachbaubar (keine Platine, USB-AVR in SMD-Pitch) und verfolgt auch einen anderen Ansatz.
    Ich suche die kleine Variante zum problemlosen Nachempfinden. Also: fertige Platine und die notwendigste Software zum Übertragen in den freien Speicher. Der USB-Loader wird nur den Tape-Buffer (<190 Bytes) belegen und das Kernal muss nicht geändert werden.


    Es ist eine parallele Übertragung wie eh und je, verfolgt aber einen ganz anderen Ansatz als XLink auf anderem AVR.

  • Für mich sieht das so aus, als wenn ihr gerade das Übertragungsprotokoll vom XLink nacherfindet...

    Naja, Bausteine wie der 6526 und vor allem die Vorgänger 6522 und 6520 sind nun mal für die parallele Datenübertragung entwickelt und auch dafür optimiert worden.
    Dafür haben sie parallele 8-Bit-Port und dazu passende Handshake-Leitungen. Wie die parallele Kommunikation gedacht war, ist in den Manuals und diversen Büchern schon Ende der 70er beschrieben worden.
    Ich glaube nicht, dass Xlink die parallele Kommunikation erfunden hat. :D


    Der 6522 hatte eine flankengetriggerte Latchfunktion. Der Sender musste also nicht warten, bis der Prozessor hinter dem 6522 die Daten abgeholt hat und konnte zwischenzeitlich bereits neue Daten anlegen. Ich weiss nicht, in wie weit das beim 6526 erhalten geblieben ist.

  • Ich weiß nicht, warum man hier das Rad noch mal neu erfindet. Nehmt einfach Servant64-Modul und ihr habt alles. Hätte sogar noch Platinen da.

  • Ich weiß nicht, warum man hier das Rad noch mal neu erfindet. Nehmt einfach Servant64-Modul und ihr habt alles. Hätte sogar noch Platinen da.

    Ich kann dazu leider keine Software für (Debian) Linux finden. Die Webseite dazu ist im Wartungsmodus und ich kann auch generell nichts zum Nachbau finden.
    Soweit ich es gesehen habe ist die Software für Windows und VB.NET ? - Damit kann ich leider gar nichts machen. Windows und nicht plattformübergreifende Software ist junk.

  • Windows und nicht plattformübergreifende Software ist junk.

    Genau solche Aussagen haben auch damals zum Motivationsverlust geführt. Wir haben uns nun mal für Windows und VB.Net entschieden.
    Es stand jedem frei, sich am Projekt zu beteiligen und es auf eine universellere Sprache zu portieren. Das wollte sich aber auch keiner antun.

  • Genau solche Aussagen haben auch damals zum Motivationsverlust geführt. Wir haben uns nun mal für Windows und VB.Net entschieden.Es stand jedem frei, sich am Projekt zu beteiligen und es auf eine universellere Sprache zu portieren. Das wollte sich aber auch keiner antun.


    Das ist (für mich) nun mal so, ich kann auch beim besten Willen nichts mit Windows-Software machen. Da laufen nur wenige Sachen wirklich stabil mit Wine oder Mono.


    Notiert sich "alles ins Git, Quelltexte und Schaltung "

  • Musst Du wissen, ob es sich lohnt, das ganze hier noch mal neu zu erfinden. Wir haben damals in mühseliger Arbeit ein eigenes Übertragungsprotokoll für das Servant64 entwickelt, welche aktuell auf eine neue Programmiersprache und Hardware portiert wird. Wie schon geschrieben, wird man bald von uns hören. :)

  • Windows und nicht plattformübergreifende Software ist junk.

    Naja, die Software im Arduino ist ja schon mal Plattform übergreifend. Der Arduino kann an Windows, Linux und MacOS angeschlossen werden.
    Ich programmiere selbst auch nur unter Windows. Deswegen kommt z. B. der TapecardFlasher mit einer USB-API, einem Windows-Frontend und einem Terminal-Mode, über den die wichtigsten Funktionen von jedem Betriebssystem erreichbar sind. Es hat dann auch nicht lange gedauert und Kim Jørgensen hatte ein Linux-Frontend geschrieben.


    Plattformübergreifende Frontends sind nach meiner Erfahrung oft der kleineste gemeinsame Nenner aller Plattformen. Das ist oft weniger als auf jeder Plattform möglich wäre.
    Das sieht man z.B. am neuen Gtk-Vice, mit dem viele Windows-User erstmal überhaupt nicht klar kommen.


    Für mich ist das Frontend zweitrangig. Wichtig ist die Firmware auf dem Arduino und die implementierte USB-API. Dann findet sich schon jemand, der ein schönes Frontend programmiert.


    Wir haben damals in mühseliger Arbeit ein eigenes Übertragungsprotokoll für das Servant64 entwickelt,

    Hat das Servant64 eine offene, dokumentierte USB-API, so dass man eigene Frontends dafür schreiben könnte?


    Musst Du wissen, ob es sich lohnt, das ganze hier noch mal neu zu erfinden.

    Ich finde es gut, wenn mehrere parallele Ansätze verfolgt werden. In der Regel befruchten sich die Projekte dann gegenseitig. ;)


    EDIT: Wenn es noch Servant64-Boards oder Platinen gibt, würde ich gerne eine oder zwei abnehmen. Für eigene Versuche am User-Port. Ich würde mich dafür auch als Servant64-Tester zu Verfügung stellen. :D
    Bei der VB.NET-Programmierung kann ich leider nicht helfen. Ich programmiere unter Windows nur C#.