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.
sicher gibt es noch Steuersignal (Read, Write, Select). Ich weiß nicht auf welchen Schaltplan du gerade schaust.
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.
:
Bearbeitet durch Moderator
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.
Das RAM hat festgelegte sichere Bereitstellungszeiten, nach denen die Datenleitungen gültig sein müssen (nehme ich an).
Quelle : DataBecker 64 intern Vic , Pal ,Farb Ram , Character Rom viel Spaß damit
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...
:
Bearbeitet durch User
Tipp: mal im forum64.de posten. Da gibt es noch mehr Leute, die sich mit sowas beschäftigen.
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.
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. 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/apple2e_z80_card.jpg http://forum.classic-computing.de/index.php?page=Attachment&attachmentID=6861&h=01d2a1564ba7148116ecdc2a95aba68a4d62785f
:
Bearbeitet durch User
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)
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.