Hi Leute. Ich habe hier einen nagelneuen WDC65C02 vor mir liegen und will mich mal ein bisschen mit der Materie befassen und das Teil auf einem Steckbrett zum laufen bekommen. Jetzt hätte ich für den Anfang mal 2 Fragen die ich aus dem Datenblatt nicht wirklich herauslesen konnte. 1. Kann ich an den Daten und Adresspins einfach LED's mit dranhängen um zu sehen ob sich was tut (und auch nur weils cool ist)? Ich hab keine Angabe gefunden wieviel mA der Prozessor an den Pins liefert. 2. Gibts sowas wie eine minimale Taktrate? Ich würde am Anfang gerne über einen Arduino eine sehr langsame Taktrate generieren lassen (so 1Hz) um an den LED's auch zu erkennen was er macht und ob ichs richtig gemacht hab. Oder geht irgendwas flöten wenn 0.5 Sekunden High und dann 0.5 Sekunden Low am Clockpin anliegen? Gruß Tom
Ich will ja kein notorischer Spielverderber sein, aber das würde ich besser bleiben lassen. Dabei lernst du nichts nützliches. Wenn du gerade Langeweile hast und die AVR schon kennst, dann schau Dir einen 32bit ARM Controller an. Evaluation Kits bekommst du innerhalb von 48 Stunden original ab 10€: https://www.amazon.de/STM32-ST-NUCLEO-L073RZ-Nucleo-Development/dp/B01IO2JP60
Thomas P. schrieb: > 1. Kann ich an den Daten und Adresspins einfach LED's mit dranhängen um > zu sehen ob sich was tut (und auch nur weils cool ist)? Ich hab keine > Angabe gefunden wieviel mA der Prozessor an den Pins liefert. Iol/Ioh stehen im Datasheet. Treiber dazwischen hängen. 74HC544 tuts. > 2. Gibts sowas wie eine minimale Taktrate? Es steht keine maximale Zykluszeit im Datasheet, also nein.
Das ist mir schon auch klar. ABER: Es soll gar nichts nützliches rauskommen. Es ist nur eine Spielerei auf die ich Lust hab. Die AVR's sind tolle Prozessoren aber das ist nicht was ich wirklich will. Ich mag alte Retro Computer und will einfach aus Spass selber einen basteln. Mit einem "alten" Prozessor und verständlicher Hardware und Logik. Arduino's und Teensy's programmiere ich schon lange, das ist nicht mehr wirklich interessant. Der alte Weg mit einem Prozessor der eigentlich nix kann und man alles irgendwie Softwareseitig in Assembler lösen muß fasziniert mich.
Thomas P. schrieb: > Ich habe hier einen nagelneuen WDC65C02 vor mir liegen und will mich mal > ein bisschen mit der Materie befassen und das Teil auf einem Steckbrett > zum laufen bekommen. Dafür brauchst du deutlich mehr, als die CPU. Ohne externen Speicher (SRAM) läuft da gar nichts.
Stefanus F. schrieb: > Ich will ja kein notorischer Spielverderber sein, aber das würde ich > besser bleiben lassen. Dabei lernst du nichts nützliches. Wenn er den Befehl/Datenfluss beobachten will, dann passt das schon. Sowas siehst du bei integrierten Controllern nicht, beim 6502 schon.
Wolfgang schrieb: > Dafür brauchst du deutlich mehr, als die CPU. > Ohne externen Speicher (SRAM) läuft da gar nichts. Mit Mäuseklavier, LED-Zeilen und manueller Taktung kann man die Zyklen durchtakten. Ein Schachprogramm wird so nicht draus, aber lernen kann man schon. Allerdings kann man sowas heute auch auf dem Bildschirm im Simulator.
Stefanus F. schrieb: > Ich will ja kein notorischer Spielverderber sein Dann lass es auch bleiben ;) > Dabei lernst du nichts nützliches. Na und? Es ist aber u.U. lustig. Jetzt mal zum Thema: Thomas P. schrieb: > 1. Kann ich an den Daten und Adresspins einfach LED's mit dranhängen um > zu sehen ob sich was tut (und auch nur weils cool ist)? Ich hab keine > Angabe gefunden wieviel mA der Prozessor an den Pins liefert. Laut Datenblatt 700µA High, 3.2mA low bei 5V Versorgung und eingehaltenen Logikpegeln. Also .. eher nicht, wobei moderne LEDs zugegeben auch bei 100µA noch gut sichtbar leuchten. Thomas P. schrieb: > 2. Gibts sowas wie eine minimale Taktrate? Ich würde am Anfang gerne > über einen Arduino eine sehr langsame Taktrate generieren lassen (so > 1Hz) um an den LED's auch zu erkennen was er macht und ob ichs richtig > gemacht hab. Oder geht irgendwas flöten wenn 0.5 Sekunden High und dann > 0.5 Sekunden Low am Clockpin anliegen? Im Gegensatz zum originalen 6502 welcher intern teilweise dynamische Speicherzellen hatte ist der WDC "fully static", du kannst ihn also bis auf 0Hz heruntertakten. Gruß, Christian
Thomas P. schrieb: > Hi Leute. > Ich habe hier einen nagelneuen WDC65C02 vor mir liegen und will mich mal > ein bisschen mit der Materie befassen und das Teil auf einem Steckbrett > zum laufen bekommen. Du hast warscheinlich einen WDC65C02S, wenn er nagelneu ist, oder? > Jetzt hätte ich für den Anfang mal 2 Fragen die ich aus dem Datenblatt > nicht wirklich herauslesen konnte. > > 1. Kann ich an den Daten und Adresspins einfach LED's mit dranhängen um > zu sehen ob sich was tut (und auch nur weils cool ist)? Ich hab keine > Angabe gefunden wieviel mA der Prozessor an den Pins liefert. http://www.westerndesigncenter.com/wdc/documentation/w65c02s.pdf Seite 24, "Table 6-2 DC Characteristics" > 2. Gibts sowas wie eine minimale Taktrate? Selbes PDF, nächste Seite. "3.Since this is a static design, the maximum cycle time could be infinite." Das mit dem Lesen üben wir aber noch mal, oder? fchk
Parallele SRAM's und EEPROM's hab ich noch liegen. Schon klar das nur die CPU nicht reicht. Ich will auch gar keine Diskussion starten ob das Sinn macht oder nicht. Es wird einfach nur eine Bastelei die sich vielleicht irgendwann mal schick neben dem C64 in der Vitrine macht. ;)
Wenn du ihm am Datenbus ein festes $EA unterschiebst (NOP Stecker), dann sollte er lustig Adressen durchzählen. Der 60C02 arbeitet voll statisch, kann also mit beliebig niedriger Taktfrequenz betrieben werden. Die Einspeisung des Taktes ist aber nicht ganz trivial, da der kleine Kerl ein 2-Phasensignal möchte.
:
Bearbeitet durch User
Matthias S. schrieb: > Die Einspeisung des Taktes ist aber nicht > ganz trivial, da der kleine Kerl ein 2-Phasensignal möchte. Nope. Ein Takteingang, aber zwei komplementäre Ausgänge. 6502 und SC65C02S differieren jedoch etwas. Der 6502 nennt das Phi0(rein) und Phi1/2(raus), der SC Phi2(rein) und Phi1O/Phi2C(raus). Reingeführte 2 Phasen gibts bei den 651x.
:
Bearbeitet durch User
Puh, so viele Antworten. ;) Danke euch allen, es ist ein WDC65C02S6TPG-14
Ich würde die Busse mit 74xx245 versehen. Ein SRAM dran. Wenn man das geschickt macht kann man mit dem Arduino Programme in den Ram schreiben und wieder auslesen. Als Anzeigen würde ich 7Segment nehmen und Hex dekodieren. Die 74xx245 können z.T 40mA pro Ausgang. Hier gibt es einen Basicrechner : http://searle.hostei.com/grant/6502/Simple6502.html
> ein bisschen mit der Materie befassen und das Teil auf einem Steckbrett ggf. mal Suchen; site:6502.org W65C02S ---- ggf. da mal drüberlesen: https://mysite.du.edu/~jcalvert/tech/6504.htm Breadboard a Computer This small system has been tested, and it works! You will need a fairly large breadboard, but not necessarily one of the expensive large ones :)
karadur schrieb: > Ich würde die Busse mit 74xx245 versehen. Ein SRAM dran. Bei einfachen Systemen unnötig. Die LEDs abzukoppeln ist sinnvoll, aber CPU, ROM, RAM und evtl IO kann man direkt ohne Treiber koppeln, wenn man kein Mehrplatinen-Trumm bauen will.
Ist mir klar nur wenn er z.B. Ein Programm vom Arduino ins RAM schreiben will muss er trennen.
Im Datasheet vom W65C02S gibts das, was der 6502 nicht hatte: Ein Bus-Enable Signal. Damit gehts auch ohne Treiber.
Thomas P. schrieb: > Das ist mir schon auch klar. ABER: Es soll gar nichts nützliches > rauskommen. Es ist nur eine Spielerei auf die ich Lust hab. Die AVR's > sind tolle Prozessoren aber das ist nicht was ich wirklich will. > > Ich mag alte Retro Computer und will einfach aus Spass selber einen > basteln. Mit einem "alten" Prozessor und verständlicher Hardware und > Logik. > > Arduino's und Teensy's programmiere ich schon lange, das ist nicht mehr > wirklich interessant. Der alte Weg mit einem Prozessor der eigentlich > nix kann und man alles irgendwie Softwareseitig in Assembler lösen muß > fasziniert mich. Ich kann dir morgen einen ATARI 320XE Schaltplan raussuchen und empfehle ATRIE intern zur Lektüre Darin werkelte eine 65C02. Hab auch noch einiges dazu. Retro ist gut ;) Namaste
Thomas P. schrieb: > Der alte Weg mit einem Prozessor der eigentlich > nix kann und man alles irgendwie Softwareseitig in Assembler lösen muß > fasziniert mich. Wie jetzt? Der Prozessor kann genau so wenig oder viel wie jeder andere, nämlich genau garnichts, solange man ihm kein Programm gibt. Es ist schon zweistellige Jahre her, dass ich mit dem 6502 gearbeitet habe, natürlich waren da EPROM, RAM und Portbausteine mit auf dem Board - welches ich von Hand selbst layoutet habe. Vom 65SC02 weiß ich, dass der statisch ist: Ich hatte Ärger, dass sein Takt den Abgleich eines Empfängers sabotierte, also wurde er angehalten und der Quarzoszillator abgeschaltet. Irgendwas war da aber, es mussten Phasenbedingungen eingehalten werden, um nach der Pause definert weiter zu laufen. Hier im Regal liegt noch ein InCircuitEmulator von Huntsville, damit konnte man den Programmlauf beliebig anhalten und am PC in die Register gucken ... lang lang ist's her, ich habe fast alles dazu vergessen. Was Du mit LEDs und Arduino um einen 6502 herum willst, erschließt sich mir nicht.
A. K. schrieb: > Im Datasheet vom W65C02S gibts das, was der 6502 nicht hatte: Ein Oscillator! RC oder Quartz an PHI2/PHI10... ;)
.. schrieb: > A. K. schrieb: >> Im Datasheet vom W65C02S gibts das, was der 6502 nicht hatte: Ein > > Oscillator! RC oder Quartz an PHI2/PHI10... ;) So wie der 6501...
hinz schrieb: > So wie der 6501... Es gibt / gab keinen 6501. Der kleine Bruder des 6502 ist der 6504.
Manfred schrieb: > Der Prozessor kann genau so wenig oder viel wie jeder andere, Ich meinte damit nur 8 bit, nur 2 Register, kein firlefanz Manfred schrieb: > Was Du mit LEDs und Arduino um einen 6502 herum willst, erschließt sich > mir nicht. Alles nur zum rumspielen und testen. LED's waren nur so eine Idee um zu sehen ob sich was tut. Ein Arduino als Taktgeber kann so langsam Takten das ich nicht nur geflimmer hab, sondern es nachvollziehen kann. Also kann ich jetzt z.B. den Arduino direkt auf die Address Pins legen und einfach "mitlesen" um mir dann die aktuelle Adresse Seriell an den PC schicken? Dann würde ich mir fürs erste die LED's sparen.
Manfred schrieb: > hinz schrieb: >> So wie der 6501... > > Es gibt / gab keinen 6501. Der kleine Bruder des 6502 ist der 6504. Natürlich gabs den 6501, der ist aber ehr der große Bruder des 6502.
hinz schrieb: > Manfred schrieb: >> hinz schrieb: >>> So wie der 6501... >> >> Es gibt / gab keinen 6501. Der kleine Bruder des 6502 ist der 6504. > > Natürlich gabs den 6501, der ist aber ehr der große Bruder des 6502. http://www.obelisk.me.uk/electronics/R6501.html
Thomas P. schrieb: > Also kann ich jetzt z.B. den Arduino direkt auf die Address Pins legen > und einfach "mitlesen" um mir dann die aktuelle Adresse Seriell an den > PC schicken? Dann würde ich mir fürs erste die LED's sparen. Wenn du diesen Teil weglassen willst, dann kannst du auch gleich bei einer Simulation bleiben. Für den 6502 gibt es online einen Simulator bis auf Transistor - Ebene. http://www.visual6502.org/
Axel S. schrieb: > Wenn du diesen Teil weglassen willst, dann kannst du auch gleich bei > einer Simulation bleiben. Für den 6502 gibt es online einen Simulator > bis auf Transistor - Ebene. http://www.visual6502.org/ Das ist doch alles nur mal fürs erste testen um es mir einfacher zu machen. Am Ende wird da kein Arduino mehr dran sein. Und Simulatoren sind gut, aber echte Hardware ist schöner. Ich nutze ja auch einen echten C64 und keinen Emulator zum spielen. Und um sowas geht es ja am Ende. Versuchen einen 8bit Computer selber zu bauen. Vielleicht sogar besser als der C64. (Was eigentlich schon passiert ist wenn man das Basic weglässt...) ;)
Wenn du dich für Basteleien mit dem 6502 interessierst, da gibt es auch ein aktulles Projekt. https://steckschwein.de/
Als 8Bit-CPU dürfte der Z80 interessanter sein. Er unterstützt bis zu 128 Interruptvektoren. Es gibt auch passende Peripherie-ICs (PIO, SIO, CTC, DMA).
Wie sich der 65C02 bei niedrigen Taktraten verhält, weiß ich nicht. Ich bin mal nen anderen Weg gegangen und hab nen 65(C?)22 an einen Mega1284P gehängt, um mit dessen Portleitungen den 6502 Bus zu simulieren. Hab nen 555-Timer an den PHI-Eingang des 6522 angeflanscht. Total asynchron, das Ganze. Ging trotzdem einwandfrei.
Peter D. schrieb: > Als 8Bit-CPU dürfte der Z80 interessanter sein. Er unterstützt bis zu > 128 Interruptvektoren. Es gibt auch passende Peripherie-ICs (PIO, SIO, > CTC, DMA). Wenn es massgeblich darum geht, auf dem Bus direkt mitzuschnüffeln, ist das bei 6502 (oder 68xx) wesentlich leichter, weil ein Taktzyklus einem Speicherzyklus entspricht. Man kann also in jedem Schritt einen Buszyklus verfolgen. Bei der Z80 mit 3-4 Takten pro Buszyklus und 2 verschiedenen Zyklustypen ist das wesentlich komplexer.
Peter D. schrieb: > Als 8Bit-CPU dürfte der Z80 interessanter sein. Wie AVR vs. Pic Mit anderen Worten: Du hattest keine Apple II, C64, Atari o.ä., sondern einen TRS80, ZX81 oder was auch immer. ;-) Ich fand die Adressierungsarten des 6502 immer spannend: Indiziert/Indirekt indirekt/indiziert, Zero page und dann noch die exotischen undokumentierten Befehle. Bastler schrieb: > Wie sich der 65C02 bei niedrigen Taktraten verhält, weiß ich nicht. Meines Wissens ist die CMOS Version voll statisch. Ich habe es übrigens mal geschafft den 6502 auf 2MHz statt 1MhHz zu takten. Das hat allerdings nur mit einem asymetrischen Taktsignal geklappt.
A. K. schrieb: > 6502A lief ganz offiziell mit 2MHz. Es gab auch später welche mit 4MHz, aber ich meinte den Originalen.
Der 6502 ist ein schöner Prozessor mit vielen interessanten Adressierungsarten, leider nur mit sehr wenigen Registern. Gute Ansätze für ein Minimalsystem kann man den Schaltplänen folgender SBCs entnehmen: Elektor Junior Computer Rockwell AIM-65 Commodore Kim-1 Ein Programm-Eprom muss auf den oberen Speicherbereich 0xFFFF (Reset-Vector) gemappt werden! Ohne den startet der Prozessor nicht richtig!
Wolfgang R. schrieb: > Der 6502 ist ein schöner Prozessor mit vielen interessanten > Adressierungsarten, leider nur mit sehr wenigen Registern. Das ist ja gerade der Hauptunterschied zu anderen Prozessoren: Beim 6502 dient die Zeropage quasi als (etwas langsamere) Registerbank.
Wolfgang R. schrieb: > Der 6502 ist ein schöner Prozessor mit vielen interessanten > Adressierungsarten, leider nur mit sehr wenigen Registern. Die ersten 256 Byte im RAM arbeiten wie Register. Immer noch mein Lieblings uC ;)
So wie ich das verstanden habe, geht es hier nicht um Unterschiede in der Anwendbarkeit heute oder damals, sondern um Bastelspielchen auf unterster Ebene. Direkt an den Pins zu verfolgen, was die Kiste macht. Unterschiede in Befehlssatz, Programmierung oder gar Hochsprachen spielen dann keine Rolle. Umso mehr die Unterschiede in der Hardware direkt.
Wolfgang R. schrieb: > Elektor Junior Computer > Rockwell AIM-65 > Commodore Kim-1 Da darf der CEPAC-65 nicht fehlen, ein Minimalsystem, wenn man noch einen 6532 auftreiben kann: http://retro.hansotten.nl/6502-sbc/cepac-65/
Für Fans: "WDC also licenses 65C02 cores that run up to 200MHz." Aber hier gehts ja eher um < 1 Hz.
:
Bearbeitet durch User
Andreas B. schrieb: >> 6502A lief ganz offiziell mit 2MHz. > > Es gab auch später welche mit 4MHz, aber ich meinte den Originalen. Ich auch: http://6502.org/documents/datasheets/mos/mos_6500_mpu_preliminary_may_1976.pdf
A. K. schrieb: > Für Fans: "WDC also licenses 65C02 cores that run up to 200MHz." Gab (oder gibt) es den auch zu kaufen? Obwohl, zu spät, mein Ohio Superboard zum Aufpimpen ist schon von 20 Jahren in der Tonne gelandet. A. K. schrieb: > Andreas B. schrieb: >>> 6502A lief ganz offiziell mit 2MHz. >> >> Es gab auch später welche mit 4MHz, aber ich meinte den Originalen. > > Ich auch: > http://6502.org/documents/datasheets/mos/mos_6500_mpu_preliminary_may_1976.pdf Das war der 6502A. Der war im Ohio und den ersten 6502 Homecomputern nicht verbaut.
:
Bearbeitet durch User
Matthias S. schrieb: > Da darf der CEPAC-65 nicht fehlen, ein Minimalsystem, wenn man noch > einen 6532 auftreiben kann: Yep. Ein Mikrocontroller für Bastler. Ging auch noch kleiner mit 28-Pin 6504 statt 40-Pin 6502. Als Entwicklungsssystem diente ein AIM-65, Commodore oder sonst einer der 6502 "PCs", bei dem man sowieso schon eine Entwicklungsumgebung drauf hatte - der Unterschied zu echten µCs.
A. K. schrieb: > Wenn es massgeblich darum geht, auf dem Bus direkt mitzuschnüffeln, ist > das bei 6502 (oder 68xx) wesentlich leichter, weil ein Taktzyklus einem > Speicherzyklus entspricht. Ich finde das Schnüffeln beim Z80 leichter, da hat man getrennte Signale für IO, RAM und Code lesen/schreiben (IORQ, MREQ, M1, RD, WR). Wie erfolgt denn beim 6502 das Latchen beim Lesen oder Schreiben? Ich sehe da nur ein Signal Read/Write (RWB).
Peter D. schrieb: > Ich sehe da nur ein Signal Read/Write (RWB). Mehr braucht es auch nicht, da sowohl die Register (Zero Page) als auch das I/O im Speicher gemappt sind.
Peter D. schrieb: > Wie erfolgt denn beim 6502 das Latchen beim Lesen oder Schreiben? > Ich sehe da nur ein Signal Read/Write (RWB). Eben. Mehr gibts auch nicht. Taktsignal high kennzeichnet den Zugriff. Taktzyklen ohne Zugriff gibts nicht. Wenn grad nichts ansteht, findet eben ein Dummy-Read statt. Was auf eine Adresse sein kann, die sich in der Adressrechnung ohne Übertrag nach A8 ergibt. Gibts keinen Übertrag, ist dieser Zyklus produktiv. Andernfalls wird er ignoriert und in diesem Takt die obere Adresshälfte berechnet. Jetzt klar, wieso das Teil auf dem Bus einfacher zu tracken ist? ;-) PS: SYNC kennzeichnet den Opcode-Fetch vgl M1. Nützlich, wenn man das mit RDY oder NMI zum Single-Step koppelt.
:
Bearbeitet durch User
Andreas B. schrieb: > Mehr braucht es auch nicht, da sowohl die Register (Zero Page) als auch > das I/O im Speicher gemappt sind. Du brauchst mindestens noch ein Strobe, um beim Schreiben zu sagen, daß Adressen und Daten stabil sind. Einem Schreibzyklus kann man doch nicht die Adressen/Daten unterm Hintern wegändern. Ein Strobe beim Lesen ist auch nicht schlecht, damit man IC-Ausgänge enablen kann, ohne daß die kurzzeitig gegeneinander kämpfen.
Peter D. schrieb: > Du brauchst mindestens noch ein Strobe, um beim Schreiben zu sagen, daß > Adressen und Daten stabil sind. Einem Schreibzyklus kann man doch nicht > die Adressen/Daten unterm Hintern wegändern. Dazu wird das Taktsignal Φ2 verwendet. RD,WR Signale lassen sich aus Φ2 und R/W per Gatter ableiten, wenn nötig. 6800 ist genauso, wobei da aber ein VMA-Signal eine gültige Adresse anzeigt und Φ2 als "E" bezeichnet wird. Das kennst du selbst aus Text-LCDs, der HD44780 wurde für den 6800 Bus entwickelt. Hitachi war 2nd Source für 6800 und entwickelte da auch selber.
:
Bearbeitet durch User
Stefanus F. schrieb: > Dabei lernst du nichts nützliches. Und ob man dabei nützliches lernt. Beispielsweise kann man, wenn man den Prozessor mit minimalem Takt betreibt, einer Instruktion Takt für Takt zusehen - Anlegen von Adress- und Steuersignalen Lesen des Opcodes Anlegen von Adress- und Steuersignalen Lesen etwaiger Operanden Anlegen von Adress- und Steuersignalen Schreiben etwaiger Ergebnisse Man kann das natürlich als theoretisch zu erlernende Grundlagen ansehen, aber es trainiert auch das Lesen von Binärzahlen. Ich hab' (vor sehr, sehr langer Zeit) meinen ersten Selbstbau-Rechner auf diese Art und Weise in Betrieb genommen. Im Eprom (das mir ein Freund für das Ding gebrannt hatte) war ein Fehler, und den habe ich mit LEDs und einem Assemblerlisting gesucht. Das war sozusagen Debuggen im Single-Step-Betrieb, wenn auch ohne Möglichkeit, die Registerinhalte zu sehen. Nach ein paar tausend Taktzyklen war der Fehler gefunden, ein anderer Freund mit Eprommer patchte das Programm und dann lief die Kiste ...
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > war ein Fehler, und den habe ich mit > LEDs und einem Assemblerlisting gesucht. Da hast Du es ja noch gut gehabt. Ich habe mich beim Ohio mit Maschinencode durchgefrickelt und auch so programmiert.
Gab es da nicht ein fertiges Board mit einem diskreten Nachbau der CPU und zahlreichen LEDs drauf? Moment, ich google mal... Da isser: https://monster6502.com/
A. K. schrieb: > Peter D. schrieb: >> Du brauchst mindestens noch ein Strobe, um beim Schreiben zu sagen, daß >> Adressen und Daten stabil sind. Einem Schreibzyklus kann man doch nicht >> die Adressen/Daten unterm Hintern wegändern. > > Dazu wird das Taktsignal Φ2 verwendet. RD,WR Signale lassen sich aus Φ2 > und R/W per Gatter ableiten, wenn nötig. 6800 ist genauso, wobei da aber > ein VMA-Signal eine gültige Adresse anzeigt und Φ2 als "E" bezeichnet > wird. > Falls es jemanden interessiert: http://osi.marks-lab.com/reference/files/C1P-UserManual.pdf Das ganze Adressdecodierung und RAM Logik sieht man auf S.13.
A. K. schrieb: > Peter D. schrieb: >> Wie erfolgt denn beim 6502 das Latchen beim Lesen oder Schreiben? >> Ich sehe da nur ein Signal Read/Write (RWB). > > Eben. Mehr gibts auch nicht. Taktsignal high kennzeichnet den Zugriff. > Taktzyklen ohne Zugriff gibts nicht. Wenn grad nichts ansteht, findet > eben ein Dummy-Read statt. > > Was auf eine Adresse sein kann, die sich in der Adressrechnung ohne > Übertrag nach A8 ergibt. Gibts keinen Übertrag, ist dieser Zyklus > produktiv. Andernfalls wird er ignoriert und in diesem Takt die obere > Adresshälfte berechnet. > > Jetzt klar, wieso das Teil auf dem Bus einfacher zu tracken ist? ;-) ..nö. Zumindest mir nicht. Ich halte eine Einzelschrittmimik am Z80 für trivial, habe früher schon Sowas gebaut und aktuell sogar ein Bauwerk eines damaligen Freundes auf dem Tisch. Ich verstehe nicht was Du daran für kompliziert hältst, kenne aber auch den 6502 nicht wirklich. Die Tatsache das der Z80 zusätzlich eine IO Adreßraum hat, äußert sich in einer zusätzlichen LED für IORQ zu MREQ. Das macht aber weder was einfacher noch komplizierter. Du kannst IORQ auch einfach weglassen und mit dem Z80 ein rein Memory-Mapped System bauen, Niemand wird Dich daran hindern. > > PS: SYNC kennzeichnet den Opcode-Fetch vgl M1. Nützlich, wenn man das > mit RDY oder NMI zum Single-Step koppelt. Demzufolge scheint es da nicht viel Unterschied zu geben. Gruß, Holm
A. K. schrieb: > Peter D. schrieb: >> Du brauchst mindestens noch ein Strobe, um beim Schreiben zu sagen, daß >> Adressen und Daten stabil sind. Einem Schreibzyklus kann man doch nicht >> die Adressen/Daten unterm Hintern wegändern. > > Dazu wird das Taktsignal Φ2 verwendet. RD,WR Signale lassen sich aus Φ2 > und R/W per Gatter ableiten, wenn nötig. 6800 ist genauso, wobei da aber > ein VMA-Signal eine gültige Adresse anzeigt und Φ2 als "E" bezeichnet > wird. > > Das kennst du selbst aus Text-LCDs, der HD44780 wurde für den 6800 Bus > entwickelt. Hitachi war 2nd Source für 6800 und entwickelte da auch > selber. Das ist anders, aber nicht einfacher. Wie Du schon sagst läßt sich das mit ein paar Gattern inneinander überleiten. I8080 hat IOW und IOR, MEMW und MEMR..oder einfach Statussignale die erst decodiert werden müssen. Das ist das Selbe wie MREQ und RD für MEMR oder MREQ und WR für MEMW, Io analog. Gruß, Holm
Stefanus F. schrieb: > Gab es da nicht ein fertiges Board mit einem diskreten Nachbau der CPU > und zahlreichen LEDs drauf? Moment, ich google mal... > > Da isser: https://monster6502.com/ Wow - sehr schick - so etwas wäre doch definitiv etwas für die Bürowand eines Elektronikunternehmens - jedenfalls deutlich besser als irgendwelche geschmacklosen Bilder (lokaler Künstler) :-)
Manfred schrieb: > Es gibt / gab keinen 6501. Der kleine Bruder des 6502 ist der 6504. Komisch, mein Rockwell Datenbuch von 1984 hat auf Seite 2-18 einen R6501Q im 64 beinigen Gehäuse. Der hat 32 I/O Pins zusätzlich und etwas internen Speicher.
65C02 auf Steckbrett wird sportlich. Die Versorgungsspannung ist etwas zickig bei denen. Da müssen die Siebkondensatoren ganz nahe beim Chip sein, sonst verrechnet der sich.
Guido Körber schrieb: > Komisch, mein Rockwell Datenbuch von 1984 hat auf Seite 2-18 einen > R6501Q im 64 beinigen Gehäuse. Der hat 32 I/O Pins zusätzlich und etwas > internen Speicher. Die sind wg. Patentproblemem mit Motorola ziemlich schnell wieder eingestampft worden.
Andreas B. schrieb: >> Komisch, mein Rockwell Datenbuch von 1984 hat auf Seite 2-18 einen >> R6501Q im 64 beinigen Gehäuse. Der hat 32 I/O Pins zusätzlich und etwas >> internen Speicher. > > Die sind wg. Patentproblemem mit Motorola ziemlich schnell wieder > eingestampft worden. Der erste 6501 war pinkompatibel zum 40-pinnigen 6800 und musste deshalb eingestampft werden. Der R6501Q ist ein wesentlich später entstandener 64-Pinner ohne Verwandschaft zum 6800.
:
Bearbeitet durch User
Andreas B. schrieb: > Die sind wg. Patentproblemem mit Motorola ziemlich schnell wieder > eingestampft worden. Gut, dass man sie bei ebay trotzdem problemlos kaufen kann...
Holm T. schrieb: > Ich halte eine Einzelschrittmimik am Z80 für trivial, Gemeint sind hier m.E. Einzelschritte auf dem Bus, nicht einzelne Befehle. Also Takt für Takt zum mitlesen.
Wolfgang R. schrieb: > Gut, dass man sie bei ebay trotzdem problemlos kaufen kann... Ja, das kleine Q am Ende übersehen. ;-)
Andreas B. schrieb: > Wolfgang R. schrieb: >> Gut, dass man sie bei ebay trotzdem problemlos kaufen kann... > > Ja, das kleine Q am Ende übersehen. ;-) Es geht mehr um MCS6501 vs R6501.
hinz schrieb: > Es geht mehr um MCS6501 vs R6501. Eigentlich geht es weder um den einen noch den anderen, sondern um den W65C02. ;-)
:
Bearbeitet durch User
A. K. schrieb: > hinz schrieb: >> Es geht mehr um MCS6501 vs R6501. > > Eigentlich geht es weder um den einen noch den anderen, > sondern um den W65C02. ;-) Viel zu modern!
Wahnsinn was ich hier für eine Diskussion losgetreten hab! Guido Körber schrieb: > 65C02 auf Steckbrett wird sportlich. Die Versorgungsspannung ist etwas > zickig bei denen. Da müssen die Siebkondensatoren ganz nahe beim Chip > sein, sonst verrechnet der sich. Da hab ich bei den Projekten wie z.B. Steckschwein noch nix von Problemen gelesen. Ist auch egal, 100nF's hab ich genug da. ;) So, hab ihn heut mal auf dem Steckbrett aufgebaut, $EA fest auf die IO Pins gelegt und die Adresspins und Clock auf nen Arduino der mit die Aktuelle Adresse bei jedem Takt ausliest und seriell an den PC schickt. Klappt soweit ohne Probleme. Habs gemütlich mit 1Hz angefangen und als das klappte ihn mal ne weile mit 50Hz laufen lassen. Bis jetzt alles sauber und stabil. Nächster Schritt ist unten 32kB RAM und oben 8kB ROM rein zu packen um das ganze OE CS WE geschalte zu verstehen. Gruß Tom
A. K. schrieb: > Holm T. schrieb: >> Ich halte eine Einzelschrittmimik am Z80 für trivial, > > Gemeint sind hier m.E. Einzelschritte auf dem Bus, nicht einzelne > Befehle. Also Takt für Takt zum mitlesen. Die Einzelschrittmimik die ich kenne löst auch die Einzelnen Buszyklen auf, also ist bei cpir z.B. nicht nur der Befehl, sondern jedes einzelne Data-Read zu verfolgen. Ich verstehe also immer noch nicht wieso Du das für problematisch hältst. Gruß, Holm
Holm T. schrieb: > Die Einzelschrittmimik die ich kenne löst auch die Einzelnen Buszyklen > auf, also ist bei cpir z.B. nicht nur der Befehl, sondern jedes einzelne > Data-Read zu verfolgen. CPIR wird nicht als Statemachine-Schleife ausgeführt, sondern der Befehl wird in voller Schönheit vollständig wiederholt (*), als bestünde er aus einem CPI und einem Sprung zurück auf sich selbst. Also CPI,CPI,CPI,CPI,... Dadurch werden zwischen den Iterationen Interrupts möglich und es wird der Refresh nicht vergessen. Und natürlich verfolgt ein Single Step jede Iteration einzeln. > Ich verstehe also immer noch nicht wieso Du das für problematisch > hältst. Ich schrieb "komplexer", nicht "problematisch". *: HLT arbeitet genauso, mit Sprung auf sich selbst. Nonstop wiederholte M1 Zyklen.
:
Bearbeitet durch User
A. K. schrieb: > Holm T. schrieb: >> Die Einzelschrittmimik die ich kenne löst auch die Einzelnen Buszyklen >> auf, also ist bei cpir z.B. nicht nur der Befehl, sondern jedes einzelne >> Data-Read zu verfolgen. > > CPIR wird nicht als Statemachine-Schleife ausgeführt, sondern der Befehl > wird in voller Schönheit vollständig wiederholt (*), als bestünde er aus > einem CPI und einem Sprung zurück auf sich selbst. Also > CPI,CPI,CPI,CPI,... Dadurch werden zwischen den Iterationen Interrupts > möglich und es wird der Refresh nicht vergessen. Und natürlich verfolgt > ein Single Step jede Iteration einzeln. Ja und? > >> Ich verstehe also immer noch nicht wieso Du das für problematisch >> hältst. > > Ich schrieb "komplexer", nicht "problematisch". > Hmm.. > *: HLT arbeitet genauso, mit Sprung auf sich selbst. > Nonstop wiederholte M1 Zyklen. Sonst wäre kein Refresh möglich. ..und komplexer ist da gar Nichts. Gruß, Holm
Wir haben hier aber gar keinen Z80, sondern es ist ein 65C02. Der hat CPIR oder LDIR gar nicht, sondern jeder Befehl wird in 1, 2 oder max. 3 Zyklen abgearbeitet. Das ist ja gerade neben dem beinharten Timing der Trick. Und das Timing ermöglicht so geniale Konstruktionen wie den im Hauptspeicher liegenden Video RAM, der ohne Wartezyklen oder andere Tricks von CPU und Display 'gleichzeitig' benutzt wurde. Siehe den Schaltplan vom Apple ][.
Matthias S. schrieb: > sondern jeder Befehl wird in 1, 2 oder max. 3 Zyklen abgearbeitet. 2 bis 7 Zyklen.
mach neu schrieb: > Gibt es den Core auch als Emulation Äh, natürlich gibt es 6502-Emulatoren. Die ganzen Kisten von Commodore vor dem Amiga verwendeten den, die Kisten von Atari vor dem ST taten das auch und natürlich alles von Apple vor Mac/Lisa tat das. Mit nur wenigen Momenten der Suche wirst Du was finden, da bin ich sicher.
Matthias S. schrieb: > Und das Timing ermöglicht so geniale Konstruktionen wie den im > Hauptspeicher liegenden Video RAM, Naja, das liegt in erster Linie daran, daß alle Aktivität sich in der zweiten Hälfte des Taktzyklus drängelt. Das war beim 6800 genauso, und deswegen konnte man, sofern das RAM nur schnell genug war, problemlos mit 180° Phasenverschiebung zwei Prozessoren/Controller alternierend auf das gleiche RAM zugreifen lassen. Das konnte man für Video-RAM o.ä. nutzen (stilsicher mit 6845) oder aber auch für Multiprozessorsysteme. Dafür war halt die Taktfrequenz nicht besonders hoch; die meisten 6502-Systeme wurden mit gerade mal 1 MHz betrieben, mehr als 2 MHz waren dann schon selten. Bei 68xx-Systemen sah das genauso aus. Ursprünglich war das RAM (und auch die EPROMs) so langsam, daß man derartiges nicht anstellen konnte.
Rufus Τ. F. schrieb: > Ursprünglich war das RAM (und auch die EPROMs) so langsam, daß man > derartiges nicht anstellen konnte. Die üblichen EPROMs hatte 450ns Zugriffszeit, mehr als 1 MHz geht da nicht. SRAMs wie 2114 1Kx4 waren in der Standardausführung auch nicht schneller.
:
Bearbeitet durch User
Matthias S. schrieb: > Wir haben hier aber gar keinen Z80, sondern es ist ein 65C02. Der > hat > CPIR oder LDIR gar nicht, sondern jeder Befehl wird in 1, 2 oder max. 3 > Zyklen abgearbeitet. Das ist ja gerade neben dem beinharten Timing der > Trick. > > Und das Timing ermöglicht so geniale Konstruktionen wie den im > Hauptspeicher liegenden Video RAM, der ohne Wartezyklen oder andere > Tricks von CPU und Display 'gleichzeitig' benutzt wurde. > Siehe den Schaltplan vom Apple ][. Das ist wirklich genial, was der Wozniak da gebaut hat. Ich habe Tage und Wochen über dem Assembler Code gesessen und „mehr“gelernt als in allen Vorlesungen zusammen ??
call -151 c050 c057 nach 37 Jahren kann ich das immer noch nicht vergessen ;)
Hallo, Rufus Τ. F. schrieb: > Das war beim 6800 genauso, meine erste Begegnung mit einem µP, da mußte man sich wenigestens nicht mit sovielen Registern rumschlagen. ;-) Hardware drumrum waren der Original-Taktgenerator (MC6870) und ein 128x8 Ram (MC6810). Dazu D195 (7495) als Latch für Daten und Adressbus mit 7-Segment-Decodern und VQB71. Tastatur eine 4x5 Matrix als Hex-Tastatur mit TTL-Grab, um Daten und Adresse für den 6800 bereitzustellen. Ich weiß bis heute nicht, ob der 6800 überhaupt voll statisch war, zumindest ging ein Single-Step in Hardware bei mir stabil... LDAA #0x03 LDAB #0x04 STAA 0x0080 oder so ähnlich und es lag Adresse 0x80 mit Daten 0x07 an, Hurra. Ende dieser Einstigsphase war 6800, 8x 2102 (1kx8 Ram), ein 2708 (1k EPORM), ein 6820 (PIA) und ein 6850 (UART). 7-Segment mit Software-Multiplex, Tastatur als Matrix, 300Baud Cansas-City Standard als Kasseninterface, Monitorprogamm mit den üblichen Funktionen. Von manchen dieser Erkenntnisse zehre ich wohl heute noch, ich bin mir aber sehr sicher, das ich den Drahtverhau heute nicht mehr löten würde... ;-) Das kann er aber gern rund um den 6502 bauen, wenn es Spaß macht. Gruß aus Berlin Michael
Tim schrieb: >> Und das Timing ermöglicht so geniale Konstruktionen wie den im >> Hauptspeicher liegenden Video RAM, der ohne Wartezyklen oder andere >> Tricks von CPU und Display 'gleichzeitig' benutzt wurde. >> Siehe den Schaltplan vom Apple ][. > > Das ist wirklich genial, was der Wozniak da gebaut hat. > Ich habe Tage und Wochen über dem Assembler Code gesessen und > „mehr“gelernt als in allen Vorlesungen zusammen ?? Das haben der Ohio 1P und andere genauso gemacht. Daß das so von Wozniac stammt, möchte ich mal bezweifeln.
Michael U. schrieb: > Ich weiß bis heute nicht, ob der 6800 überhaupt voll statisch war, War er nicht. DMA über Cycle Stealing durfte man man nur so ein Dutzend Takte lang machen, sonst unregistrierten sich die Register.
Andreas B. schrieb: > Tim schrieb: >>> Und das Timing ermöglicht so geniale Konstruktionen wie den im >>> Hauptspeicher liegenden Video RAM, der ohne Wartezyklen oder andere >>> Tricks von CPU und Display 'gleichzeitig' benutzt wurde. >>> Siehe den Schaltplan vom Apple ][. >> >> Das ist wirklich genial, was der Wozniak da gebaut hat. >> Ich habe Tage und Wochen über dem Assembler Code gesessen und >> „mehr“gelernt als in allen Vorlesungen zusammen ?? > > Das haben der Ohio 1P und andere genauso gemacht. Daß das so von Wozniac > stammt, möchte ich mal bezweifeln. Ja, 2 und mehr Jahre später....?
Zyklische Videoausgabe aus dem Dynamischen Programm-RAM heraus ist schon genial, weil es die komplette Refresh-Logik unnötig macht...
Tim schrieb: > Ja, 2 und mehr Jahre später....? Und wohlgemerkt in 2kByte ROM (!). Die anderen ROMs enthielten nur das BASIC. Hat man die rausgezogen, startete der Monitor ohne Knurren und Brummen.
Tim schrieb: > Andreas B. schrieb: >> Tim schrieb: >>>> Und das Timing ermöglicht so geniale Konstruktionen wie den im >>>> Hauptspeicher liegenden Video RAM, der ohne Wartezyklen oder andere >>>> Tricks von CPU und Display 'gleichzeitig' benutzt wurde. >>>> Siehe den Schaltplan vom Apple ][. >>> >>> Das ist wirklich genial, was der Wozniak da gebaut hat. >>> Ich habe Tage und Wochen über dem Assembler Code gesessen und >>> „mehr“gelernt als in allen Vorlesungen zusammen ?? >> >> Das haben der Ohio 1P und andere genauso gemacht. Daß das so von Wozniac >> stammt, möchte ich mal bezweifeln. > > Ja, 2 und mehr Jahre später....? Apple II und Superboard 1P kamen beide 1977 raus. Ich denke eher, daß man zwangsläufig auf diese Idee kommen muß. Ich hatte mal mal ein einfaches DOS für den Ohio geschrieben. Ich kam mir sehr schlau dabei vor, das OS auf die ersten Spuren zu schreiben und das Inhaltsverzeichnis auf die mittlere Spur der Disk (Zugriffszeit). Später habe ich festgestellt daß CP/M das schon lange so gemacht hatte. :-(
Fairerweise: Auf recht clevere Weise CPU-RAM und Videorefresh zu kombinieren ist auch Sinclair bei ZX-80 gelungen, in insgesamt 1kB RAM.
Michael U. schrieb: > Von manchen dieser Erkenntnisse zehre ich wohl heute noch, Bei mir war es einige Jahre später, mit einem 6809 und 48 kiB RAM. Auf Lochrasterplatinen gefädelt. Die Kiste lief dann etliche Jahre lang zuverlässig mit 2 MHz Takt ...
Die Form des Video-Sharings wurde sogar noch bei 68000 Systemen genutzt, auf die gleiche Weise. Die konnte ja auch noch den 6800 Bus. Allerdings war der Zugriff darauf langsamer, weshalb es in dem System 2 Banks gab, eine schnelle und eine langsame.
A. K. schrieb: > Fairerweise: Auf recht clevere Weise CPU-RAM und Videorefresh zu > kombinieren ist auch Sinclair bei ZX-80 gelungen, in insgesamt 1kB RAM. Das ist wahr, allerdings wurde zumindest beim ZX-81 ja insofern die CPU ausgebremst, indem die ULA dem Z80 NOPs unterschob, während der Bildschirm abgearbeitet wurde. Ich habe nie so ganz verstanden, warum man sich nicht den Refresh Zähler des Z80 zunutze gemacht hat, um mit ihm den Videoram auszulesen, die Idee spukte mir immer mal wieder im Kopf rum, aber ist im Laufe der Jahre natürlich obsolet geworden. Der Bauteileaufwand war natürlich beim ZX-81 ungeschlagen niedrig - typisch Clive Sinclair.
:
Bearbeitet durch User
A. K. schrieb: > Auf recht clevere Weise CPU-RAM und Videorefresh zu > kombinieren ist auch Sinclair bei ZX-80 gelungen, in insgesamt 1kB RAM. Der ZX-81 hat aber statische RAMs auf dem Motherboard, die brauchen keinen Refresh...
Ich vermute mal, die ursprünglich Idee kam von Don Lancaster: https://en.wikipedia.org/wiki/TV_Typewriter#TV_Typewriter_Cookbook Wäre mal interessant da reinzuschauen.
A. K. schrieb: > Die Form des Video-Sharings wurde sogar noch bei 68000 Systemen genutzt, > auf die gleiche Weise. Jep. Gutes Beispiel ist der klassische Macintosh (128k/512k/SE), der auf die Art auch gleich noch den Sound produzierte, der die gleiche Samplefrequenz wie die Zeilenfrequenz des Videos hatte...
Wolfgang R. schrieb: > A. K. schrieb: >> Auf recht clevere Weise CPU-RAM und Videorefresh zu >> kombinieren ist auch Sinclair bei ZX-80 gelungen, in insgesamt 1kB RAM. > > Der ZX-81 hat aber statische RAMs auf dem Motherboard, die brauchen > keinen Refresh... Die RAms nicht, aber die Videologik.
Beim Z80-Homecomputer (KC85) waren auch die CPU- und Videozugriffe ineinander verschachtelt. Daher mußte der CPU-Quarz auch eine ganz bestimmte Frequenz haben. Ich glaube, die Videoausgaben wurden in den Refreshzyklus eingeblendet, statt der Refreshadresse. Da die Videoausgabe die Adresse hochzählte, funktionierte der DRAM-Refresh weiterhin.
Hallo, A. K. schrieb: > Michael U. schrieb: >> Ich weiß bis heute nicht, ob der 6800 überhaupt voll statisch war, > > War er nicht. DMA über Cycle Stealing durfte man man nur so ein Dutzend > Takte lang machen, sonst unregistrierten sich die Register. gerade mal das Datenblatt des MC6800 runtergeladen. Ich habe es wohl über /HALT realisiert, Takt lief ja durch. Damit darf man das ja machen. Damals kannte ich aber nichtmal den Unterschied. ;) Gruß aus Berlin Michael
Rufus Τ. F. schrieb: > Mit nur wenigen Momenten der Suche wirst Du was finden, da bin ich > sicher. Für PC ja klar, gibt s bis zum Abwinken, aber für ARM oder einen anderen embedded (nicht raspberry)???
Man bekommt solche Emulationen auch als C-Code. Den kompiliert man dann für das System der Wahl.
A. K. schrieb: > Fairerweise: Auf recht clevere Weise CPU-RAM und Videorefresh zu > kombinieren ist auch Sinclair bei ZX-80 gelungen, in insgesamt 1kB RAM. Nicht wirklich. Der ZX-80 konnte entweder das Programm ausführen oder etwas auf dem Monitor anzeigen. Beides gleichzeitig ging nicht. Wenn das Programm lief, dann war der Monitor schwarz. Wenn der Monitor etwas anzeigte, dann war die Programmausführung angehalten.
mach neu schrieb: > Rufus Τ. F. schrieb: >> Mit nur wenigen Momenten der Suche wirst Du was finden, da bin ich >> sicher. > > Für PC ja klar, gibt s bis zum Abwinken, aber für ARM oder einen anderen > embedded (nicht raspberry)??? Das ist doch vollkommen Wumpe. Eine Emulation eines CPU-Kerns kann man in 100% architekturunabhängigem C schreiben. Im Grunde ist das nur eine etwas größere Statemachine. Wenn man da nicht schlampt oder absichtlich eine Abhängigkeit von der Zielarchitektur einbaut, dann compiliert das auf einem ARM genauso wie auf einem x86 PC. Geschwindigkeit ist natürlich eine andere Frage. Aber ein 6502 ist gemessen an heutigen Architekturen so lahm, daß man sich anstrengen muß, um die Emulation noch langsamer zu machen, als das Original.
Thomas P. schrieb: > Wahnsinn was ich hier für eine Diskussion losgetreten hab! > > Guido Körber schrieb: >> 65C02 auf Steckbrett wird sportlich. Die Versorgungsspannung ist etwas >> zickig bei denen. Da müssen die Siebkondensatoren ganz nahe beim Chip >> sein, sonst verrechnet der sich. > > Da hab ich bei den Projekten wie z.B. Steckschwein noch nix von > Problemen gelesen. Ist auch egal, 100nF's hab ich genug da. ;) > > So, hab ihn heut mal auf dem Steckbrett aufgebaut, $EA fest auf die IO > Pins gelegt und die Adresspins und Clock auf nen Arduino der mit die > Aktuelle Adresse bei jedem Takt ausliest und seriell an den PC schickt. > Klappt soweit ohne Probleme. Habs gemütlich mit 1Hz angefangen und als > das klappte ihn mal ne weile mit 50Hz laufen lassen. Bis jetzt alles > sauber und stabil. > > Nächster Schritt ist unten 32kB RAM und oben 8kB ROM rein zu packen um > das ganze OE CS WE geschalte zu verstehen. > > Gruß Tom Hallo Tom, 65C02 auf Steckbrett ist absolut problemlos, einfach ein paar 100nF in die GND/VCC Schiene stecken und gut ist. Bei mir lief ein 65C02 mit 11MHz ohne das geringste Problem. http://forum.6502.org/viewtopic.php?f=4&t=3458&hilit=romulus+1st da es für 11MHz beim ROM schwierig wird habe ich dem 6502 einen AVR spendiert der ihm beim Booten ein paar Instruktionen liefert und so das "BootROM" liefert. Der AVR kontrolliert den Takt, d.h. da hat der AVR keine Eile. Sobald das "BootROM" über diesen Weg geladen ist übernimmt der 65C02 das Szepter. Der AVR liefert weiterhin den Takt aber nun nicht via Software sondern via Hardware (PHI2 ist ein Timer output). Der AVR übernimmt danach die Aufgabe einen VGA Monitor zu füttern und ein PS/2 Keyboard zu bedienen. Gruss Peter
GeraldB schrieb: > Nicht wirklich. Der ZX-80 konnte entweder das Programm ausführen oder > etwas auf dem Monitor anzeigen. Beides gleichzeitig ging nicht. Nur gut, daß andere Z80 Kleincomputer mit TV-Ausgang das nicht wußten, die konnten das nämlich sehr wohl.
Es gab aber einige Systeme, die einen Großteil der Bilderzeugung in Software erledigt haben. Bei abgeschaltetem Bildschirm liefen Berechnungen dann deutlich schneller.
Peter D. schrieb: >> Nicht wirklich. Der ZX-80 konnte entweder das Programm ausführen oder >> etwas auf dem Monitor anzeigen. Beides gleichzeitig ging nicht. > > Nur gut, daß andere Z80 Kleincomputer mit TV-Ausgang das nicht wußten, > die konnten das nämlich sehr wohl. Die Aussage bezog sich auf die extrem minimalistische Weise, mit der ZX-80 und ZX-81 den Videorefresh abwickelten. Nicht auf alle Z80-Systeme. Wenn man den Program Counter als Adresszähler für Videodaten verwendet und den Befehlsdekoder zusammen mit der Refresh-Adresse für die Erkennung vom Zeilenende, dann kann man schlecht parallel dazu ein Programm ausführen. Der ZX-81 fügte einen Modus hinzu, in dem das Programm in der vertikalen Austastlücke ausgeführt wurde. Schnell war das natürlich nicht. Aber die Bilddarstellung setzte nicht aus und es war immer noch sparsam in Hardware.
:
Bearbeitet durch User
Matthias S. schrieb: > Ich habe nie so ganz verstanden, warum > man sich nicht den Refresh Zähler des Z80 zunutze gemacht hat, um mit > ihm den Videoram auszulesen, die Idee spukte mir immer mal wieder im > Kopf rum, aber ist im Laufe der Jahre natürlich obsolet geworden. Das Problem ist das Timing. Das geht nur, wenn die CPU ausschliesslich M1 Zyklen ausführt. So kannst du aber kein sinnvolles Programm ausführen. Weshalb der ZX-80 das auch nicht tat, d.h. sein "Programm" bestand beim Videorefresh innerhalb einer Zeile nur aus NOP und HLT, die sich auf dem Bus nur in der PC-Zählung unterscheiden.
:
Bearbeitet durch User
Sehr zu empfehlen, wenn man sich ein 6502-System auf Breadboard-Basis aufbauen möchte (und dazu eine Menge über die Systemarchitektur lernen möchte): Mehrteiliges Video-Tutorial von Ben Eater auf https://eater.net/6502
Thread beobachten
Seitenaufteilung abschaltenBitte 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.