Forum64

Ich hab in den letzten Monaten versucht, mir möglichst viel der Funktionalität des C64 zu ergründen.
Ich hab in der Zeit auch einiges an Elektronik gelernt, dass ich auch viel mehr verstehe.
Aber über einen Port am C64 scheint es recht wenig technische Informationen zu geben. Dem Expansionsport. Ich hab jedenfalls nur sehr wenig dazu gefunden.

Jetzt hab ich mich bemüht, das Teil anhand der Schaltpläne, sowie der Beschreibungen der Hardware in der "64 Intern" zu erarbeiten und die doch ziemlich vorhandenen Lücken in dem Buch durch diese Webseite aufgefüllt.

Ich kam zu einigen Ergebnissen, aber immer noch vielen Fragen.

Warnung: Was jetzt kommt ist viel, und zu einem großen Teil nur für die, die die Hardware des C64 des C64 Willen erforscht haben.



Die erheblich einfachere Variante der Nutzung des Expansionsports ist die einfache Verwendung als Software-Cartridge.
Entscheidend dafür sind die folgenden Pins:

GAME: Wenn man das auf Low legt, sagt man dem PLA, dass da ein Speicherchip für 0x8000-0x9FFF am Address- und Datenbus vom Expansionsport hängt.
ROML: Das ist das Chip Enable für besagten Speicherbereich
EXROM: siehe GAME für 0xA000-0xBFFF. Überbügelt das BASIC-ROM.
ROMH: siehe ROML.

Das ist recht einfach. Die vollständige Kontrolle liegt beim Gespann MPU und PLA. Man muss sich um überhaupt nichts weiter kümmern. Aber abgesehen von den enthaltenen eventuell gestarten Programmen (Stichwort: Modulstart, siehe "Reset") hat das Teil keinerlei eigene Logik.

Immerhin, es gibt ja da noch den
R/W Ausgang: Bestimmt ob Daten am Datenbus geschrieben oder gelesen werden sollen.

So wie ich das sehe, spricht nichts dagegen, dass diese Speicher von 0x8000-0xBFFF nicht auch RAM sein könnten. Gut, nicht so sonderlich sinnvoll, weil sie ja fest beim Rechner-Neustart eingeblendet sind und nicht von der Seite des C64 wieder ausgeschaltet werden können, aber die eine oder andere Anwendung dafür könnte ich mir schon vorstellen. (z.B. selbstmodifizierendes Betriebssystem). Und man könnte natürlich EEPROMS verwenden. Das hätte schon einen gewissen Reiz.

Trotzdem, lieber wäre mir, wenn man auf den GAME-Bereich als Bank-Switch für eine Speicherbereich nutzen könnte.
Am Anfang habe ich mir überlegt, woher man die Informationen nehmen kann, welcher Bereich gerade eingeblendet wird. Meine erste Lösung war etwas, na ja, "messy". Mir schwebte eine Art "unsichbares Register" vor. Das Cartridge überwacht den Addressbus nach einer vorher ausgemachten Speicherzelle (z.B. im IO-Bereich) und horcht Schreibzugriffe darauf ab. Diese Speicherzelle wäre nicht lesbar, aber es würde funktionieren. Allerdings würde man die Speicherzelle für nichts anderes mehr benutzen können, selbst wenn man den IO-Bereich ausblendet.

Also, eine andere Möglichkeit muss her.

Es gibt da noch zwei andere Leitungen am Expansionsport:

I/O1: 0xDE00-0xDEFF
I/O2: 0xDF00-0xDFFF

Das hört sich schon erheblich mehr nach dem an, was ich suche. Wie genau man diese beiden Leitungen verwendet, um Register zu etablieren, das hab ich noch nicht vollkommen raus. Ist etwas kompliziert im Schaltplan. Aber das krieg ich noch raus.
Wenn ich meinen Register im I/O-Bereich habe, kann man die Speicherbereiche, die über GAME und EXROM eingeblendet werden, einfach so umblenden. Das ist schon eher was für eine Speichererweiterung! Wenn auch sehr grob.
Ich weiß ja nicht viel über die REUs von Commodore, aber die haben ganz offensichtlich nicht so funktioniert.

Angeblich soll der Expansionsport ja viel mehr bieten. Einen vollständigen anderen CPU kann man angeblich dran hängen. Und eben jenen REU.
Das braucht viel mehr Logik.
Und dafür brauche ich noch die letzten Leitungen. Und hier wird es kompliziert.

Ein langes Studium der Schaltpläne und Input-64 folgte. Nicht vollständig fruchtvoll.
Nachdem ich gelesen habe, wie die Takte im C64 generiert werden und von welchen unterschiedlichen ICs mit welchem Zweck habe ich mich schon gefragt ob die, die das so erdacht haben, Genies oder einfach nur durchgedreht waren.
Jedenfalls war die Recherche schwierig und aus dem 64 Intern alleine nicht vollständig.

Also, zuerst mal die einfachen Pins.

RESET: Klar. Haben wir schon alle mal benutzt, denke ich.
IRQ: Für die unterdrückbaren Unterbrechungen im Leben.
NMI: Wenn's ganz dringend ist.

Ich schätze es empfiehlt sich, im IO-Bereich Register mit Interrupt-Masken und Requests einzurichten. Man sollte schon ermitteln können, wenn das Cartridge für einen Unterrupt verantwortlich ist.

Bleiben noch
ø2: Systemtakt
DotClock: ca. 8 MHz Takt. Ich glaube, den könnte man für einen eigen Video-Ausgang verwenden. Praktischer für mich als Takt für einen AVR.
BA: Kontrolliert den Address-Bus.
DMA: Kontrolliert den Address-Bus.

Hier musste ich etwas Phantasie entwickeln und genau nachlesen.
Zum einen wurde aus der 64 Intern nicht ersichtlich, worin genau der Unterschied zwischen dem RDY und dem AEC im MPU liegt, die ja gewissermaßen über den BA und dem DMA-Ausgang am Expansionsport und vom VIC gesteuert werden.
Zum anderen was ø1 von ø2 unterscheidet.

Die Lösung fand ich anderswo.
Was ø2 angeht, kann ich jetzt sagten, dass Low bedeutet, der Bus gehört dem VIC, ein Hight gibt den Bus an den MPU.
So wie ich das jetzt sehe, ist der entscheidende Punkt bei RDY und AEC, dass ein RDY auf Low dem MPU Leseoperationen untersagt, nicht aber Schreiboperationen! Wenn der VIC mal mehr Zeit am Bus braucht, als ihm normalerweise zugestanden würde, legt er erst den BA (und damit den RDY) auf Low und verhindert, dass der MPU noch weitere Leseaktionen durchführen kann. Dann wartet der VIC drei Systemtakte lang, bis der MPU alle eventuell noch laufenden Schreibaktionen beendet.
Erst dann setzt er AEC auf Low und sperrt den MPU vollständig, setzt alle Ausgänge auf Tri-State und isoliert den Bus so vom MPU.

Zurück zum Expansionsport.
Was wäre, wenn man DMA auf Low setzt?
DMA hängt an den AND-Gattern sowohl vom BA (und damit RDY) als auch dem AEC. Folglich könnte ein einfaches Low am DMA den MPU abkoppeln und das Cartridge hätte volle Kontrolle über den Bus bei allen Phasen, in denen ø2 High ist.
Wozu aber dann der BA-Pin noch zusätzlich? Ein DMA Low setzt ja auch automatisch das AND-Gatter mit dem BA auf Low.

Ich sage euch jetzt, wie ich mir das vorstelle.
Keine Garantie auf Korrektheit.

Wenn man einfach so DMA auf Low legt, kann es sein, dass der MPU abgewürgt wird, während er noch Schreibeoperationen durchführt. Das wären die klassischen Fehler, die erst nach Wochen und nur sporadisch auftreten, und furchtbar schwer zu debuggen sind.
Also sollte man es wie der VIC machen:
Erst BA auf low ziehen, drei Systemtakte warten, und dann über den DMA auf Low auch das AEC auf Low ziehen.

Aber wieso wurde AEC nicht einfach am Expansionsport ausgegeben? Wieso diese trickreiche Sache mit den AND-Gattern?
Ich denke das ist gemacht für den Fall, dass der VIC eventuell Bus-Zeit anfordert, aber jetzt nicht mehr vom MPU, sondern von der Cartridge.
Indem man in der Cartridge DMA auf Low legt, bleibt der MPU gesperrt, aber gleichzeitig kann man den BA wieder "freigeben". Das heisst, man kann am BA lauschen. Wenn der VIC ihn auf Low legt, merkt man das sofort, und man kann seine Kontrolle über den Bus aufgeben und dem VIC übergeben.

Viel einfacher wäre natürlich folgendes: Den Bildschirm deaktivieren! Ich gehe mal davon aus, dass dann der VIC auf keinen Fall mehr den Bus extra reservieren muss. Deshalb funktioniert ja auch die Datenübertragung von der Datasette.

Wenn man das so macht, hat man weitgehende Verfügungsgewalt über den Addressbus und den Datenbus. Sowohl was Lesen als auch was Schreiben angeht.
Damit könnte man locker mal aus einer Speichererweiterung heraus in superschneller Zeit den größten Teil des C64 RAM in beide Richtungen umkopieren.
Es würde mich nicht wundern, wenn die REUs das so machen.

Bleiben zwei Probleme.
Zum einen hat die Cartridge leider keinen direkten Einfluss auf den Speicherbelegungsplan im C64. Denn dummerweise ist das einzige Register, das das machen kann im MPU integriert, und liegt deshalb überhaupt nicht im Einflussbereich des Cartridges!
Das ist ein Hauptfallstrick wenn ich mich daran machen würde, einen Ersatz-Prozessor für den C64 an den Expansionsport zu stecken.

Zum anderen macht dieses ganze DMA-Zeug es doch recht aufwändig, die Kommunikation zwischen Cartridge und C64 zu koordinieren. Ich schätze ich bräuchte fünf bis sieben ICs. Da kommt die maximale Leistungsaufnahme des Expansionsports doch recht schnell an ihre Grenze.
Natürlich könnte man sich davon einiges ersparen, wenn man den Bildschirm abschaltet, aber dummerweise geht das nur über die IO-Register, die eventuell überhaupt nicht eingeblendet sind. Aber sicherstellen kann das nur der MPU, nicht die Cartridge, weshalb man sich nicht darauf verlassen kann.


PS: Wofür steht "MPU" eigentlich?

Quoted

Original von strik

Quoted

Original von Nightshade
Immerhin, es gibt ja da noch den
R/W Ausgang: Bestimmt ob Daten am Datenbus geschrieben oder gelesen werden sollen.

So wie ich das sehe, spricht nichts dagegen, dass diese Speicher von 0x8000-0xBFFF nicht auch RAM sein könnten.

Hm... Die Dekodierleitungen des PLA werden aber nicht low (= aktiv), wenn man in diese Speicherbereiche schreibt. Sprich: Wenn du da RAM reinpacken willst, dann mußt du das selbst dekodieren. Ausserdem würde dann auch in den RAM "unter" den ROMs reingeschrieben werden, so dass du im internen RAM und im "externen" RAM den gleichen Wert hättest. Macht nicht viel Sinn, oder?

Ich gebe zu, es kam mir nicht in den Sinn den RW-Eingang am PLA mir in seinen Auswirkungen näher anzuschauen.
Werde ich irgendwann nachholen.

Quoted

Quoted

Gut, nicht so sonderlich sinnvoll, weil sie ja fest beim Rechner-Neustart eingeblendet sind und nicht von der Seite des C64 wieder ausgeschaltet werden können,

Doch, kann ausgeblendet werden, wenn du in dem Modul diese Möglichkeit vorsiehst (Register).

Als ich das getippt habe, habe ich die Möglichkeit für die Register noch nicht gefunden.
Stimmt schon, kling logisch. Einfach Leitung in der Cartridge kappen und gut is.

Quoted

Quoted

Es gibt da noch zwei andere Leitungen am Expansionsport:

I/O1: 0xDE00-0xDEFF
I/O2: 0xDF00-0xDFFF

Das hört sich schon erheblich mehr nach dem an, was ich suche. Wie genau man diese beiden Leitungen verwendet, um Register zu etablieren, das hab ich noch nicht vollkommen raus. Ist etwas kompliziert im Schaltplan. Aber das krieg ich noch raus.

Eigentlich ganz einfach: Sofern irgendein Zugriff im Bereich $DE00-$DEFF erfolgt (egal ob Lese- oder Schreibe, allerdings muss es im I/O-Bereich sein; bei Zugriffen zum Characterrom oder RAM unter I/O wird das nicht gesetzt), so wird I/O1 auf low gesetzt. Ebenso I/O2 bei $DF00-$DFFF (gleiche Bedingungen).

Du kannst I/O1 oder I/O2 nutzen, um das ganze weiter auszudekodieren, oder auch als Chip Select für einen I/O-Baustein.

Eigentlich dachte ich nur als Chip Select. Ein Microcontroller würde womöglich zu spät reagieren.
Das habe ich mir inzwischen auch zusammengedacht. Was mir momentan noch das größte Kopfzerbrechen macht ist einen Chip zu finden, der ein paar Dutzend Byte Speicher hat, jeweils 8 Bit Ausgabe hat, billig ist, wenig Stromaufnahme hat und bei Reichelt bestellbar ist.
bisher habe ich keinen Gefunden.
Einen voll ausgewachsenen modernen RAM dafür zu nehmen scheint mir etwas übertrieben...

Quoted

Quoted

Hier musste ich etwas Phantasie entwickeln und genau nachlesen.
Zum einen wurde aus der 64 Intern nicht ersichtlich, worin genau der Unterschied zwischen dem RDY und dem AEC im MPU liegt,

Mit RDY stoppst du die CPU (nach maximal 3 Takten). Die CPU treibt dann aber immer noch die Busse. AEC sorgt dafür, dass die CPU in den Tristate-Modus geht; d.h., die Busse werden nicht mehr getrieben, so dass jemand anderes (VIC, ext. Prozessor, REU) die Busse treiben darf.
Die beiden Leitungen können nicht zusammengefaßt werden, da nach RDY noch bis zu 3 Takte ausgeführt werden können. Damit die CPU das kann muss sie die Busse natürlich noch treiben.

Wie ich später noch geschrieben habe, in der 64 Intern hab ich es nicht gefunden. In der einen Webseite über den VIC aber sehr wohl.

Quoted

AEC sperrt die CPU nicht, es sorgt nur für den Tristate-Modus. Wenn dabei nicht RDY aktiv ist dürfte die CPU alles mögiche Verhalten zeigen (Absturz?).

Wusste ich nicht, ist aber auch nicht wichtig. Würde ja eh keinen Sinn machen, den AEC vor dem RDY auszulösen.

Quoted

Quoted

Zurück zum Expansionsport.
Was wäre, wenn man DMA auf Low setzt?
DMA hängt an den AND-Gattern sowohl vom BA (und damit RDY) als auch dem AEC. Folglich könnte ein einfaches Low am DMA den MPU abkoppeln und das Cartridge hätte volle Kontrolle über den Bus bei allen Phasen, in denen ø2 High ist.
Wozu aber dann der BA-Pin noch zusätzlich? Ein DMA Low setzt ja auch automatisch das AND-Gatter mit dem BA auf Low.

Du willst BA lesen können, nicht setzen! Damit kannst du feststellen, ob gerade der VIC auf den Bus zugreifen will. Dann muss ja auch die ext. CPU den Bus freigeben (Tristate).

Das habe ich ja auch herausgefunden, wie ich unten geschrieben habe.

Quoted

Quoted

Also sollte man es wie der VIC machen:
Erst BA auf low ziehen, drei Systemtakte warten, und dann über den DMA auf Low auch das AEC auf Low ziehen.

Nein. BA niemals selbst auf low ziehen, das macht schon der VIC!

Und das kapiere ich wiederum nicht.
Wie bitteschön soll denn ich ein DMA machen, ohne vorher gestaffelt RDY und drei Takte später AEC auszuführen?
Wenn ich einfach so DMA auf Low lege, würde doch genau das passieren, was der VIC mit dem drei Takte Vorlaufzeit zu verhindern sucht: Den MPU bei einer möglichen Schreibarbeit zu unterbrechen.
Wenn ich DMA einfach so auf Low lege ohne vorher den BA verwendet zu haben um ein RDY ohne ein AEC auszulösen, dann würde ich doch evtl Speicher korrumpieren!
Vielleicht habe ich ja etwas übersehen, aber wenn ich mir den Schaltplan so anschaue, macht für mich nur das einen Sinn.
Ich lasse mich aber gern anderweitig überzeugen. Würde die Sache sehr vereinfachen.

Oder was meinst du mit "das macht schon der VIC"? Muss die Cartridge den VIC irgendwie unterreichten, damit der den MPU für die Cartridge sperrt? Glaub ich nicht.

Quoted

Quoted

Viel einfacher wäre natürlich folgendes: Den Bildschirm deaktivieren! Ich gehe mal davon aus, dass dann der VIC auf keinen Fall mehr den Bus extra reservieren muss. Deshalb funktioniert ja auch die Datenübertragung von der Datasette.

IIRC kann der VIC den Bus trotzdem noch belegen, sofern die Sprites nicht abgeschaltet wurden.

Werden bei Datasettenbetrieb auch die Sprites ausgeschaltet? Müsste ich nachschauen. Ist aber nicht so wichtig.

Jedenfalls schon mal vielen Dank für deine Kommentare!

Quoted

Original von Nightshade
Wie bitteschön soll denn ich ein DMA machen, ohne vorher gestaffelt RDY und drei Takte später AEC auszuführen?
Wenn ich einfach so DMA auf Low lege, würde doch genau das passieren, was der VIC mit dem drei Takte Vorlaufzeit zu verhindern sucht: Den MPU bei einer möglichen Schreibarbeit zu unterbrechen.
Wenn ich DMA einfach so auf Low lege ohne vorher den BA verwendet zu haben um ein RDY ohne ein AEC auszulösen, dann würde ich doch evtl Speicher korrumpieren!
Vielleicht habe ich ja etwas übersehen, aber wenn ich mir den Schaltplan so anschaue, macht für mich nur das einen Sinn.
Ich lasse mich aber gern anderweitig überzeugen. Würde die Sache sehr vereinfachen.

Mir ist gerade eine mögliche Lösung eingefallen.
Sicherstellen, dass nach einer Aufforderung von Seiten des MPU (z.B. durch einen Register-Eintrag) den MPU in eine Warteschleife ohne Schreibzugriffe schicken, dann ein paar Takte warten und einfach so DMA setzen. Damit wäre man ziemlich sicher, dass man keinen Schreibzugriff unterbricht.
Aber es gibt mehrere Gründe, wieso ich das so nicht gerne machen würde.

1. Die Verantwortung, dass alles gut geht, liegt in der Verantwortung der Treibersoftware. Sowas gefällt mir nie!
   
2. Was ist mit Interrupts? Interrupts kann man sperren, aber nur die IRQs. Wenn aus irgendeinem Grund ein NMI passiert, hat man seinen möglicherweise unterbrochenen Schreibzugriff.
   [/list=a]