250466+ oder der Versuch ein klassisches Board etwas zu optimieren

Klar, dauerhaft will ich nicht eingreifen. Wenn aktives Eingreifen notwendig ist, dann nur bei gedrückter Restore-Taste. Und filtern will ich eventuell auf meiner Seite, damit der Tastaturscan des C64 mir keine falschen Tastendrücke vorgaukelt. Natürlich könnte mein Scan kurzzeitig zu Fehlerkennungen seitens des C64 führen, aber einen Tod muß man sterben. SID-Adressen und Kernal schaltet man ja nun auch nicht pausenlos hin und her und nicht unbedingt mitten in einem Spiel oder während man EPROMs programmiert.

Ich hätte jetzt auch gedacht, daß man über die IRQ-Leitung abschätzen kann, wann normale interruptbasierte Tastaturscans ablaufen und dann die eigenen Eingriffe so timen kann, daß man eine Kollision vermeidet. Klar, es kann immer irgendwelches wildes Polling irgendwo laufen, aber wie gesagt: ein absolut 100% kollisionsfreier Scan ist vermutlich nicht notwendig.

Eventuell gibt es auch andere Strategien. Eigentlich sollte es auch möglich sein, durch Überwachen der Column/Row-Pins das Timing des Scans dynamisch abzuschätzen und dann aufgrund der letzten N Erfassungen eine Lücke abzupassen. Oder so.

Die Idee ist ja daß man die Restore-Taste nur dann länger drückt, wenn man nicht gerade wild auf der Tastatur rumhackt, am Joystick rüttelt oder das Diagnosemodul laufen läßt.

ich habe ja nicht gesagt, daß das nicht möglich ist, aber das ist ganz klar nicht Ziel meiner kleinen Mikrocontrollerplatine und auch nicht als Feature in meinem 250466+ eingeplant. Hätte ich sowas geplant, hätte ich die Chroma-/Luma-Signale ebenfalls abgreifbar machen müssen. Habe ich aber nicht. Also müßte man die Leitungen woanders auftrennen, ich bräuchte einen viel fetteren Mikrokontroller usw. Aber natürlich sollte es möglich sein, dieses Overlay-Board auch mit meinem Board zu verwenden und die entsprechenden Kernal-/SID-/Joystick-Steuerleitungen als Eingänge zu benutzen.

Das Overlay ist sicher ein cooles Projekt, aber halt für meinen Fall schon ein bißchen "over the top". Ich habe in meinem Brotkasten derzeit vier Kernals, von denen ich aber nur 1-2 nutze. Den SID werde ich noch weniger oft umschalten und für den Joystickport reicht die LED.

Na ja, bei echten SIDs und meinem Board muß man da Jumper setzen oder man kriegt es über diese Mikrocontrollerplatine hin.

Habe das bislang nicht näher erforscht, aber die IRQ-Leitung zwischen CPU, VIC, CIAs und Expansionsport erlaubt es doch, die Auslösung der IRQ-Routine zu beobachten, in der üblicherweise der Tastaturscan usw. läuft. Zumindest solange da keine Rasterzeileninterrupts programmiert sind, sollte man die Periodizität erkennen und die eigene Abfrage möglichst mittig zwischen zwei Durchläufen ausführen können.

Alternativ könnte man auch Spalten- und Zeilenpins direkt beobachten. Wenn man eine Periodizität beobachtet, legt man den eigenen Scan in die Mitte, ansonsten (längere Zeit nie low -> Timeout), riskiert man einfach einen unmittelbaren Scan. Vermutlich würde auch jeweils eine Zeile und eine Spalte reichen.

Oder die ganze primitive Lösung: man wartet für bis zu 25ms, ob eine der beobachteten Zeilen/Spalten eine fallende Flanke hat. Falls man eine solche Flanke beobachtet, dann wartet man 1ms und startet den eigenen Scan. Ansonsten startet man ihn nach Ablauf der 20ms.

Das macht man N mal und entscheidet dann, ob man einen einzelnen Tastendruck oft genug erkannt hat, um sicher zu sein, daß eine der beobachteten Tasten gedrückt wurde. Das sollte eigentlich robust genug sein. Und falls man dann doch mal einen Scan auf dem C64 stört, dann ist das halt so.

Na ja, wie gesagt; ich würde jetzt mal davon ausgehen, daß niemand wild am Joystick rüttelt oder auf der Tastatur eingeschlafen ist, während er gerade per Restore+1 o.ä. den Kernal umschaltet.

Außerdem würde eine dauerhaft auf Low gezogene Joystickleitung (o.ä.) den ganzen Tastaturscan betreffen und nicht nur meinen Kram und was nicht geht, geht dann halt nicht.

Das mit dem dauerhaften Low-Pegel wegen des PotXY-Multiplexers sollte eigentlich nur PA6 (exklusiv) oder PA7 betreffen und auch nur bei Spielen/Applikationen, die eine Maus (wenige) oder Paddles (noch weniger) benutzen. Aber gut, das ist ein berechtigter Einwand. PA6 zu verlieren wäre mir weitestgehend wumpe. Auf PA7 liegen halt die Tasten 1 und 2, die ich für die Kernalumschaltung benutzen wollte, aber irgendwas ist ja immer.

Und sich auf den passiven Scan zu Verlassen ist halt auch etwas riskant. So lange es nur um den BIOS-Keyscan geht, ist das ja nur ein Timingproblem. Aber bei beliebigen Spielen weiß man ja gar nicht, auf was für kranke Ideen die Leute so kommen. Und es ist ja nicht gesagt, das ein Spiel, das nur Space und einen Joystick abfragt, überhaupt einen kompletten Scan macht. Es wurden ja auch schon Demos usw genannt, die gar keinen Scan machen.

Offen gestanden würde ich mich auf den Standpunkt stellen, daß ein eigener Scan immer noch die relativ robusteste Lösung ist Zur Not halt ohne PA6/PA7. Wenn halt zu diesem Zeitpunkt ein Scan aktiv verhindert wird, indem die CIA-Ports dauerhaft gegen Masse geschaltet sind, dann kann man halt zu diesem Zeitpunkt die Umschaltung nicht vornehmen, aber ein (harter) Reset über langes Drücken von Restore geht immer und danach sollte man im Basic sein und umschalten können. Das mag zwar dann nicht perfekt sein, aber immer noch besser als die Kiste aufzuschrauben und Jumper umzustöpseln.

Wenn es nur um die Kernalumschaltung ginge, die eh immer einen Reset machen soll, könnte man natürlich ganz pragmatisch sein und die Resetleitung ziehen, bevor man den Scan startet. Dann wären die CIAs im Reset und damit aus dem Rennen und man könnte schätzungsweise in aller Ruhe nach Belieben scannen. Keine Ahnung wie sinnvoll eine Umschaltung des SIDs ohne Reset ist. Könnte dazu führen, daß der SID nur teilweise initialisiert ist oder so.

Zugegebenermaßen würde ich aber zumindest den Joystickport schon gerne ohne Reset umschalten. Das wollte ich eigentlich mit Restore+J oder so machen. Aber in der Not würde es vermutlich auch über eine Restore-Sequenz gehen (Lang-kurz oder so).

Wie der Kernal-Scan im Prinzip funktioniert, ist mir einigermaßen klar. Da wird eine 0 durch PA geschoben. Hatte mir mal im Rahmen einer Mausdiskussion den Quellcode angeschaut. Damals hatte ich also schon mal gesehen, daß PA7 nach dem Kernal-Scan auf 0 bleibt und gleich wieder vergessen.

Aber den Kernal-Scan mitzulauschen ist halt wie weiter oben erwähnt auch nur so eine 20%-Lösung. In Spielen, Demos usw. würde die Tastaturabfrage dann u.U. gar nicht funktionieren. Man kann ja einen Funktion schreiben, die stattdessen eine 0 durch PB schiebt oder man kann nur einige wenige Spalten/Zeilen abfragen oder gar keine.

Beim Kernal stimme ich Dir ja zu, aber wie gesagt wollte ich den Joystick schon gerne im Spiel umschalten.

Ich würde auch nach wie vor annehmen, daß dauerhaft auf low gezogene CIA-Ausgänge bis auf PA7/PA6 eher die Ausnahme sind. Aber wenn ich auf PA6/PA7 verzichte, sollte ein eigener Scan bei gedrückter Restore-Taste eigentlich machbar sein und ich würde hoffen/erwarten, daß man damit in den allermeisten Spielen usw. die restlichen Tasten erfassen könnte. Wobei das zugegebenermaßen mehr eine Annahme ist. Müßte man wohl man praktisch testen, aber das ginge besser mit meinem Board.

Acht Direktwahltasten für den Kernal wären halt ganz cool gewesen, aber ohne PA7 fehlen mir halt die 1 und die 2. Man könnte immer noch 3 bis 0 nehmen, aber sonderlich logisch ist das nicht. Oder A-H, aber die sind wild über die Tastatur verteilt.

Es gibt halt nur vier Funktionstasten, die würden sich für den SID als Direktwahl anbieten. Mehrere Tasten auf einmal will ich eigentlich vermeiden. Außerdem ist die rechte Shift-Taste auf PA6. Gäbe noch die Möglichkeit, eine "+/-"-Auswahl mit zwei Tasten zu machen, aber dann müßte man im Zweifel viermal drücken bis zum richtigen Kernal.

Ist leider alles wieder komplizierter als es mir lieb ist.

Im Nachhinein betrachtet wäre es möglich gewesen, die 16 Leitungen zum CIA per Analogschalter o.ä. abzutrennen, aber das wäre halt auch ein riesiger Aufwand für eine 100%ige Lösung.

Ist zwar nicht sonderlich logisch, aber mit A-H für die Kernalauswahl, F1-F7 für die SID-Adressen, S und K für die SID-/Kernal-Blinkinfo und J für die Joystickumschaltung würde ich mit je 5 Spalten und Zeilen auskommen.

In der allergrößten Not könnte ich ja immer noch eine Platine in den Tastaturstecker einschleifen, aber genau das wollte ich ja eigentlich vermeiden. Ich versuche es erstmal so. Gibt ja genügend Ausweichstrategien.

Ist schon klar, aber Du hast Dir ja auch nicht gerade ein eigenes Board entworfen, das sowas theoretisch gleich hätte einbauen können ;). Wobei die 100%-Lösung halt 16 Analogschalter gebraucht hätte und das wäre mit DIP-ICs ein ziemlicher Aufwand geworden. Aber wie gesagt: ich bin halb optimistisch, daß man das auch ohne die Schalter ziemlich gut hinkriegen kann.

Wie gesagt: die Kernal-Scans sind nur ein Timing Problem. Dazu müßte man keine Schalter benutzen. Für alles außerhalb des Kernal-Scans müßte man eigentlich beide Seiten der Matrix trennen.

Jupp.

Im "Dual Mono"-Modus wird auch die R/W-Leitung des zweiten SIDs manipuliert, damit immer vom ersten SID gelesen wird. Zumindest in der Theorie