Z80/UA880D mit 28C64 startet nicht

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.

* /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.

- 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.

>/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.

Thomas Z. schrieb:
> Mit 10Hz Clock wird's vermutlich nichts werden das dürfte keine
> statische CPU sein.

Meiner Erinnerung nach schon.

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

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.

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.

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.

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.

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.

michael_ schrieb:
> Aus Erfahrung von damals.
> Obige Flanke wird benötigt.

Entnehme ich dem Datenblatt nicht, aber Erfahrungen damit habe ich 
nicht.

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).

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.

Die 27xxx-Typen sind definitiv statisch.
Früher hab ich die gern in verb. mit einem rückgekoppelten 8bit-Latch 
als Statemachine verwendet.

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?

Evtl. auch die Flussspannung von D1 nicht beachtet (blaue LED?^^), 
dadurch Eingangspegel am 4023 im verbotenen Bereich.

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"

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.

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.

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.

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.

(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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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!

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.

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.

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.

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?

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 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 ;-)

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.

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.

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 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.

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.

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.

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"

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ß.

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.

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.

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.

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

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).

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.

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.

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.