Neues Projekt MeGALoDOS

Gestern habe ich mich mit dem Arduino Code von Tommi_nrw im MeGALoDOS beschäftigt.

Ich habe seeehr viel gelernt über Arduino.

Mein Eindruck von Arduino, da ist alles easy und simpel, ist nun etwas getrübt.

Es ist nur simpel, wenn man ein Arduino Standard Board verwendet.

Aber letztlich hat es geklappt, dank der Hilfe von Tommi.

Nur zur Info, man muss in der Arduino IDE einiges installieren, damit es dann wirklich so easy ist, wie man es von Arduino gewöhnt ist.

Zum programmieren des ATmega328PB im MeGALoDOS genügt ein einfaches Arduino Board und 6 Drähte.

Es funktioniert nun tadellos.

Ich werde das heute auf der MeGALoDOS Wiki Seite dokumentieren.

Man muss nicht unbedingt ein Arduino Standard Board verwenden wichtig ist ja eigentlich nur der Microcontroller der verwendet wird. An was man sich halten muss sind halt die Vorgaben und Limitierungen wie das Arduino System den Controller handhabt.

Und wenn man sich mal daran gewöhnt hat über die SPI Schnittstelle zu programmieren anstatt per USB dann ist das Ganze eigentlich auch wieder sehr einfach.

Lektürensammlung SPI BUS:

Erstes Drittel dieser Ausarbeitung.

Man muss da nicht gleich das komplette Protokoll verstanden haben um den Bus zu nutzen. Muss ja auch niemand das komplette TCP/IP Protokoll verstehen um das Internet zu nutzen. Der SPI Bus ist in den Controllern integriert, ein billiger (unter 10 Euro) Programmer übernimmt die Kommunikation. Und selbst wenn man das Protokoll selbst programmiert ist das kein Hexenwerk solange man Master ist und das Timing in der Hand hat (hab ich bei meinem Joy-Controll 64 "damals" gemacht (also I2C in dem Fall)).

Zipcom : Also ich sitze hier so mit Jacky D. und Lola und wir sind nach langen Verhandlungen zu der Ansicht gelangt, daß das ganze ersteinmal mit Diddl und Tommi_nrw erörtert und alsdann abgesprochen werden muß.

Beim SPI BUS habe ich z.B. gelesen, das dieser nicht allzu lang sein darf. So auf ca. eine Platine begrenzt. Das ist nach meiner Auffassung evtl. nicht lang genug.

Zitat von WalkThatWay

Beim SPI BUS habe ich z.B. gelesen, das dieser nicht allzu lang sein darf. So auf ca. eine Platine begrenzt. Das ist nach meiner Auffassung evtl. nicht lang genug.

Es ist immer nur eine Frage der Geschwindigkeit, mit der die Daten übertragen werden.

Je höher die Geschwindigkeit, desto problematischer die Kabellänge, bei gleichem Kabeltyp.

In unserem Fall spielt Geschwindigkeit keine Rolle.

Wir übertragen da ja nur ein paar Bytes.

Es würde reichen, es zu morsen ...

UART habe ich vorgeschlagen, weil:

• es gibt Standard Soft-UART Implementierung beim Arduino
• es ist unproblematisch und leicht testbar
• es benötigt nur einen Draht
• es läuft sicher

Man könnte überhaupt den CBM-Bus nehmen:

• RESET auf GND ziehen -> Alle Geräte am Bus sind still und reagieren nicht.
• Währenddessen ATN, CLK, DATA für Übertragung verwenden.
• RESET wieder loslassen.

Zitat von kinzi

Währenddessen ATN, CLK, DATA für Übertragung verwenden.

Der Vorteil:

• das Kabel gibt es schon
• es könnte auch ein C64 Programm Kommandos senden an das meGALoDOS

Der Nachteil:

• mehr als ein Draht
• man muss den IEC anschließen am MeGALoDOS ATmega
• wie schließe ich aus, dass C64 und C64 ATmega nicht gleichzeitig "sprechen"
• ich kann keine Daten aus dem MeGALoDOS lesen

Zitat von Diddl

mehr als ein Draht

DATA und CLK sind bidirektional. Wenn ich "1-wire" irgendwo implementieren kann, dann hier auch.

Zitat von Diddl

man muss den IEC anschließen am MeGALoDOS ATmega

Ansonsten muss ich halt einen anderen Draht anschließen, ich sehe keinen Unterschied.

Zitat von Diddl

wie schließe ich aus, dass C64 und C64 ATmega nicht gleichzeitig "sprechen"

Protokoll?

Wenn man nicht gerade ein LOAD"*",8,1 macht, während man das ROM umstellt wird das sowieso nicht passieren.

Zitat von Diddl

ch kann keine Daten aus dem MeGALoDOS lesen

Natürlich kann man das, wieso nicht?

Ich möchte nicht, dass die beiden Controller über dieselben Leitungen kommunizieren, wie die beiden CPUs.

Zitat von Diddl

Ich möchte nicht, dass die beiden Controller über dieselben Leitungen kommunizieren, wie die beiden CPUs.

OK, wenn man nicht möchte, ist das natürlich das ultimative Argument.

Zitat von Tommi_nrw

Trotzdem würden die normale Kommunikation auf dem seriellen Bus und durch den Reset auch der

Zustand der Geräte dadurch beeinflusst.

Dem wage ich zu widersprechen:

Der Benutzer will das ROM wechseln. WAS sollt ein diesem Moment den Bus benötigen? Oder will jemand während eines laufenden Demos, Spiels, .... das ROM umschalten können? Selbst der Reset wäre egal - nein! Absolut notwendig, da ja das umgeschaltete Gerät jedenfalls einen ausführen muss. Dass die anderen Geräte mit resetted werden schadet doch nicht - wenn doch, würde ich gerne wissen wieso?

Aber gut, dann nicht mit Reset, dann mit ATN. Jedes Megalodos bekommt eine IEC-ID mit gesetztem Bit 3 - also das in Laufwerk 8 bekommt ID 16, usw. Dann kann man per normalem BUS kommunizieren.

Vorteil: Das ganze funktioniert auch ohne Parallelkabel.

Aber gut, ich bin schon wieder raus. Definitiv nicht meine Baustelle hier. ich wollte nur eine Idee liefern. Muss nicht jeder gut finden, ist mir klar.

Zitat von Tommi_nrw

Warum ? Ich und sicherlich auch die anderen schätzen Deine Ideen.
Und Du liegst ja nicht mal falsch...

Nein, nein, alles gut, ich wollte nicht "beleidigt" reagieren. Ich meinte damit nur, es ist natürlich dein Baby und du machst das so, wie so möchtest. Ich lasse mir ja bei meinen Dingen auch nicht gerne dreinreden.

Wären ESP32-Controller drin, könnte man gleich per Bluetooth oder WLAN drahtlos kommunizieren.

Zitat von Charly

Wären ESP32-Controller drin, könnte man gleich per Bluetooth oder WLAN drahtlos kommunizieren.

Ja genau.

Und eine ganze Menge Pegel Converter ...

Bloß keinen Bluetooth Müll. Lieber lege ich Kabel durchs ganze Haus.

Zitat von WalkThatWay

Evtl. Profibus?

Wie wäre es mit PROFINET? Da gibt es sogar schon Hardware für den C64, die das deutlich vereinfachen würde.