Datentransfer zum CBM mit "nano488"

Genial! Bin schon voll drauf gespannt!

Super. Wuerde gerne investieren in diesem Projekt.

Natuerlich mit einer kleinen Gewinn Absicht ;-)))))))))

Genial. Genau an sowas war ich auch vor Jahren schon mal dran. Mit einem Arduino Uno.

Wäre super, wenn du Erfolg hättest. Dann muss ich mein altes Projekt nicht wieder ausgraben.

Ich bin übrigens am GET# gescheitert.

Oder genauer: wegen dem GET# Befehl hätte ich meine Arduino-Software dermaßen auf den Kopf stellen müssen, dass ich keine Lust mehr hatte.

LOAD und SAVE hatte ich schon funktionsfähig.

Ist sehe gerade auf dem alten Foto, dass ich dann irgendwann auch einen Nano verwendet hatte.

Also ich drücke dir wirklich die Daumen, weil ich gerade genau sowas brauchen könnte.

Das XS1541 macht das schon auf einem ATmega

https://www.c64-wiki.de/wiki/XS1541

Zitat von fachat

lass mich raten, der DIR Befehl, oder?

Der macht im Prinzip lauter GET# ...

Der ist so grottig programmiert im BASIC 4

Nein, es ist der GET# Befehl an sich. Der ist ja schon beim Basic 2 grottenlahm, wenn man zeichenweise aus einer Datei lesen will.

Der CBM sendet bei jedem GET# ein TALK an die Floppy (die Datei muss natürlich zum Lesen geöffnet sein).

Dann wird ein Zeichen empfangen und dann wird der Empfang mit ATN abgewürgt und UNTALK gesendet.

Und das bei jedem einzelnen Zeichen. Das ist schon ein ganz schöner Overhead.

Mein Protokoll zwischen Nano und PC gab es einfach nicht her. Ich hatte das vorher nicht durchdacht.

Dafür hätte ich den IEEE-Handshake an den PC durchreichen und die Daten Zeichen für Zeichen anfordern müssen.

Ich habe dann angefangen, das umzubauen, dann kamen andere Sachen dazwischen und dann ist es liegen geblieben. Und da liegt es seit 5 Jahren.

Ich hätte einfach LOAD und SAVE fertig machen sollen. Dann hätte ich mit der Software wenigstens Programme von PC auf den CBM übertragen können (und umgekehrt). Wie gesagt, hat das ja prinzipiell funktioniert. Aber ich wollte es mal wieder hunderprozentig machen.

Zitat von Diddl

Das XS1541 macht das schon auf einem ATmega

https://www.c64-wiki.de/wiki/XS1541

Das ist genau andersrum. Damit kann man eine IEEE-Floppy an den PC anschließen. Bei dem Projekt von fachat geht es darum, einen PC als Floppy an dem CBM anzuschließen. Der Vorteil ist, dass die Floppy-Files alle schon auf dem PC liegen. Man muss sie nicht extra auf SD-Karte kopieren und in ein SD2IEC oder petSD+ stecken. Größere Programmsammlungen lassen sich so leichter auf dem PC verwalten und man kann sie direkt mit dem CBM abrufen.

Das XS1541 ist ziemlich veraltet. Um IEEE-Floppys an den PC anzuschließen, verwendet man inzwischen das ZoomFloppy.

https://www.c64-wiki.de/wiki/ZoomFloppy

Was XD2031 macht, habe ich noch nicht verstanden.

Zitat von Toast_r

Damit wird das XS-1541 für den CBM als Floppy ansprechbar, und verbindet über USB zu einer Server-Software auf dem PC.

Der Server kann Verzeichnisse auf dem PC oder auch Diskimages freigeben.

Es können mehrere Laufwerke gleichzeitig zur Verfügung gestellt werden.

Ich dachte, das wäre genau das, was fachat hier bauen möchte.

Also geht es hier darum, für die XD2031 Firmware eine schlankere Hardware zu entwickeln?

Das heisst also, wenn ich XD2031-Firmware auf mein petSD+ aufspiele und den XD2031 Server verwende, dann kann ich jetzt schon auf den PC zugreifen?

Ok, dann macht das natürlich Sinn, das auch einem Nano ohne SD-Karte laufen zu lassen.

Und wenn es die Firmware und Server schon gibt, dann wird das ja auch funktionieren. Ich bin sehr gespannt!

Noch eine Frage zum XD2031-Server: Kann der auch Host-Verzeichnisse als Laufwerk zu Verfügung stellen oder arbeitet der nur auf D64-Images?

EDIT: Und gibt es irgendwo noch die Windows-Binaries zum Runterladen. Die Links in der Doku sind ja anscheinend tot.

Zitat von Toast_r

Es gehen die gängigen Image-Formate (D64,D71,D81,D80,D82) und Verzeichnisse auf dem Host.

Die von SD2IEC/petSD bekannten Verzeichnisbefehle funktionieren auch.

Das hört sich gut an!

Vielen Dank!

hallo andré,

Zitat von fachat

D.h. auch mit hardware-basiertem ATN-Ack.

super. so verschwendest du keine timing und speicherplatz ressourcen dafür.

besonders wenn dein programm und die funktionen noch wachsen.

durch die handshake leitungen kannst du den bus beliebig steuern, bis zu einem einzellschritt.

so hast du jede zeit zur verfügung für deine eigentliche software, die du benötigst.

Zitat von fachat

es sind echte IEEE488 Treiber drauf (75160/75161) um die Hardware kompatibel zu machen.

super, dann gibt es auch keine treiber probleme mit mehreren geräten am bus

Zitat von fachat

Da der Arduino nano mit seinem Atmega328p deutlich kleiner ist als der 644p auf xs1541 oder petSD wird es erstmal nur eine begrenzte Funktion geben - REL files, Direct channel Block Read/Writes sind rausgefallen.

von den atmega 324 in smd habe ich reichlich da und ein paar von den 1284.

besonders von den 324 könnte ich dir 10 stück und vom 1284 drei stück zusenden.

du könntest dir ja einen adapter auf dip / tht ja erstellen, am besten dann gleich mit quarz und den kondensatoren.

von den kleineren atmega 328 / xx8 wollte ich mir keine zulegen, die xxx4 haben auch mehr IOs.

und dann fängt man wieder an zusätzliche ics drumherum zu packen.

lg

helmut

Hast Du Dir mal stm32 blue pill angesehen? Mehr Speicher und höherer Takt. Wär das nix?

Zitat von daybyter

Hast Du Dir mal stm32 blue pill angesehen? Mehr Speicher und höherer Takt. Wär das nix?

Ist der irgendwo verfügbar? Die Atmels gibt's an jeder Ecke für ganz kleines Geld (ab 3-4 Euro).

Und ob das mit den 3,3V Pegeln ohne zusätzliche Pegelumsetzer mit den IEEE-Treibern klappt, weiß ich nicht.

https://m.de.aliexpress.com/item/1005002721621360.html

Ich hab mich eingedeckt, als man den überall unter 3,- bekommen hat.

Hab auch noch etliche von den billigen Levelshiftern hier, obwohl die stm32 Pins ja fast alle 5v tolerant sind und 3,3v bei ttl als high gilt.

Zitat von daybyter

https://m.de.aliexpress.com/item/1005002721621360.html

Ich hab mich eingedeckt, als man den überall unter 3,- bekommen hat.

Das hilft leider anderen nicht, die das Projekt nachbauen möchten. Die sieht mir nach einen Auslaufprodukt aus.

Arduinos haben den Vorteil, dass die jeder nachbauen darf und es daher viele Hersteller gibt.

https://m.de.aliexpress.com/item/1005001798664558.html

Die blue pill werden so langsam durch black pill abgelöst. Die Schaltpläne beider Boards sind verfügbar und es gibt viele Lieferanten. Sie sind in der Arduino ide programmierbar.

Zitat von fachat

Edit 2: Hier https://www.mikrocontroller.net/topic/266204 wird das mit den Schrauben erklärt.

Das stimmt was da steht, es gibt schwarze (=metrisch) und silberne (=zöllig) Schraubverbindungen in der Norm. Das mag erklären warum sich manche Kabel verschrauben lassen und andere aber nicht.

Eine kurze Stichprobe hat ergeben, dass meine SFD1001 silberne Gewindebolzen hat, die 8250LP aber schwarze.

Vielleicht ist das Thema Schrauben doch nicht so zielführend, am Ende passt es dann doch nicht.

Dazu kommt noch, dass ja das Gewinde, mit dem der Bolzen in die Buchse verschraubt wird, zur Buchse passen muss. Mein Federbügelsockel von Reichelt hat die typisch zölligen "PC-Gewinde", aber meine vorhandenen "silbernen" Bolzen passen da nicht rein, die scheinen ein zölliges Feingewinde zu haben.

Jetzt verstehe ich warum axorp sich die drehen lassen will.