letzter Beitrag von Frenetic am
"Generieren". Du müsstest also einen schnellen Stein haben der auf dem Bus lauscht und wenn Adressenim Bereich des SID fallen dann die CS Leitung zieht. Anders macht das die PLA auch nicht.
"Generieren". Du müsstest also einen schnellen Stein haben der auf dem Bus lauscht und wenn Adressenim Bereich des SID fallen dann die CS Leitung zieht. Anders macht das die PLA auch nicht.
Die PLA berücksichtigt aber noch, dass man über $01 den I/O-Bereich ausblenden kann. Am Expansionsport bekommt man das leider nicht mit.
Verstehe ich das richtig, wenn $01 entsprechend gesetzt ist, dann könnte die CPU auf Speicher im Adressbereich des SID schreiben und gar nicht den SID meinen?
Genau, an der Adresse könnte ja gerade auch das Char-ROM oder RAM eingeblendet sein. Das ist allerdings nur ein Problem, wenn du den Expansionsport-SID unter der Originaladresse ansprechen willst - wenn der bei $DExx oder $DFxx eingeblendet werden soll kümmert sich die PLA schon darum und man kann einfach die IO1 bzw. IO2-Leitungen des Expansionsports verwenden.
Nachtrag: nicht, dass ich das versuchen wollte, nur Interesse halber -- ließe sich das Problem umgehen, wenn man $01 beim Schreiben erfasst, die Verknüpfungen der PLA nachbildet und dann CS richtig generiert?
Nicht wirklich - der 6510 schaltet bei Schreibzugriffen auf $00 und $01 den Datenbus nicht auf Ausgang, du siehst also nicht die geschriebenen Daten.
Warum den RPi nicht einfach auf eine der IO-Adressen $de00 oder $df00 lauschen lassen? Es gibt ausreichend Stereo-SID Anwendungen, die einen dieser Bereiche verwenden können.
Jens
kann man zum selektieren, bzw. Adressabfragen nicht auch nen Eprom nehmen ? Oder ist das nicht schnell genug ?
Warum den RPi nicht einfach auf eine der IO-Adressen $de00 oder $df00 lauschen lassen? Es gibt ausreichend Stereo-SID Anwendungen, die einen dieser Bereiche verwenden können.
Für einen 2. SID kein Problem. Aber ich will den 1. gleich mit ersetzen (derzeit habe ich den RPi am SID-Sockel + A5 (für Dual SID) + IO2 (für Sound Expander Emulation) und alles funktioniert gut) -- und wenn ich alles richtig verstehe, dann fehlt mir leider die Möglichkeit, das CS nur von Signalen am ExpPort zu erzeugen. Oder gibt's noch einen Trick?
kann man zum selektieren, bzw. Adressabfragen nicht auch nen Eprom nehmen ? Oder ist das nicht schnell genug ?
Das wäre die brute force Variante 
Ich dachte an 74xx um weniger RPi-Pins opfern zu müssen, aber s.o. scheitert wohl an grundsätzlichem...
Oder gibt's noch einen Trick?
Nein, es ist "von außen" praktisch unmöglich, bzw. nur mit großem Aufwand. Die Aufgabe ist ähnlich dem, was schon vor vielen Jahren vom 64er Magazin als Hardware-Wettbewerb ausgerufen wurde: Das Kernal-Replacement am Expansionsport, welches 100% kompatibel zum internen Kernal ist. Auch hier fehlt Dir die Information über den Inhalt der Prozessoradresse $01. Beim Kernal ist es aber einfacher, denn man kann durch einen kurzen Impuls auf einer der oberen Adressleitungen die "gefundene" Adresse im Kernal-Bereich auf eine externe ROM-Adresse ummodeln, schaut nach einigen zehn Nanosekunden, ob der Select-Pin wackelt und kann dann Rückschlüsse ziehen über den Zustand der HIRAM-Leitung.
Beim IO-Bereich funktioniert das leider gar nicht, denn man hat "außen" nur die $de00 und $df00-Bereiche die man abfragen könnte. Im Vergleich zu $d400 müssen aber Adressleitungen von 0 auf 1 gezogen werden, um ein derartiges sub-cycle-probing durchzuführen. Das ist aber in NMOS bzw. HMOS-Schaltungen nicht erlaubt, denn es würde den Adresstreiber des 6510 überlasten.
Es hat seinerzeit Lösungen gegeben, die mit einem zusätzlichen 6510 Prozessor außen am Expansionsport gearbeitet haben. Das ist "nahezu elegant", denn der kann komplett passiv laufen, indem man seine AEC-Leitung auf "jetzt bitte hochohmig" schaltet. Man greift einfach den Zustand der unteren drei $01-Portbits ab und hat die nötige Information, die man für eine Kopie des IO-Select Signals benötigt.
Nun wachsen 6510-Prozessoren nicht gerade auf Bäumen, so dass ein solcher Ansatz im Jahr 2018 nicht mehr gangbar ist.
Wir hatten mit dem Chameleon das gleiche Problem - schließlich ist das Chameleon gestartet unter dem Arbeitstitel "VGA64" - es sollte damals nur ein Flicker fixer für den Expansionsport werden. Da wir aber extern nicht so leicht herausfinden konnten, ob ein Registerzugriff auf den VIC oder ins RAM geht, mussten wir einen Prozessor mit in den FPGA holen. Der Rest ist Geschichte 
Die IO-Gleichung in der PLA benötigt alle drei Signale des $01-Registers: Loram, Hiram und Charen. Der Rest ist (bis auf AEC, was man mit BA eigentlich hat) am Expansionsport verfügbar.
Hach, wie wäre wohl die Geschichte der C64-Hardwarerweiterungen verlaufen, wenn Commodore damals dem Expansionsport vier mehr Pins gegeben hätte: Die drei $01-Bits und einen Override-Pin, der die Auskodierung in der PLA abschaltet...
Jens
@Wiesel Vielen Dank für die ausführliche Erklärung!
Ich befürchte fast die "eleganteste" Lösung für mein Vorhaben ist eine Platine am Expansionsport (selbiger durchgeschleift) an dem ich an alles herankomme außer SID-CS. Und das CS separat nach außen legen. Gibt's noch einen ungenutzten Pin an einer Buchse, den man missbrauchen könnte? (z.B. einen Pint mit Zwischenstecker bei der Videobuchse abgreifen ... da ist nur leider Pin7 schon für "klassische" Stereo-SIDs und Pin8 beim 128er anderweitig belegt -- was macht der da eigentlich mit +5V?).
Gibt's noch einen ungenutzten Pin an einer Buchse, den man missbrauchen könnte?
Wenn's nur für Deine Maschine sein soll, dann könntest Du einen der Massepins am Expansionsport umfunktionieren. Die oberen zwei sind sehr einfach zu kapern: Einfach durchknipsen, hochbiegen und das SID-CS Signal dran löten. Nur empfohlen für Maschinen, die ohnehin schon verbastelt sind!
Jens
Beim Prologic DOS (Speeder am Expansionport) lief es so, dass man das Signal intern abgegriffen hat (ich glaube per per Zwischensockel unter der CPU) und den Draht durch den Modulport nach aussen gefuehrt und auf einen PIN-header der Modulplatine gesteckt hat. Das war eigentlich ganz OK so. Nur musste man den Rechner eben einmal mal Aufschrauben. Fortan baumelte das Kaebelchen dann aus dem Modulport.
Ich habe mir fuer meine experimentellen SID Platinen am Modulport auf diese Weise die 12V fuer die SIDs nach aussen gelegt. Aber die braucht Dein RasPi ja zum Glueck nicht
@andi6510 Auf Deinen Tipp hin, habe ich mir gerade die Installationsanleitung angesehen... abenteuerlich Eigentlich wäre ich davor zurückgeschreckt, aber wenn die das durften, dann wäre das für mich auch was. Vielleicht mit einem so schicken Kabel mit Klemme wie bei Eurem FPGASID. Dann sollte ich optional zwecks Harmonisierung vielleicht einen Modus haben um einen SID #3 und #4 zu emulieren 
