Hallo Mitstreiter,

wie im anderen Thread erwähnt, finde ich die Idee interessant, einen RP2350A (weniger Pins, Pi Pico 2) oder RP2350B (48 GPIOs) anstelle von CPU+RAM+ROM mit dem NKC-BUS zu verbinden. Damit könnte man die Peripherie (SOUND, Grafik, LCD usw.) mal per Micropython und ziemlich viel Rechenleistung ansteuern. Ob das klappt und sinnvoll ist, weiß ich noch nicht.

Ich habe mal eine minimale Verbindungsdefinition vorgegeben und die KI beauftragt, erstmal simple Routinen zum Schreiben auf die Peripherie oder zum Lesen davon zu erstellen. Da der RP mit Python zu langsam für die Hardwarezugriffe ist, wird dafür die PIO des RP genutzt.

Ich hänge mal den Code der Google KI (könnte eigentlich auch mein bezahltes Copilot nehmen) hier an.

NKC.txt

write_nkc.py

read_nkc.py

KI:

Wichtiger Hinweis zur Lücke bei den Side-Set Pins im Lese-Beispiel

In Ihrer Pin-Belegung liegt /WR auf GPIO 17 und /IORQ auf GPIO 18. Wenn die PIO side_set nutzt, müssen die Pins physikalisch direkt nebeneinander liegen.

* Beim Schreiben ist das perfekt (/WR=17, /IORQ=18).
* Beim Lesen benötigen Sie aber /RD (16) und /IORQ (18). Da GPIO 17 dazwischen liegt, funktioniert das side_set_base=Pin(16) hier nicht sauber, weil es GPIO 16 und 17 schalten würde, statt 16 und 18.

Zwei Lösungsmöglichkeiten hierfür:

1. Verdrahtung ändern (Empfohlen): Legen Sie /RD auf 16 und /WR auf 18 (oder umgekehrt) und platzieren Sie /IORQ auf GPIO 17. Dann können Sie für beide Operationen immer die Pins 16+17 oder 17+18 als kompaktes Side-Set nutzen.

2. Im PIO-Code manuell schalten: Falls die Verdrahtung fix ist, müssen Sie im Lese-Code auf side_set verzichten und die Steuerleitungen stattdessen zeitaufwändiger über normale set(pins, ...) Befehle innerhalb des PIO-Ablaufs auf Low und High ziehen.

Also nochmal die Belegung geändert. Dabei ist der KI gleich noch ein Fehler in ihrem Beispiel aufgefallen:

Diese Tabelle ist absolut perfekt und fehlerfrei für die Hardware-Emulation mit der PIO geeignet. Durch die lückenlose und logische Anordnung der Steuersignale (/RD=16, /IORQ=17, /WR=18) laufen die Buszyklen nun maximal effizient.

Ein kleiner, aber entscheidender Fehler steckte in meinem vorherigen Lese-Code: Die Richtung der Daten-Pins (GPIO 0?7) muss bei der Initialisierung der State Machines präzise definiert werden, da der RP2350 standardmäßig nicht weiß, ob die Pins Ausgänge oder Eingänge sein sollen.

Hier ist der vollständige, korrigierte und betriebsbereite Gesamtcode, angepasst an Ihre finale Verdrahtungstabelle:

NKC.txt

read_write_nkc.py

Mal sehen, wann ich noch dazu komme, das Board mit dem NKC zu verkabeln. Dann würde ich wohl als erstes mit der NKC-IO plus Service-IO oder der NKC-LCD erste Tests machen. Damit sieht man dann ja gleich etwas.

Warum tx_stall() und das Umschalten wichtig sind:

Da Sie den Pico direkt an den Z80-Bus hängen, müssen die Datenleitungen (GPIO 0?7) im Leerlauf immer hochohmig (Eingang / Tristate) sein. Wenn die write_io-Funktion aufgerufen wird, schaltet Python die Pins auf Ausgang, die PIO feuert die Signale ab, und sobald die PIO fertig ist (tx_stall), schaltet Python die Leitungen sofort wieder auf Eingang. So wird verhindert, dass der Pico dauerhaft gegen eine NKC-Karte ankämpft.

Welches spezifische I/O-Gerät des NKC (z. B. der Soundchip AY-3-8910 oder eine bestimmte PIO/PIO-Karte) soll als Erstes getestet werden? Ich kann Ihnen helfen, die Initialisierungs-Bytes dafür aufzubauen.