Hallo,
ich starte gerade erst mit VHDL und digitaler Logik und habe mir zum
Verständnis mal den Schaltplan meines geliebten C-64 angesehen um zu
verstehen, wie er tatsächlich funktioniert.
Hierbei bin ich darauf gestoßen, dass jeder der 8-einzelnen 4164
RAM-Chips jeweils ein Bit zu einem Byte beiträgt. Diese 8 Signale (8x1
Bit) werden demnach auf die d0-d7 Pins u.a. bei der CPU angeliefert.
Meine (wohl triviale) Frage ist nun, woher weiß die CPU des C-64 ohne
separate Signalisierung ("Data Ready" oder sowas) dass tatsächlich alle
RAM-Chips ihr Bit geliefert haben und sie nun den Status der d0-d7 Pins
auslesen und verarbeiten kann? Nicht, dass ein RAM Chip eine kleine
Pause eingelegt hat und noch gar nichts "gesendet" hat? Die einzelnen
4164 RAMs melden doch kein "Data Ready" oder ähnliches an die CPU?
Außerdem liest der VIC Chip des C64 kurz darauf ebenfalls die RAMs aus,
d.h. auch jetzt wird wieder d0-d7 mit Signalen befeuert. Zwar wird hier
per Multiplexer die Leitungen zur CPU hochohmig geschaltet, aber
bedeutet dies nicht dass das vorherige an der CPU anliegende d0-d7
Signal unbedingt vorher ausgelesen sein muss und es nicht
"überschrieben" wird?
Ähnlich: Wenn ich asynchron (also ohne ein CLK) viermal ein logische Bit
0 zu einem Baustein übertrage (z.B. von FPGA zu FPGA als
std_logic_vector(3 downto 0), woher weiß der empfangene FPGA dass ich
tatsächlich vier Bits (4x "0") "gesendet" habe bzw. überhaupt viermal
"0" (und nicht 3 mal 0 oder 5 mal 0 oder gar nichts) übertragen wurde
wenn ich dieses als Eingangssignal auswerten möchte?
Ich weiß, dass sind ganz klare Anfängerfragen. Ich habe bereits im
Internet und in der Literatur Erklärungen gesucht und wohl auch
Informationen gefunden, kann diese aber noch nicht richtig einordnen, da
mir hier wohl ein elementare Funktionsweise der Signalisierungen
unbekannt ist.
Danke schon mal,
Bernd.
Diese DRAMs haben eine spezifizierte Zugriffszeit, nach der die Daten
anliegen. Dazu gibt es meist Timing-Diagramme im Datenblatt.
Dein Design muss also nur lange genug warten, dann kann es die Daten
ablesen. Handshaking gibt es keines.
Bernd schrieb:> woher weiß die CPU des C-64 ohne separate Signalisierung ("Data Ready"> oder sowas) dass tatsächlich alle RAM-Chips ihr Bit geliefert haben
Sie wartet lange genug. Der Takt gibt die Wartezeit vor.
Bernd schrieb:> Ähnlich: Wenn ich asynchron (also ohne ein CLK) viermal ein logische Bit> 0 zu einem Baustein übertrage (z.B. von FPGA zu FPGA als> std_logic_vector(3 downto 0), woher weiß der empfangene FPGA dass ich> tatsächlich vier Bits (4x "0") "gesendet" habe bzw. überhaupt viermal> "0" (und nicht 3 mal 0 oder 5 mal 0 oder gar nichts) übertragen wurde> wenn ich dieses als Eingangssignal auswerten möchte?
Du brauchst zusätzliche Validierungssignale. Sie dir einfach mal das
Timigdiagramm eines asynchronen RAMs an.
Danke für die Erläuterung. Wenn die CPU demnach zu lange wartete, also
wenn der VIC bereits wieder Daten aus den RAMs anfordert und d0-d7 durch
den Multiplayer hochohmig geschaltet sind, würde ich dann als CPU
Datenmüll an d0-d7 lesen? Nochmal Danke...
Bernd schrieb:> Danke für die Erläuterung. Wenn die CPU demnach zu lange wartete,> also wenn der VIC bereits wieder Daten aus den RAMs anfordert und d0-d7> durch den Multiplayer.
Natürlich Multiplexer (T9...)...
An den Steuersignalen sollte tunlichst immer nur einer Rütteln (entweder
die CPU oder der VIC), sonst verletzt du mit ziemlicher Sicherheit das
Timing des DRAMs.
Ansonsten ist die Datenübergabe zwischen DRAM und Umgebung zwar
asynchron, aber da das Gesamtsystem synchron zum Systemtakt ist, kann es
nicht passieren, dass die CPU "zu lange" wartet oder der RAM "mal ne
Pause" einlegt. Das ist alles brav synchronisiert.
Hallo,
erstmal Allen Dank, die geantwortet haben.
>>Ansonsten ist die Datenübergabe zwischen DRAM und Umgebung zwar
asynchron, aber da das Gesamtsystem synchron zum Systemtakt ist, kann es
nicht passieren, dass die CPU "zu lange" wartet oder der RAM "mal ne
Pause" einlegt.
Klaro, wollte nur einmal wissen, was passierte wenn es nicht
synchronisiert wäre und die CPU halt zu "spät" ausliest. Aus Deiner
Antwort entnehme ich, dass es tatsächlich dann ein Problem wäre und
Datenmüll gelesen würde (wohl nur dann, falls die CPU keine Latches
nutzet, die den einmal gelieferten Wert für ein "zu spätes" Auslesen
zwischenspeichern).
Dank an Lothar: Jeeeetzt, nachdem ich mir auch das Timing Diagramm vom
4164 angesehen habe weiß ich auch, von wann bis wann ich gültige Daten
erwarten kann.
1001 Dank für eure Hilfe. Ich glaube ich komme jetzt klar.
Bernd schrieb:> Jeeeetzt, nachdem ich mir auch das Timing Diagramm vom 4164 angesehen> habe weiß ich auch, von wann bis wann ich gültige Daten erwarten kann.
Das ist eigentlich kein "von bis", sondern ein "ab". Denn wenn du z.B.
Lesen willst, dann gibt es eine Zeit, ab der die Daten stabil sind,
solange sich an der Adresse und den Steuersignalen nichts ändert.
Ah
Lothar M. schrieb:> Das ist eigentlich kein "von bis", sondern ein "ab". Denn wenn du z.B.> Lesen willst, dann gibt es eine Zeit, ab der die Daten stabil sind,> solange sich an der Adresse und den Steuersignalen nichts ändert.
Ah, OK. Ich hatte es so interpretiert, dass Q nur für einen bestimmten
Zeitraum gültig ist.
Habe mir gleich Mal ein paar 4164er besorgt: Einmal als Ersatz, falls
meine im C64 irgendwann Mal wieder zu Sand werden, und einmal zur
Probeansteuerung: Mal versuchen ein Bit zu Speichern, wieder auszulesen
und den 5V Refresh hinzubekommen. Denke, da habe ich noch Einiges vor
der Brust...
Du kannst dir ja mal das AVR-CP/M-Projekt anschauen. Das hat zwar nichts
mit FPGAs zu tun, aber da wird mit einem AVR in Software ein DRAM (256k
x 4) angesteuert. Der AVR simuliert dann noch einen Z80 dafür. ;-)
Der Monsterthread (knapp 1700 Posts) ist hier:
Beitrag "CP/M auf ATmega88"
S. R. schrieb:> Du kannst dir ja mal das AVR-CP/M-Projekt anschauen. Das hat zwar ...> Der Monsterthread (knapp 1700 Posts) ist hier: Beitrag "CP/M auf> ATmega88"
Ist ja Wahnsinn was es alles gibt... Und ich dachte das Timing für den
4164 wäre schon mit nem FPGA nix für schwache Nerven... Aber mit nem AVR
der noch nen Z80 simuliert? Hammer! Guck ich mir Mal an, was da mit dem
RAM gemacht wird. Gefühle für meinen treuen ZX-81 kommen da wieder auf
:-), oder für meinen damaligen Apple II komp. mit Z80 und
80-Zeichenkarte...
Danke,
Bernd.
Das Speicherinterface ist doch asynchron... da kannst du schon ziemlich
langsam rangehen (solange du noch genug Refreshzyklen fährst).
Mal davon abgesehen: Der C64 geht da mit welchem Tempo ran? 1 MHz? 2
MHz? Dein FPGA schafft mehrere 100 MHz, wenn du willst...
Bernd schrieb:> Und ich dachte das Timing für den> 4164 wäre schon mit nem FPGA nix für schwache Nerven..
Bestimmt hast Du Dir schon das PDF zum z.B. KM4164b
runtergeladen und die Timingdiagramme angeschaut.
Beim C64 erfolgen die Speicherzugriffe per RandomRead/Write
(und nicht per PageRead/Write). Das erfordert im ggs
zum SRAM schon mehr Aufwand, ist aber per FSM locker
umsetzbar, zeitkritisch wird's für einen heutigen FPGA
auf keinen Fall, ist eher ein Witz. Der gesammte Ablauf
erfordert etwas weniger als 300ns.
Ein Grossteil des Timings wird vom Graphikchip (VIC-II)
erledigt und per PAL (Spezialchip) an die DRAMs
weitergereicht. Der VIC steuert auch die CPU entsprechend
an, um seinen Buszugriff abzusichern. Genauer wird das
z.B. im VIC-Dokument von Christian Bauer beschrieben. Such
einfach mal im Netz.
Ich habe selber schon fast alle C64-Chips angesteuert
und durchgetestet, darunter auch die DRAMs. Dazu ist nur
eine einfache fastlineare FSM mit zwei Zugriffen (R/W)
zu implementieren. Einziges verbleibende HW-Problem ist
die 5V-tolerante Ansteuerung (nur der FPGA muss per
Levelshifter geschützt werden, die DRAMs kommen mit 3.3V
klar, jedenfalls bei meinen).
"oder für meinen damaligen Apple II komp. mit Z80"
Hä???
Der Apple II hatte doch auch einen 6502 drin, wie soll er dann
kompatibel mit nem Z80 sein? Die konnten sich damals sicher nicht
gegenseitig emulieren.
Joachim B. schrieb:> MagIO schrieb:> aber es gab eine Z80 Karte und eine 80Z(eichen) Karte und damit lief> CP/M prima, wo ist nun dein Verständnisproblem?>> http://www.runkel.info/wp-content/uploads/2014/05/...>> http://forum.classic-computing.de/index.php?page=A...
Korrekt. Wollte sagen dass mein Apple II kompatibler (! Hatte kein
Geld für einen echten Apple) Rechner eine Z80 und 80 Zeichenkarte
hatte... Damit kam damals echtes Mainframe Feeling auf:-) Mit
Grünmonitor und heftigem flackern bei der 40 auf 80 Zeichen
Umschaltung.
Joachim B. schrieb:> wo ist nun dein Verständnisproblem?
NUN hab ich kein Verständnis-Problem mehr.
Im original Text stand nicht "Z80 Karte und Z80Z(eichen) Karte" ...
und auch nicht "Z80- und 80-Zeichen-Karte" ...
sondern "Apple II komp. mit Z80" ...
Wo ist Dein Problem, dass ich da nochmal Nachfrage? ;o)
Und Danke für die Links & die Aufklärung.
Sigin. Einziges verbleibende HW-Problem ist
> die 5V-tolerante Ansteuerung (nur der FPGA muss per> Levelshifter geschützt werden, die DRAMs kommen mit 3.3V> klar, jedenfalls bei meinen).Sigi schrieb:>> Ein G Einziges verbleibende HW-Problem ist> die 5V-tolerante Ansteuerung (nur der FPGA muss per> Levelshifter geschützt werden, die DRAMs kommen mit 3.3V> klar, jedenfalls bei meinen).
Danke für die Warnung. Möchte mein DE1 nicht gleich zerschießen.
Habe mir den 74LVC245A ausgeguckt um von Q wieder in einen FPGA Eingang
zu kommen (bzw. später von 8x 4164 ). Hoffe eine gute Wahl...
Bernd schrieb:> Korrekt. Wollte sagen dass mein Apple II kompatibler (! Hatte kein> Geld für einen echten Apple) Rechner eine Z80 und 80 Zeichenkarte> hatte... Damit kam damals echtes Mainframe Feeling auf:-) Mit> Grünmonitor und heftigem flackern bei der 40 auf 80 Zeichen> Umschaltung.
ich als armer Student, alles selbstgelötet
apple2 Nachbau Leerplatine 155,- DM und ca. 2000 Lötstellen in
Handarbeit
letzte Ausbaustufe mit 10 Steckplatinen auf 8 Plätze mit huckpack und
freier Querverdrahtung freier Adressbereiche
Drucker
Z80
80z
Floppy
2x 128K Ramdisk
RGB Karte
Modem Karte
eigene VIA Karte gefädelt
EPROMER Karte
MagIO schrieb:> "oder für meinen damaligen Apple II komp. mit Z80">> Hä???> Der Apple II hatte doch auch einen 6502 drin, wie soll er dann> kompatibel mit nem Z80 sein? Die konnten sich damals sicher nicht> gegenseitig emulieren.
M.J. hat im forum64 einen z80 Emulator veröffentlicht, der cp/m ohne z80
Karte starten lässt. Ok, er bricht keine Rekorde, aber laufen tut es
schon...
Joachim B. schrieb:> Bernd schrieb:> ich als armer Student, alles selbstgelötet>> apple2 Nachbau Leerplatine 155,- DM und ca. 2000 Lötstellen in> Handarbeit
Rückblickend, denke ich, war es wohl gut investierte Zeit, gelle?
Welcher Student baut heute noch ähnliches und bekommt so praktische
Erfahrung in gleich mehreren Bereichen (Britzel!)?
Ich hatte schon Probleme mit meiner Huckepack aufgelöteten Atari 260(!)
ST Speichererweiterung... Fast jeden Tag machte es leise 'Pling' und ich
hatte Schnee im Bild. Habe die Kiste zum Schluss gar nicht mehr
zugeschraubt, sondern gleich nachgebritzelt :-) Alles nur für XTron,
damals das einzige Programm was 1MB nutzte (für Sound Samples...)...
Bernd schrieb:> Ich hatte schon Probleme mit meiner Huckepack aufgelöteten Atari 260(!)> ST Speichererweiterung...
ich hatte wohl Glück, erst beim 260ST von 1MB auf 2,5MB (50,-DM pro
Stein x16), huckepack mit Adaptersockel.
Das Ganze in ein Schroffgehäuse mit 3,5" Floppy uns 5 1/4" Floppy
unschaltbar.
Später eine Leerplatine vom megaST bekommen und alle Customchips vom
260ST umgesetzt und auf 4MB (50,-DM pro Stein x16), als SMD.
Ein altes SH205 Gehäuse bekommen die megaST4 Platine eingesetzt und 2
Teac HD Floppys eingebaut, das Gehäuse musste innen gefräst werden, MB
tiefergelegt ober Lüftungsschlitze plan gefräst damit die beiden
slimline 3,5" HD reinpassten übereinander.
Später noch ein Syquest 44MB Wechselplatte und auch in meinen ersten PC
Claus Brod Scheibenkleister schrieb dann den Bootsektor damit man die
Syquest im Atari und PC einsetzen konnte und erweiterte sein supeformat
so das ich die 3,5 HD Disketten auch voll nutzen konnte, 8/16 MHz am
WD1772 Umschaltung per HD Locherkennung mit GAL.
Ich habe als Student so viel beim "basteln" an PCs gelernt das das mein
erster richtiger Job wurde in der Prüfentwicklung weil ich nämlich den
PET 2001 auswendig kannte mit allen Chips (bis hin zur maximalen
Aufrüstung (8KB statische Karte + 16KB dyn. Karte + Sound mit VIA)
