Hallo, ich versuche mich aktuell daran einen alten Computer zu klonen. Dieser basiert auf UA880D mit 4x 2716 EPROMs. Aktuell versuche ich, dass ein (noch) UA880D sein Programm von einem 28C64 liest, aber das ganze funktioniert leider nicht. Ich habe die Chip-Selects CS0 bis CS3 zusammen gefasst, da ja nur noch ein Speicherchip vorhanden ist. OE ist, wie beim alten, einfach auf GND gezogen. Man hätte es hier auch mit RD verbinden können, aber vorher hat es ja auch funktioniert. In der Schaltung befinden sich noch viele weitere Bausteine. PIOs / SIOs/ CTC. Diese sind aktuell nicht verbaut, sondern lediglich CPU, EEPROM und RAM. Sowohl mit originaler 4MHz clock, als auch mit 10Hz clock aus einem Arduino macht der CPU keinen Anschein startet zu wollen. Ich habe mit dem Arduino einmal die Datenpins beim Start ausgelesen, um zu schauen ob irgendwo der Inhalt des EEPROMs sichtbar wird. Leider verläuft sich das ganze nach ein paar Zyklen schon und der CPU bleibt hängen. Im Anhang befinden sich die Zeichnungen und die "Aufzeichnungen" von 6 Startversuchen. Erkennt jemand, warum der Z80 sich sein Programm nicht vom EEPROM lädt? Vielen Dank für die Hilfe!
Angehängte Dateien:
-
z80alt.png
190 KB -
z80neu.png
200 KB
Mit dem Startup kann niemand was anfangen. Was bedeuten denn die einzelnen Bits? Sind das die Adressen?
Angehängte Dateien:
-
ROM-A.PNG
17 KB
Fooji schrieb: > Mit dem Startup kann niemand was anfangen. Was bedeuten denn die > einzelnen Bits? Sind das die Adressen? Das sind wie erwähnt die Datenpins. Ich hatte nicht genug I/O auf dem Arduino um gleichzeitig die Adressen herauszulesen. Ich wollte nachschauen, ob ich in den Datenpins die Inhalte des EEPROMs wiederfinde. Zumindest die ersten paar Bits. Der Inhalt beginnt mit: 31 00 28 AF ED 47 18 0A EF 11 41 14 68 05 C0 0B 05 18 ED 5E 3E 03 D3 7F 21 00 20 11 01 20 01 86 01 36 00 ED B0 21 88 20 11 Aber es ist nichts zu sehen, außer das gezeigte, bis sich der CPU aufhängt / nichts mehr auf den Datenpins passiert.
:
Bearbeitet durch User
Guck mit dem Arduino mal auf die Adressen. Da sollte nach dem RESET 0000h anliegen und dann mit jedem Takt hochzählen.
* /RFSH wird nur bei DRAM benötigt -> nicht beschalten.. * /RD der CPU auf /OE des EEPROM. * Den Adressdecoder statt mit A11-A13 mit A13-A15 verbinden. Der Output /O0 geht dann direkt auf /CS des EEProm. Die Kombination der Ausgänge mit den beiden NAND ist dann überflüssig. Dann solle die CPU zumindest anlaufen, wobei das ohne RAM immer noch wenig Sinn ergibt. /O1 kann dann als /CS für ein (statisches) RAM genutzt werden. Der /CS für das RAM darf nicht invertiert werden! Die Ausgänge des 74138 sind active Low.
:
Bearbeitet durch User
- Schau dir den CS des EEproms an der muss 0 werden immer wenn das Rom angesprochen wird. - Schau dir /RST an der muss 1 sein damit die CPU rennt. - Schau dir /Halt und /Wait an die müssen 1 sein. Mit 10Hz Clock wird's vermutlich nichts werden das dürfte keine statische CPU sein.
Moin, - investiere 10EUR in einen billigen Logikanalysator. Alles andere ist vergebene Lebenszeit. Und Du weisst schon, dass die Maschine ab 0x2000 RAM erwartet, der Stack bei 0x2800 ist, vielleicht hat auch der I/O-Port bei 0x7f eine Funktion (zeigst ja nicht). Ich weiss ja auch nicht, was Du das misst. Gruesse Th.
Vergessen: Ich weiss nicht, welche der verschiedenen CPUs Du benutzt: Die CMOS-Versionen sind statisch, NMOS brauchen ca. 100kHz (aus der Erinnerung, das Datanblatt habe ich nicht in der Hand). Gruesse Th.
>/CS für das RAM darf nicht invertiert werden!
wie heisst das RAM? hat es tatsächlich einen high aktiven CS-Eingang?
Sonst ist es ja immer aktiv, auch bei Zugriff auf das EEPROM, dann
beissen sich die beiden Ausgänge.
Wieso sind die oberen Adressen nicht ausdecodiert? So tauchen alle Daten
an vier verschiedenen Adressen wieder auf.
Jetzt würde ich erst mal den Oszi benutzen um zu prüfen, ob die Signale sauber sind oder die Buslast Ärger macht.
Thomas Z. schrieb: > Mit 10Hz Clock wird's vermutlich nichts werden das dürfte keine > statische CPU sein. Meiner Erinnerung nach schon.
Christoph db1uq K. schrieb: >>/CS für das RAM darf nicht invertiert werden! > wie heisst das RAM? hat es tatsächlich einen high aktiven CS-Eingang? Hat es sicher nicht, also ist das RAM immer aktiv, ausser dann wenn es soll. Und ausserdem funktioniert ein Z80-Programm ohne RAM so gut wie sicher nicht. Georg
Angehängte Dateien:
Es ist RAM vorhanden. Ich bin aktuell unterwegs, daher nur kurz der Screenshot vom RAM. Ich melde mich später wieder diesbezüglich.
Jörg W. schrieb: > Thomas Z. schrieb: >> Mit 10Hz Clock wird's vermutlich nichts werden das dürfte keine >> statische CPU sein. > > Meiner Erinnerung nach schon. "Although static by design, testing guarantees tw(phi-H) of 200µs maximum."
Georg schrieb: > Und ausserdem funktioniert ein Z80-Programm ohne RAM so gut wie > sicher nicht. Ich schrieb welche, die alleine mit den vielen Registern des Z80 auskamen.
Kommen da jetzt noch viele Salamischeiben? 1kx4 SRams ... Wow sowas kenne ich nur noch aus meiner Azubi Zeit... und ich bin 81 fertig geworden. Damals gab's aber noch keine 4MHz CPUs
Maik S. schrieb: > OE ist, wie beim alten, einfach auf GND gezogen. Man hätte es hier auch > mit RD verbinden können, aber vorher hat es ja auch funktioniert. Die EEPROM sind C-MOS. Die wollen getaktete Signale. Trenne mal /OE von Masse und verbinde es mit /CE. Beim 2716 ist das nicht nötig.
Thomas Z. schrieb: > Kommen da jetzt noch viele Salamischeiben? 1kx4 SRams ... Wow > sowas > kenne ich nur noch aus meiner Azubi Zeit... und ich bin 81 fertig > geworden. Damals gab's aber noch keine 4MHz CPUs Den Z80 gabs 1981 sogar als 6Mhz Version.
Moin, - ein wenig off-Topic aber: H. H. schrieb: > Thomas Z. schrieb: >> Kommen da jetzt noch viele Salamischeiben? 1kx4 SRams ... Wow >> sowas >> kenne ich nur noch aus meiner Azubi Zeit... und ich bin 81 fertig >> geworden. Damals gab's aber noch keine 4MHz CPUs > > Den Z80 gabs 1981 sogar als 6Mhz Version. Elektor Juli/August 1983, ehring-Elektronik: Z80B = 24,50DEM. Die 4MHz war mit 8.45DEM richtig guenstig. Genug ueber die "guten alten Zeiten" sinniert. Gruesse Th. P.S.: Der Junior-Computer hatte auch 2 * 1k x 4bit. Das war halt die Dichte an Static-RAM die bezahlbar war.
Maik S. schrieb: > Erkennt jemand, warum der Z80 sich sein Programm nicht vom EEPROM lädt? Das wichtigste hast Du auf Deinem Schaltplan nicht drauf, nämlich wo der Takt herkommt. Die alten NMOS-CPUs brauchen richtig massiv High-Pegel am CLK-Pin, einfach TTL reicht nicht. Da nimmt man einen LS-TTL mit 330 Ohm Pullup gegen VDD oder baut sich eine aktive Pull-Stufe mit einem PNP-Transistor. Bei CMOS (Z84C00..) kannst Du mit Logikpegel reingehen, aber Du willst ja die guten alten Dinger einsetzen :-) Ansonsten: erstmal ein EPROM mit lauter Nullen einsetzen (oder die Datenleitungen auf low klemmen). Dann führt das Ding lauter NOPs aus und zählt die Adressleitungen hoch. Auf dem Oszi sieht das scheisse aus weil die Refresh-Zyklen dazischenliegen, aber im Logikdiagramm sieht man die Systematik. Bzw Fehler in derselben, die auf Probleme mit CPU und Adressbus schließen lassen.
H. H. schrieb: > Den Z80 gabs 1981 sogar als 6Mhz Version. OK die Erinnerung ist getrübt.... Lt Wiki wurde die 4MHz Version des UA880D ab 1984 produziert.
:
Bearbeitet durch User
Angehängte Dateien:
Soul E. schrieb: > Maik S. schrieb: > >> Erkennt jemand, warum der Z80 sich sein Programm nicht vom EEPROM lädt? > > Das wichtigste hast Du auf Deinem Schaltplan nicht drauf, nämlich wo der > Takt herkommt. Die alten NMOS-CPUs brauchen richtig massiv High-Pegel am > CLK-Pin, einfach TTL reicht nicht. Da nimmt man einen LS-TTL mit 330 Ohm > Pullup gegen VDD oder baut sich eine aktive Pull-Stufe mit einem > PNP-Transistor. Ich hatte den Clockgenerator ausgeblendet, da er schon getestet ist und funktioniert. Aber der Vollständigkeit halber hier nochmal ein Auszug. > Bei CMOS (Z84C00..) kannst Du mit Logikpegel reingehen, aber Du willst > ja die guten alten Dinger einsetzen :-) Der Plan ist, erst einen Klon im alten Zustand zum laufen zu bringen um dann nach und nach modernere Komponenten zu nutzen. Die 2716 mussten nur sofort weichen, weil die (+Beschreiben) schon sehr teuer sind.
magic9994 schrieb: > Die 2716 mussten nur sofort weichen, weil die (+Beschreiben) schon sehr > teuer sind. Huh? Davon sollte es doch noch Unmengen geben, und fürs Beschreiben hätte ich lediglich die Portokosten verlangt (viele andere sicher auch). Nichtsdestotrotz solltest du die 64er auch zum Laufen bekommen.
magic9994 schrieb: > Ich hatte den Clockgenerator ausgeblendet, da er schon getestet ist und > funktioniert. "Funktioniert" heisst für einen NMOS Z80, der High-Pegel liegt ganz dicht unter oder kurz über VDD. Deine Schaltung sieht passend aus, das sollte so laufen.
Es gibt noch zwei Z80-Rechner zu kaufen, das Landolt-TNC2C (2,4 MHz-Takt) und TNC2C-H (10 MHz ?), dazu auch Einzelteile, z.B. den 10MHz-Z80 für 6,70€: https://www.landolt.de/info/afuinfo/tnc2c9k6.htm https://www.landolt.de/preise/bauteile.htm
Wer noch Z80 CPUs und/oder Peripherie-Chips braucht, darf mich gerne kontaktieren. Gegen Erstattung der Porto-Kosten würde ich die abgeben.
Beitrag #6747710 wurde von einem Moderator gelöscht.
Beim Drüberschauen ist mir aufgefallen, dass das CS-Signal der RAMs über ein 4023-CMOS-Gatter erzeugt wird. Verzögerung bei 5V 125ns (typ.)/250 ns (max.). Passt das zum Timing von CPU und RAM (konnte kein Datenblatt zu letzterem finden)? Soweit ich das im Kopf habe musste vor 40 Jahren mein RAM für die 4MHz Z80A-CPU 350ms und für 6 MHz Z80B-CPU 250 ns Zugriffszeit haben. Da fällt die Gatterlaufzeit der klassischen 4000er schon ins Gewicht.
magic9994 schrieb: > Der Plan ist, erst einen Klon im alten Zustand zum laufen zu bringen um > dann nach und nach modernere Komponenten zu nutzen. Die 2716 mussten nur > sofort weichen, weil die (+Beschreiben) schon sehr teuer sind. Dann nimm erst mal wieder einen 2716! michael_ schrieb: > Die EEPROM sind C-MOS. > > Die wollen getaktete Signale. > Trenne mal /OE von Masse und verbinde es mit /CE. Dann mach das erst mal! Vergleiche die Datenblätter! C-MOS brauchen die fallende Flanke an /OE.
Angehängte Dateien:
-
camphoto_1932422408.JPG
3,1 MB
Ich habe nun einen Logic Analyzer angeschlossen um mir die 14 Adressen und die CS des RAM und EEPROM anzeigen zu lassen. Ich habe ihn zuletzt mit einem Takt von 350Khz betrieben. Er zeigte dabei verschiedene Verhaltensweisen. 1. Er "stürzt" irgendwann ab. die letzten Adressen die angesprochen wurden bleiben einfach hängen. Nichts passiert. Die zuletzt angesprochene Adresse ist dabei meistens eine andere. Dabei war CS des EEPROMs immer Low. 2. Er landet in einem Loop, durchsucht dabei immer den RAM(?) von Adresse 2000 - 217F, ist ein paar Schritte im Adressbereich 27XX und fängt wieder von vorne an. Dieser Loop ist aber nicht, in dem er landen sollte denke ich, ansonsten würde die 7 Segmentanzeige, welche an einem PIO hängt leuchten. Hoffentlich.. (siehe Video) Es handelt sich dabei um den Klon des Tiracon 6V Computers. Ich habe daher einen noch funktionierenden Computer hier und kann die Layouts vergleichen. Einzig und allein wurde hier bisher die 4 EEPROMs gegen einen 28C64 getauscht. Der Schaltplan ist mehrfach geprüft und sollte keine Fehler mehr beinhalten. Fooji schrieb: > Guck mit dem Arduino mal auf die Adressen. Da sollte nach dem > RESET > 0000h anliegen und dann mit jedem Takt hochzählen. Das konnte ich auf dem Oszi beobachten. Harry L. schrieb: > * /RFSH wird nur bei DRAM benötigt -> nicht beschalten.. Ist mit der alten Platine abgeglichen und genau wie auf der alten und auch neuen Schaltung gleich. > * /RD der CPU auf /OE des EEPROM. Würde ich auch nochmal ausprobieren. > * Den Adressdecoder statt mit A11-A13 mit A13-A15 verbinden. Der Output > /O0 geht dann direkt auf /CS des EEProm. > Die Kombination der Ausgänge mit den beiden NAND ist dann überflüssig. > Dann solle die CPU zumindest anlaufen, wobei das ohne RAM immer noch > wenig Sinn ergibt. > > /O1 kann dann als /CS für ein (statisches) RAM genutzt werden. > > Der /CS für das RAM darf nicht invertiert werden! > Die Ausgänge des 74138 sind active Low. Ist ebenfalls mit der alten Platine abgeglichen und genau wie im alten und neuen Schaltplan gleich. A14 und A15 sind nicht verbunden, die Unterscheidung mit CS, ob der Z80 im RAM landen möchte oder im EEPROM scheint ja auch zu klappen. Die angesprochenen Adressbereiche während der jeweiligen Phasen sind richtig. Thomas W. schrieb: > Vergessen: > > Ich weiss nicht, welche der verschiedenen CPUs Du benutzt: Die > CMOS-Versionen sind statisch, NMOS brauchen ca. 100kHz (aus der > Erinnerung, das Datanblatt habe ich nicht in der Hand). > > Gruesse > > Th. UA880D. Das ist ein DDR Z80. Der Tiracon 6V ist ein DDR Synthesizer. Ich wollte, wenn dieses Board mit altem CPU funktioniert testen, ob der Code auch auf "normalen" Z80 läuft. Uwe Grassmé schrieb: > Beim Drüberschauen ist mir aufgefallen, dass das CS-Signal der > RAMs über > ein 4023-CMOS-Gatter erzeugt wird. Verzögerung bei 5V 125ns (typ.)/250 > ns (max.). > > Passt das zum Timing von CPU und RAM (konnte kein Datenblatt zu > letzterem finden)? > > Soweit ich das im Kopf habe musste vor 40 Jahren mein RAM für die 4MHz > Z80A-CPU 350ms und für 6 MHz Z80B-CPU 250 ns Zugriffszeit haben. Da > fällt die Gatterlaufzeit der klassischen 4000er schon ins Gewicht. Guter Einwand, aber auch hier hätte das ja beim Vorgänger ebenfalls dann nicht funktioniert vermute ich. Hier einmal ein Bild der alten Platine, im Anhang ist der Klon zu sehen. http://www.analog-service.com/images/tiracon-6v/tiracon-6v-digitalplatine-bestueckungsseite-hires.jpg PS: Auch voll bestückt mit 8/4MHz Clock startet er nicht, falls das jemand aufgrund des Bildes vermutet.
:
Bearbeitet durch User
Maik S. schrieb: > camphoto_1932422408.JPG Um Himmels Willen! Wie konnte man nur vor fast 40 Jahren ohne das Drahtgefitze so eine Schaltung in den Griff kriegen? Danke, dass ich sowas noch erleben darf.
michael_ schrieb: > Vergleiche die Datenblätter! > C-MOS brauchen die fallende Flanke an /OE. Da du das nun schon mehrmals behauptest, wo steht das? Ich sehe da (im Lesebetrieb) nur Diagramme mit Gültigkeitszeiten, keine Verpflichtung, dass es Flanken an /OE geben muss. (Sinnvoll kann es natürlich trotzdem sein, /OE zu beschalten.)
Ich sehe 2 Probleme die dir ev die "Petersilien Verhageln" könnten 1)SOFTWARE DATA PROTECTION: Hast du versehentlich dies Aktiviert? werkseitig ist es normalerweise Dissabled 2)AC Read Characteristics: Es ist möglich das die Daten nicht verfügbar sind wenn der Z80 sie braucht, Das kann einesteils vom Timing her kommen, anderen teils auch davon das das EEPROM ev Kommandos sieht. Hast du schon mal Probiert anstelle des EEPROM ein UV-EPROM zu verwenden? Da dein Z80 schön aufwärz zählt wen er NoOps siht ist das Problem da im Timingverhalten des EEPROM zu suchen. Dein geposteter Datastream zeigt keine vernünftigen Z80 Befehle!
Patrick L. schrieb: > Ich sehe 2 Probleme die dir ev die "Petersilien Verhageln" könnten > 1)SOFTWARE DATA PROTECTION: Das ist ein Schreibschutz. Fürs Auslesen der Daten spielt das keine Rolle. Der wesentliche Sinn dieser data protection ist es, dass man auch mit irgendwelchen race conditions an /WE (vor allem beim Powerup) nicht versehentlich Daten überschreiben kann. > 2)AC Read Characteristics: > Es ist möglich das die Daten nicht verfügbar sind wenn der Z80 sie > braucht, > Das kann einesteils vom Timing her kommen, Das ist erstmal nicht grundlegend anders als bei einem normalen EPROM. "Kommandos" sehe ich da nicht im Datenblatt. Alles, was von normalem EPROM-Verhalten abweicht, braucht irgendwie irgendwann low-Signal an /WE. Solange das auf high ist, sollte sich das Teil komplett wie ein normaler EPROM benehmen.
Jörg W. schrieb: > sollte sich das Teil komplett wie ein > normaler EPROM benehmen. Das ist richtig, nur wenn alles andere >Richtig ist, warum ist dann im Datenstrom nur Müll und keine vernünftigen Z80 Opcodes zu sehen? Der Z80 ist ein Statisches CPU, also kann man den Clock ja quasi von Hand machen. Aber dennoch zeigt der Gepostete Datenstrom nur Müll. Ergo entweder blockiert was den Datenbus, oder das EEPROM hat Müll drin. Wen beides nicht zutrifft bleibt logischerweise nur noch das Timingverhalten übrig!
Patrick L. schrieb: > warum ist dann im Datenstrom nur Müll und keine vernünftigen Z80 Opcodes > zu sehen? Muss man halt analysieren. Bei meinem Z80-Computer habe ich damals einen primitiven LA mit ein paar Siebensegmentanzeigen gebaut und damit die Kurzschlüsse zwischen den Busleitungen aufgespürt. Heutzutage gibt es preiswerte LAs, allerdings wird die Luft im Bereich "preiswert" bei mehr als 16 Bit Breite ziemlich schnell dünn. Die LAs von vor 30 Jahren dagegen glänzten vor allem durch extrem breite Datenerfassung, denn das war bei derartigen Computersystemen wesentlich.
Jörg W. schrieb: > 16 Bit Breite ziemlich schnell dünn. Ja das ist so aber falls es von Nöten wäre habe ich hier noch ein Dolch DLI mit 64 Kanälen und wenn dass nicht reicht, noch ein anderer (Groß und schwer) GOULD mit 256 Kanälen Bei bedarf kann mann sich die Ausleihen, aber entweder kommt die Schaltung zu mir, oder man holt sie und bringt sie wieder zum Versenden sind beide zu schwer und unhandlich ....LOL...
Vor etwas mehr als 35 Jahren, hat mir eine Schaltung, ähnlich dieser Beitrag "Re: [Z80] Einzelschritt Takterzeugung, langt da ein Knopf an _CLK?" bei der Inbetriebnahme/Fehlersuche gute Dienste geleistet.
Patrick L. schrieb: > 1)SOFTWARE DATA PROTECTION: > Hast du versehentlich dies Aktiviert? werkseitig ist es normalerweise > Dissabled Die sollte man nicht versehentlich aktivieren, sondern absichtlich! Ansonsten kann im Einschaltmoment ein Glitch auf /WE den EEPROM-Inhalt verändern. Beachten muß man auch, EEPROM sind zu SRAM pinkompatibel, aber nicht zu EPROM!
Patrick L. schrieb: > Der Z80 ist ein Statisches CPU, also kann man den Clock ja quasi von > Hand machen. Der CMOS Z80 ja. Der n-MOS Z80 und insbesondere der U880 nicht. Die brauchen eine minimale Taktfrequenz. Der Wert ist stark exemplar- und temperaturabhängig. So um die 100kHz sollten es schon sein.
:
Bearbeitet durch User
Angehängte Dateien:
-
28c64_OE.jpg
14 KB
Jörg W. schrieb: > Da du das nun schon mehrmals behauptest, wo steht das? > > Ich sehe da (im Lesebetrieb) nur Diagramme mit Gültigkeitszeiten, keine > Verpflichtung, dass es Flanken an /OE geben muss. (Sinnvoll kann es > natürlich trotzdem sein, /OE zu beschalten.) Aus Erfahrung von damals. Obige Flanke wird benötigt. Gilt auch für C-MOS EPROM, 6116, usw. Peter D. schrieb: > Beachten muß man auch, EEPROM sind zu SRAM pinkompatibel, aber nicht zu > EPROM! Zum 27C64 doch.
michael_ schrieb: > Aus Erfahrung von damals. > Obige Flanke wird benötigt. Entnehme ich dem Datenblatt nicht, aber Erfahrungen damit habe ich nicht.
2716 habe ich schon ewig nicht mehr benutzt aber aus der Erinnerung: CS/ aktiviert die interne Dekodierung der Adressen. OE/ aktiviert nur die Tri-State Ausgänge wenn CS/ aktiv ist. Ich habe CS/ immer auf GND gelegt und nur mit OE/ gearbeitet weil damit einige ns Geschwindigkeit zu holen waren. Der Stromverbrauch aber geringfügig steigt.
EPROM mit Adreßlatch, die eine /CE-Flanke benötigen, hatten eine abweichende Bezeichnung, z.B. 27C65, 27C257. Damit konnte man am 80C31 das Adreßlatch (74HC573) einsparen. EEPROM mit Adreßlatch sind mir keine bekannt. Aus DDR-Zeiten habe ich noch einen U6516 (SRAM mit Adreßlatch).
Angehängte Dateien:
-
Read.jpg
53 KB
michael_ schrieb: > Aus Erfahrung von damals. > Obige Flanke wird benötigt. > Gilt auch für C-MOS EPROM, 6116, usw. Noe, wenn CS und RD = Low und WE = High ist, dann erscheint an den Ausgaengen direkt das Datenbyte auf was die Addresspins zeigen. Flanken braucht es da nicht.
Bei meinem ersten (Fernseh)Terminal war der Zeichengenerator mit einem 2716 bei dem CS/ und OE/ fest auf GND lagen. Definitiv statisch.
Die 27xxx-Typen sind definitiv statisch. Früher hab ich die gern in verb. mit einem rückgekoppelten 8bit-Latch als Statemachine verwendet.
:
Bearbeitet durch User
Angehängte Dateien:
-
28c64-1.PNG
90 KB
Karadur schrieb: > Bei meinem ersten (Fernseh)Terminal war der Zeichengenerator mit > einem > 2716 bei dem CS/ und OE/ fest auf GND lagen. Definitiv statisch. Harry L. schrieb: > Die 27xxx-Typen sind definitiv statisch. > Früher hab ich die gern in verb. mit einem rückgekoppelten 8bit-Latch > als Statemachine verwendet. Als ich meinen Tiracon erhielt hatte er defekte 2716er drin. Diese konnte ich einfach auf einem Breadboard mit 5V und ein paar LEDs auslesen. Definitiv statisch. Aber verhält sich der 28C64 auch so? Ich muss mich leider gleich erstmal um die Clock kümmern, irgendwie will die nun nicht mehr. Dann trenne ich OE vom GND und verbinde es mit RD vom CPU. Ich bekomme evtl. im laufe des Tages noch einen größeren LA mit Eingängen und Ausgängen. Dann kann ich den EEPROM Inhalt auch noch einmal überprüfen. Frage: Reicht es denn beim 28C64 WE einfach mit auf die +5V Spannungsversorgung zu hängen, sodass beim Einschalten nichts passiert oder sollte hier noch etwas anders gemacht werden?
Moin, - Maik S. schrieb: > Als ich meinen Tiracon erhielt hatte er defekte 2716er drin. Diese > konnte ich einfach auf einem Breadboard mit 5V und ein paar LEDs > auslesen. Definitiv statisch. Aber verhält sich der 28C64 auch so? Und wo hast Du den Inhalt herbekommen (andere Maschine)? Ich haenge /WE immer ueber 4k7 gegen +5V ueber eine Steckbruecke (wenn man schreiben will/muss). Ist aber nicht noetig (+5V an /WE) reicht. Du koenntest vielleicht mal die komplette Schaltplaene veroeffentlichen, mit Salamischeiben ist es immer nervig. Gruesse Th.
Evtl. auch die Flussspannung von D1 nicht beachtet (blaue LED?^^), dadurch Eingangspegel am 4023 im verbotenen Bereich.
Nach diesem DB: https://www.futurlec.com/Memory/28C64PLCC.shtml ist es kein Problem. Schau mal bei Writeprotection.
michael_ schrieb: > Aus Erfahrung von damals. > Obige Flanke wird benötigt. Wie Dein angehängtes Diagramm zeigt kannst Du während /CE und /OE low sind nach Belieben die Adressen ändern und die Daten ändern sich passend mit. Sonst wäre ja auch ein Betrieb als "Wertetabelle" mit fest auf low gelegtem /CE und /OE nicht möglich.
Soul E. schrieb: > Wie Dein angehängtes Diagramm zeigt kannst Du während /CE und /OE low > sind nach Belieben die Adressen ändern und die Daten ändern sich passend > mit. Sonst wäre ja auch ein Betrieb als "Wertetabelle" mit fest auf low > gelegtem /CE und /OE nicht möglich. Das funktioniert übrigens statisch perfekt mit den EEPROMs auf meinem Nibbler [1] [1] Beitrag "Re: Nibbler 4 Bit CPU"
:
Bearbeitet durch User
Thomas W. schrieb: > Moin, - > Maik S. schrieb: > >> Als ich meinen Tiracon erhielt hatte er defekte 2716er drin. Diese >> konnte ich einfach auf einem Breadboard mit 5V und ein paar LEDs >> auslesen. Definitiv statisch. Aber verhält sich der 28C64 auch so? > > Und wo hast Du den Inhalt herbekommen (andere Maschine)? http://www.tiracon-6v.de/htm/manuals.htm Dort gibt es auch das Service Manual mit allen Schaltplänen > Du koenntest vielleicht mal die komplette Schaltplaene veroeffentlichen, > mit Salamischeiben ist es immer nervig. Sorry für das Denglisch. War dabei ihn vollständig zu übersetzen, aber mich überkam die Faulheit. Kai O. schrieb: > Evtl. auch die Flussspannung von D1 nicht beachtet (blaue LED?^^), > dadurch Eingangspegel am 4023 im verbotenen Bereich. rote LED, vorher war die LED grün.
Moin, - eine banale Frage zum Verstaendnis: Du baust die CPU-Karte von Scratch neu auf. Warum mischt Du CMOS (CD4023) mit den antiken TTL-Speicher? Ein 6116 (2kx8) braucht weniger Platz und (Du willst ja auch den Speicherinhalt halten) laesst sich sehr gut mit einer kleinen Zelle puffern. Falls Du den 6116 nicht mehr bekommst, ein 6264 kostet 2.60EUR. Du hast schon die 2716 ausgetauscht (aus 4 mach 1), mach doch das gleiche auch bei dem Speicher (auch aus 4 mach 1). Gruesse Th.
Man sollte auch die Anhänge nicht vergessen. Zur Info: X130 ist mit X310 verbunden. Das Flachbandkabel ist auf dem Bild zu sehen. Thomas W. schrieb: > Moin, - > > eine banale Frage zum Verstaendnis: Du baust die CPU-Karte von Scratch > neu auf. Warum mischt Du CMOS (CD4023) mit den antiken TTL-Speicher? Ein > 6116 (2kx8) braucht weniger Platz und (Du willst ja auch den > Speicherinhalt halten) laesst sich sehr gut mit einer kleinen Zelle > puffern. Falls Du den 6116 nicht mehr bekommst, ein 6264 kostet 2.60EUR. > > Du hast schon die 2716 ausgetauscht (aus 4 mach 1), mach doch das > gleiche auch bei dem Speicher (auch aus 4 mach 1). Naja so gut wie das mit dem EEPROM bisher geklappt hat, überlege ich fast wieder auf 2716 zurück zu gehen. Die Kombination CD4023 und TTL-Speicher habe ich mir nicht ausgedacht. Ich bin aber offen für Verbesserungen.
:
Bearbeitet durch User
Maik S. schrieb: > Naja so gut wie das mit dem EEPROM bisher geklappt hat, überlege ich > fast wieder auf 2716 zurück zu gehen. > Die Kombination CD4023 und TTL-Speicher habe ich mir nicht ausgedacht. > Ich bin aber offen für Verbesserungen. warum den, ich sehe jetzt erst mal nichts was nicht funktioniert, deine CPU rennt ja los, und wie du schreibst wird auf dem Ram rumgeschrieben, das passt doch. Wenn deine CPU in einen Halt geht, muss man das untersuchen, am EEprom wird das sicher nicht liegen, wenn du die Inhalte richtig zusammenkopiert hast. In Frage kommen da Kurzschlüsse zb an einer der höheren Adressen da der Anfang ja wohl korrekt ist. So ein SingleStep FF an Halt, ev mit 2 * 74HC688 zur Einstellung eines Triggers sind da hifreich. Das wurde ja schon oben angedeutet. Hilfreich wäre auch ein Disassembler Output. Zum Ram: das hätte ich an deiner Stelle gleich mit geändert und ein 2k SRAM verwendet. Damit würde dein Inverter am CS sowie die NANDs des Ramdecoder wegfallen. Ich mache mir in solchen Fällen immer eine Memory Map und schreibe mir die Addressbereiche der einzelnen CS auf. In deinen Fall ev auch im IO Bereich. Ich habe nicht geprüft ob die IO Bausteine in den Speicher gemappt sind oder ob die im IO Bereich liegen.
Maik S. schrieb: > Die Kombination CD4023 und TTL-Speicher habe ich mir nicht ausgedacht. > Ich bin aber offen für Verbesserungen. Der CD4023 ist viel zu langsam (ca. 250ns tpd). Es kann sein das die RAMs noch Daten auf dem Bus ausgeben wenn schon das EPROM wieder aktiviert ist. Versuch denn mal durch einen 74HC10 zu ersetzen. Ist zwar jetzt nicht Pinkompatibel... aber ein bisschen Draht hilft da schon. Ansonsten mal ein kleines Testprogramm schreiben, was nicht viel macht. Und wo nur das Eprom angesprochen wird. Also so etwas: org 0h Start: jmp Start und dann die Daten und Addressleitungen dir mal anschauen. Und wie viele schon vorher gesagt haben den RD mal imt dem OE des EEPROM verbinden, ebendo bei den RAMs.
Thomas Z. schrieb: > wenn du die Inhalte richtig zusammenkopiert hast. > In Frage kommen da Kurzschlüsse zb an einer der höheren Adressen da der > Anfang ja wohl korrekt ist. So ein SingleStep FF an Halt, ev mit 2 * > 74HC688 zur Einstellung eines Triggers sind da hifreich. Das wurde ja > schon oben angedeutet. Ich werde das mal bauen und anschließen wenn mir jetzt nicht der Gedankenblitz über den Weg läuft woran es liegt. >Hilfreich wäre auch ein Disassembler Output. siehe Anhang > Zum Ram: > das hätte ich an deiner Stelle gleich mit geändert und ein 2k SRAM > verwendet. Damit würde dein Inverter am CS sowie die NANDs des > Ramdecoder wegfallen. Ich hatte es erstmal so gelassen. Die RAMs waren noch erhältlich, nicht zu teuer und müssen ja einfach nur draufgesteckt werden, nicht beschrieben werden wie EPROMs. Ich hatte nur bereits Probleme mir 2716er für den originalen beschreiben zu lassen, daher der tausch. Sollte das Board aber bald starten wäre das der nächste Schritt. Vielen dank für die Hinweise. > Ich mache mir in solchen Fällen immer eine Memory Map und schreibe mir > die Addressbereiche der einzelnen CS auf. In deinen Fall ev auch im IO > Bereich. Ich habe nicht geprüft ob die IO Bausteine in den Speicher > gemappt sind oder ob die im IO Bereich liegen. Ich muss zugeben - Ich habe kaum Ahnung von Z80 / Mikrocontroller im Allgemeinen. Ich kann Atmegas programmieren, hatte auch in der Schule AVR ASM gelernt und erfolgreich wieder vergessen. Z80 ASM zu lesen ist daher für mich nicht wirklich möglich. Auch was in welchen Adressbereichen liegt, liegen darf usw. muss ich mir nun wohl oder übel aneignen. Vielleicht wäre es aber doch ein besserer Ansatz den Computer auf einer modernen Plattform neu zu programmieren. Befürchte aber, dass man die Eigenarten des Synthesizers dabei dann völlig verliert. Die wenden mit dem D/A etwas Magie an, indem die über das Wechseln der Referenzspannung die Auflösung von 12 auf 15 Bit erweitern. So müssen auch alle Bereiche der analogen Steuerspannungen erst herausgefunden werden etc. Da erschien ein Klon eines Z80 Rechners einfacher.
Helmut L. schrieb: > Der CD4023 ist viel zu langsam Was sich bei der erzielbaren Taktfrequenz zeigen würde, somit leicht zu diagnostizieren.
Maik S. schrieb: > Ich hatte nur bereits Probleme mir 2716er für den originalen > beschreiben zu lassen, daher der tausch. Wie geschrieben: wenn du da was brauchst, gegen Portoerstattung werde ich da ganz sicher noch was finden können.
Helmut L. schrieb: > Der CD4023 ist viel zu langsam (ca. 250ns tpd). Es kann sein das die > RAMs noch Daten auf dem Bus ausgeben wenn schon das EPROM wieder > aktiviert ist. > Versuch denn mal durch einen 74HC10 zu ersetzen. Ist zwar jetzt nicht > Pinkompatibel... aber ein bisschen Draht hilft da schon. Ich werde mir den IC besorgen und das umbauen. Es ist auch echt eine ungewöhnliche Kombination, aber es funktioniert im originalen ja auch. Vielleicht hole ich mir zusätzlich aber auch mal einen "DDR" CD4023 - vielleicht hat dieser irgendwelche Eigenarten, die das ganze wieder möglich machen. Dennoch hätte dann aber auch der "aktuelle" CD4023 bei niedrigerem Takt des CPU reichen müssen, oder? > Ansonsten mal ein kleines Testprogramm schreiben, was nicht viel macht. > Und wo nur das Eprom angesprochen wird. Ich habe kein Schreibgerät für die EEPROMs hier. Ich werde mir die Grundlagen des Z80 ASM mal anschauen, ein kleines Testprogramm schreiben und meinen Kumpel bitten mir das auf einen EEPROM zu schreiben. Vielleicht hole ich mir aber auch einfach ein Schreibgerät - mal schauen. > Und wie viele schon vorher gesagt haben den RD mal imt dem OE des EEPROM > verbinden, ebendo bei den RAMs. Werde ich heute Abend umsetzen.
Helmut L. schrieb: > Der CD4023 ist viel zu langsam (ca. 250ns tpd) ich kann mir nicht vorstellen dass das ein Problem ist, das war im Original ja wohl auch so. Wie hoch ist den die Zyklus Zeit bei einem Ram Zugriff auf einem Z80? Ich würde ja sagen 2 uS bei 4MHz (min 8 Zyklen?). Habe leider kein Datenblatt zur hand. Das ist aber etwas was man mit dem LA schön prüfen kann. @TO: lade die 4 images der Original Eproms sowie das Image des EEproms hier hoch. Ich vermute einen simplen Kopier Fehler. Ev kannst du auch eine HuckePack Version aus SRAM und EEprom löten, und die Steuerleitungen manuel verdraten.
Thomas Z. schrieb: > @TO: > lade die 4 images der Original Eproms sowie das Image des EEproms hier > hoch. Ich vermute einen simplen Kopier Fehler. Ist mir leider nicht möglich, da der EEPROM von einem Kumpel beschrieben wurde. Die Inhalte wurden einfach hintereinander gehangen. Vielleicht ist hier wirklich ein Fehler passiert. Ich werde das später überprüfen.
:
Bearbeitet durch User
TIR-A ist auf jeden Fall der Start. Dort wird als erstes der Stack initialisiert. Ansonsten ist der Disassembler Output weitgehend unbrauchbar, da keine Label gesetzt werden und jeder Teil wieder bei Addresse 0 anfängt. Es wäre wirklich hilfreich das EEprom als BIN File zu haben. Dann kann man das leicht überprüfen.
Thomas Z. schrieb: > Helmut L. schrieb: >> Der CD4023 ist viel zu langsam (ca. 250ns tpd) > ich kann mir nicht vorstellen dass das ein Problem ist, das war im > Original ja wohl auch so. Der V4023D scheint schneller zu sein als seine internationalen Vergleichstypen. Ich habe bei 5 V 170 ns gefunden als garantierte Werte. > Wie hoch ist den die Zyklus Zeit bei einem Ram > Zugriff auf einem Z80? http://www.piclist.com/techref/mem/dram/slide4.html Bei f_CPU = 4 MHz sind es 375 ns im M1 (falls aus dem RAM Befehle gelesen werden), aber entspannte 625 ns für das Lesen von Daten aus dem RAM. Ist halt die Frage, ob Abarbeitung von Befehlen aus dem RAM hier überhaupt vorgesehen ist. Wenn nicht, dann hat das Ganze mit dem 4023 + U224D35 genug Reserve.
Jörg W. schrieb: > Ist halt die Frage, ob Abarbeitung von Befehlen aus dem RAM hier > überhaupt vorgesehen ist. Wenn nicht, dann hat das Ganze mit dem 4023 + > U224D35 genug Reserve. Tretmine.
Maik S. schrieb: > Thomas Z. schrieb: >> @TO: >> lade die 4 images der Original Eproms sowie das Image des EEproms hier >> hoch. Ich vermute einen simplen Kopier Fehler. > > Ist mir leider nicht möglich, da der EEPROM von einem Kumpel beschrieben > wurde. Die Inhalte wurden einfach hintereinander gehangen. Vielleicht > ist hier wirklich ein Fehler passiert. Ich werde das später überprüfen. OK, Du kannst einen Arduino als EEprommer benutzen (z.B. https://github.com/beneater/eeprom-programmer oder https://forum.arduino.cc/t/arduino-based-parallel-eeprom-programmer/159892). Dann kannst Du Deine vier Images dann selbst schreiben (vor allen Dingen kannst Du lesen und dann einigermassen sicher sein was im EEprom steht). Achte ein bischen ueber die Adressen: Das erste 2716 geht von 0x0000-0x07ff (2k), das zweite (offensichtlich) von 0x0800 - 0x0fff. Leider kann man an den Dumps nicht die absolute Adresse sehen. Gruesse Th.
(prx) A. K. schrieb: > Jörg W. schrieb: >> Ist halt die Frage, ob Abarbeitung von Befehlen aus dem RAM hier >> überhaupt vorgesehen ist. Wenn nicht, dann hat das Ganze mit dem 4023 + >> U224D35 genug Reserve. > > Tretmine. Jein. Wofür auch immer das Ganze gedacht ist, wenn das System von EPROMs abarbeitet, gibt es ja normalerweise keinen richtigen Grund, auch noch den RAM (noch dazu mit Backup-Batterie) als Befehlsspeicher zu benutzen. Zwar war bei CP/M selbstmodifizierender Code hoch im Kurs :), aber CP/M arbeitete halt auch immer aus dem RAM ab. Anders als heute bei Flash-MCUs wiederum war die Abarbeitung aus dem RAM nicht schneller als die aus dem EPROM, und man hätte das Zeug erst noch aus dem ROM ins RAM kopieren müssen. Insofern sehe ich gute Chancen, dass das System nicht dafür ausgelegt war, jemals Code aus dem RAM abzuarbeiten.
Thomas Z. schrieb: > Es wäre wirklich hilfreich das EEprom als BIN File zu haben. Dann kann > man das leicht überprüfen.
Angehängte Dateien:
-
IMG_8074.jpg
240 KB
Thomas W. schrieb: > OK, Du kannst einen Arduino als EEprommer benutzen (z.B. > https://github.com/beneater/eeprom-programmer Mit diesem Tutorial habe ich die 2716er meines Tiracons ausgelesen und dadurch festgestellt, dass der Inhalt fehlerhaft war. Ich wollte das gleich auf 28C64 umbauen und dann dort mal reinschauen.
:
Bearbeitet durch User
Maik S. schrieb: > Kai O. schrieb: >> Evtl. auch die Flussspannung von D1 nicht beachtet (blaue LED?^^), >> dadurch Eingangspegel am 4023 im verbotenen Bereich. > > rote LED, vorher war die LED grün. Das ist auch mit einer roten LED für einen 4023 kein solider HIGH-Pegel. Welche Funktion soll diese LED denn haben, außer die 5V anzuzeigen? Dann ist an dieser Stelle aber bestimmt keine Verbindung zum 4023 nötig. Einfach die LED mal kurzschließen, so dass der 4023 an dieser Stelle einen definierten HIGH-Pegel hat und das SRAM sauber selektiert wird.
Angehängte Dateien:
-
ida.png
73 KB
ich hab mir mal die Mühe gemacht und die 4 Binaries der Reihe nach in IDA geladen. Das Ganze ergibt soweit Sinn. Auch an den Eprom Grenzen um 0x800, 0x1000 und 0x1800 scheint das Ganze zu passen. Leider bin ich mit dem Z80 Mnemnics nicht (mehr) auf du und du, ich hatte ganz früher mit dem 8085 gearbeitet. Das Disassembly hab ich mal angehängt. Wie man im Bild erkennen ist da noch viel Nacharbeit angesagt. Nur die blau gekennzeichneten Bereiche sind gültiger Assembler Funktionen. Rot ist übersetzter code (nicht zugeordnet) Grau Bereiche die der Disassembler nicht erreichen konnte. Kandidaten wo man genauer hinschauen muss sind die out Befehle und alle rst xx RST 38 sind leere Bereiche im Eprom (0xFF). Auch Referenzen auserhalb der entsprechenden Code und Datenbereiche sind immer suspekt. Wobei das in diesem Fall auch als Schutz gedient haben mag, schlieslich ist A14 und A15 nicht angeschlossen was 16k Spiegelungen gibt.
:
Bearbeitet durch User
Thomas Z. schrieb: > ich hab mir mal die Mühe gemacht und die 4 Binaries der Reihe nach > in IDA geladen. Das Ganze ergibt soweit Sinn. Auch an den Eprom > Grenzen um 0x800, 0x1000 und 0x1800 scheint das Ganze zu passen. Ich kann ehrlich gesagt nicht erkennen, woran du das festmachst. Der Z80 startet nach Reset bei 0x0000. Da muß gültiger Code stehen, wenigstens ein Sprung. Allerdings ist das das Herz eines Analog-Sythies, also ein Einzweck-System. Da würde ich gar keine Spezialitäten erwarten, einfach Code ab 0x0000. Eventuell noch um die Restart-Adressen wie 0x0038 herumspringend.
:
Bearbeitet durch User
Die RSTs scheinen hier nicht für Interrupts genutzt zu werden:
1 | seg000:0000 ld sp, 2800h |
2 | seg000:0003 xor a |
3 | seg000:0004 ld i, a |
4 | ... |
5 | seg000:0012 im 2 |
6 | ... |
7 | seg000:0038 jp loc_0 |
8 | ... |
9 | seg000:0066 jp loc_1960 |
Hier scheint der Interruptmode 2 genutzt zu werden, bei dem die RST-Befehle nicht die Wichtigkeit haben wie bei Intel. mit xor a/ ld i,a wird die Interrupt-Vektortabelle auf die ersten 256 Bytes gelegt, der Zeiger auf den Tabelleneintrag kommt dann von dem Periperiebaustein. Der RST38H führt hier in einen Neustart, der RST066H (NMI) zu einer Behandlungsroutine.
Axel S. schrieb: > Ich kann ehrlich gesagt nicht erkennen, woran du das festmachst. Der Z80 > startet nach Reset bei 0x0000. Da muß gültiger Code stehen, ab 0 steht gültiger Code. Zur Erinnerung: im Original gibt es 4 Eproms. Wenn da was verdreht wäre würde an den Code Grenzen unsinniger Code rauskommen. Im IDA würde man das ziemlich sicher sehen können.
Zumindest in TIR-A.BIN stehen sinnvolle Z80-Befehle (den Rest habe ich noch nicht angeschaut), die auch fleißig auf RAM und Stack zugreifen. Deshalb würde ich untersuchen, ob die SRAM-Zugriffe überhaupt richtig funktionieren (siehe insbesondere meine Anmerkung oben). Praktischerweise schreibt man hierfür ein kleines Testprogramm.
Angehängte Dateien:
-
fjdhkjasuwepi.PNG
5,6 KB
Entweder stimmt was mit meinem Lesegerät hier nicht, oder die EEPROMs sind fehlerhaft. Ich bekomme morgen einen beschriebenen 2764, vielleicht hat das mehr Erfolg. Die Daten scheinen zwar da, aber sind auch nur ganz leicht in den LEDs sichtbar.
:
Bearbeitet durch User
nun was immer dein Lesegerät so macht, zumindest hat es Probleme die geraden Adressen zu lesen. Ob ein prog. Eprom, dessen Inhalt du nicht kennst die bessere Lösung ist? Zusätzlich haben Eproms und EEproms unterschiedliche Belegungen, da musst du erst mal schauen ob das in deinem Fall auch passt
Thomas Z. schrieb: > nun was immer dein Lesegerät so macht, zumindest hat es Probleme die > geraden Adressen zu lesen. Ob ein prog. Eprom, dessen Inhalt du nicht > kennst die bessere Lösung ist? > Zusätzlich haben Eproms und EEproms unterschiedliche Belegungen, da > musst du erst mal schauen ob das in deinem Fall auch passt Ich hätte es vielleicht anders Formulieren sollen. Der 28C64 und 2764 sind pinkompatibel und natürlich sind die 4 Dateien wieder hintereinander auf dem 2764. Das hat auf dem 28C64 soweit auch schon richtig funktioniert, nur gibt es da Probleme mit allen graden Adressen.
Maik S. schrieb: > Das hat auf dem 28C64 soweit auch > schon richtig funktioniert, was hat richtig funktioniert. Hast du überprüft ob die Reihenfolge im EEprom stimmt? Wie hast du das denn überprüft wenn den Lesegerät einen Schuss hat.
Jörg W. schrieb: > aber CP/M > arbeitete halt auch immer aus dem RAM ab Neee! Das war zwar meist so, aber nicht technisch begründet. Ich hatte damals nen ECB-Bus-System gebaut, wo das kompl. CP/M+ (BIOS, BDOS + CCP) im EPROM lief. Das ganze noch mit Bankswitching, so daß ich 62kB freien Speicher für Anwendungen hatte. Geht vollkommen problemlos.
Thomas Z. schrieb: > Maik S. schrieb: >> Das hat auf dem 28C64 soweit auch >> schon richtig funktioniert, > > was hat richtig funktioniert. Hast du überprüft ob die Reihenfolge im > EEprom stimmt? Wie hast du das denn überprüft wenn den Lesegerät einen > Schuss hat. Hat ja nur einen Schuss, nicht 2. Die Hälfte die nicht 00 war hat ja noch gestimmt. Damit konnte man zumindest vergleichen, ob die Dateien richtig hintereinander liegen.
Maik S. schrieb: > Hat ja nur einen Schuss, nicht 2. Die Hälfte die nicht 00 war hat ja > noch gestimmt OK dann wird's mit einem 2764 aber auch nicht anders funktionieren als mit dem 28c64. Da bin ich mir relativ sicher. Die Buslast dürfte auch noch ok sein, zumal du ja die IO Bausteine noch nicht in Betrieb hast. Klingel die Adressleitungen und die Datenleitungen durch. Auf Durchgang und Kurzschluss gegen Vcc und Gnd
Harry L. schrieb: > Ich hatte damals nen ECB-Bus-System gebaut, wo das kompl. CP/M+ (BIOS, > BDOS + CCP) im EPROM lief. Ich glaube mich zu erinnern, dass das BDOS durchaus auch diesen berühmt-berüchtigten selbstmodifizierten Code benutzt hat, bei dem man Variablen dadurch realisiert hat, dass man Direktoperanden im Programmcode patcht:
1 | var1 equ $+1 |
2 | ld hl, 0 ; 0 ist "var1" mit Initialwert 0 |
3 | ... |
4 | ld hl, var1 |
5 | ld (hl), a |
Bis auf eine Stelle (die offensichtlich nutzlos war, weil das Codestück nie erreicht werden konnte) hatte ich dazumals das disassemblierte BDOS ganz gut verstanden. Ist aber lange her. :) Kann natürlich sein, dass es von Digital Research auch (OEM?-)Varianten gab, die sowas nicht gemacht haben. Dass man die eigentlichen CP/M-Anwenderprogramme aus was anderem als RAM ausführen kann, kann ich mir aber wirklich nicht vorstellen.
Ingo W. schrieb: > Die RSTs scheinen hier nicht für Interrupts genutzt zu werden: > > seg000:0000 ld sp, 2800h > seg000:0003 xor a > seg000:0004 ld i, a > ... > seg000:0012 im 2 > ... > seg000:0038 jp loc_0 Ja. Bis auf die ausgelassenen Teile sieht das korrekt aus. Auch SP zeigt auf das RAM-Ende. Jeder der 8 Decoder-Ausgänge ist für einen 2K Block aktiv und auf dem 5. liegt das RAM. Insofern korrekt. Nur: der ursprüngliche IDA-Screenshot zeigte das nicht. Insofern paßte er nicht zur Behauptung.
Jörg W. schrieb: > Harry L. schrieb: >> Ich hatte damals nen ECB-Bus-System gebaut, wo das kompl. CP/M+ (BIOS, >> BDOS + CCP) im EPROM lief. > > Ich glaube mich zu erinnern, dass das BDOS durchaus auch diesen > berühmt-berüchtigten selbstmodifizierten Code benutzt hat, bei dem man > Variablen dadurch realisiert hat, dass man Direktoperanden im > Programmcode patcht: > var1 equ $+1 > ld hl, 0 ; 0 ist "var1" mit Initialwert 0 > ... > ld hl, var1 > ld (hl), a > > Bis auf eine Stelle (die offensichtlich nutzlos war, weil das Codestück > nie erreicht werden konnte) hatte ich dazumals das disassemblierte BDOS > ganz gut verstanden. > > Ist aber lange her. :) > > Kann natürlich sein, dass es von Digital Research auch (OEM?-)Varianten > gab, die sowas nicht gemacht haben. > > Dass man die eigentlichen CP/M-Anwenderprogramme aus was anderem als RAM > ausführen kann, kann ich mir aber wirklich nicht vorstellen. Also ich hatte damals die CP/M+ Version von DR ohne BIOS wie sie auch an OEMs geliefert wurde, und der Code lief auch aus einem ROM. Also offenbar keine selbst-modiizierenden Teile im Code. Bei CP/M 2.2 war das noch deutlich einfacher. Irgendwo hab ich sogar noch den originalen BDOS-Source von 2.2 (Der war mir damals eine große Hilfe) Das BIOS hab ich komplett selbst geschrieben Ich hatte auch mal versuchsweise eine Karte mit ganz vielen EEPROMs gebaut, die ich als ROM-Disk genutzt hab. Zumindest WordStar, der MS-Assembler/linker und Lauterbach Trace80 lief auch im ROM. Allerdings hab ich das sehr schnell durch eine RAM-Disk ersetzt. Das grösste Problem war das erste Kilobyte (0x0000-0x0400) - das Segment durfte man nicht ausblenden, da da u.A. die Interrupt-Vectoren lagen. Die entsprechenden Einsprungspunkte lagen dann im obersten kB. Später hab ich einen HD64180 von Hitachi genutzt, der bereits eine rudimentäre Banking-Logik enthielt, und bis zu 512kB RAM verwalten konnte. Damit konnte ich dann tatsächlich >62kB für Anwendungen frei schaufeln. Lang, lang ists her, und eines dieser Selbstbau-Systeme steht noch irgendwo auf dem Dachboden....wenn die Disketten nix "vergessen" haben, sollte das sogar noch funktionieren....
Harry L. schrieb: > Das BIOS hab ich komplett selbst geschrieben /metoo > Ich hatte auch mal versuchsweise eine Karte mit ganz vielen EEPROMs > gebaut, die ich als ROM-Disk genutzt hab. > Zumindest WordStar, der MS-Assembler/linker und Lauterbach Trace80 lief > auch im ROM. Sicher? Wenn das eine ROM-Disk war, wurde das doch vermutlich von dort ab 100h in den RAM geladen (wie bei einer schreibgeschützten Diskette). Meine Kiste konnte per 2 x MH74S89 den gesamten Adressraum in 4-KiB-Blöcken beliebig auf den physischen Adressraum von 20 Bit abbilden. Damit waren auch RAM-Disks ganz einfach, und deren Transfer mittels DMA realisierbar. Aber ja, lange her, und nicht wirklich für das hier diskutierte System relevant.
Beitrag #6748906 wurde vom Autor gelöscht.
Jörg W. schrieb: > Der V4023D scheint schneller zu sein als seine internationalen > Vergleichstypen. Ich habe bei 5 V 170 ns gefunden als garantierte > Werte. Habe ich bei HEF aber auch gefunden. Wenn das ein bisher fertiges Projekt ist, wird es schon getestet sein. Auch mit dem EEPROM /OE. Obwohl ich mit dem 4023 und den U224D mit 350ns in einem 4MHz System Bauchschmerzen hätte. Passt nicht so recht, scheint aber zu laufen. Da es ein fertiges Projekt ist, wird der Fehler im Aufbau liegen. Axel S. schrieb: > Auch SP > zeigt auf das RAM-Ende. Jeder der 8 Decoder-Ausgänge ist für einen 2K > Block aktiv und auf dem 5. liegt das RAM. Insofern korrekt. Der Grundaufbau basiert auf dem LC-80. Erst ROM, dann ab 2000H RAM mit in der Grundausführung 1K RAM. Erweiterbar mit U214/U224 auf 4K. Thomas Z. schrieb: > Klingel die Adressleitungen und die Datenleitungen durch. Auf Durchgang > und Kurzschluss gegen Vcc und Gnd Test geht gut mit einem NOP-Eprom. Einfach 76H (Halt) programmieren. Oder eine Adapterplatine, wo die Datenleitungen mit Widerständen auf L gelegt werden.
michael_ schrieb: > Obwohl ich mit dem 4023 und den U224D mit 350ns in einem 4MHz System > Bauchschmerzen hätte. Siehe oben, wenn keine M1-Zyklen aus dem RAM gefahren werden sollen, ist das entspannt, da man 2,5 Taktzyklen Zeit hat. M1 hat aber nur 1,5 Taktzyklen Zeit, bis das Ergebnis eingelesen wird.
Harry L. schrieb: > Ich hatte damals nen ECB-Bus-System gebaut, wo das kompl. CP/M+ (BIOS, > BDOS + CCP) im EPROM lief. Falsch. CP/M lief nur im RAM. Schon deshalb, weil diverse Variable im Code verstreut gespeichert wurden. Um aus dem ROM laufen zu können, musste man den Quelltext heftig editieren und neu übersetzen. Offensichtlich wird hier "ROM-Disk" mit "läuft aus dem ROM" verwechselt. Selbst modifizierenden Code gibt es im originalen CP/M nicht, auch nicht den beliebten Trick mit Sprung in einen Befehl hinein. Das wurde im BASIC Interpreter gemacht, damit der Code kleiner als 8k wurde.
Angehängte Dateien:
-
inverter1.PNG
160 KB
Nach weiteren Versuchen gestern Abend haben wir in den CS von RAM / EEPROM gesehen, dass der Inverter für das CS des EEPROMS doch raus muss. Nun passen die CS zueinander. Adressen mit 0x2XXX erscheinen, wenn CS vom RAM Low ist, Adressen mit 0x0XXX erscheinen, wenn er aus dem EEPROM lesen möchte. Passt also. Nun zeigt er weiteres komisches Verhalten. Im Video ist der aktuelle Start zu sehen. Von oben nach unten im Scope: CS RAM, CS EEPROM, A13-A0 Man sieht nun, wie der Z80 beim Start Adresspin A11-A13 nutzt, nach kurzer Zeit (welche etwa zur Startzeit des Synthesizers passt) werden A12 und A11 ruhig. In A10 sieht man definitiv den CS den RAM, aber weiter passiert mal wieder nichts. Zieht man den EEPROM ändert sich das Verhalten wieder auf Wirrwarr. Beide (E)EPROMs (28C64; 2764) zeigen das auf dem Video sichtbare Verhalten. Wir haben auch mal versucht die Inhalte anders herum in den EEPROM zu schreiben: also nicht ABCD sondern DCBA. Das führt aber wieder nur zu Wirrwarr. Es passiert aber nichts weiter. Also PIOs sind still. Es kommen keine Interrupts. Ich werde gleich mal in dem funktionstüchtigen Synthesizers nachschauen, wie sich die Adressen dort beim Start verhalten.
Maik S. schrieb: > (welche etwa zur Startzeit des Synthesizers passt) Sag mal bastelst du an einem Memory-Moog rum? ich meinte der hat so ein mindestens ähnliches Board drin?
Patrick L. schrieb im Beitrag > Sag mal bastelst du an einem Memory-Moog rum? ich meinte der hat so ein > mindestens ähnliches Board drin? Leider kein Memory Moog. Es ist ein Tiracon 6v. Man findet im Analogforum bereits, wie ich schon erfolgreich den Analogteil des Tiracons geklont habe. Da wollte ich nun noch den Rechner klonen.
Magic9994 schrieb: > Es ist ein Tiracon 6v. Cool !! das ist auch ein schönes stück gewesen :-) ich hatte ein Memmory-Moog aber aus Platzgründen vor bald 30 Jahren weggegeben und vor etwa 3 Jahren mein Jupiter 6 leider auch :-( jetzt habe ich in der Beziehung nur noch ein ein JP8 (der neue ganz kleine). und ganz viele Rolands und Yamaha's :-) und auch einige EWMS Typen :-) Ich habe übrigens aus dem Grund mein Dolch DLI damals mit dem Z80 und 8080 Decoder aufrüsten lassen ;-)
Maik S. schrieb: > Nach weiteren Versuchen gestern Abend haben wir in den CS von RAM / > EEPROM gesehen, dass der Inverter für das CS des EEPROMS doch raus muss. > Nun passen die CS zueinander. Adressen mit 0x2XXX erscheinen, wenn CS > vom RAM Low ist, Adressen mit 0x0XXX erscheinen, wenn er aus dem EEPROM > lesen möchte. Das sehe ich nicht so, jedenfalls sagt der Schaltplanausschnitt mir etwas anderes. Solltest nochmal darüber nachdenken. Mir scheint, Du bist in einer Phase des Rumprobierens. Ein schlechter Weg, eine Lösung zu finden.
Maik S. schrieb: > Nach weiteren Versuchen gestern Abend haben wir in den CS von RAM > / > EEPROM gesehen, dass der Inverter für das CS des EEPROMS doch raus muss. Bestimmt nicht. Die Ausgänge des Decoders sind L-aktiv. CS vom EEPROM ist L-aktiv. Zum Zusammenfassen von Decoder-Ausgängen braucht man also ein AND. Jetzt ist da ein NAND. Paßt also nicht. Tatsächlich braucht man den Decoder für das EEPROM gar nicht, weil es reicht, A13=L und RD=L zu detektieren. Und das EEPROM hat zwei L-aktive Steuereingange (CS und OE). > Nun passen die CS zueinander. Adressen mit 0x2XXX erscheinen, wenn CS > vom RAM Low ist, Adressen mit 0x0XXX erscheinen, wenn er aus dem EEPROM > lesen möchte. Passt also. Was auch immer du zu sehen gehaben glaubst - es ist nicht die Realität. Dein Gewurschtel bei vollkommenem Unverständnis der Schaltungen, die du versuchst zu reparieren, setzt sich also fort. Nachdem du den Analogteil des Synthesizers schon nicht verstanden hast (folglich auch nicht reparieren konntest) setzt sich das jetzt beim Digitalteil fort.
Axel S. schrieb: > Tatsächlich braucht man den Decoder für das EEPROM gar nicht, weil es > reicht, A13=L und RD=L zu detektieren. Und das EEPROM hat zwei > L-aktive Steuereingange (CS und OE). richtig aber /MREQ muss schon noch ausgewertet werden sonst gibts Probleme mit den I/Os. Das Vorgehen des TO wirkt etwas planlos. Wie ich schon angemerkt hatte, hat die Verwendung des 27c64 anstelle des 28c64 keine Auswirkungen. Stehen bleiben ist etwas schwierig, Die CPU wird immer etwas machen solange ein Clock da ist und kein Reset anliegt. Das kann man M1 Pin sehen. Der Inverter muss drin bleiben!
:
Bearbeitet durch User
Thomas Z. schrieb: > Stehen bleiben ist etwas schwierig Dafür gibt's doch /WAIT. Darüber habe ich damals Pseudo-Singlestep bei der Inbetriebnahme gemacht.
Angehängte Dateien:
-
IMG_8109.jpg
2,9 MB
Axel S. schrieb: > Bestimmt nicht. Die Ausgänge des Decoders sind L-aktiv. CS vom EEPROM > ist L-aktiv. Zum Zusammenfassen von Decoder-Ausgängen braucht man also > ein AND. Jetzt ist da ein NAND. Paßt also nicht. Rein logisch betrachtet macht es keinen Sinn, da stimme ich dir zu. Hier aber im Anhang nochmal eine etwas bessere Ansicht mit beschrifteten CS. > Tatsächlich braucht man den Decoder für das EEPROM gar nicht, weil es > reicht, A13=L und RD=L zu detektieren. Und das EEPROM hat zwei > L-aktive Steuereingange (CS und OE). Ich kann den Decoder gerne mal raus nehmen, aber wie man sieht deckt sich A13 ja auch schon mit dem CS des EEPROM. Komischerweise auch richtig herum und nicht invertiert. > Was auch immer du zu sehen gehaben glaubst - es ist nicht die Realität. Sieh selbst, wir sind ebenfalls verwirrt. Ich nehme die CS direkt am EEPROM und RAM ab. > Dein Gewurschtel bei vollkommenem Unverständnis der Schaltungen, die du > versuchst zu reparieren, setzt sich also fort. Nachdem du den Analogteil > des Synthesizers schon nicht verstanden hast (folglich auch nicht > reparieren konntest) setzt sich das jetzt beim Digitalteil fort. Ach du bists. Ich verstehe dich nicht. Das hier ist ein Forum. Hier kommen unwissende an und wollen Wissen erlangen. Wozu bist du hier wenn jeder deiner Beiträge die Leute eigentlich nur beleidigt, wie dumm sie doch sind? Schau dir bitte das Bild vom Scope an und erkläre mir, warum ich so dumm bin und jetzt meine, dass CS vom RAM und CS vom EEPROM nun (zumindest was die Invertierung angeht) zueinander richtig stehen. Thomas Z. schrieb: > Das Vorgehen des TO wirkt etwas planlos. Wie ich > schon angemerkt hatte, hat die Verwendung des 27c64 anstelle des 28c64 > keine Auswirkungen. > Der Inverter muss drin bleiben! Ehrlich gesagt bin ich mit meinem Latein auch am Ende. Ich will durch dieses Projekt mehr Wissen erlangen. Ich benötige immer Projekte an denen ich mich festbeißen kann als einfach nur Bücher vor meiner Nase. Learning by doing.
Moin, - mach Dir doch mal ein kleines Testprogramm:
1 | 0000 3E A5 START: LD a,0xA5 |
2 | 0002 32 00 00 LD (0x0000),a |
3 | 0005 32 00 20 LD (0x2000),a |
4 | 0008 3E 5A LD a,0x5A |
5 | 000A 32 00 00 LD (0x0000),a |
6 | 000D 32 00 20 LD (0x2000),a |
7 | 0010 ; a bit of delay |
8 | 0010 06 00 LD b,0x00 |
9 | 0012 10 FE L1: DJNZ l1 |
10 | 0014 C3 00 00 JP start |
Dann bist Du sicher, ob die Adresskodierung funktioniert. Naechste Stufe ist dann Schreiben und lesen beim RAM. Gruesse Th.
Jörg W. schrieb: > Dafür gibt's doch /WAIT. > > Darüber habe ich damals Pseudo-Singlestep bei der Inbetriebnahme > gemacht. ja das ist aber was ganz anderes, da braucht es dann ein Singlestep FF. von alleine bleibt da nichts stehen. Es sei denn es gibt irgendwo einen HALT Befehl. @TO Falls du Interesse hast versuche ich mal den Schaltplan der SingleStep Karte aus dem MFA System zu finden. Das war zwar 8085 sollte aber trotzdem passen.
Maik S. schrieb: > Ich benötige immer Projekte an denen ich mich festbeißen kann als > einfach nur Bücher vor meiner Nase. Learning by doing. Das ist doch an sich völlig in Ordnung, haben wir (und da schließe ich jetzt mal Axel mit ein, den ich zwar noch nie gesehen habe, aber von dem ich weiß, dass zumindest ein Teil seines Lebenswegs ähnlich wie meiner verlief) auch so gemacht. Aber: damals gab's kein Internet, auch nur wenige Mitstreiter, mit denen man sich hätte mal schnell austauschen können. Dokumentation gab's auf totem Baum – mein "electronica"-Heftchen mit den Z80-Opcodes ist wohl das zerfleddertste Buch, das ich jemals besessen habe. Man musste da einfach auch mal systematisch rangehen und die Messmittel, die man hatte (in meinem Falle eine 8fach-Siebensegmentanzeige, mit der man multiplex Daten- und Adressbus anzeigen konnte) irgendwie sinnvoll adaptieren, sich also selbst Hilfsmittel schaffen für das, was man nicht hatte (in meinem Falle ein "richtiger" LA). Das von meinem Vor-Vorredner genannte Stück Testprogramm wäre auch so ein Hilfsmittel. Systematisches Vorgehen ist aber das, was einige hier bei dir gerade vermissen.
:
Bearbeitet durch Moderator
Thomas Z. schrieb: > ja das ist aber was ganz anderes, da braucht es dann ein Singlestep FF Yep, zusammen mit einem Taster. Eins der Hilfsmittel, über die ich gerade geschrieben habe. Ohne sowas hätte ich meine Kurzschlüsse auf den Bussen damals nicht gefunden.
Maik S. schrieb: > Schau dir bitte das Bild vom Scope an und erkläre mir, warum > ich so dumm bin und jetzt meine, dass CS vom RAM und CS vom EEPROM nun > (zumindest was die Invertierung angeht) zueinander richtig stehen. Es ist eben nicht richtig, und kann so, wie gezeigt gar nicht funktionieren. Dir wurden bereits am Anfang des Thread sinnvolle Vorschläge für die Modifikation gemacht, die du ausnahmslos ignoriert hast. Daß du dich dann beschwerst, daß man dir klar aufzeigt wie falsch du liegst, rundeT das Bild nur noch ab. Das was du hier treibst ist "Stochern im Nebel"! Man verliert die Lust überhaupt zu helfen. Wie wäre es denn mal mit dem Studium der Datenblätter?
:
Bearbeitet durch User
Moin, - bei dem Screenshot kann man sehen, dass CS_EPROM immer LOW ist, d.h. das EPROM ist immer aktiv (ausser beim CS_RAM). Das kann eigentlich nicht sein, weil Du (ueber den '138) /MREQ beruecksichtigt. Da ist etwas faul. Gruesse Th.
Thomas W. schrieb: > Moin, - > mach Dir doch mal ein kleines Testprogramm: > Dann bist Du sicher, ob die Adresskodierung funktioniert. Naechste Stufe > ist dann Schreiben und lesen beim RAM. Vielen Dank! Ich werde mir das gleich mal näher anschauen und versuchen zu verstehen. Ich hatte bisher nur AVR ASM, aber den habe ich zumindest einigermaßen verstanden. Jörg W. schrieb: > Aber: damals gab's kein Internet, auch nur wenige Mitstreiter, mit denen > man sich hätte mal schnell austauschen können. Dokumentation gab's auf > totem Baum – mein "electronica"-Heftchen mit den Z80-Opcodes ist wohl > das zerfleddertste Buch, das ich jemals besessen habe. Man musste da > einfach auch mal systematisch rangehen und die Messmittel, die man hatte > (in meinem Falle eine 8fach-Siebensegmentanzeige, mit der man multiplex > Daten- und Adressbus anzeigen konnte) irgendwie sinnvoll adaptieren, > sich also selbst Hilfsmittel schaffen für das, was man nicht hatte (in > meinem Falle ein "richtiger" LA). In den nächsten Tagen sollte mein Arduino Mega ankommen, mit dem kann ich Daten und Adressbus gleichzeitig auslesen. Ich finde aber auch, man darf die Möglichkeiten des Internets schon nutzen. Die wenigen Mitstreiter, welche man damals hatte sind heute im Bezug auf einen Z80 Computer quasi nicht mehr vorhanden. Alle die ich kenne wissen noch nicht mal, was ein Z80 Computer ist. Außer eine Person, welche mir ebenfalls schon hilft. > Systematisches Vorgehen ist aber das, was einige hier bei dir gerade > vermissen. Das kann ich tatsächlich verstehen, ich erkenne selber grade kein System bei mir. Heute kommt mein EEPROM programmer, dann kann ich ein Testprogramm erstellen und ausprobieren. Thomas Z. schrieb: > @TO Falls du Interesse hast versuche ich mal den Schaltplan der > SingleStep Karte aus dem MFA System zu finden. Das war zwar 8085 sollte > aber trotzdem passen. Daran bin ich ebenfalls interessiert, so kann ich das Testprogramm später besser auswerten. Funktioniert das denn auch mit UA880? Vorredner hatten hier erwähnt, dass etwa 100KHz min. anliegen müssen. Oder wird durch solch eine Single-Step Schaltung genau dieses Problem umgangen?
Maik S. schrieb: > Heute kommt mein EEPROM programmer gut! Erste Aufgabe: Füll dein EEPROM mit NOP und schau dir die Addressleitungen an. > Funktioniert das denn auch mit UA880? ja so ein SingleStep Dingens hat nichts mit dem Clock zu tun das funktioniert auch mit 4MHz.
Maik S. schrieb: > Heute kommt mein EEPROM programmer, dann kann ich ein Testprogramm > erstellen und ausprobieren. Das ist natürlich für die Inbetriebnahme solch eines Computers essenziell. Ein EPROMmer (noch ganz und gar ohne CPU) war folglich damals auch das allererste, was ich mir bauen musste. Viehischer Drahtverhau, alles TTL-Logik, aber hat getan, was er sollte. Klar kannst und sollst du heute auch das Internet benutzen, keine Frage, aber eben auch ein bissel System reinbringen und an der einen oder anderen Stelle (wie bei /CS des EEPROMs) mal drüber nachdenken, ob das, was du gerade siehst, überhaupt sein kann.
Thomas W. schrieb: > bei dem Screenshot kann man sehen, dass CS_EPROM immer LOW ist, d.h. das > EPROM ist immer aktiv (ausser beim CS_RAM). Das kann eigentlich nicht > sein, weil Du (ueber den '138) /MREQ beruecksichtigt. > Da ist etwas faul. Da habe ich eben auch schon etwas ungläubig draufgestarrt und den selben Gedanken gehabt. Der CS des EEPROMs ist zu lange LOW. Ich gehe dieser Sache ebenfalls mal auf den Grund. Thomas Z. schrieb: > gut! Erste Aufgabe: Füll dein EEPROM mit NOP und schau dir die > Addressleitungen an. Wird gemacht. Wenn der Z80 ein NOP erhält macht er 4 Clock Zyklen nichts und sucht dann einfach in der nächsten Adresse weiter, oder?
Maik S. schrieb: > Wenn der Z80 ein NOP erhält macht er 4 Clock Zyklen nichts und sucht > dann einfach in der nächsten Adresse weiter, oder? So ist es, du hast dann einen etwas aufwändig gestalteten Zähler. ;-)
Maik S. schrieb: > Wird gemacht. Wenn der Z80 ein NOP erhält macht er 4 Clock Zyklen nichts > und sucht dann einfach in der nächsten Adresse weiter, oder? genau was im Ergebnis bedeutet, das du an den Adressleitungen Rechteck Signale sehen wirst, die sich von Adresspin zu Adresspin halbieren. Jede Abweichung davon deutet auf einen Busfehler hin.
Thomas W. schrieb: > bei dem Screenshot kann man sehen, dass CS_EPROM immer LOW ist, d.h. das > EPROM ist immer aktiv (ausser beim CS_RAM). Das kann eigentlich nicht > sein, weil Du (ueber den '138) /MREQ beruecksichtigt. Und wenn es schlecht läuft, hast du Datenkämpfen der Ausgänge von ROM und RAM. Letztere sind da empfindlich, hoffentlich hast du sie in Fassungen. Jörg W. schrieb: > Aber: damals gab's kein Internet, auch nur wenige Mitstreiter, mit denen > man sich hätte mal schnell austauschen können. Dokumentation gab's auf > totem Baum – mein "electronica"-Heftchen mit den Z80-Opcodes ist wohl > das zerfleddertste Buch, das ich jemals besessen habe. Meines hier zerfällt auch, Hübler/Evert 227/228. Und daraus zur Ergänzung ein I/O Test. Testrom: M1: IN A OUT A INC C JR M1 Dann /IORQ, /RD, /WR ansehen. Auf S.22 ist auch ein Kochrezept für eine Inbetriebnahme beschrieben. Ist die Leiterplatte fertig von dem Projekt bezogen oder selbst erstelt?
Thomas Z. schrieb: > Maik S. schrieb: >> Wird gemacht. Wenn der Z80 ein NOP erhält macht er 4 Clock Zyklen nichts >> und sucht dann einfach in der nächsten Adresse weiter, oder? > > genau was im Ergebnis bedeutet, das du an den Adressleitungen Rechteck > Signale sehen wirst, die sich von Adresspin zu Adresspin halbieren. Jede > Abweichung davon deutet auf einen Busfehler hin. Das bedeutet aber auch, dass er sein Oszi oder Logikanalysator mit dem Reset des Z80 synchronisieren muss, d.h. er muss sich beim Messen im unteren 8 kByte Adressraum bewegen. Darüber hinaus gibt es dann keine NOPs mehr, weil EEPROM ausgeblendet.
Holger T. schrieb: > Das bedeutet aber auch, dass er sein Oszi oder Logikanalysator mit dem > Reset des Z80 synchronisieren muss, d.h. er muss sich beim Messen im > unteren 8 kByte Adressraum bewegen. Man kann auch einfach einen Reset erzeugen, sowie die 8 KiB überschritten werden.
Holger T. schrieb: > Darüber hinaus gibt es dann keine > NOPs mehr, weil EEPROM ausgeblendet. nein A14 und A15 sind nicht angeschlossen das läuft einfach durch.
michael_ schrieb: > Letztere sind da empfindlich, hoffentlich hast du sie in Fassungen. Alle ICs sind in Sockeln. Außerdem: Adress und Datenleitungen habe ich grade auf Kurzschlüsse jeweils zueinander als auch zu GND und +5V geprüft. Auf einer unbestückten und auf der bestückten Platine. Keine vorhanden.
Thomas Z. schrieb: > nein A14 und A15 sind nicht angeschlossen das läuft einfach durch. ok das war käse. Ans Ende sollte ein Jump Reset.
Thomas W. schrieb: > mach Dir doch mal ein kleines Testprogramm: >
1 | > 0000 3E A5 START: LD a,0xA5 |
2 | > 0002 32 00 00 LD (0x0000),a |
3 | > 0005 32 00 20 LD (0x2000),a |
4 | > 0008 3E 5A LD a,0x5A |
5 | > 000A 32 00 00 LD (0x0000),a |
6 | > 000D 32 00 20 LD (0x2000),a |
7 | > 0010 ; a bit of delay |
8 | > 0010 06 00 LD b,0x00 |
9 | > 0012 10 FE L1: DJNZ l1 |
10 | > 0014 C3 00 00 JP start |
11 | >
|
Ich versuche das grade mal zu verstehen, aber so ganz werde ich nicht daraus schlau.
1 | LD a,0xA5 |
- Lade den Wert "0xA5" in das Register A
1 | LD (0x0000),a |
- Lade den Inhalt des Registers A in Speicherplatzadresse 0x0000. Also hier der EEPROM. Man kann zwar nicht schreiben, aber das Ziel ist es denke ich mal den CS zu aktivieren, sodass ich sehen kann, dass jetzt theoretisch auf den Datenleitungen A5 zu sehen sein sollte, NUR CS vom EEPROM erscheinen sollte und die Adressen 0x0000 ausgeben.
1 | LD (0x2000),a |
- Lade den Inhalt des Registers A in Speicherplatzadresse 0x2000, hier also RAM. Dabei soll ich hier das selbe Spiel wie beim EEPROM sehen, nur eben NUR der RAM sollte dabei aktiv sein.
1 | LD a,0x5A |
2 | LD (0x0000),a |
3 | LD (0x2000),a |
selbes Spiel nochmal nur andere Werte, damit man eine Änderung sieht?
1 | LD b,0x00 |
2 | DJNZ l1 |
3 | JP start |
Ich verstehe hier den Befehl "DJNZ" nicht. "DJNZ nn - Der Inhalt des Registers B wird um eine vermindert, relative bedingter Sprung zur Adresse nn, wenn B <> 0" (aus http://www.fundus.org/pdf.asp?ID=6378)
Georg G. schrieb: > auch nicht den beliebten Trick mit Sprung in einen Befehl hinein. Doch, manche Routinen hattdn zwei Einsprungstellen, was geringfügig andere Registernutzung erlaubte. So wurden, wimre, recht gerne mal die Inhalte von DE und HL ausgetauscht oder ähnliches. > Das > wurde im BASIC Interpreter gemacht, damit der Code kleiner als 8k wurde. Das war bei MBASIC der Fall; extrem war die Subroutinen-Sprungleiste, die im Segment C3 lag, um so mit zwei Bytes pro Sprung auszukommen; angespringen wurdexdas Konstrukt berechnet über JMP M bzw (HL). Ich habe die Sprünge nicht gezählt, aber aus naheliegenden Gründen können hierdurch höchstens 256 Bytes eingespart werden; realistisch ist ein Bruchteil davon. Wer braucht schon 256 Subroutinen, die alle nur "C9" enthalten? Da also aus diesen Subs wiederum sonstwohin gesprungen werden musste, ist die Gesamtersparnis recht fraglich. Tricky war es trotzdem, zweifellos!
Maik S. schrieb: > Ich verstehe hier den Befehl "DJNZ" nicht. "Decrement, Jump if not zero" Da das in diesem Falle eine Schleife auf sich selbst ist (die relative Sprungweite ist FEh, also -2, genau vor den Befehl selbst), ist das eine simple Verzögerungsschleife – wie der Kommentar ja auch sagt: "a bit of delay". Da B anfangs 0 ist, aber dann vor der Bewertung auf != 0 erst einmal dekrementiert wird, macht die Schleife 256 Durchläufe, die maximal mögliche Anzahl halt.
Percy N. schrieb: > Tricky war es trotzdem, > zweifellos! Das war auch dem damals teuren RAM geschuldet, als Beispiel hatte der ZX81 unzähliger solcher Tricks angewendet, nicht nur zum Platz sparen, sondern auch um Zeit zu sparen, da der Z80 neben dem Programmflow, auch noch das Bild aufbauen musste. da war jede nS Gold wert ;-) Aber das war jetzt etwas OT ;-)
Maik, - die Idee ist halt, dass Du ein bisschen kontrolliert auf den Datenbus zugreifst. Es geht immer nur darum, zu sehen, was passiert. 0xA5 und 0x5A sind bitweise komplementaer. Du muesstest auf den Databus die 0xA5/0x5A sehen koennen. Das Du nicht in ROM schreiben kannst, ist mir klar. Aber Du kannst den Dekoder pruefen. Und das weisst Du, ob Dein Adressdekoder funktioniert. > Ich verstehe hier den Befehl "DJNZ" nicht. > "DJNZ nn - Der Inhalt des Registers B wird um eine vermindert, relative > bedingter Sprung zur Adresse nn, wenn B <> 0" Das ist eine kleine Schleife, 256x nichts tun: Diese Pause kannst Du sofort auf dem Scope sehen (wenn man eine LED haette, koennte man eine LED leuchten lassen). Eine Pause in einem regelmaessigen Signal erkennen Menschen recht schnell. Gruesse Th.
Wenn deine CPU gesockelt ist kannst du den Adressdekoder ohne CPU mit einigen Stück Draht testen. Sind doch nur 5 Leitungen: Mreq/ Rfsh/ A11 A12 A13
Thomas W. schrieb: > die Idee ist halt, dass Du ein bisschen kontrolliert auf den Datenbus > zugreifst. Es geht immer nur darum, zu sehen, was passiert. Dann bin ich jetzt im Bilde was da passieren soll. Vielen Dank! Karadur schrieb: > Wenn deine CPU gesockelt ist kannst du den Adressdekoder ohne CPU mit > einigen > > Stück Draht testen. Sind doch nur 5 Leitungen: Mreq/ Rfsh/ A11 A12 A13 Und das könnte ich ja schon mal testen bis der EEPROM-Programmer hier ist.
Ich möchte doch noch einmal auf das /OE zurückkommen. Bei den Schaltungen, welche ich so im Netz gefunden habe, wird das /OE Pin-22 auf /RD gelegt. Niemals statisch mit Masse verbunden. Und auch im DB vom 2764 steht das: ### Assuming that the addresses are stable, addressaccess time (tAVQV) is equal to the delay from E tooutput (tELQV). Data is available at the outputs afterthe falling edge of G, assuming that E has been lowand the addresses have been stable for at leasttAVQV-tGLQV. ### G ist Pin-22 Und wenn ich mir die Schaltung DLP-g1.PDF ansehe, funktioniert das sowieso nicht richtig. An einem ROM sollte doch unbedingt /RD zum lesen der Daten anliegen. Nichts zu sehen. Und warum zum Teufel liegt /Rfsh am'138 an? Es ist doch kein D-RAM im System.
michael_ schrieb: > Ich möchte doch noch einmal auf das /OE zurückkommen. > > Bei den Schaltungen, welche ich so im Netz gefunden habe, wird das /OE > Pin-22 auf /RD gelegt. > Niemals statisch mit Masse verbunden. > > An einem ROM sollte doch unbedingt /RD zum lesen der Daten anliegen. > Nichts zu sehen. Habe ich nun umgesetzt. Verbindung mit Masse ist getrennt und der OE des EEPROMs hängt nun an RD des CPUs. Ergab leider noch keine Änderung irgendwelcher Zustände. > Und warum zum Teufel liegt /Rfsh am'138 an? > Es ist doch kein D-RAM im System. Ich habe es mit der originalen Platine verglichen. /RFSH lieg am Pin 6 (E3) des 138ers an.
Moin, - > An einem ROM sollte doch unbedingt /RD zum lesen der Daten anliegen. > Nichts zu sehen. Das waere auch meine erste Wahl. > Und warum zum Teufel liegt /Rfsh am'138 an? > Es ist doch kein D-RAM im System. Du sollst nicht fluchen: Das ist eine Extrawurst fuer die Z80: Wenn /MREQ ist Aktiv und /REFRESH aktive, dann kannst Du den (nicht vorhandenen) dynamischen Speicher auffrischen. Ist /REFRESH nicht aktive (und /MREQ aktiv) -> gueltige Adresse. So haette ich das nicht gemacht, aber schon OK. Gruesse Th. P.S.: Die Frage hatte ich mir auch gestellt und gestern abend noch mal das Datenblatt der Z80 angeguckt. Lang ist es her.
michael_ schrieb: > Und warum zum Teufel liegt /Rfsh am'138 an? Einfach mal das Timing eines M1-Zyklus richtig anschauen.
Maik S. schrieb: > Ich habe es mit der originalen Platine verglichen. /RFSH lieg am Pin 6 > (E3) des 138ers an. das ist auch richtig so falls Refresh Zyklen auf dem Bus auftauchen darf das ROM nicht aktiv sein. Ich bin mir gerade nicht sicher aber musste der Refresh per Software aktiviert werden? oder sind die Refresh Zyklen automatisch immer aktiv? Das gabs ja beim 8085 nicht
Thomas Z. schrieb: > oder sind die Refresh Zyklen automatisch immer aktiv? Ja, sind sie. Der Inhalt des R-Registers wird stets während der Decodierphase im M1-Zyklus auf den Bus ausgegeben, dabei wird zuerst /RFSH und dann etwas kürzer /MREQ aktiviert. Allerdings sind weder /RD noch /WR aktiv. Andererseits wäre es egal, ob in der Zeit irgendein Speicherbaustein seine Daten sinnloserweise auf den Bus gibt; es würde sich einfach keiner dafür interessieren.
Thomas W. schrieb: > Du sollst nicht fluchen: Das ist eine Extrawurst fuer die Z80: Wenn > /MREQ ist Aktiv und /REFRESH aktive, dann kannst Du den (nicht > vorhandenen) dynamischen Speicher auffrischen. Ist /REFRESH nicht aktive > (und /MREQ aktiv) -> gueltige Adresse. Aber nicht so. Wird noch mit dem Takt und M1 (?) verknüpft. Macht hier evtl. nur Ärger. Einfach weglassen.
Thomas Z. schrieb: > Axel S. schrieb: >> Tatsächlich braucht man den Decoder für das EEPROM gar nicht, weil es >> reicht, A13=L und RD=L zu detektieren. Und das EEPROM hat zwei >> L-aktive Steuereingange (CS und OE). > > richtig aber /MREQ muss schon noch ausgewertet werden sonst gibts > Probleme mit den I/Os. Jein. Im Prinzip müßte MREQ noch ausgewertet werden. ABER: die Originalschaltung (Eröffnungpost) tut das auch nicht. Deswegen gehe ich davon aus, daß das kollisionsfrei ist.
Axel S. schrieb: > Thomas Z. schrieb: >> Axel S. schrieb: >>> Tatsächlich braucht man den Decoder für das EEPROM gar nicht, weil es >>> reicht, A13=L und RD=L zu detektieren. Und das EEPROM hat zwei >>> L-aktive Steuereingange (CS und OE). >> >> richtig aber /MREQ muss schon noch ausgewertet werden sonst gibts >> Probleme mit den I/Os. > > Jein. Im Prinzip müßte MREQ noch ausgewertet werden. ABER: die > Originalschaltung (Eröffnungpost) tut das auch nicht. Deswegen gehe ich > davon aus, daß das kollisionsfrei ist. Der '138 wird mit /REFRESH und /MREQ gesteuert (und A11 - A13). Alles gut. Gruesse Th.
michael_ schrieb: > Thomas W. schrieb: >> Du sollst nicht fluchen: Das ist eine Extrawurst fuer die Z80: Wenn >> /MREQ ist Aktiv und /REFRESH aktive, dann kannst Du den (nicht >> vorhandenen) dynamischen Speicher auffrischen. Ist /REFRESH nicht aktive >> (und /MREQ aktiv) -> gueltige Adresse. > > Aber nicht so. Wird noch mit dem Takt und M1 (?) verknüpft. > Macht hier evtl. nur Ärger. Einfach weglassen. Nochmal: das ist kein Z80 Universalsystem, sondern ein Einzwecksystem. Da läuft auch nur eine (in Zahlen: 1) Software drauf. Und deswegen benutzt es jede Menge Vereinfachungen und Abkürzungen. Im Prinzip würde das EPROM Chipselect auch beim Schreiben auf eine EPROM-Adresse aktiv werden. Kann aber nicht passieren, weil die Software das einfach nicht tut. Man kann jetzt darüber streiten, ob es sinnvoll ist, das Z80-System wie im Original aufzubauen. Oder es "richtig" zu machen. Wenn die Original Software drauf läuft, macht es keinen Unterschied.
Axel S. schrieb: > m Prinzip müßte MREQ noch ausgewertet werden. ABER: die > Originalschaltung (Eröffnungpost) tut das auch nicht Oops. /MREQ=L und /RFSH=H wird ja ausgewertet. Mein Fehler.
Angehängte Dateien:
-
bussig.png
110 KB
So wie versprochen die MFA Singlestepkarte. Beim MFA ist das die sog. Bussignal Anzeige Die 266er würde man wohl mit 2 688er oder (in disem Fall mit 3 85er) machen. Das ist aber sowieso nur notwendig wenn man Breaks auf Adressen machen will. Da das für den 8085 war muss man ALE Emulieren /S1 sollte wie ein ALE funktionieren. /MemRd /MemWr /IORd und /IOWr sind vordekodierte Signale gewonnen aus /MREQ /IOREQ /RD und /WR. Im ersten Schritt wird es reichen nur das Geraffel um die FF nachzubauen. Die Schaltung ist übrigens ähnlich alt wie dein Synt... nähere Infos unter http://oldcomputers-ddns.org/public/pub/rechner/mfa_mikrocomputer_fuer_ausbildung/dokumentation/index.html Band 1 enthält die Beschreibungen und Schaltpläne.
:
Bearbeitet durch User
Jörg W. schrieb: > Holger T. schrieb: >> Das bedeutet aber auch, dass er sein Oszi oder Logikanalysator mit dem >> Reset des Z80 synchronisieren muss, d.h. er muss sich beim Messen im >> unteren 8 kByte Adressraum bewegen. > > Man kann auch einfach einen Reset erzeugen, sowie die 8 KiB > überschritten werden. Wait ist auch ziemlich nützlich, man kann den Rechner zu interessanten Zeitpunkten anhalten, einfach /Wait mit einem /CS verbinden hält den Rechner beim ersten Zugriff an, dann kann man mit dem TTL-Prüfstift (Tm) in aller Ruhe die Signale mit dem Soll vergleichen...
Jörg W. schrieb: > Holger T. schrieb: >> Das bedeutet aber auch, dass er sein Oszi oder Logikanalysator mit dem >> Reset des Z80 synchronisieren muss, d.h. er muss sich beim Messen im >> unteren 8 kByte Adressraum bewegen. > > Man kann auch einfach einen Reset erzeugen, sowie die 8 KiB > überschritten werden. Wait ist auch ziemlich nützlich, man kann den Rechner zu interessanten Zeitpunkten anhalten, einfach /Wait mit einem /CS verbinden hält den Rechner beim ersten Zugriff an, dann kann man mit dem TTL-Prüfstift (Tm) in aller Ruhe die Signale mit dem Soll vergleichen... michael_ schrieb: > Thomas W. schrieb: >> Du sollst nicht fluchen: Das ist eine Extrawurst fuer die Z80: Wenn >> /MREQ ist Aktiv und /REFRESH aktive, dann kannst Du den (nicht >> vorhandenen) dynamischen Speicher auffrischen. Ist /REFRESH nicht aktive >> (und /MREQ aktiv) -> gueltige Adresse. > > Aber nicht so. Wird noch mit dem Takt und M1 (?) verknüpft. > Macht hier evtl. nur Ärger. > Einfach weglassen. Sehe ich nicht so. E3 ist H aktiv, ein aktives /RFSH disabled den Decoder, das schadet auf keinen Fall.
Jörg W. schrieb: > Holger T. schrieb: >> Das bedeutet aber auch, dass er sein Oszi oder Logikanalysator mit dem >> Reset des Z80 synchronisieren muss, d.h. er muss sich beim Messen im >> unteren 8 kByte Adressraum bewegen. > > Man kann auch einfach einen Reset erzeugen, sowie die 8 KiB > überschritten werden. Wait ist auch ziemlich nützlich, man kann den Rechner zu interessanten Zeitpunkten anhalten, einfach /Wait mit einem /CS verbinden hält den Rechner beim ersten Zugriff an, dann kann man mit dem TTL-Prüfstift (Tm) in aller Ruhe die Signale mit dem Soll vergleichen... michael_ schrieb: > Thomas W. schrieb: >> Du sollst nicht fluchen: Das ist eine Extrawurst fuer die Z80: Wenn >> /MREQ ist Aktiv und /REFRESH aktive, dann kannst Du den (nicht >> vorhandenen) dynamischen Speicher auffrischen. Ist /REFRESH nicht aktive >> (und /MREQ aktiv) -> gueltige Adresse. > > Aber nicht so. Wird noch mit dem Takt und M1 (?) verknüpft. > Macht hier evtl. nur Ärger. > Einfach weglassen. Sehe ich nicht so. E3 ist H aktiv, ein aktives /RFSH disabled den Decoder, das schadet auf keinen Fall. Thomas Z. schrieb: > So wie versprochen die MFA Singlestepkarte. Beim MFA ist das die > sog. > Bussignal Anzeige > > Die 266er würde man wohl mit 2 688er oder (in disem Fall mit 3 85er) > machen. Das ist aber sowieso nur notwendig wenn man Breaks auf Adressen > machen will. Da das für den 8085 war muss man ALE Emulieren /S1 sollte > wie ein ALE funktionieren. /MemRd /MemWr /IORd und /IOWr sind > vordekodierte Signale gewonnen aus /MREQ /IOREQ /RD und /WR. > > Im ersten Schritt wird es reichen nur das Geraffel um die FF > nachzubauen. > > Die Schaltung ist übrigens ähnlich alt wie dein Synt... > > nähere Infos unter > http://oldcomputers-ddns.org/public/pub/rechner/mfa_mikrocomputer_fuer_ausbildung/dokumentation/index.html > > Band 1 enthält die Beschreibungen und Schaltpläne. Das ist wenig nützlich da der Intel Bus dem Z80 Bus nicht sonderlich ähnlich ist..und TIL311 :-), Nice to have ..aber die sind heute im Wesentlichen Unobtanium. Hier steht wies geht: https://z80project.wordpress.com/2014/02/16/single-step-instruction-circuit/
Also Leute, so wie ich diesen Thread sehe, ist er am Zersplittern. Deshalb hier zuerst mal 2 Fragen, um zum eigentlichen Problem zurückzukommen: 1. gibt es den Quellcode? Zumindest einen richtigen Maschinencode-Abzug von der Firmware gibt es als Notnagel. 2. Dreht sich die genze Diskussion eher um die Wiederherstellung der Gerätefunktion oder eher um das Wiederbeleben eines Z80 Systems? Wenn es eher um die Gerätefunktion geht, dann meine ich, daß es auch ein gangbarer Weg wäre, daß der TO die Schnittstellen zwischen Z80 System und Analogsystem untersucht und dann ggf. diese Schnittstellen mit einem anderen µC-System ansteuert, was er besser kennt als den Z80. Oder alternativ sich ein Z80 System ausdenkt mit neueren Bauteilen als den hier diskutierten 27xxx und 28xxx und diskreter Logik. W.S.
Beitrag #6750939 wurde von einem Moderator gelöscht.
Beitrag #6751050 wurde von einem Moderator gelöscht.
W.S. schrieb: > Wenn es eher um die Gerätefunktion geht, dann meine ich, daß es auch ein > gangbarer Weg wäre, daß der TO die Schnittstellen zwischen Z80 System > und Analogsystem untersucht und dann ggf. diese Schnittstellen mit einem > anderen µC-System ansteuert, was er besser kennt als den Z80 Im anderen Thread [1], wo es um die analogen Funktionen im Tiracon 6V ging, hieß es noch die EPROMs wären vergeßlich geworden, aber nach den neubeschreiben ginge es soweit. Irgendwo in den Tiefen der Analogkomponenten war was kaputt (Analogmux, leckender Hold-Kondensator, fehlerhafter Puffer - etwas in der Art). Und eine VCO-Karte hatte wohl einen Klaps, Elko trocken. Alles halb so wild. Aber der TE hat auch damals schon allen guten Rat in den Wind geschlagen und das Gerät nicht restauriert, sondern mehr schlecht als recht neu aufgebaut. Nachdem er den Analogteil verhunzt hat, ist jetzt wohl der Digitalteil dran. An Ende wird er den wohl (mangels Kenntnissen und seinem Umgang mit gutem Rat [s.o.]) auch neu und anders aufbauen. <schulterzuck> Schade um das schöne Gerät. Aber was solls. Ich kann die Welt nicht retten. Will ich auch gar nicht. [1] Beitrag "Tiracon 6V (DDR-Synthesizer) - Restauration, Probleme mit Überkreuzungen von Steuerspannungen"
W.S. schrieb: > 1. gibt es den Quellcode? Zumindest einen richtigen Maschinencode-Abzug > von der Firmware gibt es als Notnagel. Die EPROM gibt es doch hier: michael_ schrieb: > Übrigens, Handbuch plus EPROM vom original Tiracon hier: > > https://www.tiracon-6v.de/htm/manuals.htm Quellcode wäre sicher gut. Und wäre die Voraussetzung für Schrittbetrieb, der mehrfach genannt wurde. Die Soft ist aber getestet und stabil. Also SB nicht nötig. > 2. Dreht sich die genze Diskussion eher um die Wiederherstellung der > Gerätefunktion oder eher um das Wiederbeleben eines Z80 Systems? Es ist ein simpler Nachbau. Schuld ist weder der EEPROM noch die Software. Nur ein oder tausende Fehler im Aufbau.
Axel S. schrieb: > An Ende wird er den wohl (mangels Kenntnissen und > seinem Umgang mit gutem Rat [s.o.]) auch neu und anders aufbauen. Es ist aber ein Konzept, was er benutzt. Und auch vielleicht (?) die Leiterplatten von dort bezogen. So erst mal nicht schlecht. Aber wehe, es tritt ein Fehler auf. Und das ist hier geschehen. Für mich sicher kein Problem. Habe mal meinen aufgemotzten LC-80 wiederbelebt. Werde da mal mein Assembler wieder auffrischen. Schöne Beispiele in den Begleitheften.
Falls das noch niemand vorher getan hat: Ich hab die Files TIR-A.BIN ... TIR-D.BIN vom TO mit den gezippten Files TIR-A.COM ... TIR-D.COM von der geposteten URL mit den Original- unterlagen verglichen. Sie sind identisch. Damit sind alle Inhalte und die Reihenfolge A,B,C,D der ROMS erfolgreich verifiziert.
Kieser Meder Mikroprozessortechnik? siehe https://www.zvab.com/servlet/BookDetailsPL?bi=30915372103&searchurl=hl%3Don%26sortby%3D20%26tn%3DMikroprozessortechnik%26an%3Dkieser%2Bmeder&cm_sp=snippet-_-srp1-_-title1 michael_ schrieb: > Nur ein oder tausende Fehler im Aufbau. Schrieb ich oben schon: Lastfaktor und Signale prüfen. Der Bus muß saubere Signale haben und diese müssen auch zeitlich richtig anliegen. RAMs und EPROMs haben bestimmte Antwortzeiten. Evtl. sind Waits nötig?
Angehängte Dateien:
-
Polyphonic.jpg
23 KB
oszi40 schrieb: > Schrieb ich oben schon: Lastfaktor und Signale prüfen. Ganz so verbissen muß man es nicht sehen. Aber wenn es von der Nachbautruppe wie oben ist, dann sollte es bei richtigen Aufbau schon funktionieren. Schade, dass man da kein Datum erkennen kann. Den RAM hätte ich durch einen 6116 ersetzt, den es schon sehr lange gibt. Der teure und seltene 28c64 macht auch keinen Sinn. Ein schnöder 2764 oder irgendein Flash aus einem alten Mainboard hätte es auch getan. Hauptsache er passt in die Fassung. Aber egal. Es erinnert mich an den Beitrag mit dem Schachcomputer, wo es (angeblich) dann die PIO waren.
michael_ schrieb: > Schade, dass man da kein Datum erkennen kann. Auf dem anderen Blatt ist 2021 vermerkt. Schade, dass sie nicht neue Bauelemente eingepflegt haben.
michael_ schrieb: > Die EPROM gibt es doch hier: Zwischen einem (oder 4) Eprom-Inhalt und einem möglichst sinnvoll kommentierten Quellcode gibt es einen gewissen Unterschied... W.S.
michael_ schrieb: > Quellcode wäre sicher gut. Kommt drauf an, was man machen will. Ich halte ihn für unnötig. > Und wäre die Voraussetzung für Schrittbetrieb, der mehrfach > genannt wurde. Seit wann ist denn der Quellcode die Voraussetzung für Schrittbetrieb? Der Inhalt der EPROMs liegt vor. Disassembler existieren. Und 8KB sind überschaubar. Das Kernal des C64 ist auch 8KB und von dritter Stelle bestens dokumentiert. > Die Soft ist aber getestet und stabil. Also SB nicht nötig. Hardware-Schrittbetrieb hilft nicht (nur) bei Softwarefehlern, sondern auch (hauptsächlich?) bei Hardwarefehlern. Aber in der Tat: ich frage mich, was der TE eingentlich bezweckt. Will er den Nachweis erbringen, daß ein in den 80ern gebautes Gerät heute immer noch gebaut werden kann und funktioniert? Vielleicht will er ja einfach nur spielen (im Sinne von basteln). OK, nichts dagegen einzuwenden. Aber warum belästigt er dann das Forum damit? Es wäre etwas anderes wenn er das Gerät restaurieren wöllte. Aber im Moment habe ich den Eindruck, daß er einfach nur wissen will, wie es funktioniert. Außer daß er immer dann, wenn jemand was erklärt, ganz dringend irgendwo hin muß.
Axel S. schrieb: > Aber in der Tat: ich frage mich, was der TE eingentlich bezweckt. Will > er den Nachweis erbringen, daß ein in den 80ern gebautes Gerät heute > immer noch gebaut werden kann und funktioniert? > > Vielleicht will er ja einfach nur spielen (im Sinne von basteln). OK, > nichts dagegen einzuwenden. Aber warum belästigt er dann das Forum > damit? Es wäre etwas anderes wenn er das Gerät restaurieren wöllte. Aber > im Moment habe ich den Eindruck, daß er einfach nur wissen will, wie es > funktioniert. Außer daß er immer dann, wenn jemand was erklärt, ganz > dringend irgendwo hin muß. So sind sie die jungen Leute. Früher mußte man alles noch selber lernen, sich aus Büchern erarbeiten und sich durchprobieren. Heute hat man ein Problem und belästigt damit direkt die Leute in Foren. Was auch immer sein Ziel war, er hat es nicht so einfach erreicht wie er vermutet hatte und möchte es nun von anderen gemacht bekommen. Er erwartet schlichtweg eine Ferndiagnose, daß ihm jemand den Rechner fertigstellt. Warum er das ganze macht kann ich mir auch nicht erklären. Er hat zwar erwähnt, daß der Computer in seinem Gerät hin und wieder abstürzt, aber dieser Ursache könnte man sicherlich auch auf den Grund gehen, anstatt wie beim Analogteil es einfach neu zu bauen und das Gerät somit völlig zu verbasteln. Wirklich Schade um das alte Stück. So etwas will ich hier nicht unterstützen.
Seit mal nicht so streng :-) Der TO hat offensichtlich gewaltige Defizite was das Verständnis angeht, immer noch keinen EEpromer und ignoriert sinnvolle Vorschläge. Der Nachbau des Digitalteils enthält irgendwo einen Fehler, und der ist nicht bei der Zusammenfassung der Eproms zu suchen. Es ist ja davon auszugehen, dass die Original Schaltung funktioniert, die wurde ja verkauft. Es wäre jedoch durchaus möglich, dass im Original Schaltplan irgendwo Zeichnungsfehler sind. Da kommen insbesondere die IO Adressen in Frage. Das ist aber schnell (im Original) durchgeklingelt. Es gibt ja Hinweise in seinem Schaltplan dass nicht alles 100% gestimmt hat. Wie auch immer vieleicht ist das ganze Projekt einfach zu ergeizig für den TO.
Beitrag #6751620 wurde von einem Moderator gelöscht.
Beitrag #6751637 wurde von einem Moderator gelöscht.
Thomas Z. schrieb: > Es wäre jedoch durchaus möglich, dass im Original Schaltplan irgendwo > Zeichnungsfehler sind. Ich habe den Maik schon zweimal gefragt, ob er die Platine da gekauft oder nach dem Schaltplan selbst erstellt hat. Würde alles weiter eingrenzen.
Udo_P schrieb: > So sind sie die jungen Leute. Früher mußte man alles noch selber lernen, > sich aus Büchern erarbeiten und sich durchprobieren. Heute hat man ein > Problem und belästigt damit direkt die Leute in Foren. Die alte Leier: Früher war alles besser....
michael_ schrieb: > Thomas Z. schrieb: >> Es wäre jedoch durchaus möglich, dass im Original Schaltplan irgendwo >> Zeichnungsfehler sind. > > Ich habe den Maik schon zweimal gefragt, ob er die Platine da gekauft > oder nach dem Schaltplan selbst erstellt hat. > Würde alles weiter eingrenzen. Und ich frage mich die ganze Zeit wo "da" ist. Habe mich dadurch nie angesprochen gefühlt und dachte immer, es ging um OT Dinge. Aber die Platine ist selbst gezeichnet, aber bei einer Firma extern gefertigt. Ich probiere aktuell alles hier genannte aus. Es sind Fehler im Adressbus, soviel kann ich schonmal sagen. Ich suche grade die Ursache.
Da kann ein ganzer Batzen Fehler hinzukommen. Womit wir nicht so gerechnet haben. Maik S. schrieb: > In der Schaltung befinden sich noch viele weitere Bausteine. PIOs / > SIOs/ CTC. Diese sind aktuell nicht verbaut, sondern lediglich CPU, > EEPROM und RAM. Das ist schon mal einigermaßen richtig. > Erkennt jemand, warum der Z80 sich sein Programm nicht vom EEPROM lädt? Solch große Glaskugeln sind noch in Entwicklung. Du mußt dich da noch tiefer einarbeiten. Oder besser einen alten Sack mit U880/Z80 Erfahrung vor Ort suchen, der dir hilft.
Beitrag #6751718 wurde von einem Moderator gelöscht.
Maik S. schrieb: > Aber die Platine ist selbst gezeichnet, aber bei einer Firma extern > gefertigt Da du das ja offenbar mit KiCad gemacht hast, wie wäre es, wenn du die KiCad-Dateien hier postest? Dann könnten andere mal drüber schauen, ob es in Schaltung oder Layout irgendwelche "Gurken" gibt. Nur so als Idee.
Ich habe jetzt mal das Service-Handbuch grob durchgeblättert. Das ist ein ganz schön gewaltiges Ding. Eigentlich nichts für Anfänger. Bei Reperatur gleich am Anfang steht etwas zur Prüfung eines CTC-Interruptes. Vielleicht ist das der Grund. Bestücke die mal.
Maik S. schrieb: > Es sind Fehler im > Adressbus, soviel kann ich schonmal sagen dann sollte aber das NOP EEPROM erste Anhaltspunkte liefern. Falls du das nicht hast einfach D0..D7 auf GND und EEprom + Rams raus. Im Ergebnis sollte das NOP also endlos laufen
Angehängte Dateien:
-
A3.jpg
240 KB -
A7.jpg
220 KB -
weiteres.jpg
230 KB
Nachdem der Computer mit dem NOP EEPROM ebenfalls nichts anfangen konnte, habe ich nun auch EEPROM und RAM entfernt. Aktuell ist nur die CPU verbaut, sodass man hier das hochzählen der Adressen nun sehen sollte. Das ist auch vorhanden, nur werden manche Adressen von einem 1MHz Takt begleitet. Dieses 1MHz "flattern" ist bei allen Adressen ganz leicht sichtbar. Aber bei A7 (und weiteren höheren Adressen) sind diese 1MHz auf vollem Pegel mit dabei. Ich bin daraufhin die Traces auf dem PCB nachgegangen, ob es irgendwo Kreuzungen gibt mit einem Trace, der ein 1MHz Takt führt. Die betroffenen Adressen schneiden sich auf dem Weg durch RAM und EEPROM evtl. mal mit den Daten, welche aktuell immer auf 0 sind. Weitere Kreuzungen gibt es nicht. A7 wird hier noch mit dem CTC verbunden, welcher aktuell nicht verbaut ist. Dabei ist er einmal sehr nah am Clock Trace, aber die Flanken passen nicht zueinander, sodass man Crosstalk hier eigentlich ausschließen kann. Ansonsten ist an ICs nur noch N101 (A302D vom Reset_SW) mit der CPU verbunden. Sind das vielleicht einfach Hinweise auf defekte UA880D?
Das dürfte an den nach jedem Befehlslese- (M1) folgenden Refreshzyklen liegen. Beim Refresh werden die untersten 7 Adressbits hochgezählt (u.U. sogar synchron zu deinen NOPs), auf den oberen 8 Adressbits immer das Gleiche (wenn ich mich recht erinnere: das I-Register).
Maik S. schrieb: > Sind das vielleicht einfach Hinweise auf defekte UA880D? Uff! Woher sollen wir das wissen? Natürlich müssen deine Bausteine ladenneu oder getestet sein!
Ingo W. schrieb: > Beim Refresh werden die untersten 7 Adressbits hochgezählt (u.U. Ich sage doch, macht nur Ärger. Hier aber sicher unbedeutend.
nun ja wenn weder Ram noch EEprom bestückt ist wird die CPU vermutlich 0xFF lesen ds entspricht RST38 also ein JMP zu 0x0038 und das in einer Endlosschleife. Mit deinen Bildern kann ich nichts anfangen, zumindest die Kanäe solltest du beschriften.
Thomas Z. schrieb: > nun ja wenn weder Ram noch EEprom bestückt ist wird die CPU vermutlich > 0xFF lesen ds entspricht RST38 also ein JMP zu 0x0038 und das in einer > Endlosschleife. > Mit deinen Bildern kann ich nichts anfangen, zumindest die Kanäe > solltest du beschriften. liest sie dann nicht 0x00? Zumindest sind die Datenleitungen (gemessen) alle immer low. D0-D13 = A0-A13 D15 = CS EEPROM Bei den Analogen Messungen heißt das Bild wie der gemessene Wert.
Maik S. schrieb: > Sind das vielleicht einfach Hinweise auf defekte UA880D? Naja. Mit einem NOP Stecker macht die CPU erst mal nur M1 Zyklen. Per Default (kein /WAIT oder sonstige Sonderlocken) sind die 4 Takte lang. Aber: ein M1 Zyklus enthält ebenfalls einen Refresh Zyklus. Und in dem wird das R-Register auf A0..A6 ausgegeben. Diese Bits "zappeln" also unabhängig. Wenn dein LA ein Triggersignal kann, dann triggere auf einen Zeitpunkt wo die Speicheradresse stabil ist. Bspw. fallende Flanke an /RD. Ansonsten siehe Timing-Diagramme.
Angehängte Dateien:
-
camphoto_1254324197.JPG
240 KB
Maik S. schrieb: > liest sie dann nicht 0x00? Zumindest sind die Datenleitungen (gemessen) > alle immer low. Er hat alleine alle Adressen bis A13 hochgezählt, nur waren diese geschreddert von diesen 1MHz. Daher sind die Kurven hier ausgefüllt.
Axel S. schrieb: > Aber: ein M1 Zyklus enthält ebenfalls einen Refresh Zyklus. Und in dem > wird das R-Register auf A0..A6 ausgegeben. Diese Bits "zappeln" also > unabhängig. Wenn dein LA ein Triggersignal kann, dann triggere auf einen > Zeitpunkt wo die Speicheradresse stabil ist. Bspw. fallende Flanke an > /RD. Das erklärt also das 1MHz "zappeln" ab A7.
Das ist nur wirres Zeug, ueberhaupt nicht zielgerichtete Vorgehensweise. Man weiss nicht was er da misst und zeigt. Auf was er ertriggert: Keine Ahnung. Tschuess Th.
Maik S. schrieb: > Er hat alleine alle Adressen bis A13 hochgezählt, nur waren diese > geschreddert von diesen 1MHz. Daher sind die Kurven hier ausgefüllt. ok das passt. Ich hätte jetzt eher vermutet dass offene D0..D7 als 1 gelesen werden... Nur warum geht dann dein NOP EEPROM nicht? Im nächsten Schritt kannst du ja mal D0..D7 auf 1 legen dann sollte das erwähnte RST38 gelesen werden. Die CPU scheint ok zu sein.
Und nun wartest du auf deinen Programmer. Schreibst damit paar 00H (NOP) rein und dann eine 76H (Halt). Dieses Mini-Programm lässt dann den Halt-Pin der CPU wechseln. Damit funktioniert erst mal CPU und ROM.
Angehängte Dateien:
-
IMG_8136.jpg
230 KB
michael_ schrieb: > Und nun wartest du auf deinen Programmer. > > Schreibst damit paar 00H (NOP) rein und dann eine 76H (Halt). > > Dieses Mini-Programm lässt dann den Halt-Pin der CPU wechseln. > Damit funktioniert erst mal CPU und ROM. Der ist schon lange da, der NOP EEPROM wurde doch auch schon getestet. Da man also nun sagen konnte, dass der CPU in Ordnung zu sein schien, habe ich den NOP EEPROM eingesteckt. Das hätte ja dann zum genau selben Ergebnis führen müssen. Leider flippte erneut alles durch die Gegend. Nachdem ich den EEPROM also wieder entfernt hatte folgendes Ergebnis: (siehe Bild) D4 (A4) getriggert auf D5 (A5) (weil stabil) bekommt ebenfalls manchmal den 1MHz Takt ab, allerdings nur sporadisch. Dieses flippen auf A4 hatte ich gestern Abend bereits gesehen. Heute morgen war es verschwunden, nun ist es wieder da. Ich hab den LA entfernt und A4 analog gemessen, das flippen war noch da. Ich werde mir mal einen neuen Z80 besorgen und es damit testen.
:
Bearbeitet durch User
Es ist doch komplett egal, was auf dem Bus abgeht, wenn Du kein Timing beruecksichtigt: Die CPU lauft wohl, also: CS ROM und EPROM testen. Mein kleines Test-Prograemmchen programmieren und dann weisst Du, ob Dein Adressdekoder funktioniert. Trigger auf /MREQ, nur CLK, /MREQ, CS_ROM, CS_RAM. Du musst die vier Speicherzugriffe sehen und die Pause. Wenn ja, kleines Test-Programm fuer die IO-bauen und fertig. Th.
Thomas W. schrieb: > Es ist doch komplett egal, was auf dem Bus abgeht, wenn Du kein > Timing > beruecksichtigt: Die CPU lauft wohl, also: CS ROM und EPROM testen. Mein > kleines Test-Prograemmchen programmieren und dann weisst Du, ob Dein > Adressdekoder funktioniert. Trigger auf /MREQ, nur CLK, /MREQ, CS_ROM, > CS_RAM. Du musst die vier Speicherzugriffe sehen und die Pause. > > Wenn ja, kleines Test-Programm fuer die IO-bauen und fertig. > > Th. Dein kleines Programm funktioniert! Habe den CPU getauscht. Beim NOP EEPROM zählte er dumm hoch und bei deinem Testprogramm konnte ich A5 / 5A auf den Datenleitungen sehen und die Pause ebenfalls erkennen. Habe leider kein Foto gemacht und jetzt wieder alles abgeklemmt, da ich nun den RAM testen möchte.
Ich brauche kein Photo. Du weisst jetzt: - Der Datenpfad ROM->CPU funktioniert. RAM-Test auch ganz einfach: Du hast ja keine Ausgabe, daher mache einfach so: Fuelle einen Block mit Daten 00 - ff:
1 | ; Fuelle ein Block 0x2000 - 0x20ff mit 00 - ff |
2 | ;
|
3 | 0000 21 00 20 START: LD hl,0x2000 |
4 | 0003 06 00 LD B,0x00 |
5 | 0005 78 X: LD a,b |
6 | 0006 77 LD (hl),a |
7 | 0007 23 INC hl |
8 | 0008 10 FB DJNZ x |
9 | ;
|
10 | ; Ausgabe: Output Port 0xDE (IC D130, PIO, NICHT bestuecken) |
11 | ; Trigger auf: /IORQ und /A5 (A5 ist benutzt als /CE) |
12 | ;
|
13 | 000A 21 00 20 LD hl,0x2000 |
14 | 000D 06 00 LD b,0x00 |
15 | 000F 7E XX: LD a,(hl) |
16 | 0010 D3 DE OUT (0xDE),a |
17 | 0012 23 INC hl |
18 | 0013 10 FA DJNZ xx |
19 | ; loop forever |
20 | 0015 18 FE ZZ: JR zz |
Dein LA sollte dann (wenn Du auf /IORQ und /A5 triggerst) den Inhalt des Speicherbereiches 0x2000 - 0x20ff anzeigen. Gruesse Th. P.S.: der Online-Assembler https://www.asm80.com finde ich schon genial.
Erstaunlich wie der Sozialismus noch wirkt. Natürlich kann die CPU nicht defekt sein, ist ja Spitzenware. Und man hat ja auch nur die Eine. 😂😂😂🤣🤣🤣
Angehängte Dateien:
-
28C64readcycle.JPG
44 KB
Hi Maik, wenn ich Dein Wiring diagram nicht falsch gelesen habe, ist OE auf GND gelegt, was mich sehr wundert. Der 28C64 stellt erst mit den falling edges von CE und OE Daten auf dem Datenbus bereit, ansonsten ist der Datenbus hochohmig. OE müsste deshalb eigentlich mit RD des Z80 verbunden sein. Kennen wir uns nicht zufällig von einer After Hour? ;-) Grüße Ralf
Angehängte Dateien:
-
27C64readcycle.JPG
47 KB
Kleine Ergänzung: Dasselbe gilt auch für den 27C64 ... Grüße Ralf ralf.nelle@gmail.com
Ralf Nelle schrieb: > Der 28C64 stellt erst mit den falling edges von CE und OE Daten auf dem > Datenbus bereit, ansonsten ist der Datenbus hochohmig. OE müsste deshalb > eigentlich mit RD des Z80 verbunden sein. Unsinn. EPROMS sind vollständig kombinatorisch und brauchen keinerlei Takt. Egal ob CMOS oder NMOS. Du kannst /CE und /OE fest auf Masse legen und den Baustein als Wertetabelle benutzen. Ich habe etliche Designs, die das so machen, mit CMOS und mit NMOS. In Deinem Diagramm ist eine Mindestzeit zwischen der fallenden Flanke von /CE und den gültigen Daten spezifiziert. Aber keine Maximalzeit, und insbesondere keine Maximalzeit zwischen Adresse gültig und /CE low. D.h. /CE darf auch letzte Woche low geworden sein, das reicht aus. Es gibt spezielle Bausteine, die mit der fallenden Flanke die Adresse latchen (damit man sich beim 8051 den '373 sparen kann), aber die heissen nicht 27xxx/27Cxxx.
Soul E. schrieb: > Du kannst /CE und /OE fest auf Masse legen und den Baustein als > Wertetabelle benutzen. Beide Signale fest auf Masse? Wozu soll das gut sein? Dann belegt das EPROM ja permanent den Datenbus. Folge: - Kein I/O möglich - Kein RAM-Zugriff möglich - Datenkollisiion beim Schreiben von Daten Oder gehts hier nur um ein Test-Szenario?
:
Bearbeitet durch Moderator
Frank M. schrieb: > Oder gehts hier nur um ein Test-Szenario? Um Wertetabellen. Um Anwendungen, wo die Ausgänge unmittelbar den Eingängen folgen sollen. Wenn man mehrere Bausteine in einen Adressbereich einblenden will, dann nutzt man selbstverständlich /CE und /OE -- genau dafür sind sie da. Dem EPROM selber ist es aber völlig egal ob das Flanken ankommen oder ob es den kompletten Adressbereich belegt. Eine bekannte Kombination aus Z80 (U880) und einem den kompletten Adressbereich belegenden EPROM (/CE auf Masse) ist die "Melodieklingel" aus dem "Funkamateur". Die hatte kein RAM, daher durfte das ROM das.
Es steht klar im Datasheet des 28C64 (findet sich genauso beim 27C64): Read Mode The 28C64A has two control functions, both of which must be logically satisfied in order to obtain data at the outputs. Chip enable (CE) is the power control and should be used for device selection. Output Enable (OE) is the output control and is used to gate data to the output pins independent of device selection. Assuming that addresses are stable, address access time (tACC) is equal to the delay from CE to output (tCE). Data is available at the output tOE after the falling edge of OE, assuming that CE has been low and addresses have been stable for at least tACC-tOE. Noch mal der letzte Satz für diejenigen, die ihn überlesen haben: DATA IS AVAILABLE AT THE OUTPUT AFTER THE FALLING EDGE OF OE.
Auch wenn du das noch ein paar Mal wiederholst wird es deshalb nicht richtiger. Die Eingänge /CE und /OE sind nicht flankensensitive.
Angehängte Dateien:
-
ReadCycle.PNG
36 KB -
Apple_IIe_Schematic_-_1.jpg
250 KB
Ralf Nelle schrieb: > Noch mal der letzte Satz für diejenigen, die ihn überlesen haben: > DATA IS AVAILABLE AT THE OUTPUT AFTER THE FALLING EDGE OF OE. Willst Du Dich hier krampfhaft lächerlich machen? Sowohl für tACC als auch für tCE sind nur Minimalwerte spezifiziert. Es gibt keine Obergrenze. Du kannst einmal beim Einschalten /CE auf Low legen und dann immer wieder die Adresse verändern, oder die Adresse anlegen und danach /CE pulsen. Der Baustein ist rein kombinatorisch, sobald alle Eingangsbedingungen erfüllt sind erscheint das Signal am Ausgang.
Mein Senf: - 27C64 ist vollstatisch, 28C64 auch..basta. - Der Z80 hat mit seinem Wait Eingang eine wunderbare onboard debugging Möglichkeit. Als erstes mal auf Masse legen und das Mopped einschalten, auf dem Datenbus müssen die 0x31 vom Laden des Stackpointers zu sehen sein. Man kann also bei anliegendem Takt mit einem Logiktester in Ruhe jedes einzelne Pin checken. Da die Adresse 0 auf die Dauer langweilig ist, kann man /Wait auch mit allerlei anderen Lustigen Sachen verbinden, z.B. mit dem /CS von RAMS oder ROMS oder auch Peripherie, dann hält das Ding halt beim ersten Zugriff auf den Baustein an. Ich bin mir jetzt nicht sicher ob ich Alles mitbekommen habe, deswegen Entschuldigung wenn mir was durch die Lappen gegangen ist: Dein 13MB Video von den finster funzelnden LEDs zeigt mir Datenkämpfe auf dem BUS an, da arbeiten verschiedene Ausgänge gegeneinander, z.B. RAM und ROM beim lesen, oder 2 unterschiedliche ROMs. Da wirdwas gleichzeitig selektiert. Versuche erst mal die Fehler zu finden in dem Du den Rechner beim Zugriff wie angegeben einfach anhältst. Der U224 ist kein "antiker TTL RAM" sondern CMOS wie der 6216 auch, nur halt nur ein halbes K (und der braucht Flanken an /CS weil er ein Adreßlatch hat, im Unterschied zum vollstatischen U214 (MN21114)der aber Pinkompatibel ist, hier sollten Beide funktionieren.). Es ist übrigens weder bei MN2114 (und anderen kompatiblen West-Chips), noch U214 noch U224 selbstverständlich das auch "neue" Chips nach der Zeit noch funktionieren, das sind Erfahrungswerte. Pille
Thomas Z. schrieb: > Auch wenn du das noch ein paar Mal wiederholst wird es deshalb nicht > richtiger. Die Eingänge /CE und /OE sind nicht flankensensitive. Die Eingänge sicher nicht. Aber die Ausgänge. Übrigens hat Statisch nichts mit der Steuerung der Ausgänge zu tun.
michael_ schrieb: > Thomas Z. schrieb: >> Auch wenn du das noch ein paar Mal wiederholst wird es deshalb nicht >> richtiger. Die Eingänge /CE und /OE sind nicht flankensensitive. > > Die Eingänge sicher nicht. > Aber die Ausgänge. > Übrigens hat Statisch nichts mit der Steuerung der Ausgänge zu tun. Ok, Du magst meine Bezeichnung nicht. Akzeptiert. Den Rest Deiner Aussage kann man aber getrost in die Tonne drücken. Mit statischem /OE und /CE folgen die Daten ohne weitere Aktionen den angelegten Adressen sonst würden jede Menge CRT Ansteuerungen in denen Eproms als Charaktergenerator sitzen nicht funktionieren. Es gibt Dinger wie 27C65 die ein Adreßlatch enthalten für Controller der MCS51 Serie. Damit kann man den üblichen 74LS373/573 einsparen, aber das stand oben schon geschrieben. Für diese Dinger gilt das nicht, für die normalen Proms aber schon. Gruß, Pille
Soul E. schrieb: > Willst Du Dich hier krampfhaft lächerlich machen? Es ist wirklich schlechter Stil, wenn sachliche Argumente durch persönliche Angriffe ersetzt werden. Wenn Du den von Dir selbst angehängten Schaltplan vom Apple IIe einfach mal genauer ansiehst, dann entdeckst Du vielleicht auch, dass er das zeigt, was ich sage: Dort liegt /CE liegt auf Masse, während /OE von der MMU getriggert wird. Da der Output hochohmig wird, wenn entweder /CE oder /OE high ist, deckt sich die Schaltung zu 100% mit den Angaben aus dem Datenblatt. Dein Read Cycle Diagramm finde ich in keinem 28C64-Datasheet. Für tACC und tCE gibt es keine "Obergrenzen". Das ist die Spezifikation der Zeiten, die das (E)EPROM für die Signalverarbeitung benötigt. Diese sind maximal 150, 200 oder 250ns, je nachdem, ob ein AT28C64B-15, AT28C64B-20 oder AT28C64B-25 verwendet wird. Aus den Signalverarbeitungszeiten ergibt sich die maximale Zugriffsgeschwindigkeit des (E)EPROMs.
Angehängte Dateien:
-
Single_Step.jpg
160 KB
Wie Jörg W. schon schrieb [1], eine einfache Schaltung reicht oft aus, um die CPU und die Peripherie Schritt für Schritt zu testen. Anbei mal meine „moderne“ Variante am Z180. [1] Beitrag "Re: Z80/UA880D mit 28C64 startet nicht"
Ralf Nelle schrieb: > Der 28C64 stellt erst mit den falling edges von CE und OE Daten auf dem > Datenbus bereit, ansonsten ist der Datenbus hochohmig. Nochmal es gibt genügend Beispiele auch hier im Forum wo Eproms als simple Decoder missbraucht werden. Bei diesen Schaltungen liegt dann /CE und /OE auf GND und die Bitmuster werden werden nur von den Addressen beeinflusst. Die bekanntesten Beispiele dürften prog. Lauflichter oder die Char Roms auf alten Grakas sein. Solche Schaltungen würden ja dann garnicht funktionieren. Da gabs vor einiger Zeit mal ein Thread hier wo jemand einen Fehler in so einer Schaltung suchte. Finde den leider nicht mehr.
Ralf Nelle schrieb: > Der 28C64 stellt erst mit den falling edges von CE und OE Daten auf dem > Datenbus bereit, ansonsten ist der Datenbus hochohmig. Falsch: 28C64 und 27C64 liefert Daten am Datenbus, sobald CE# und OE# low und WE# high sind. Pegelgesteuert und nicht flankengesteuert. Aber vielleicht ist dein "mit den falling edges" auch missverständlich ausgedrückt...
:
Bearbeitet durch User
Thomas Z. schrieb: > Nochmal es gibt genügend Beispiele auch hier im Forum wo Eproms als > simple Decoder missbraucht werden. Das wird hier leider mantraartig wiederholt, ohne dass jemand ein konkretes Beispiel liefert. Und es ist noch nicht einmal grundsätzlich falsch: Mit einen 27C16 funktioniert es, weil die Ausgänge direkt am Output Buffer hängen. Wenn man sich jedoch einmal die Mühe macht und in die Datenblätter guckt, stellt man beim Vergleich der Blockdiagramme fest, dass es anders als beim 27C16 beim 27C64 und 28C64 zusätzlich ein Data Latch gibt, dass zwischen den Ausgängen und dem Output Buffer liegt. Dieses Data Latch wird mit der fallenden Flanke von /OE getriggert. Maik hat die ursprünglich verwendeten vier 27C16 durch ein 28C64 ersetzt, deshalb funktioniert die Schaltung jetzt auch nicht mehr. Eine einfache Lösung wäre, /CE auf Masse zu legen und /OE an den Adressdekoder oder - die sauberste Lösung, /OE mit /RD der CPU zu verbinden.
Angehängte Dateien:
Ja und da gibt es auch noch Unterschiede je nach Typ und Hersteller. Ralf Nelle schrieb: > Maik hat die ursprünglich verwendeten vier 27C16 durch ein 28C64 > ersetzt, deshalb funktioniert die Schaltung jetzt auch nicht mehr. Eine > einfache Lösung wäre, /CE auf Masse zu legen und /OE an den > Adressdekoder oder - die sauberste Lösung, /OE mit /RD der CPU zu > verbinden. Halte ich auch für Sinnvoll, den. Microchip hat wohl welche mit transparentem Latch, da funktioniert ein Decoder, wobei der Adresslatch bei Intel nicht transparent ist, somit würde ein Decoder mit dem EPROM, nicht funktionieren. Habe jetzt leider nicht die Möglichkeit/Zeit dies in den Datenblätter genau nachzulesen, aber ich mag mich an genau so ein Problem erinnern als ich damals Apple][ Clones gebaut hatte, das Problem mit dem Adresslatch im 27C64 machte Probleme, weil der CE/PE fest auf masse war. die einten EPROMS gingen, die anderen eben nicht.
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.