Bitte melde dich an, um diesen Link zu sehen. Nein, wir haben keine universell verwendbare API implementiert.
Arduino am Userport
-
frickr -
4. August 2011 um 20:46 -
Erledigt
Es gibt 84 Antworten in diesem Thema, welches 16.595 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Bitte melde dich an, um diesen Link zu sehen. Nein, wir haben keine universell verwendbare API implementiert.
Das ist schade. Aber oft reicht es schon aus, wenn das Protokoll dokumentiert ist.
Ich bin trotzdem gespannt, was da kommen wird. -
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.
Ach, da muss man nichts erfinden.
Den Loader für den C64 hatte ich schon für PET und Plus/4 verwendet, der muss nur angepasst werden. Fand das gleiche Prinzip auch hier mit dem Raspi als WLAN-Brücke wieder: Bitte melde dich an, um diesen Link zu sehen. als ich eine Runde zum Thema gegoogelt hatte.
Die Kleinarbeit kenne ich, besonders wenn es in hohe Baudraten geht, aber das ist auch keine Lebensaufgabe. Wenn man ganz weit zurückgeht und im 6502-Code sucht, wird man das sicher auch im uralten SpeedDOS wiederfinden.Aber wenn es fertig werden sollte, auf dem Linux-PC läuft, schaue ich es mir natürlich gern an.
Ich bin jetzt soweit dass ich demnächst die erste Übertragung vom PC testen kann. Urlaub ist allerdings vorbei und da wird es auch bei mir etwas länger dauern.
-
Danke für den Artikel. Parallelen sind durchaus auch zu unserem Projekt zu finden. Wobei wir aber schon seit 2013 an dem Thema dran sind. Na ja, egal.
Ich wollte Dir jetzt auch nicht den Spaß an der Entwicklung nehmen und eben nur Bescheid geben, das wir da schon was in der Schublade haben.
Nicht das es nachher heißt, wir hätten nichts gesagt.
-
Danke für den Artikel. Parallelen sind durchaus auch zu unserem Projekt zu finden
(*) Das hat einen fundamentalen Grund: diese Routine wird seit über 35 Jahren so verwendet. Beim AVR wurde das etwas modifiziert, weil dort 16 knapp 1Mhz gegenüberstehen. Der AVR legt das Byte so schnell hin, dass der den C64 überrennen würde, wenn man das Abholen des Byte zwischen die Auswertung der Steuerleitungen legen würde. Zumindest wenn man schnell übertragen möchte.
Ich wollte Dir jetzt auch nicht den Spaß an der Entwicklung nehmen und eben nur Bescheid geben, das wir da schon was in der Schublade haben.
Nicht das es nachher heißt, wir hätten nichts gesagt.
Ich passe nur alt bewährte Routinen an, bei einem parallelen Transfer muss man nichts entwickeln (Siehe (*)). Mein PC steht nah am C64, also ist "by wire" eine schöne Lösung, WLAN wäre da eher unfreiwillig komisch oder "excessive nerdy". Das hat SKERN auch schon mit dem IEC-Bus in Arbeit.Meinetwegen können auch noch fünf andere Leute irgendetwas bauen. Ich baue es so, wie ich es einsetzen möchte. Wer das dann ändern möchte, kann das Git forken oder etwas ganz anderes verwenden. Ist mir vollkommen egal.
Meine Plus/4-Lösung mit dem Paddle der 1551 wird mittlerweile von den C16 Programmierern verwendet, wie ich in der C16-Facebook-Liste lesen konnte. Aber die haben auch nicht viel.
Beim Plus/4 konnte ich den internen "3plus1"-Mist rauswerfen und die Low Modulbank verwenden. Da suche ich auch für den C64 noch eine Lösung ohne das originale Kernal verändern zu müssen. Aber das müsste eigentlich mit einem schnöden 8K Lo-Modul machbar sein oder mit der Softwareversion, die sich selbst in den Tapebuffer relokiert.
Auch beides altbewährte Methoden. Erwähne es nur, falls jemand auf die Idee kommen sollte, dass da etwas entwickelt werden muss.
-
Also ich finde die idee von euch gut, wenn man z.B. auf dem c64Studio Codet und dann gleich auf der Real Maschiene testen könnte!
-
Wenn Du hier "altbewährtes" nutzt, dann verstehe ich nicht, warum Du in Post 47 mit Timing herumexperimentierst, anstatt wie von Kinzi empfohlen (und wie wir es übrigens auch machen) mit vernünftigem Handshaking? Sorry, ich habe den Eindruck, als trägst Du hier ziemlich auf. Aber ich bin jetzt hier raus. Viel Spaß noch weiterhin bei Deinen altbewährten Experimenten.

Also ich finde die idee von euch gut, wenn man z.B. auf dem c64Studio Codet und dann gleich auf der Real Maschiene testen könnte!
Gibts schon. Nennt sich Xlink. Zum X-ten Mal.

-
Wenn Du hier "altbewährtes" nutzt, dann verstehe ich nicht, warum Du in Post 47 mit Timing herumexperimentierst, anstatt wie von Kinzi empfohlen (und wie wir es übrigens auch machen) mit vernünftigem Handshaking? Sorry, ich habe den Eindruck, als trägst Du hier ziemlich auf. Aber ich bin jetzt hier raus. Viel Spaß noch weiterhin bei Deinen altbewährten Experimenten.
Ja, das ist auch so ein Experte, der ein Handshaking empfehlen wollte, das längst verwendet wurde, was ich ihm dann auch erklärte und offen legte. Hätte er aber auch am Screenshot erkennen können.
Abgesehen davon, meine Ausführungen lassen sich alle nachvollziehen.
Und wie kann man mit Basic ein Timig testen, das sich letztendlich im Bereich von 10-20khz bewegen wird ? - Ich hatte nur die grundlegende Funktion gezeigt und eine indirekte Frage gestellt. Und die bezog sich nur auch das Festlegen der Richtung beim Transfer.
Bei Deinen Provokationen und Unterstellungen solltest Du diesem Thema wirklich fernbleiben, dem Du gar nichts beitragen konntest.
-
Ja, das ist auch so ein Experte, der ein Handshaking empfehlen wollte, das längst verwendet wurde, was ich ihm dann auch erklärte und offen legte. Hätte er aber auch am Screenshot erkennen können.
Ich göaube nicht, dass ich mich hier von der Seite anmachen lassen muss.
Aus deinen Ausführungen ging für mich hervor, dass du Software-Handshaking machen willst, denn das hier ...
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.
... klingt für mich nicht nach Hardware-Handshaking. Und ich bitte um Verständnis, dass ich mir nicht die Schaltung deines Aufbaus aus dem Foto herausgezeichnet oder deinen Code auf dem Screenshot durchgeackert habe.
Ich wollte weder besonders gescheit sein noch besonders aufdringlich, sondern habe im Trugschluss, dass du in einem Forum etwas zur Diskusssion stellst - bzw. "indirekt fragst", wie du es bezeichnest - versucht, einen Beitrag zu leisten. Ich nehme aber hiermit zur Kenntnis, dass das gar nicht in deinem Sinne ist, input zu bekommen; zumindest nicht von mir.
Tut mir leid, dass ich mich eingemischt habe, kommt sicher nicht mehr vor.
-
Ich göaube nicht, dass ich mich hier von der Seite anmachen lassen muss.
Ja, sorry, war eben auch etwas angefressen, weil man hier nur mit "wir haben auch mal etwas Transfer gemacht, möchten niemanden demotivieren, aber lass es doch bitte sein" Sprüchen belegt wird.
Das Handshaking ging aus einem früheren Post hervor: Bitte melde dich an, um diesen Link zu sehen. . Ich hatte vorausgesetzt, dass das Thema auch gelesen wird.
Ist immer gleich: der C64 kann den IRQ von FLAG auswerten und hat PA2 zum Toggeln. Und das war immer schon so, aber schrieb ich ja auch schon mehrfach.
-
Ja, sorry, war eben auch etwas angefressen
OK, Schwamm drüber. Aber eine Frage gestatte mir noch - wo hätte ich hier das Handshaling erkennen sollen?
Bitte melde dich an, um diesen Anhang zu sehen.
Das ist der Screenshot, wie es auf meinem Schirm aussieht. Ohne schon wieder pöbeln zu wollen, es ist sehr schlecht zu erkennen.
-
Das ist der Screenshot, wie es auf meinem Schirm aussieht. Ohne schon wieder pöbeln zu wollen, es ist sehr schlecht zu erkennen.
Wenn PA2 und FLAG am Arduino angeschlossen sind, kann man wohl davon ausgehen, dass die auch verwendet werden. Was die Farbgebung angeht, da musst Du Dich an den Forenbetreiber weden.

Edit: vergessen, in diesem Post (Screenshot vom C64) wird es auch benutzt: Bitte melde dich an, um diesen Link zu sehen.
Es ist angeschlossen und wird benutzt, was wird das wohl werden ?
-
Wenn PA2 und FLAG am Arduino angeschlossen sind, kann man wohl davon ausgehen, dass die auch verwendet werden.
Wenn ich das in diesem Post erkannt hätte, hätte es mir vermutlich gezündet. Ich habe mir aber ehrlich gesagt nicht die Mühe gemacht, das irgendwie in eine erkennbare Form zu bringen.
Was die Farbgebung angeht, da musst Du Dich an den Forenbetreiber weden.
Ich verwende in solchen Fällen gerne Grafiken, die ich hochlade. Da bin ich mir sicher, dass andere das auch lesen können.

Aber ich nerve dich jetzt wirklich nicht länger - ich denke, wir haben unsere Standpunkte geklärt und die Streitpunkte soweit ausgeräumt. Gutes Gelingen bei deinem Projekt!

-
leider steht hier schon zuviel um mitreden zu können ohne das man alles mühsam durchlesen muss.
kann mir einer, hier ein kurze stichwort übersicht, schreiben?
geht es um eine sehr schnelle daten übertragung?
daten sehr schnell senden oder sehr schnell empfangen?
dann könnte ich etwas schreiben, wie ich es damals, beim pet, cbm und anderen geräten z.b. auch dem c64 gemacht habe.
auch meine schnellste kommunikation zwischen z.b. c64 und der 1541. also damals hat es keiner schneller gelöst.
und auch heutzutage würde ich es wohl, für kunden, noch so machen.meine kunden hatten ja manchmal timing probleme, da musste manches efektiver und schneller gelöst werden. eine umbau auf eine schnelle cpu war nicht einfach.
besonders ressourcen sparend sollte es auch meistens sein. die geräte damals hatten ja nur ein paar kb an ram.
ein pet oder vc20 hatte auch nicht besonders viel. dass reichte manchmal noch nicht mal für die programme, konnten ja auch nicht mehr als 32kb verwalten.
da musste ich auch hardware tricks manchmal anwenden. sonnst war es damals nicht möglich.
große betriebssystem änderungen waren auch teuer, da damls eproms klein (nur 1 oder 2kb) und sehr teuer waren. musste ich die original roms nehmen und
durch kleine z.b. 32 bytes (256 bit) proms nur bestimmte bereiche patchen. ein 256 byte prom kostete ca. 100 dm. und die proms sind nur einmal programmierbar.
dann überlegt man sich 10 x ob es auch laufen könnte. dann übersah man doch etwas.ich nannte es z.b. den endlosen (programm) speicher oder das endlose stack usw. je nach dem welche automatische hardware funktion es hatte.
gruß
helmut -
kann mir einer, hier ein kurze stichwort übersicht, schreiben?
geht es um eine sehr schnelle daten übertragung?
Mir wurde unterstellt dass ich wohl nicht weiss, wie der parallele Datentransfer am Userport funktioniert.
Hatte ich damals schon mit dem PET gemacht und wollte es jetzt einen Ardunino am C64 nutzen.
Ist und war immer gleich: flankengertiggerter Eingang und ein zusätzliches Portbit als Steuerleitungen. Wie hier: Bitte melde dich an, um diesen Link zu sehen. , oder auch hier: Bitte melde dich an, um diesen Link zu sehen. und geht natürlich auch über Portbits wie hier: Bitte melde dich an, um diesen Link zu sehen. .Ich hatte nur darauf hingewiesen, dass es auch beim C64 seit ehe und je gleich ist. Also Fastloader und zig Transfertools es so nutzen. Allerweltswissen ... wurde aber in Abrede gestellt.
-
Mein Lieber, komm mal langsam von Deinem hohen Ross herunter und höre mit Deinen ständigen Sticheleien auf. Oder möchtest Du jetzt noch bis zum Sanktnimmerleinstag darauf hinweisen, das Dich (der große cbmhardware) mal einer als "unwissend" betitelt hat? Junge, Du hast Probleme. Sorry, es tut mir unendlich leid. Wird nie wieder vorkommen.

Edit:
Ich hatte nur darauf hingewiesen, dass es auch beim C64 seit ehe und je gleich ist. Also Fastloader und zig Transfertools es so nutzen. Allerweltswissen ... wurde aber in Abrede gestellt.
Nein, Du hast die Arbeit der anderen schlecht gemacht. Das eine ist Dir zu kompliziert (Xlink) und das andere (Servant64) passt Dir nicht, weil es zur Zeit nur auf Windows-Systemen läuft, was im Moment auch geändert wird.
Wie hast Du Dich genau ausgedrückt? Ach ja, das wäre "junk".
Das ist ein himmelweiter Unterschied. Es kommt immer darauf an, wie man es sagt. Und von Dir kam es ganz von weit oben, nach unter herab.
Also, die Nase mal wieder auf gleiche Höhe bringen und alles ist gut.
-
Nein, Du hast die Arbeit der anderen schlecht gemacht. Das eine ist Dir zu kompliziert (Xlink) und das andere (Servant64) passt Dir nicht, weil es zur Zeit nur auf Windows-Systemen läuft, was im Moment auch geändert wird.
Wie hast Du Dich genau ausgedrückt? Ach ja, das wäre "junk".Frage mal einen x-beliebigen Linuxer, ob ein nicht ausführbares Windows-Programm ganz toll oder junk ist. Du wirst immer die gleiche Antwort erhalten.
Und ich habe nichts schlecht gemacht. Xlink ist sehr gut ausgearbeitet und setzt nun mal nicht auf den Arduino, damit ist es hier offtopic. Nur zur Erinnerung: das Thema nennt sich "Arduino am Userport".Bei Servant64 kann ich nichts sagen, es ist nichts verfügbar.
Wir können doch einfach jeder seinen eigenen Ansatz verfolgen und damit glücklich sein. Und nach Fertigstellung meinetwegen auch gern Vor- und Nachteile gegenüber stellen.
Auf der Basis meiner jetzigen Software möchte ich später auch noch das uralte Crossload für den PET neu schreiben. Das ist für den DOS-PC und auch junk.
Und zum ersten Punkt: Ich habe nicht darauf hingewiesen, es wurde danach gefragt und der Rest ist eine Darstellung der Fakten. Die Sticheleien muss Du wohl eher bei Dir selbst suchen.
-
Gut, Schwamm drüber. Folgender Vorschlag. Wir fangen noch mal (in einem vernünftigen Ton) ganz neu an. Ohne irgendwelche Überheblichkeiten und ganz sachlich.
Was hältst Du davon? Ich bin dazu bereit.
Unsere Seite ist übrigens nur aus einem einzigen Grund offline. Wegen dieser bescheuerten DSGVO.
Es hätte jetzt wahrscheinlich auch gar keinen Sinn, Dir irgendwelche Windows-Codes vom alten Projekt zuzusenden?
-
Meinetwegen können wir gern nochmal neu starten.
Mit Windows-Software kann ich leider nichts machen. Was war das denn ? - Ein File-Selektor mit zusätzlichen Funktionen, die der Übertragung dienen ?
So eine komfortables UI würde für mich zeitlich den Rahmen sprengen. Mit Qt gehen da auch plattformübergreifend schöne Sachen, aber das würde wahrscheinlich niemals fertig werden.
Ist für mich eine Nummer zu gross.Setzte da auf Kommandozeilen-Tools in GCC.
-
Da muss ich jetzt mal als User von beiden System was sagen! Also Linux ist gut ja, aber wehe man will was nachinstallieren, dann fehlt das Packet oder die Lib usw.. Wenn es mal läuft alles gut, aber wehe es ist was dran, dann mus man sich schon echt gut auskennen. Also nichst für den normal User!
Windows seit Windows 7 Habe ich vieleicht 4 Bluescreens gehabt, also ich weis nicht was die leute immer meckern das Windows Instabiel ist usw.. Ich wette wenn auf einer Kiste Windows nicht geht, geht auch kein Linux. Denn dann ist meist das RAM Defekt oder irgend was anderes!
-