6502 System funktioniert nicht richtig

[Joachim B. (jar)]

Tom K. schrieb:
> Statt Kältespray Heissluft einzusetzen ist natürlich auch ne gute Idee,
> so gehts auch, nur das Warten, bis alles wieder abgekühlt ist, ist
> nervig.

das mußt du übersetzen, welches "warten" mit Kältespray und Föhn?

[(prx) A. K. (prx)]

Tom K. schrieb:
> ber PHI2 also Clk statt CE zu triggern

Im Prinzip ja. Nur gibts dann wahrscheinlich keine eindeutige Sequenz. 
Könnte man dann aber mit Dauersample als eye diagram nutzen.

[Tom K. (katdroid)]

Joachim B. schrieb:
> Tom K. schrieb:
>> Statt Kältespray Heissluft einzusetzen ist natürlich auch ne gute Idee,
>> so gehts auch, nur das Warten, bis alles wieder abgekühlt ist, ist
>> nervig.
>
> das mußt du übersetzen, welches "warten" mit Kältespray und Föhn?

Vergiss es!

Ich meinte, dass du ja von heiß(kein Fehler) auf kalt(Fehlerfall) bei 
den warmen Temperaturen im Moment warten musst, bis alles abgekühlt ist.

Aber erstens: Es ist ja heute nicht mehr so affenwarm

und Zweitens: man kann den Föhn ja auf kalt stellen, das sollte schon 
gehen.

(wenn ich so drüber nachdenke ;-)

Ach ja, vielleicht schreibts du mal an das Schachcomputer online Museum, 
die refurbishen ihre Computer ja auch, was ich so gelesen habe.
Die haben vielleicht Tipps auf Lager, wo man die Teile, die heute keiner 
mehr baut, noch bekommt oder wie man sich behilft.

LG Thomas

[Tom K. (katdroid)]

(prx) A. K. schrieb:
> Tom K. schrieb:
>> ber PHI2 also Clk statt CE zu triggern
>
> Im Prinzip ja. Nur gibts dann wahrscheinlich keine eindeutige Sequenz.
> Könnte man dann aber mit Dauersample als eye diagram nutzen.

Da hast du recht, da sieht man nix.

Vielleicht über A15 oder A13 triggern, das wird ja nur selten beim Lesen 
des PC high sein, vielleicht kann man dann die nächsten Takte 
nachvollziehen.

[Johannes S. (vamogu05)]

Tom K. schrieb:
> Ach ja, vielleicht schreibts du mal an das Schachcomputer online Museum,
> die refurbishen ihre Computer ja auch, was ich so gelesen habe.
> Die haben vielleicht Tipps auf Lager, wo man die Teile, die heute keiner

Die kenne ich alle sehr gut. Wir treffen uns einmal im Jahr. Bin mit 
denen laufend in Kontakt.

Ich werde als nächstes einen neuen Schaltplan mit der empfohlenen 
Ansteuerung machen (schon in Arbeit). Dann bitte ich Euch mal drüber zu 
sehen bevor ich das neue Layout versuche. Muss schauen, dass die nächste 
Platine bald bestellt wird. Dann kann ich mich wieder um die Fehlersuche 
kümmern.

Danke an Alle für die wertvollen Tipps. Ich halte Euch auf dem 
Laufenden.

[Johannes S. (vamogu05)]

Ach ja, bevor ich es vergesse. Was ist denn an meinem Schaltplan 
wirklich so schlecht?
Im Anhang nochmals der ursprüngliche Schaltplan. Ich möchte jetzt nicht 
die selben Fehler machen wie zuerst.
Ich verwende halt globale Labels bei den Bauteilen. Findet Ihr Busse 
besser zu lesen? Was könnte ich besser machen?

[Thomas W. (dbstw)]

Johannes S. schrieb:
> Ich werde als nächstes einen neuen Schaltplan mit der empfohlenen
> Ansteuerung machen (schon in Arbeit). Dann bitte ich Euch mal drüber zu
> sehen bevor ich das neue Layout versuche. Muss schauen, dass die nächste
> Platine bald bestellt wird. Dann kann ich mich wieder um die Fehlersuche
> kümmern.

Wozu? Du hast doch den Fehler der aktuellen Platine noch nicht einmal 
eingrenzen koennen (OK, ich habe z.z. keine neue Idee) aber jetzt eine 
neue Platine entwerfen und gucken ob es jetzt besser funktioniert ist, 
vorsichtig ausgedrueckt, sinnfrei.

Auch ganz banal: Wo hast Du denn die CPU und VIA gekauft und gibt es 
eine einwandfreie Platine, auf der die spezifische CPU funktioniert? 
(Hintergrund: Es laesst sich fast alles faelschen. Und auch Chinesen 
koennen Laserbeschriften :-)).

Denn Deine Signal sehen so auf den ersten Blick einwandfrei aus (bei 
1MHz so oder so, und bei 16MHz auch noch).

[Klaus F. (klaus27f)]

Johannes S. schrieb:
> anbei die Bilder von den Oszillogrammen mit 16MHz Taktfrequenz gemessen.
> Ich hoffe, Du kannst da was brauchbares erkennen.

Hallo,
habe mir die Bilder jetzt auch angesehen.
Also prinzipiell sieht das brauchbar aus, keine Auffälligkeiten.
Wobei --wie schon geschrieben-- bin ich bzgl. 6502 nicht der Spezialist, 
weiss also nicht an welcher Stelle welchen "Phi" clocks die CPU die 
gültigen Daten ünenimmt.
Prinzipiell sollte das aber natürlich im Datenblatt der CPU exakt 
dokumentiert sein.

Daß es bei de eher geringen Stromaufnahme "grosse" Hitzeprobleme gibt 
ist auch wenig plausibel.
Da wäre nicht äusserst geringe Verschiebungen im Bereich weniger 
einzelner ns erwartbar.
Schwierig.
Vielleicht noch Decodierung von "HC" auf "AC" Bauteile austauschen, als 
Versuch. Aber mit mikrigen 1 MHz sind HC schnell genug.

Evtl. --jeweils einzeln-- Bauteile gegen "andere Charge" tauschen, nicht 
daß du von einen Bauteiltyp eine "schlechte Sorte" bekommen hast.

Sonst habe ich momentan keine weitere Idee, leider.

[Klaus F. (klaus27f)]

Da wäre   nur   äusserst geringe Verschiebungen

[Johannes S. (vamogu05)]

Thomas W. schrieb:
> Johannes S. schrieb:
>> Ich werde als nächstes einen neuen Schaltplan mit der empfohlenen
>> Ansteuerung machen (schon in Arbeit). Dann bitte ich Euch mal drüber zu
>> sehen bevor ich das neue Layout versuche. Muss schauen, dass die nächste
>> Platine bald bestellt wird. Dann kann ich mich wieder um die Fehlersuche
>> kümmern.
>
> Wozu? Du hast doch den Fehler der aktuellen Platine noch nicht einmal
> eingrenzen koennen (OK, ich habe z.z. keine neue Idee) aber jetzt eine
> neue Platine entwerfen und gucken ob es jetzt besser funktioniert ist,
> vorsichtig ausgedrueckt, sinnfrei.
>
> Auch ganz banal: Wo hast Du denn die CPU und VIA gekauft und gibt es
> eine einwandfreie Platine, auf der die spezifische CPU funktioniert?
> (Hintergrund: Es laesst sich fast alles faelschen. Und auch Chinesen
> koennen Laserbeschriften :-)).
>
> Denn Deine Signal sehen so auf den ersten Blick einwandfrei aus (bei
> 1MHz so oder so, und bei 16MHz auch noch).

Hallo Thomas,

Ich habe eine Platine, die so aufgebaut sein müsste wie meine, die 
einwandfrei läuft. Mein Nachbau hat allerdings die o.a. Probleme und 
funktioniert erst nach einer gewißen Aufwärmzeit. Ich denke, dass es am 
Layout liegt.
Die Teile habe ich bei Mouser und Digikey gekauft und schon in der 
funktionierenden Platine gegengecheckt.

[Johannes S. (vamogu05)]

Klaus F. schrieb:
> Evtl. --jeweils einzeln-- Bauteile gegen "andere Charge" tauschen, nicht
> daß du von einen Bauteiltyp eine "schlechte Sorte" bekommen hast.

Hallo Klaus,

danke, für den Tipp. Das wäre natürlich eine Erklärung wenn die 
Decoderbausteine zu lange Gatterlaufzeiten hätten. Ich werde mir mal ein 
paar Stück "AC" zum Testen kaufen. Momentan habe ich ja die "F"-Typen 
verbaut.

[Thomas W. (dbstw)]

Johannes S. schrieb:

> Ich habe eine Platine, die so aufgebaut sein müsste wie meine, die
> einwandfrei läuft. Mein Nachbau hat allerdings die o.a. Probleme und
> funktioniert erst nach einer gewißen Aufwärmzeit. Ich denke, dass es am
> Layout liegt.

> Die Teile habe ich bei Mouser und Digikey gekauft und schon in der
> funktionierenden Platine gegengecheckt.

Schade eigentlich, denn Faelschungen gibt es immer. Aber Kreuztausch und 
"richtiger" Distributor spricht dagegen.

[Irgend W. (Firma: egal) (irgendwer)]

Klaus F. schrieb:
> an welcher Stelle welchen "Phi" clocks die CPU die gültigen Daten ünenimmt.

Eventuell mal die Sache mit dem phi2, r/w, ce und Adressdecoder nochmal 
genauer untersuchen. Eventuell genau diese Signale auch nochmal mit der 
Originalplatine vergleichen. Nicht das da irgendwo eine Signal 
"vertauscht" ist und dadurch auf der "falsche" flanke gearbeitet wird.
Kann beim "Durchklingeln" durchaus mal passieren, dass man da was 
vertauscht wird.

Das ist hier z.B. ist etwas anders gelöst:
- https://eater.net/6502

[Tom K. (katdroid)]

Irgend W. schrieb:
> Eventuell mal die Sache mit dem phi2, r/w, ce und Adressdecoder nochmal
> genauer untersuchen. Eventuell genau diese Signale auch nochmal mit der
> Originalplatine vergleichen. Nicht das da irgendwo eine Signal
> "vertauscht" ist und dadurch auf der "falsche" flanke gearbeitet wird.

Laut Datenblatt RAM, werden die Daten beim Schreibzugriff übernommen, 
wenn CE#
und WE# beide low sind, allerdings darf sich die Adresse nur ändern, 
wenn CE# und WE# beide high sind, steht da jedenfalls unter dem Diagram.

Also irgendwie ist das blöd ausgedrückt. Ein RAM ist doch nichts 
anderes, als ein Flipflop, oder? Da nehme ich doch an, dass der 
Flankenwechsel von low nach high doch der Zeitpunkt ist, wann die Daten 
stabil auf dem Bus liegen müssen.
Das Timing Diagramm legt das auch nahe, finde ich. Der Text verwirrt 
mich mehr, als er hilft.

Na sei es, wie es ist.
Auf jeden Fall dekodierst du CE# aus A13-15, d.h. die Adressbits ändern 
sich und dann erst (nach dem Durchlaufen der Gatter) wird CE# wieder 
high, falls die neue Adresse nicht mehr passt. Das würde gegen obigen 
Satz aus dem Datasheet verstoßen. (Um wenige Picosekunden? Wie schnell 
ist denn so ein Gatter?)
Versuche doch mal, CE# noch mit dem PHI2# zu ANDen, dann müsste CE# 
früher, also zur Mitte des Taktes, was m. E. ja auch sinnvoll wäre, high 
werden.

Ich hoffe, man kann verstehen, was ich hier meine ;-)

LG Thomas

[Norbert (der_norbert)]

Tom K. schrieb:
> (Um wenige Picosekunden? Wie schnell
> ist denn so ein Gatter?)

Die Annahme würde ich gleich mal um einige Größenordnungen nach oben 
korrigieren. ;-)

[Thomas W. (dbstw)]

Tom K. schrieb:
> Satz aus dem Datasheet verstoßen. (Um wenige Picosekunden? Wie schnell
> ist denn so ein Gatter?)

https://homepages.uni-regensburg.de/~erc24492/TTL/TTL.html

[Irgend W. (Firma: egal) (irgendwer)]

Norbert schrieb:
> Tom K. schrieb:
>> (Um wenige Picosekunden? Wie schnell
>> ist denn so ein Gatter?)
>
> Die Annahme würde ich gleich mal um einige Größenordnungen nach oben
> korrigieren. ;-)

Der 74F04 hat ca. 3ns (Seite 3)
- https://www.ti.com/lit/ds/symlink/sn54f04.pdf
- https://www.ti.com/lit/ds/symlink/sn74hc04.pdf
- https://www.ti.com/lit/ds/symlink/sn54als04b.pdf

HC und ALS sind sogars langsamer.

[Joachim B. (jar)]

Tom K. schrieb:
> Ich meinte, dass du ja von heiß(kein Fehler) auf kalt(Fehlerfall) bei
> den warmen Temperaturen im Moment warten musst, bis alles abgekühlt ist.

mit Kältespray bewaffnet muß man warten?

[Tom K. (katdroid)]

Joachim B. schrieb:
> Tom K. schrieb:
>> Ich meinte, dass du ja von heiß(kein Fehler) auf kalt(Fehlerfall) bei
>> den warmen Temperaturen im Moment warten musst, bis alles abgekühlt ist.
>
> mit Kältespray bewaffnet muß man warten?
Nee, mit Kältespray kühlst du ja ganz schnell runter, da brauchst du 
nicht Warten, da wird sich der Fehler hoffentlich schnell wieder zeigen.
Ich wollte sagen, wenn du keins hast, dann musst du entweder warten, bis 
alles wieder Raumtemperatur hat, oder du kannst mit einem Gebläse ein 
bisschen nachhelfen.
Also Kältespray ist prima, aber mit Fön geht halt auch.
LG Thomas

[Tom K. (katdroid)]

Irgend W. schrieb:
> Norbert schrieb:
>> Tom K. schrieb:
>>> (Um wenige Picosekunden? Wie schnell
>>> ist denn so ein Gatter?)
>>
>> Die Annahme würde ich gleich mal um einige Größenordnungen nach oben
>> korrigieren. ;-)
>
> Der 74F04 hat ca. 3ns (Seite 3)
> - https://www.ti.com/lit/ds/symlink/sn54f04.pdf
> - https://www.ti.com/lit/ds/symlink/sn74hc04.pdf
> - https://www.ti.com/lit/ds/symlink/sn54als04b.pdf
>
> HC und ALS sind sogars langsamer.

Ich sach doch, wenige Tausend Picosekunden später.... ;-)
Ok, Danke für die Links, kommen sofort in die Sammlung.

VG Thomas

[Tom K. (katdroid)]

Ich hab das Datenblatt vom RAM nochmal studiert:

Notes :
1.WE#, CE# must be high during all address transitions.
2.A write occurs during the overlap of a low CE#, low WE#.
[...]

Da drüber sind zwei Timing Diagramme, eins für WE# controlled, eins für 
CE# controlled.

Es war wohl WE# resp. CE# gemeint, je nachdem, was kontrolliert wird. 
Daher sollte deine Schaltung doch funktionieren.
Aber hier kam doch der Vorschlag, bei https://eater.net/6502 zu schauen, 
das würde ich dir auch empfehlen.

LG Thomas

[Johannes S. (vamogu05)]

Ich habe nun neue Erkenntnis gewonnen:
Im Anhang seht Ihr das Layout meiner Platine mit einem weißen Kreis 
gekennzeichnet. Wenn ich diesen Bereich erwärme funktioniert die Platine 
sofort.
Zuerst habe ich mit meiner Heißluftstation das RAM erwärmt und der 
Schachcomputer lief daraufhin einwandfrei. Danach habe ich das RAM aber 
ausgebaut, erwärmt und wieder eingebaut. Lief wieder nicht richtig. Es 
ist also nicht der SRAM-IC selbst. Sobald ich aber die eingekreiste 
Stelle erwärme, läuft er sofort einwandfrei.
Ich brauche nur die Pins, so im Bereich A2-A5 (Pin 5-8) mit dem Finger 
berühren und der Fehler verschwindet. Dabei ist es egal ob ich diese 
Pins am RAM selbst oder dem nebenan gelegenen EPROM berühre.
Liegt es an den zu knappen Abständen? Ich habe dort zwischen A2-Leitung 
und dem CE-Signal nur 0,2mm Abstand über ein kurzes Stück (siehe Bild). 
Kann das die Ursache sein? Wie kann ich den Fehler weiter einkreisen? 
Habt Ihr Ideen dazu?
Danke für eure Bemühungen.

[Wolfgang S. (wolfgang_s278)]

Alle Lötstellen nachlöten.
Enge Stellen mit einer Klinge reinigen/trennen.
Durchkontaktieungen im Umfeld können im Loch unterbrochen sein.
Also ein Stück Draht hinein stecken und oben und unten verlöten.
Ebenso der PIN 1 am IC.

[Klaus F. (klaus27f)]

> Ich brauche nur die Pins, so im Bereich A2-A5 (Pin 5-8)
> mit dem Finger berühren und der Fehler verschwindet.

Irgend ein offenes Signal.
Ein Haar-Riss in einer Leiterbahn, eine Durchkontaktierung defekt.

Oder, das ich ich schonmal, ein Präzisions-IC-Sockel, wo an einem Pin 
ein Teil der "inneren Hülse" fehlt.

Es gibt nix was es nicht gibt.

[Johannes S. (vamogu05)]

Klaus F. schrieb:
>> Ich brauche nur die Pins, so im Bereich A2-A5 (Pin 5-8)
>> mit dem Finger berühren und der Fehler verschwindet.
>
> Irgend ein offenes Signal.
> Ein Haar-Riss in einer Leiterbahn, eine Durchkontaktierung defekt.
>
> Oder, das ich ich schonmal, ein Präzisions-IC-Sockel, wo an einem Pin
> ein Teil der "inneren Hülse" fehlt.
>
> Es gibt nix was es nicht gibt.

Danke für die Hinweise. Ich werde mal den Bereich nachlöten und 
genauestens kontrollieren.
Gegen eine schlechte Verbindung  spricht allerdings, dass eine weitere 
Platine genau das selbe Verhalten zeigt wie diese.
Ich konnte nun den Bereich noch genauer eingrenzen. Der Fehler ist weg, 
sobald ich A1 oder A2 berühre. Egal an welchem Baustein. Direkt an der 
CPU oder am EPROM oder SRAM.
Was kann das sein?

[Wulf D. (holler)]

Johannes S. schrieb:
> Ich konnte nun den Bereich noch genauer eingrenzen. Der Fehler ist weg,
> sobald ich A1 oder A2 berühre. Egal an welchem Baustein. Direkt an der
> CPU oder am EPROM oder SRAM.
> Was kann das sein?

Seltsam. Dein Bild von A0 sieht eigentlich ganz gut aus. Sind auf A1 und 
A2 irgendwelche Glitches drauf? Gehe mal mit dem Oszi drauf. Verändert 
sich dann was?
Ggf mal testweise 10p auf A1 und A2 gegen Masse schalten, direkt auf der 
Platine. Oder wie schon an anderer Stelle bemerkt, einen niederohmigen 
Widerstand einschleifen.

[Johannes S. (vamogu05)]

Wulf D. schrieb:
> Ggf mal testweise 10p auf A1 und A2 gegen Masse schalten, direkt auf der
> Platine.

Hallo Wulf,

danke für den Hinweis!
Ich habe je einen 10pF Kerko an Pin 8 (A2) und Pin 9 (A1) des RAM-Chips 
gelötet und siehe da, die Platine läuft einwandfrei. Zuerst hatte ich 
noch mit dem Oszilloskop die Signale dieser beiden Adressleitungen mit 
anderen Adressleitungen verglichen, aber keine Unterschiede feststellen 
können.

Kann mir jemand erklären was da bei dieser Platine schief lief, dass man 
an A1 und A2 Kerkos gegen Masse schalten musste? Das kann doch nur ein 
schlechtes Layout sein, oder?
Zumindest werde ich bei der nächsten Platine die Ansteuerung der 
OE-Eingänge so lösen wie von Euch vorgeschlagen.
Danke an Alle für die kompetente Hilfestellung.

[Klaus F. (klaus27f)]

Johannes S. schrieb:
> Das kann doch nur ein
> schlechtes Layout sein, oder?

Das kann man schlecht sagen.
Mit deinem Scope ist man da auch über der Grenze der Möglichkeiten, denn 
auch angeklemmter Tastkopf hat ungefähr diese Eingangskapazität von 
10-20pF.
Der Effekt kann auch die "ungünstige Charge" von Bauteilen kommen.
Um warum gerade A1 und A2, wohl nicht jedoch A0, oder A3, komisch, 
komisch.
---
Ich hatte vor vielen Jahren mal den Effekt daß an einer Grafikkarte das 
Pixel-Ausgangs-Schieberegister 74xx165 am Bildschirm sichtbare 
Unsauberheiten produzierte. So Art "flimmern", also was an der Grenze 
von Dateneingang, Übernahmetakt. Meißt ok (sonst wäre kein Bild gewesen) 
aber doch einzelne Pixel fehlerhaft.
Trat nur auf bei Fabrikat Texas Instruments, da auch bei anderer Charge, 
anderer Datecode. Takt war 14 oder 16 MHz, alle Specs erfüllt. Rätsel.
Herausgefunden: 74xx165 Bauteile anderer Hersteller funktionieren 
problemlos!
Also die Stückliste angepasst und konkreten Hersteller des Standardteils 
definiert, was (damals) sonst unüblich und unnötig war.
Keine weitere Änderung; das Gerät wurde noch jahrelang produziert.

[Vanye R. (vanye_rijan)]

> Kann mir jemand erklären was da bei dieser Platine schief lief, dass man
> an A1 und A2 Kerkos gegen Masse schalten musste?

Reflexionen wegen schlechten Layout bei hohen Frequenzen, aber du willst 
ja nichts verstehen. Und nebenbei einen 10pF einfach parallel schalten 
ist eine schlechte Loesung weil der einen knallhalten Kurzschluss macht. 
Entweder 10/47pF+100R in serie, gegen GND oder 100R direkt einschleifen.

Versuch den Anhang zu verstehen. Das gehoert zu den Grundlagen der NT 
die man drauf haben muss. Abmalen von Google reicht nicht.

Vanye

[Johannes S. (vamogu05)]

Vanye R. schrieb:
>> Kann mir jemand erklären was da bei dieser Platine schief lief,
> dass man
>> an A1 und A2 Kerkos gegen Masse schalten musste?
>
> Reflexionen wegen schlechten Layout bei hohen Frequenzen, aber du willst
> ja nichts verstehen. Und nebenbei einen 10pF einfach parallel schalten
> ist eine schlechte Loesung weil der einen knallhalten Kurzschluss macht.
> Entweder 10/47pF+100R in serie, gegen GND oder 100R direkt einschleifen.
>
> Versuch den Anhang zu verstehen. Das gehoert zu den Grundlagen der NT
> die man drauf haben muss. Abmalen von Google reicht nicht.
>
> Vanye

Danke für Deinen Beitrag.
Wie kommst Du drauf, dass ich nichts verstehen möchte? Ich bin froh, 
wenn mir jemand erklären kann warum sich das so verhält. Ich weiß nur 
nicht, wo im Layout ich mir das Problem eingefangen habe? Die Leitungen 
sind sicher nicht zu lange. Evtl. zu dünn, das könnte gut sein.
Gut ich werde jetzt noch einen 100Ohm Widerstand in Reihe zum C 
schalten. Danke für den Tipp.

[Thomas W. (dbstw)]

Johannes S. schrieb:
> Wulf D. schrieb:
>> Ggf mal testweise 10p auf A1 und A2 gegen Masse schalten, direkt auf der
>> Platine.
>
> Hallo Wulf,
>
> danke für den Hinweis!
> Ich habe je einen 10pF Kerko an Pin 8 (A2) und Pin 9 (A1) des RAM-Chips
> gelötet und siehe da, die Platine läuft einwandfrei.

Ich haette mehr auf einen Fabrikationsfehler bei der Platine gesetzt 
(die Platinen werden haeufig im Stapel bearbeitet, wenn eine einen 
Fehler hat, haben alle Fehler).

Ich habe mal stundenlang nach einem Fehler gesucht (Z80-Board startet 
einwandfrei, irgendwann hat es keine Lust mehr, nach stromlos-schalten 
wieder alles gut). In der Verzweifelung habe ich alle Loetstellen 
nachgeloetet, auch die bei der 39-pin-CPU...

Gruesse

[Wulf D. (holler)]

Vanye R. schrieb:
> Und nebenbei einen 10pF einfach parallel schalten
> ist eine schlechte Loesung weil der einen knallhalten Kurzschluss macht.

Na, nun bleib mal auf dem Teppich, 10p haben bei 16 MHz einen 
Blindwiderstand um 1k. Und komm mir nicht mit Oberwellen, dann überwiegt 
bald der induktive Widerstand der geschätzten 10cm Leiterbahnlänge. 
Vielleicht solltest Du zur Auffrischung auch mal deinen Anhang lesen? 
Ist jedenfalls ein guter Text.

Thomas W. schrieb:
> Ich haette mehr auf einen Fabrikationsfehler bei der Platine gesetzt
> (die Platinen werden haeufig im Stapel bearbeitet, wenn eine einen
> Fehler hat, haben alle Fehler).
Wäre auch meine Vermutung gewesen. Und Nachlöten kann nie schaden. Aber 
um die Sache einzugrenzen, eben der Tipp mit den 10pF. Klar, ist nicht 
als finale Lösung gedacht.

Eigentlich braucht man bei 16 MHz noch keine abgeschlossenen Leitungen 
auf den Bussen. Habe in den 90ern etliche solche Systeme designed (68k, 
PPC), war bis rauf zu 50 MHz nie nötig.

Tippe schon auf ein ungünstiges Layout, so dass sich die beiden 
Adressleitungen irgendwas einfangen, was dein 50MHz Oszi nicht auflösen 
kann. Kann man ohne das Layouttool nur schwer allein anhand der Bilder 
verfolgen: es fällt aber auf, dass die beiden Adressleitungen A1 und A2 
zwischen EPROM und RAM eine extra-Schleife außen rum drehen. Die anderen 
A-Leitungen hast Du direkt quer geroutet. Sollte mit A1 und A2 auch 
gehen.

Nur so als Hinweis, das würde ich schon mal ändern. Ist vermutlich nicht 
alles, könnte mir auch noch eine ungenügende Masseanbindung vorstellen.

Gruß Wulf

[Vanye R. (vanye_rijan)]

> Ich haette mehr auf einen Fabrikationsfehler bei der Platine gesetzt

Selbst billige Platinen von JLCPCB werden immer elektrisch getestet. Und 
wenn ich so drueber nachdenke, ich hab glaube ich seit mindestens 
15Jahre keine defekte Platine mehr gesehen und selbst damals wurde das 
im Test erkannt und ein huebscher Aufkleber drauf gemacht.

Vanye

[Johannes S. (vamogu05)]

Wulf D. schrieb:
> es fällt aber auf, dass die beiden Adressleitungen A1 und A2
> zwischen EPROM und RAM eine extra-Schleife außen rum drehen. Die anderen
> A-Leitungen hast Du direkt quer geroutet. Sollte mit A1 und A2 auch
> gehen.

Danke Wulf, ja, das wäre schon eine Erklärung.

[Norbert (der_norbert)]

Auch auf die Gefahr hin, das Offensichtliche zu wiederholen:

Die Probleme treten auch bei einem einzigen, einsamen, gemütlichen 
MegaHertz auf.

[Wulf D. (holler)]

Norbert schrieb:
> Die Probleme treten auch bei einem einzigen, einsamen, gemütlichen
> MegaHertz auf.
Was dann eher auf ein generelles Timing- oder Pegel-Problem hindeutet.

Die CS & WE Erzeugung aus r/w, Adr und Phi wurde hier schon im Detail 
durchdiskutiert.

Der Mix der Logikfamilien CMOS zu LS/F und wieder zurück zu CMOS gefällt 
mir nicht. Das Voh min der LS/F passt nicht so recht zum Vih min der 
CMOS Bausteine, ohne mir jetzt das Datenblatt des CMOS-RAM und EPROM 
angesehen zu haben: kannst Du nicht mal die Gatter der CS & WE Logik 
durchgängig mit AC- Bausteinen bestücken?

Gruß Wulf

[Irgend W. (Firma: egal) (irgendwer)]

Johannes S. schrieb:
> Der Fehler ist weg,
> sobald ich A1 oder A2 berühre. Egal an welchem Baustein.

Sowas in der Art hatte ich auch mal (aber keine Ahnung mehr ob das auch 
A1/A2 waren). Ursache war damals (Jugendlicher Leichtsinn) das nicht 
genügend bzw. zu weit entfernte Abblockkondensatoren verwendet wurden. 
Jedem(!) IC auf der Rückseite direkt noch eine C zwischen den Pins mit 
der Versorgungsspannung, ganz ohne Leiterbahn. Danach ist die Schaltung 
Jahrelang stabil gelaufen.

So ähnlich wie hier, nur halt manuell auf der Unterseite (ggf. mit etwas 
Schrumpfschlauch isolieren).
- 
https://www.reichelt.de/ch/de/ic-sockel-28-polig-mit-abblockkondensator-gs-ko-28p-p8238.html?r=1

[Wulf D. (holler)]

Habe gerade mal ins Datenblatt vom RAM geschaut: dessen Vih min beträgt 
2,4V. Die LS-TTL liefern mindestens einen High-Pegel von 2,7V.

Müsste gerade so ausreichen, aber etwas Geräusch und es geht schief.

Und die Stützkondensatoren an ROM und RAM sind masseseitig nur auf 
Umwegen mit deren jeweiligen Pin 14 verbunden.

Gruß Wulf

[Klaus F. (klaus27f)]

Wulf D. schrieb:
> Norbert schrieb:
>> Die Probleme treten auch bei einem einzigen, einsamen, gemütlichen
>> MegaHertz auf.
>
> Was dann eher auf ein generelles Timing- oder Pegel-Problem hindeutet.
>


Genau das meine ich auch.
Wenige MHz sind bei kürzeren Leitungslängen normalerweise problemlos.

Denn wie sollte sonst z.B. nachfolgende Schaltung jemals laufen, mit 
Pixeltakt von über 25 MHz ???

https://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/s2012/raf225_dah322/raf225_dah322/images/board.jpg

https://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/s2012/raf225_dah322/raf225_dah322/index.html

[Johannes S. (vamogu05)]

Wulf D. schrieb:
> kannst Du nicht mal die Gatter der CS & WE Logik
> durchgängig mit AC- Bausteinen bestücken?

DAs kann ich gerne ausprobieren. Werde mir die entsprechenden Bauteile 
besorgen.
Momentan habe ich als Decodiergatter F-Bauteile.

Wulf D. schrieb:
> Und die Stützkondensatoren an ROM und RAM sind masseseitig nur auf
> Umwegen mit deren jeweiligen Pin 14 verbunden.

Ja, das werde ich im künftigen Layout berücksichtigen.

[Wulf D. (holler)]

Ich würde bei der Gelegenheit mir das ganze Massenetz einmal anschauen, 
ob sich da Schleifen oder schwache Inseln ergeben.

Kenne KiCad nicht, aber es hat mit Sicherheit eine Funktion, die ein 
einzelnes Netz hervorhebt bzw. markiert, so dass man dessen Verlauf 
leicht überblickt. Meist wird das Netz dann viel heller als der Rest 
dargestellt.

Optimal wäre eine flächige oder sternförmige Masseversorgung (mit Tracks 
min 1mm) von Netzteil, CPU, RAM, ROM und Decodierlogik. Der Rest schadet 
natürlich auch nicht.

Schlecht sind lange Schleifen, zumal mit dünnen Tracks.

Gruß Wulf

[Johannes S. (vamogu05)]

Seit dem Einbau der beiden 10pF Kondensatoren läuft die Platine 
einwandfrei!
Ich habe heute versucht den Quarzoszillator zu erhöhen und festgestellt, 
dass ich einen stabilen Betrieb bis 20MHz habe. Bei 24MHz sind RAM und 
EPROM wahrscheinlich zu langsam.
Natürlich wird die nächste Version optimaler geroutet werden!
Danke nochmals an Alle die geholfen haben.

[Norbert (der_norbert)]

Johannes S. schrieb:
> Natürlich wird die nächste Version optimaler geroutet werden

So etwas geht jetzt auch schon?
Wie die Zeit voran eilt… ;-)

[Jens G. (jensig)]

Johannes S. schrieb:
> Seit dem Einbau der beiden 10pF Kondensatoren läuft die Platine
> einwandfrei!
> Ich habe heute versucht den Quarzoszillator zu erhöhen und festgestellt,
> dass ich einen stabilen Betrieb bis 20MHz habe.

Naja, wie ich schon andeutete, deutet auch dies darauf, daß sich Flanken 
irgendwelcher Signale, die zueinander mit einem bestimmten Timing 
koordiniert sein müssen, ungünstig zueinander liegen, bzw. auf Kante 
genäht sind. Ich sehe hier die Adressdekodierer, und das damit 
zusammenhängende und gleichzeitige CE/OE-Handling, was offensichtlich 
schlechte Timings verursacht ...

[Joachim B. (jar)]

Johannes S. schrieb:
> Natürlich wird die nächste Version optimaler geroutet werden!

was ist optimaler als optimal?
War die jetzige Version also nicht optimal?
Wenn etwas optimal war, wie kann die nächste Version optimaler werden?

[Johannes S. (vamogu05)]

Joachim B. schrieb:
> Johannes S. schrieb:
>> Natürlich wird die nächste Version optimaler geroutet werden!
>
> was ist optimaler als optimal?
> War die jetzige Version also nicht optimal?
> Wenn etwas optimal war, wie kann die nächste Version optimaler werden?

Die jetzige Platine brauchte je einen 10pF Kerko gegen Masse bei den 
Adressleitungen A1/A2 damit sie anstandslos funktioniert. Also sind 
vermutlich die beiden Adressleitungen schlecht geroutet. Das wird in der 
nächsten Version optimaler gestaltet. Jetzt war es ja nicht optimal, 
sonst hätte es diese Fehler nicht gegeben!

[(prx) A. K. (prx)]

Joachim B. schrieb:
> Wenn etwas optimal war, wie kann die nächste Version optimaler werden?

Wenn die gestrige Lösung gestern optimal war, es heute aber nicht mehr 
ist, kann die heute optimale Lösung dann optimaler sein als die 
gestrige? :)

[Dietrich L. (dietrichl)]

Jens G. schrieb:
> Naja, wie ich schon andeutete, deutet auch dies darauf, daß sich Flanken
> irgendwelcher Signale, die zueinander mit einem bestimmten Timing
> koordiniert sein müssen, ungünstig zueinander liegen, bzw. auf Kante
> genäht sind. Ich sehe hier die Adressdekodierer, und das damit
> zusammenhängende und gleichzeitige CE/OE-Handling, was offensichtlich
> schlechte Timings verursacht ...

Das sehe ich auch so. Wieviel ein neues Layout das "auf Kante genäht" 
verbessert ist aber ungewiss.
Ich sehe als seriöses Vorgehen:
- Das jetzige Timing mit Oszi vermessen.
- Dieses Timing mit den Vorgaben aus den Datenblättern vergleichen.
- Zusätzlich Reserve vorsehen, denn die Messung zeigt ja nur typische 
und keine Worst-Case Werte (Einfluss von Temperatur, 
Versorgungsspannung, Exemplarstreuung).
Das ganze ist allerdings anspruchsvoll und zeitaufwendig...

[Wastl (hartundweichware)]

Johannes S. schrieb:
> Also sind
> vermutlich die beiden Adressleitungen schlecht geroutet.

Nein!

Ein für alle Mal: das Bus-Timing ist nicht korrekt, eine
Veränderung an den Adressleitungen verschleiert nur das
eigentliche Problem. Adressen werden vor einem Zugriff
durch ein anderes Signal (üblicherweise /CS) für den
Adressaten gültig gemacht und sind nicht für sich alleine
stehend schon gültig.

Eine wie hier geartete Verzögerung (durch C-Last) weist
eher darauf hin dass ein adressierter Baustein zu früh
Daten auf den Bus gibt die entweder noch ungültig sind
oder eine kleine Bus-Kollision mit einem anderen Teilnehmer
auslöst dessen Daten noch (auch Timing-Problem) auf dem
Datenbus anliegen.

Die Adressleitungen werden direkt vom 6502 getrieben, werden
also nie hochohmg (floatend) sein, daher können sie auch nicht
leicht durch Einstreuungen gestört werden. Allenfalls könnten
sehr lange Adressleitungen ein Klingeln drauf haben das zu
eine Fehladressierung führt, was bei diesen Leitungslängen
aber absolut unwahrscheinlich erscheint.

[Wulf D. (holler)]

Ein paar Layoutschwächen haben wir ja schon gefunden. Ich würde die im 
vorhandenen Layout schon mal mit Drähten (A1, A2) und bedrahteten 100n 
Kercos (Stützkondensatoren) einbauen, ob es dann ohne die 10pF 
Workarounds geht.

Auch würde ich mit Hilfe des Layouttools nach weiteren Layoutschwächen 
fanden.

Und die Pegelkritische Logikkombination des Adressdekoders nicht zu 
vergessen.

Aber richtig, die hohe Fehlerempfindlichkeit bei niedrigster 
Taktfrequenz mag das nicht so recht erklären.

Das RAM wird bei Dir z.B. WE-gesteuert beschrieben: gehe doch mal mit 
einem Kanal des Oszi auf WE, triggere auf steigende Flanke und mit dem 
zweiten Kanal taste die Adress-und Datenleitungen ab. Eine Hold-Time 
benötigt das RAM nicht, aber schaue mal genau hin ob die Flanken des 
zweiten Kanals niemals (!) auf die des ersten fallen oder gar minimal 
früher kommen. Höchste Zeit-Auflösung am Oszi einstellen, die Kanäle 
müssen gleichzeitig abgetastet werden.

Ggf. viele, viele Single shots auslösen, falls das dein Oszi nicht 
triggern bzw. auflösen kann.

Analog das Lesen von RAM und EPROM prüfen.

Gruß Wulf

[Wulf D. (holler)]

Man kann und sollte für die Timings Toleranzketten aufstellen, wenn man 
ein kommerzielles Design angeht: die Min- und Max-Timings von CPU and 
Peripherie alle untereinander schreiben und schauen ob alles eingehalten 
wird.

Das ist hier aber ein Hobbyprojekt und es gibt schon einen Prototyp. Da 
ist nachmessen bequemer. Anbei ein Screenshot aus dem Datenblatt des 
RAMs. Es gibt meist mehrere Betriebsmodi. Hier WE-Controlled beim 
Schreiben als Beispiel, wie oben schon beschrieben.

Das RAM übernimmt die Daten vom Bus mit der steigenden Flanke von WE, im 
Bild mit roten Blitz markiert. Damit das funktioniert, müssen aber 
weitere Bedingungen eingehalten werden.

Die Adressen müssen lange genug (t-AW) vor dieser Flanke stabil, d.h. 
ohne Änderung, angestanden haben, genau so CE (t-CW) und WE (t-WP). Auch 
die Daten, hier genügt aber die kürzere Zeit t-DW. Genaue Werte stehen 
im Datenblatt.

Besser mal alles mit dem Oszi prüfen und ausmessen, falls der Zeiten um 
10ns auflöst.

Analog mit den Lesezyklen von RAM und EPROM verfahren (ausreichend Zeit 
von Adresswechsel bis CE-High-Flanke), wobei du hier auch einen Blick 
ins Datenblatt der CPU werfen musst. Also mit welcher Flanke übernimmt 
die die Daten.

Gruß Wulf

[Thomas W. (dbstw)]

Wastl schrieb:
> Die Adressleitungen werden direkt vom 6502 getrieben, werden
> also nie hochohmg (floatend) sein, daher können sie auch nicht
> leicht durch Einstreuungen gestört werden.

Das spielt hier keine Rolle, aber die 65C02(!) hat das BE (Bus 
enable)-Eingang. Ist der BE High, dann werden die Bustreiber in der CPU 
durchgeschaltet, bei low werden die Bustreiber asynchron abschaltet. Ist 
bei dem Patienten fest mit Vcc verbunden.

Das war damals (als die CMOS-Versionen rauskamen) das grosse Ding, denn 
Du konntest dann richtiges DMA mit der 65C02 machen (bei der 
NMOS-Version nur mit Klimmzuegen).

Ist lange her und hat keine, aber gar keine Relevanz fuer diesen Thread.

Gruesse

[Johannes S. (vamogu05)]

Wulf D. schrieb:
> Besser mal alles mit dem Oszi prüfen und ausmessen, falls der Zeiten um
> 10ns auflöst.
>
> Analog mit den Lesezyklen von RAM und EPROM verfahren (ausreichend Zeit
> von Adresswechsel bis CE-High-Flanke), wobei du hier auch einen Blick
> ins Datenblatt der CPU werfen musst. Also mit welcher Flanke übernimmt
> die die Daten.

Danke Wulf, sehr ausführlich erklärt. Ich denke, mein Oszi kann das 
gerade noch auflösen. Schaue ich mir an.

Thomas W. schrieb:
> Das spielt hier keine Rolle, aber die 65C02(!) hat das BE (Bus
> enable)-Eingang. Ist der BE High, dann werden die Bustreiber in der CPU
> durchgeschaltet, bei low werden die Bustreiber asynchron abschaltet. Ist
> bei dem Patienten fest mit Vcc verbunden.
>
> Das war damals (als die CMOS-Versionen rauskamen) das grosse Ding, denn
> Du konntest dann richtiges DMA mit der 65C02 machen (bei der
> NMOS-Version nur mit Klimmzuegen).
>
> Ist lange her und hat keine, aber gar keine Relevanz fuer diesen Thread.

Trotzdem Danke für Deinen Beitrag. Je mehr ich darüber erfahren kann, 
desto besser wird mein Verständnis darüber.

[Irgend W. (Firma: egal) (irgendwer)]

Johannes S. schrieb:
> Also sind vermutlich die beiden Adressleitungen schlecht geroutet.

Vergiss es, so schlecht kannst da das garnicht routen das diese bei 1MHz 
solche Probleme macht. Früher hat man sowas mit wilden Fädeldraht 
Konstrukten gemacht und es hat auch geklappt.

- z.B.: Beitrag "Re: Wire wrap (Fädeltechnik)"

Du hast irgendwo ein Timing-Problem! Vermutlich wird der Adress-Bus 
schon wieder inaktiv bevor der RAM die Adresse übernommen hat. Mit dem 
Kondensator-Murks verlängerst du vermutlich minimal die Zeit wo die 
Daten auf dem Bus vorhanden sind, sodass es gerade noch so funktioniert 
und der Timingfehler kaschiert wird. Wenn es demnächst draußen etwas 
Kälter wird, sind es dann A0, A3 oder sonstwas die Probleme machen.

Wenn die Abblockkondensatoren und somit die Versorgungsspannung für alle 
IC in Ordnung ist, kann es eigentlich nur irgendwo was mit viel zu 
knappen Timing sein.
Die 74F sind von Timing her wohl schnell genug, nur sind die halt TTL 
und du verwendest ansonsten CMOS, kann gehen muss es aber nicht. Dürfte 
bei zu knappen Timing aber nur noch das letzte Tröpfchen sein und nicht 
das grundlegende Problem. Aber bei 1MHz hat das früher auch problemlos 
mit den vergleichsweise lahmen 74xx bzw. 74LSxx auch funktioniert.

74AC / 74HC wäre z.B. CMOS
- 
https://en.wikipedia.org/wiki/Logic_family#Monolithic_integrated_circuit_logic_families_compared

[Soul E. (soul_eye)]

In dem Zusammenhang wäre dann interessant, welche Logikfamilien bei der 
Originalplatine verwendet wurden. Der TO schreibt im Eingangspost, alles 
wäre identisch bis auf das SRAM.

Grundsätzlich funktionieren muss das Design ja, sonst hätte der 
Originalhersteller nicht viele davon verkauft.

[Johannes S. (vamogu05)]

Irgend W. schrieb:
> Wenn es demnächst draußen etwas
> Kälter wird, sind es dann A0, A3 oder sonstwas die Probleme machen.

D.h. wenn ich die Platine mit Kältespray behandle müsste ein Fehler 
wieder auftreten. Das werde ich probieren sobald ich Kältespray habe.

Irgend W. schrieb:
> Wenn die Abblockkondensatoren und somit die Versorgungsspannung für alle
> IC in Ordnung ist, kann es eigentlich nur irgendwo was mit viel zu
> knappen Timing sein.

Möglich, aber warum macht die Platine dann auch bei niedrigerer 
Taktfrequenz Fehler? Das passt nicht ganz zum Fehlerbild.

Irgend W. schrieb:
> Die 74F sind von Timing her wohl schnell genug, nur sind die halt TTL
> und du verwendest ansonsten CMOS, kann gehen muss es aber nicht. Dürfte
> bei zu knappen Timing aber nur noch das letzte Tröpfchen sein und nicht
> das grundlegende Problem. Aber bei 1MHz hat das früher auch problemlos
> mit den vergleichsweise lahmen 74xx bzw. 74LSxx auch funktioniert.
>
> 74AC / 74HC wäre z.B. CMOS

Ok, ich habe die 74F genommen, da die Vorlage (funktionierende Platine 
eines Elektronikers) die selben Gatter verbaut hat. Dürften auch 
schneller sein als die AC-Teile.
Ich habe mir die Decodiergatter auch in AC-Ausführung bestellt. Bin 
gespannt wie die Platine sich mit diesen Teilen verhält.

Soul E. schrieb:
> In dem Zusammenhang wäre dann interessant, welche Logikfamilien bei der
> Originalplatine verwendet wurden. Der TO schreibt im Eingangspost, alles
> wäre identisch bis auf das SRAM.
>
> Grundsätzlich funktionieren muss das Design ja, sonst hätte der
> Originalhersteller nicht viele davon verkauft.

Bitte beachten: es geht nicht um die Platine des Herstellers dieses 
Schachcomputers. Die läuft mit einer normalen 6502 CPU mit 2MHz Clock 
und einer VIA 6522 mit 1MHz Takt. Die Decodierlogik ist dort wesentlich 
umfangreicher und komplizierter aufgebaut (J-K Flip Flops etc). Ein 
Tüftler hat dann dieses Originaldesign vereinfacht und getuned auf bis 
zu 24MHz, indem der die modernen Bausteine W65C02S und W65C22 von 
Western Design Center, schnelle Gatter (74Fxx) und schnelles RAM (55ns 
bzw. 15ns bei der 24MHz Variante) verbaute. Ich bin über Umwegen an eine 
16Mhz-Platine dieses Elektronikers geraten und wollte diese nachbauen 
und den ROM-Bereich vergrößern, da ich ein umfangreiches Eröffnungsbuch 
ins ROM brennen wollte. Das alles funktioniert mittlerweile bei meiner 
Platine mit den beiden Kondensatoren in A1/A2 einwandfrei. Ob das bei 
niedrigeren Temperaturen ebenfalls noch so ist, wird sich zeigen.
Das die Ansteuerung der Speicher nicht optimal gelöst wurde (OE fix auf 
GND) weiß ich mittlerweile. Mein neues Design wird das richtig machen.

[Thomas W. (dbstw)]

Johannes S. schrieb:
>
> Bitte beachten: es geht nicht um die Platine des Herstellers dieses
> Schachcomputers. Die läuft mit einer normalen 6502 CPU mit 2MHz Clock
> und einer VIA 6522 mit 1MHz Takt. Die Decodierlogik ist dort wesentlich
> umfangreicher und komplizierter aufgebaut (J-K Flip Flops etc).

Kann man die Orginalplatine irgendwo sehen/downloaden?

Gruesse

Th.

[Soul E. (soul_eye)]

Johannes S. schrieb:
> (...) Ein
> Tüftler hat dann dieses Originaldesign vereinfacht und getuned auf bis
> zu 24MHz, indem der die modernen Bausteine W65C02S und W65C22 von
> Western Design Center, schnelle Gatter (74Fxx) und schnelles RAM (55ns
> bzw. 15ns bei der 24MHz Variante) verbaute.

Eben die meinte ich mit Originalplatine. Die sollte ja weitgehend Deiner 
Schaltung entsprechen und grundsätzlich funktionieren.

[Johannes S. (vamogu05)]

Thomas W. schrieb:
> Kann man die Orginalplatine irgendwo sehen/downloaden?

Ich habe den Schaltplan leider nicht mehr.

Soul E. schrieb:
> Eben die meinte ich mit Originalplatine. Die sollte ja weitgehend Deiner
> Schaltung entsprechen und grundsätzlich funktionieren.

Ja, meine Schaltung sollte der Originalplatine entsprechen. Der 
"Tüftler" hat nur A13 nicht in die Decodierlogik aufgenommen, deshalb 
ist der Bereich von $2000 - $3FFF sowohl vom EPROM als auch vom SRAM 
belegt. Das habe ich geändert! Außerdem verwendet er 
SMD-Abblockkondensatoren, ich 100nF Kerkos.

[Klaus F. (klaus27f)]

Johannes S. schrieb:
> Ok, ich habe die 74F genommen, da die Vorlage (funktionierende Platine
> eines Elektronikers) die selben Gatter verbaut hat. Dürften auch
> schneller sein als die AC-Teile.
>

74Fxxx sind im Wert "typ" der Durchlaufverzögerung mimimal besser als 
"AC".
Allerdings bei "min" ist "AC" schneller spezifiziert, bei "max" 
langsamer.

Beispiel  Delay t PLH  ( Werte jeweils für 25°C )
74F138:   typ. 5.4ns   min. 3.5ns   max.  7.0ns
74AC138   typ. 8.0ns   min. 1.5ns   max. 11.0ns

Wichtig: Bei den "AC" ist die theor. "Streuung"  min.-max. sehr viel 
grösser. Daher niemals kritische Signale durch ungleiche Anzahl an 
Gattern laufen lassen. Also immer gleiche "Stufenzahl", idealerweise 
einstufig.
Und möglichst auch identische Gatter, selbes Gehäuse oder zumindest 
identische Fertigungscharge.
Notfalls Ausgleich durch passenden Inverter oder "Nichtinverter" 
schaffen, wofür sich idealerweise z.B. das XOR 74AC86 eignet. Im selben 
Gehäuse sind 4 dieser Zauber.

[Dietrich L. (dietrichl)]

Johannes S. schrieb:
> Möglich, aber warum macht die Platine dann auch bei niedrigerer
> Taktfrequenz Fehler? Das passt nicht ganz zum Fehlerbild.

Die Taktfrequenz bestimmt ja "nur", wie oft pro Zeiteinheit die 
Signalabläufe abgearbeitet werden. Aber alle Vorgänge, die von einer 
Taktflanke ausgelöst werden, haben das gleiche Timing bezüglich 
Verzögerungs- und Laufzeiten bei den ICs und den Signalleitungen.
Die Taktflanke ist ja bei unterschiedlichen Frequenzen gleich steil.
Lediglich bei Signalabläufen, die mehrere Takte erfordern, ist die Zeit 
des gesamten Ablaufs frequenzabhängig. Aber gibt es hier solche 
überhaupt bzw. sind sie bzgl. Timingproblemen relevant?

[Dietrich L. (dietrichl)]

Klaus F. schrieb:
> 74Fxxx sind im Wert "typ" der Durchlaufverzögerung mimimal besser als
> "AC".

Bemerkung zu Formulierung "besser": damit meinst du wahrscheinlich 
"schneller".
Das kann aber für das Verhalten der Schaltung "schlechter" bedeuten, 
wenn dadurch  ein schnelleres Signal ein langsameres "überholt".

[(prx) A. K. (prx)]

Von den AC las ich einstmals, dass die Power-Transienten sich gut zum 
Test vom Layout-Skill eignen. AHC sei friedlicher. Einige Devices dieser 
Reihe hatte man eigens deshalb in Varianten mit zentralen 
Stromversorgungspins rausgebracht, weil die Ecken zu weit weg sind. 
Dürfte aber hauptsächlich Bustreiber & Co betreffen, weniger die hier 
eingesetzten Dekoder und Logik.

[Harald K. (kirnbichler)]

Klaus F. schrieb:
> 74Fxxx sind im Wert "typ" der Durchlaufverzögerung mimimal besser als
> "AC".

Man sollte hier aber nicht nur stumpf die Durchlaufverzögerung 
vergleichen, sondern auch die Pegel für Ein- und Ausgänge.

Am Beispiel des '138, beide von Fairchild

https://www.mouser.com/datasheet/2/149/74F138-90990.pdf
https://www.mouser.com/datasheet/2/308/74ACT138_D-2309969.pdf


Sehr deutlich ist der Unterschied der ausgegebenen High-Pegel, F liefert 
min 2.7 V, AC liefert min ca. 4.9 V (muss man aus den Werten für 4.5 und 
5.5 V extrapolieren*)

Aber auch bei den eingangsseitig erkannten High-Pegel gibt es heftige 
Abweichungen. F ist mit min 2 V spezifiziert, AC aber mit ca. 3.5 V.
Bei den eingangsseitigen Low-Pegeln siehts nicht anders aus:
F ist mit max 0.8 V spezifiziert, AC aber mit ca. 1.5 V.

Wenn man das statisch (bzw. mit niedriger Taktfrequenz) betreibt, dann 
ist der Unterschied nicht so irrwitzig kritisch, aber wenn man da mit 
etwas höheren Taktfrequenzen draufgeht, wirkt sich auch jede noch so 
banal erscheinende Schluderei beim Schaltungsdesign/Layout aus.


*) Nein, ich habe noch nicht so recht nachvollziehen können, warum "DC 
Electrical Characterstics" in CMOS-Datenblättern gerne mit diversen 
Versorgungsspannungen, nicht aber 5.0V angegeben werden

[Johannes S. (vamogu05)]

Dietrich L. schrieb:
> Die Taktfrequenz bestimmt ja "nur", wie oft pro Zeiteinheit die
> Signalabläufe abgearbeitet werden. Aber alle Vorgänge, die von einer
> Taktflanke ausgelöst werden, haben das gleiche Timing bezüglich
> Verzögerungs- und Laufzeiten bei den ICs und den Signalleitungen.
> Die Taktflanke ist ja bei unterschiedlichen Frequenzen gleich steil.

Ja, das leuchtet ein!

> Lediglich bei Signalabläufen, die mehrere Takte erfordern, ist die Zeit
> des gesamten Ablaufs frequenzabhängig. Aber gibt es hier solche
> überhaupt bzw. sind sie bzgl. Timingproblemen relevant?

Aber je höher der Takt, desto kürzer muss die Zugriffszeit des EPROMs 
bzw. RAMs sein. In meinem Fall ein Wunder, das sich das noch ausgeht.

Dietrich L. schrieb:
> Bemerkung zu Formulierung "besser": damit meinst du wahrscheinlich
> "schneller".
> Das kann aber für das Verhalten der Schaltung "schlechter" bedeuten,
> wenn dadurch  ein schnelleres Signal ein langsameres "überholt".

Wenn ich das Timing-Diagramm der W65C02 richtig verstehe, so sind die 
Adresssignale erst gültig nach tADS beginnend ab fallender Phi2-Flanke. 
Das sind immerhin max. 30ns bei 14MHz (lt. Datasheet). Dann bleibt nicht 
mehr viel Zeit um die Daten vom Speicher zu bekommen. Wenn die Daten 
dann bei der nächsten fallenden Flanke übernommen werden, könnten 
Speicher-Zugriffszeiten über 32ns problematisch sein. Oder wie 
funktioniert das genau?
Ebenso könnten zu schnelle Decoder Probleme verursachen. Sind meine 
Überlegungen richtig?
In meinem Fall wird tADS wahrscheinlich kürzer sein und die Zugriffszeit 
der Speicher auch, sonst geht sich das nie und nimmer aus. Mein System 
läuft jetzt stabil mit sogar 20MHz Phi2! Das sind eben nur max. 50ns 
Zyklusdauer.

Harald K. schrieb:
> Sehr deutlich ist der Unterschied der ausgegebenen High-Pegel, F liefert
> min 2.7 V, AC liefert min ca. 4.9 V (muss man aus den Werten für 4.5 und
> 5.5 V extrapolieren*)

Ok, schön langsam verstehe ich die Unterschiede der einzelnen Typen.
Habe AC-Teile bestellt, werde das Ganze mal damit testen. Danke für den 
Hinweis!

[Johannes S. (vamogu05)]

> Irgend W. schrieb:
>> Wenn es demnächst draußen etwas
>> Kälter wird, sind es dann A0, A3 oder sonstwas die Probleme machen.
>

Johannes S. schrieb:
> D.h. wenn ich die Platine mit Kältespray behandle müsste ein Fehler
> wieder auftreten. Das werde ich probieren sobald ich Kältespray habe.

Kältespray ist immer noch nicht da. Habe die Platine mal ins 
Tiefkühlfach gelegt für eine Stunde dann eingebaut und ausprobiert. 
Läuft einwandfrei!

[Jens G. (jensig)]

Johannes S. schrieb:
> Wenn ich das Timing-Diagramm der W65C02 richtig verstehe, so sind die
> Adresssignale erst gültig nach tADS beginnend ab fallender Phi2-Flanke.
> Das sind immerhin max. 30ns bei 14MHz (lt. Datasheet). Dann bleibt nicht
> mehr viel Zeit um die Daten vom Speicher zu bekommen. Wenn die Daten
> dann bei der nächsten fallenden Flanke übernommen werden, könnten
> Speicher-Zugriffszeiten über 32ns problematisch sein. Oder wie
> funktioniert das genau?

Ja, so ist das. Aber bei den Speichern werden die Verzögerungszeiten ja 
nur als max. Zeiten angegeben. Deutlich kürzer bzw. schneller dürfen die 
ja trotzdem sein. Kann also auch sein, daß der RAM statt 55ns "nur" 30ns 
schnell ist, und dann klappte es halt auch wieder.
Und wenn tADS nicht die 30ns auskostet, sondern nur 20ns, dann haben wir 
ja wieder 10ns gewonnen. Und deswegen kann dasdurchaus noch 
funktionieren - je nach individuellen Timing-Eingenschaften der 
einzelnen Exemplare.

> Ebenso könnten zu schnelle Decoder Probleme verursachen. Sind meine
> Überlegungen richtig?

Ich hatte mir die Timing-Diagramme von CPU, RAM, EPROM und deren 
Decoder-Gatter gestern abend mal genauer angeschaut. Zumindest dem RAM 
und EPROM ist es herzlich egal, ob die damit gebildeten CE-Signale etwas 
vor oder nach den restlichen Adresssignalen ankommen. Das letzte dieser 
Eingangssignale bildet sozusagen den Startschutz für die 
Speicherverzögerungszeit. Und damit kann eigentlich die Koordination 
dieser Signale untereinander gar nicht gestört werden, wenn wir mal von 
den normalen Toleranzen in den Gatterverzögerungszeiten ausgehen.
Auch die RW-Signalaufbereitung sieht diesbezüglich für R- und 
W-Operationen  sauber aus.
Eigentlich haben wir hier wirklich nur einen Einfluß der Taktfrequenz 
selbst, die stören könnte, wenn die Operationen der HL-Flanke durch zu 
hohe Frequenzen bzw. zu kurze Perioden-Zeiten in die der LH-Flanke 
reinreichen und anders herum. Also die Peripherie dann nicht mehr 
nachkommt. Aber einen störenden Effekt auch bei sehr gemächlicher Clock 
kann ich hier nicht nachvollziehen. Das Problem muß also woanders liegen 
- vielleicht ist das einfach nur eine Falschanzeige der LED-Treiber 
durch deren gestörtes Timing?

[G. O. (aminox86)]

Hallo

unter dem Wust von Beitraegen gibt es irgendwo den zarten Hinweis, dass 
das in der Schaltung eingesetzte Ram bzw Eprom dedizierte 
Ansteuersignale (/rd, /wr, /cs) benoetigen und nicht wie gezeichnet 
quasi im Standby-Modus verharren(/cs daueraktiv).

Die verwendeten Speicherbausteine sind fuer diese Betriebsart nicht 
vorgesehen, wie ich bei der Konstruktion meiner VGA-Karte feststellen 
musste, bei der die /CS-Pin der Eprom im ersten Entwurf ebenfalls mit 
GND verbunden waren. Im Betrieb traten beim Lesezugriff auf die Eprom 
Fehlersignale auf, die ich 'mal als "Glitch" bezeichnen moechte.
Die Bildschirmaufnahme zeigt dieses Phaenomen.
Interessanterweise scheint dieses Verhalten der Eprom 
herstellerabhaengig zu sein, bin dem aber nicht weiter nachgegangen. 
Cache-Ram zeigen in dieser Betriebsart(/cs an GND) dieses Verhalten 
uebrigens nicht. Meine Problemloesung war, ein Auffangregister fuer die 
gestoerten Daten vorzusehen.


Ich wuerde beim Neuentwurf des Schachcomputers die Steuersignale der 
Speicherbausteine wie vom Hersteller vorgesehen generieren. Um die ggf 
auftretenden Verzoegerugen wuerde mir keine Gedanken machen, denn 16MHz 
sind bei entsprechenden Layout gut zu beherrschen(kurze Verbindungen, 
breite Leiterbahnen bzw Flaechen fuer die Spannungsversorgung).


Meine damalige Loesung haenge ich 'mal an. Im Zip-Archiv des Beitrags 
gibt es die Datei "vga_a.gif". Links oben im Schaltungsteil 
"Ablaufsteuerung" ist sie eingezeichnet.
mfg

Beitrag "vga-karte, fast diskret"

[Jens G. (jensig)]

G. O. schrieb:
> ie verwendeten Speicherbausteine sind fuer diese Betriebsart nicht
> vorgesehen, wie ich bei der Konstruktion meiner VGA-Karte feststellen
> musste, bei der die /CS-Pin der Eprom im ersten Entwurf ebenfalls mit
> GND verbunden waren. Im Betrieb traten beim Lesezugriff auf die Eprom
> Fehlersignale auf, die ich 'mal als "Glitch" bezeichnen moechte.
> Die Bildschirmaufnahme zeigt dieses Phaenomen.

Das ist schon richtig, aber der Glitch passiert doch offenbar nur zu der 
Zeit des Anlegens der CE/OE oder auch Adresssignale. Zu diesem Zeitpunkt 
will aber keiner die Daten lesen, sondern erst später, wenn die Daten 
lt. Zeitrechnung dann auch wirklich als gültig betrachtet werden dürfen. 
Also mindestens 55ns (oder warens 50?) beim genannten RAM warten ...

[G. O. (aminox86)]

Das mit dem Glitch ist vielleicht etwas uebertrieben.

Nachdem ich in der Zwischenzeit Entwuerfe mit dem 6502 angesehen habe 
bin ich der Meinung, dass das Board in erster Linie mit Timing- und 
nicht mit Temperaturproblemen zu kaempfen hat denn: Der Takt Phi2 wird 
direkt vom Oszillator abgeleitet und nicht von der CPU wie in den 
einschlaegigen Schaltbildern zu sehen ist. Ich denke, es enstehen 
dadurch Laufzeitunterschiede, die offensichtlich nach laengerem Bestrieb 
verschwinden.

Diese Webseite geht ausfuehrlich auf den 6502 
ein:http://wilsonminesco.com/6502primer/

mfg

[Johannes S. (vamogu05)]

G. O. schrieb:
> Das mit dem Glitch ist vielleicht etwas uebertrieben.
>
> Nachdem ich in der Zwischenzeit Entwuerfe mit dem 6502 angesehen habe
> bin ich der Meinung, dass das Board in erster Linie mit Timing- und
> nicht mit Temperaturproblemen zu kaempfen hat denn: Der Takt Phi2 wird
> direkt vom Oszillator abgeleitet und nicht von der CPU wie in den
> einschlaegigen Schaltbildern zu sehen ist. Ich denke, es enstehen
> dadurch Laufzeitunterschiede, die offensichtlich nach laengerem Bestrieb
> verschwinden.
>
> Diese Webseite geht ausfuehrlich auf den 6502
> ein:http://wilsonminesco.com/6502primer/
>
> mfg

Das ist bei der modernen Variante von Western Design Center nicht der 
Fall. siehe Datenblatt Seite 10. 
https://www.westerndesigncenter.com/wdc/documentation/w65c02s.pdf

[(prx) A. K. (prx)]

G. O. schrieb:
> Der Takt Phi2 wird
> direkt vom Oszillator abgeleitet und nicht von der CPU wie in den
> einschlaegigen Schaltbildern zu sehen ist.

Da ist was dran. Es ist irreführend, die Takte gegenüber dem Original so 
umzubenennen, dass phi0 des Originals nun phi2 heißt, und phi2 nun 
phi2O. Wobei das andererseits logisch ist, weil sich das Timing des 
Originals und des WDC auf phi2 beziehen - das aber je nach exakten 
Prozessor verschiedene Pins sind!

[Wulf D. (holler)]

G. O. schrieb:
> Hallo
>
> unter dem Wust von Beitraegen gibt es irgendwo den zarten Hinweis, dass
> das in der Schaltung eingesetzte Ram bzw Eprom dedizierte
> Ansteuersignale (/rd, /wr, /cs) benoetigen und nicht wie gezeichnet
> quasi im Standby-Modus verharren(/cs daueraktiv).

Hast Du Dir das Schaltbild wirklich angesehen?

Kein /CE ist daueraktiv.

Außerdem wären RAM und EPROM voll statisch, woher nimmst du deine Infos?

[Joachim B. (jar)]

Joachim B. schrieb:
> mir fiel noch ein das es bei dynamischen Steinen auch um den PI 0 bzw PI
> 1 Takt geht der nach den stabilen Daten passend den Pegel wechseln muß.

(prx) A. K. schrieb:
> Da ist was dran. Es ist irreführend, die Takte gegenüber dem Original so
> umzubenennen, dass phi0 des Originals nun phi2 heißt

und ich wunderte mich schon warum ich pi0 und pi1 im Kopf hatte als ich 
am PET2001 erweiterte.
Die spinnen doch alte Bezeichnungen umzubenennen.

Joachim B. schrieb:
> ok, habe noch mal nachgesehen, die beiden von der CPU zur Abstimmung mit
> externe Bausteine hießen PI1 & PI2

ich bin also reingefallen

[Alexander M. (alexander_m366)]

Mal ganz vorne angefangen:

Ich habe den Eindruck, dass der Schaltplan gar nicht zum Layout passt!?

Beim Verfolgen der Taktleitungen Phi2O sehe ich im Board, dass die 
Leitung zu einem (nichtbestückten) U16 geht, im Schaltplan gibt es den 
nicht.

Das ist erstens nicht gut und zweitens verwirrend.

[(prx) A. K. (prx)]

AN-002 Replacement Notes.

https://www.westerndesigncenter.com/wdc/AN-002_W65C02S_Replacements.php

[(prx) A. K. (prx)]

Wulf D. schrieb:
> Kein /CE ist daueraktiv.

Im Schaltbild vom Startbeitrag ist in keinem /CE ein Takt drin, weshalb 
sie durchaus daueraktiv sein können. Nur ist das bei diesen rein 
statischen Speichern egal.

[Johannes S. (vamogu05)]

Alexander M. schrieb:
> Ich habe den Eindruck, dass der Schaltplan gar nicht zum Layout passt!?
>
> Beim Verfolgen der Taktleitungen Phi2O sehe ich im Board, dass die
> Leitung zu einem (nichtbestückten) U16 geht, im Schaltplan gibt es den
> nicht.

Ja, das stimmt. Ich habe den korrigierten Schaltplan gezeigt, da ich 
während der Herstellung der Platine darauf gekommen bin, dass meine 
Überlegungen nicht funktionieren können. Deshalb ist im Layout auch ein 
unbestückter Footprint zu sehen. Habe das aber w. o. geschrieben. Wollte 
niemand verwirren:-).

[Johannes S. (vamogu05)]

Johannes S. schrieb:
> Kältespray ist immer noch nicht da. Habe die Platine mal ins
> Tiefkühlfach gelegt für eine Stunde dann eingebaut und ausprobiert.
> Läuft einwandfrei!

Mittlerweile habe ich Kältespray erhalten und die ganze Platine damit 
abgekühlt. Wie erwartet kein Fehler oder Ausfall feststellbar!

Ich habe nun das 100ns EPROM der "Originalplatine" versucht statt den 
45ns EPROM das ich verbaut hatte und es funktioniert ebenso. Das heißt 
die Zugriffszeit dieses EPROMs muss doch deutlich kürzer sein als 
angegeben. Habe da noch den 20MHz Oszillator drinnen.

Egal, meine Platine funktioniert jetzt ebenso wie die "Originale", seit 
ich die beiden Kondensatoren parallel zu den Adressleitungen A1/A2 
gelötet habe. Warum das so ist, weiß ich leider nicht. Der Unterschied 
kann doch nur mehr am Layout liegen.

[Thomas W. (dbstw)]

Johannes S. schrieb:

> Mittlerweile habe ich Kältespray erhalten und die ganze Platine damit
> abgekühlt. Wie erwartet kein Fehler oder Ausfall feststellbar!

Dann ist doch gut.

> Ich habe nun das 100ns EPROM der "Originalplatine" versucht statt den
> 45ns EPROM das ich verbaut hatte und es funktioniert ebenso. Das heißt
> die Zugriffszeit dieses EPROMs muss doch deutlich kürzer sein als
> angegeben. Habe da noch den 20MHz Oszillator drinnen.

:-) Aber so eine richtige Erklaerung, warum das Ding auch bei 1MHz nicht 
so laeuft wie geplant haben wir nicht. Manchmal muss man einfach 
akzeptieren.

> Egal, meine Platine funktioniert jetzt ebenso wie die "Originale", seit
> ich die beiden Kondensatoren parallel zu den Adressleitungen A1/A2
> gelötet habe. Warum das so ist, weiß ich leider nicht. Der Unterschied
> kann doch nur mehr am Layout liegen.

Willst Du Dir wirklich die Muehe nochmal machen, denn jetzt hast Du zwei 
funktionsfaehige Geraete? Und vielleicht baust Du mit dem neuen Layout 
neue Fehler ein.

Ich hatte mal nach dem "Auto Response Board" gesucht: Schaltplaene sind 
wohl wirklich rar. Aber das Teil ist natuerlich schon schoen. Hast Du 
ungefaehr eine Hausnummer wie teuer das Ding damals war? Ich hatte 
Sargon II auf einem TRS-80 (ca. 1980, der Massenspeicher war ein 
Kassettenrekorder), mit 1.77MHz bei einer Z80-CPU. Mit 
Kloetzchen-Grafik.

Gruesse

Th.

[Johannes S. (vamogu05)]

Hallo Thomas,

Thomas W. schrieb:
> Willst Du Dir wirklich die Muehe mal machen, denn jetzt hast Du zwei
> funktionsfaehige Geraete? Und vielleicht baust Du mit dem neuen Layout
> neue Fehler ein.

Mir geht es auch darum dabei etwas zu lernen. Es bleibt aj nicht nur bei 
dem AutoResponse Board. Ich habe schon wieder ganz andere Projekte im 
Kopf :-)

Thomas W. schrieb:
> :-) Aber so eine richtige Erklaerung, warum das Ding auch bei 1MHz nicht
> so laeuft wie geplant haben wir nicht. Manchmal muss man einfach
> akzeptieren.

Ja, leider! Ich habe noch einige Platinen und könnte da noch etwas 
experimentieren. Mal sehen wie sich die AC-Gatter verhalten werden.

Thomas W. schrieb:
> Hast Du
> ungefaehr eine Hausnummer wie teuer das Ding damals war?

Ca. 1500.- Euro Einführungspreis 1980. Heute findet man eher selten 
ARBs um 400.- auf Ebay. Meistens in desolatem Zustand. Nach Restauration 
und mit min. 16MHz sind diese Schachcomputer deutlich teurer zu 
verkaufen.

Thomas W. schrieb:
> Ich hatte
> Sargon II auf einem TRS-80 (ca. 1980, der Massenspeicher war ein
> Kassettenrekorder), mit 1.77MHz bei einer Z80-CPU. Mit
> Kloetzchen-Grafik.

Ich kenne zwar den TRS-80 nur vom Hörensagen, kann mir aber diese 
Klötzchengrafik gut vorstellen. Ich hatte mir damals einen ZX81 Bausatz 
gekauft mit Speichererweiterung und das Schachprogramm dazu. Wenn ich 
mich richtig erinnere waren die Schachfiguren nur Buchstaben. Invertiert 
und nicht invertiert.

schöne Grüße

[Thomas W. (dbstw)]

Johannes S. schrieb:
> Thomas W. schrieb:
>> Hast Du
>> ungefaehr eine Hausnummer wie teuer das Ding damals war?
>
> Ca. 1500.- Euro Einführungspreis 1980. Heute findet man eher selten
> ARBs um 400.- auf Ebay. Meistens in desolatem Zustand. Nach Restauration
> und mit min. 16MHz sind diese Schachcomputer deutlich teurer zu
> verkaufen.

Der TRS-80 war (1980) ca. 2000DEM, mit 16KB RAM, Monitor und 
Kassenrecorder als Massenspeicher. Disketten waren bei ca. 700DEM pro 
Laufwerk "out of reach" als Schueler.

> Thomas W. schrieb:
>> Ich hatte
>> Sargon II auf einem TRS-80 (ca. 1980, der Massenspeicher war ein
>> Kassettenrekorder), mit 1.77MHz bei einer Z80-CPU. Mit
>> Kloetzchen-Grafik.
>
> Ich kenne zwar den TRS-80 nur vom Hörensagen, kann mir aber diese
> Klötzchengrafik gut vorstellen.

Wikipedia hilft:

https://de.wikipedia.org/wiki/Tandy_TRS-80_Model_1

[Wulf D. (holler)]

Johannes S. schrieb:
> Egal, meine Platine funktioniert jetzt ebenso wie die "Originale", seit
> ich die beiden Kondensatoren parallel zu den Adressleitungen A1/A2
> gelötet habe. Warum das so ist, weiß ich leider nicht. Der Unterschied
> kann doch nur mehr am Layout liegen.

Hallo Johannes,
schön dass die Platine auch mit Kältespray und sogar mit langsamen 
EPROMs läuft. Aber wohl nur mit den 10p auf den Adressleitungen. Das 
liegt mit einiger Wahrscheinlichkeit nicht am Layout. Das die 
„Originale“ funktioniert, könnte eben auch nur etwas Glück sein.

Wenn du etwas lernen willst, würde ich die Timings wie beschrieben mit 
dem Oszi kontrollieren. Du kannst das auch bei 1MHz Takt machen, an den 
Verhältnissen ändert sich nichts und dein Oszi arbeitet im 
Wohlfühlbereich.

Kannst die Messungen gern hier rein posten, sind ja etliche 
Interessierte im Thread.

Gruß Wulf

[Johannes S. (vamogu05)]

Wulf D. schrieb:
> Kannst die Messungen gern hier rein posten, sind ja etliche
> Interessierte im Thread.

Hallo Wulf,
mache ich gerne. Möchte das wirklich verstehen.
Anbei ein paar Messungen von A0, D0, CE und Phi2 im Vergleich zum 
WE-Signal. Alles mit 1MHz Taktfrequenz.
Passt das soweit?
Welche Oszillogramme wären noch interessant zu sehen?

[Axel R. (axlr)]

Kannst du keinen Logikanalyser am Rigol-Oszi einstecken? Ich hab da so 
ne schmale Buchse und nen grauen Stecker. Der kann 16Kanäle und alles 
mögliche darstellen. Sicher genau hierfür mal angedacht gewesen.

[Jens G. (jensig)]

Johannes S. schrieb:
> Welche Oszillogramme wären noch interessant zu sehen?

Also die WE-Rückflanken hätte ich gerne mal mit höherer zeitlicher 
Auflösung. Also 10 oder 25ns/div oder so ...

[Johannes S. (vamogu05)]

Axel R. schrieb:
> Kannst du keinen Logikanalyser am Rigol-Oszi einstecken? Ich hab da so
> ne schmale Buchse und nen grauen Stecker. Der kann 16Kanäle und alles
> mögliche darstellen. Sicher genau hierfür mal angedacht gewesen.

Nein, das hat mein Rigol 1052E nicht.
Ich überlege aber schon lange mir so einen Logikanalyzer zu kaufen. Ich 
denke 8 Kanäle würden doch reichen? Was wäre denn da empfehlenswert?

[Wulf D. (holler)]

Hallo zusammen,
die Screenshots sind fast perfekt, jedenfalls die mit 200ns Auflösung. 
Ein Logic-Analyser würde meiner Ansicht nach nicht viel helfen.

Eigentlich sieht man schon das Problem: in WE_A0 sieht man trotz zu 
geringer Auflösung, dass die Adressen gleichzeitig mit WE ändern. Das 
ist nicht gut.
Man muss dafür sorgen, dass WE unmittelbar mit PHI2 wechselt, da die 
Hold-Time der Adressen unabhängig vom Takt (!) nur 10ns beträgt.

Zur Zeit hast Du da zwei Gatterlaufzeiten drauf, die in die Gegend von 
10ns reichen und damit unsicher werden.

WE_D0 zeigt wie ein sicheres Timing aussieht, die Daten sind also nicht 
das Problem.

Melde mich nochmal mit einer Skizze um das besser zu erklären, ggf mit 
einem Verbesserungsvorschlag.

Gruß Wulf

[Axel R. (axlr)]

Gibt es hier für diesen 65C20(?) kein referenzdesign, wie für alles 
andere auch? Selbst in der RFE-Zeitung zu DDR-Zeiten waren sowohl die 
U880, als auch die einchip-Varianten ordentlich erklärt. Sowas muss es 
doch hier erst recht geben.
Daran würde ich mein Schaltplanentwurf ausrichten und nicht „Blind“(sry) 
irgendetwas nachbauen.

[Johannes S. (vamogu05)]

Jens G. schrieb:
> Johannes S. schrieb:
>> Welche Oszillogramme wären noch interessant zu sehen?
>
> Also die WE-Rückflanken hätte ich gerne mal mit höherer zeitlicher
> Auflösung. Also 10 oder 25ns/div oder so ...

Hi Jens,

anbei die gewünschten Bilder.

[Johannes S. (vamogu05)]

Axel R. schrieb:
> Daran würde ich mein Schaltplanentwurf ausrichten und nicht „Blind“(sry)
> irgendetwas nachbauen.

Naja, die Platine die mir vorliegt funktioniert ja seit Jahren 
einwandfrei. Außerdem wurde sie von jemandem entwickelt der mehr Ahnung 
von Elektronik hat als ich.

[Johannes S. (vamogu05)]

Wulf D. schrieb:
> Eigentlich sieht man schon das Problem: in WE_A0 sieht man trotz zu
> geringer Auflösung, dass die Adressen gleichzeitig mit WE ändern. Das
> ist nicht gut.
> Man muss dafür sorgen, dass WE unmittelbar mit PHI2 wechselt, da die
> Hold-Time der Adressen unabhängig vom Takt (!) nur 10ns beträgt.

Ja, das habe ich mir auch schon gedacht. Bei den Daten sieht das Timing 
vernünftig aus.

> Melde mich nochmal mit einer Skizze um das besser zu erklären, ggf mit
> einem Verbesserungsvorschlag.

Das ist super nett von dir. Danke für Deine Bemühungen!

[Wulf D. (holler)]

Habe ein Timing-Bild aus dem Netz geklaut und angepasst, das geht Dank 
Bildersuche schneller als alles selber malen :-)

Das Timing-Diagramm basiert auf dem "General Timing Diagram" des 
Datenblatts. Ist schon ziemlich minimalistisch. Wie auch immer, man 
sieht darin, dass die Adressen und R/W gleichzeitig wechseln, und zwar 
mit der fallenden Flanke von PHI2 plus einer Hold-Time von 10ns.

Genau das wird knapp. Im Bild Zeile MEM_WE (rot) sieht man die R/W Logik 
wie du sie umgesetzt hast. PHI2 muss sowohl das 7404 als auch das 7432 
durchlaufen, bevor die steigende Flanke r/W das RAM erreicht. Bis dahin 
könnten schon Adressen wechseln, da zwei Gatter mehr als 10ns Laufzeit 
haben können.

Im unteren Vorschlag MEM_WE (grün) mit einem 7404 plus 7400 sparst du im 
kritischen Pfad eine Gatterlaufzeit und bleibst unter der Hold-Time.

Käme auf einen Versuch an, dass mal auf deinem Prototyp umzusetzen.

Gruß Wulf

[Jens G. (jensig)]

Johannes S. schrieb:
> Hi Jens,
>
> anbei die gewünschten Bilder.

Doch nicht ein einzelnes Signal, sondern in Bezug auf das jeweils andere 
Signal im selben Screenshot. Was soll denn das sonst bringen ...

[Joachim B. (jar)]

Johannes S. schrieb:
> anbei die gewünschten Bilder.

sag mal willst du uns veräppeln?

immer zusammen mit /OE /CE /CS

deswegen sind 4-kanal Oszis sinnvoller

Jens G. schrieb:
> Doch nicht ein einzelnes Signal, sondern in Bezug auf das jeweils andere
> Signal im selben Screenshot.

+1

[Thomas W. (dbstw)]

Joachim B. schrieb:
> sag mal willst du uns veräppeln?
>
> immer zusammen mit /OE /CE /CS
>
> deswegen sind 4-kanal Oszis sinnvoller
>
Und wenn er keins hat? Aus der Rippe schneiden? Creatio ex nihilo?

Der Weg ueber /WE ist nicht so schlecht.

[Joachim B. (jar)]

Thomas W. schrieb:
> Joachim B. schrieb:
>> deswegen sind 4-kanal Oszis sinnvoller
> Und wenn er keins hat?

keine Arme keine Kekse!
Blind an Elektronik reparieren ist selbstgewähltes Schicksal.

[Wulf D. (holler)]

/OE ist sinnlos, da festgelegt. CE wird direkt aus den Adressen 
geschnitten. Also ist ein Bild in höchster Zeitauflösung zwischen 
Adressleitung und /WE sinnvoll.

Eines zwischen A0-WE liegt in 500ns vor.

Eines mit A1 /WE mit abgelöteten 10pF Cs in höchster Zeitauflösung wäre 
noch interessant.

Nehme an, dass bestätigt meine Skizze oben.
Gruß Wulf

[Klaus F. (klaus27f)]

Wulf D. schrieb:
> Eines mit A1 /WE mit abgelöteten 10pF Cs in höchster Zeitauflösung wäre
> noch interessant.

Hallo liebe Leute,
das alles was ihr schreibt und vorschlagt, das haben wir schon vor Tagen 
durchgekaut.
Der TE hat ein 2-Kanal-Scope mit 50 MHz.
Die fraglichen Signale A1 und A2 "verbessern" sich, wenn man dort einen 
10 pF anbringt.

Jetzt FRAGE an euch neue Spezialisten:
Welchen Tastkopf mit "negativer Eingangskapaziät" soll er denn 
anschließen??

Und ja: Warum sind diese (beiden) Adressen, die nur aus der CPU kommen, 
so grottenschlecht bzw. zu kurz anstehzend.

Der TE meint, das Problem mit einem besseren Layout in Griff zu kriegen.

Noch niemand hat ihm geraten, die (niedrigen?) ADRESSEN zu RAM und EPROM 
mit einem  --> transparent Latch <-- festzuhalten bzw. zu verlängern 
(jedoch NICHT die -hohen- Adressen die zum Adreßdecoder führen.
Nein, ich habe dieses Details bisher auch nicht geschrieben, weil ich 
kein 6502 Spezialist bin und daher nicht weiss, welches Steuersignal 
dann für das Latch das richtig wäre.
Man sollte halt das Datenblatt des VERBAUTEN uP genau kennen.
Ich habe keine Muse mich in 6502 reinzulesen (da Z80 sowieso besser 
ist).

Ein neues Layout und konsequenter Einsatz von Cmos "AC" ist bei TE 
sowieso geplant. Unbedingt sinnvoll ist eine verbesserte Decodierung 
bzw.  Erzeugung der Signale /WE und /OE für Ram und Eprom.

[Johannes S. (vamogu05)]

Jens G. schrieb:
> Doch nicht ein einzelnes Signal, sondern in Bezug auf das jeweils andere
> Signal im selben Screenshot. Was soll denn das sonst bringen ...

Sorry, ich dachte du möchtest nur die Flankensteilheit von WE 
beurteilen.
Anbei die Bilder.

[Johannes S. (vamogu05)]

Wulf D. schrieb:
> Eines mit A1 /WE mit abgelöteten 10pF Cs in höchster Zeitauflösung wäre
> noch interessant.

Anbei das Bild. der 10pF Kondensator wurde von A1 entfernt.

[Wulf D. (holler)]

Klaus F. schrieb:
> Ich habe keine Muse mich in 6502 reinzulesen (da Z80 sowieso besser
> ist).

Dann lass es doch und schreib nicht so einen Quark. „Negative Kapazität“ 
etc.

Im Gegensatz zu dir kenne ich das CPU Datenblatt und der prinzipielle 
Timingfehler ist gefunden. Einfach mal lesen und verstehen.

Es geht nur noch um die Verifikation.

[Johannes S. (vamogu05)]

Klaus F. schrieb:
> Ein neues Layout und konsequenter Einsatz von Cmos "AC" ist bei TE
> sowieso geplant. Unbedingt sinnvoll ist eine verbesserte Decodierung
> bzw.  Erzeugung der Signale /WE und /OE für Ram und Eprom.

Ja, ist im neuen Schaltplan bereits umgesetzt. Warte aber noch mit dem 
Routen der Platine, bis alles soweit geklärt ist. Die AC-Teile dürften 
Anfang nächster Woche kommen.

[Johannes S. (vamogu05)]

Wulf D. schrieb:
> Im unteren Vorschlag MEM_WE (grün) mit einem 7404 plus 7400 sparst du im
> kritischen Pfad eine Gatterlaufzeit und bleibst unter der Hold-Time.
>
> Käme auf einen Versuch an, dass mal auf deinem Prototyp umzusetzen.

Danke Wulf, für diesen Vorschlag. Ich kann das gerne mal versuchen 
umzubauen. Muss mir aber erst die AS-Teile besorgen, die habe ich 
nämlich nicht hier.

[Klaus F. (klaus27f)]

Johannes S. schrieb:
> Anbei die Bilder.

Lieber Johannes,
du hast die falsche Flanke der Signale!
Was interessiert ist die low-nach-high Position.
Eben wenn das aktive Signal verschwindet, ob und wie lange an dieser 
Stelle noch die Adresse ansteht.

Allerdings ist es schwierig das mit deinem Scope zu erfassen, weil ein 
Tastkopf auch so um 10 pF oder mehr hat. Wie ich bereits mehrfach 
schrieb.
Aber manche halten meine Ausführungen für unlustig.

[Wulf D. (holler)]

Johannes S. schrieb:
> Wulf D. schrieb:
>> Eines mit A1 /WE mit abgelöteten 10pF Cs in höchster Zeitauflösung wäre
>> noch interessant.
>
> Anbei das Bild. der 10pF Kondensator wurde von A1 entfernt.

Die beiden Flanken kommen praktisch gleichzeitig, was gerade noch so 
zulässig wäre. Die write-recovery-time, steigende Flanke WE# zu 
Adresswechsel vom RAM, ist 0ns.

In dem Fall würde der Schreibvorgang funktionieren. Ist die Frage ob das 
bei jedem Schreibvorgang so ist oder ob es doch einzelne Ausreißer gibt. 
Oder ob die paar pF vom Oszi-Tastkopf etwas verzögern, allerdings träfe 
das genauso auf das WE# Signal zu.

Wenn du sicher gehen willst, dass dein Design im nächsten Layout ohne 
die 10pF Testkrücke sicher funktioniert, würde ich die optimierte 
R/W-Logik mal ausprobieren. Auch wenn du noch keine AS- oder AC-Chips 
hast. Ein NAND sollte doch in jeder Logiksammlung vorhanden sein :-)

Gruß Wulf

[Rick (rick)]

Johannes S. schrieb:
> Welche Oszillogramme wären noch interessant zu sehen?
Das Rigol hat bestimmt eine Memoryfunktion. Damit kann man sich z.B. die 
Kurve mit /WE und A1 (ohne Zusatz-C) abspeichern und danach das Ganze 
nochmal mit Zusatz-C aufnehmen.
Den Trigger jeweils auf die Flanke vom /WE, wobei ich die fallende 
Flanke spannender finde.

[Wulf D. (holler)]

Rick schrieb:
> Den Trigger jeweils auf die Flanke vom /WE, wobei ich die fallende
> Flanke spannender finde.

Warum fallende Flanke? Die Setup - Zeiten sind doch alle tief im grünen 
Bereich.

Die Hold-Zeit der Adressen beim /WE steigende Flanke am RAM sieht 
megakritisch aus, oder habe ich was übersehen?

Gruß Wulf

[Rick (rick)]

Wulf D. schrieb:
> Warum fallende Flanke? Die Setup - Zeiten sind doch alle tief im grünen
> Bereich.
Ich erwarte, das die Adressen vor der fallenden /WE-Flanke stabil 
anliegen. Das sah mir bei  "CE_A0_tst.jpg" (warum eigentlich jpg? -> 
Siehe Bildformate) nicht so aus. Ja, dort ist es CE, aber die Flanken 
sind mir zu nah beieinander.

[Axel R. (axlr)]

Rick schrieb:
> Johannes S. schrieb:
>> Welche Oszillogramme wären noch interessant zu sehen?
> Das Rigol hat bestimmt eine Memoryfunktion. Damit kann man sich z.B. die
> Kurve mit /WE und A1 (ohne Zusatz-C) abspeichern und danach das Ganze
> nochmal mit Zusatz-C aufnehmen.
> Den Trigger jeweils auf die Flanke vom /WE, wobei ich die fallende
> Flanke spannender finde.

Es gibt den Knopf „Referenz“ da bleibt das als weißer Kurvenzug stehen.

[Johannes S. (vamogu05)]

Wulf D. schrieb:
> Wenn du sicher gehen willst, dass dein Design im nächsten Layout ohne
> die 10pF Testkrücke sicher funktioniert, würde ich die optimierte
> R/W-Logik mal ausprobieren. Auch wenn du noch keine AS- oder AC-Chips
> hast. Ein NAND sollte doch in jeder Logiksammlung vorhanden sein :-)

Anbei zwei neue Oszillogramme nach dem Umbau wie von Wulf beschrieben.
Gelb ist wieder WE, blau ist A1 (ohne C). Zwei verschiedene Ansichten.
Ich denke, dass das LS-Gatter zu langsam ist.
Mit 16MHz läuft die Platine nun nicht mehr, mit 1MHz höre ich noch den 
Einschaltton.

[Harald K. (kirnbichler)]

Rick schrieb:
> (warum eigentlich jpg? -> Siehe Bildformate)

"Bildformate" gehört zu einem der Themenkreise, die die wenigsten Nutzer 
dieses Forums verstehen.
Das ist höhere Mathematik, ein Buch mit sieben Siegeln, Dantes Kreise 
der Hölle oder der Versuch, bei einem Bürgeramt in Berlin einen Termin 
zu bekommen.

[Joachim B. (jar)]

Johannes S. schrieb:
> Anbei zwei neue Oszillogramme nach dem Umbau wie von Wulf beschrieben

verdammt noch mal, warum schiebst du die Nulllinien nicht aufeinander, 
dann siehst du wo die Pegel landen und ob einer zu früh oder zu spät im 
gewünschten Bereich ist der Datenblatt high und low Pegel Grenzen.

Oszilloskop nutzt wenig wer nicht mit umgehen kann.

[(prx) A. K. (prx)]

Der Versuch, mit diesem Scope Timings von 5-10ns sauber dargestellt zu 
bekommen, tendiert in Richtung Kaffeesatzlesen, wenn dann noch die 
Bilder nahelegen, dass nicht die maximal mögliche Samplerate am Werk 
ist, sondern nur ein Bruchteil davon.

Beim ollen 1 MHz 6502 und zeitgenössischen Speichern und Logikbausteinen 
ging es in jeder Hinsicht gemächlicher zu. Beim viel schnelleren WDC und 
Cache-RAMs sowie später 74AC kommt man an Grenzen.

[(prx) A. K. (prx)]

Johannes S. schrieb:
> Anbei zwei neue Oszillogramme

Bissel was zum Scope: Wenn du einen langen Zeitraum sampelst und dort 
extrem reinzoomst, dann ist das wie bei einer Digicam, bei der du so 
weit reinzoomst, bis nur noch Pixelmatsch zu sehen ist.

Diese Bilder zeigen oben am Rand, dass es sich um einen winzigen 
Ausschnitt aus einer langen Aufzeichnung handelt. Die gezeigten 
Datenpunkte scheinen im Abstand der 200ns des Bildrasters zu liegen. 
Dass das kein Spitzenscope ist, ist klar. Aber das geht auch mit diesem 
Gerät sehr viel besser.

Das Datasheet vom Scope sagt 1 GS/s, also vmtl 2ns Sampleraster bei 2 
Kanälen. Die 50 MHz Bandbreite werden das zwar deutlich flachbügeln, 
aber das ist dann immer noch weit aussagekräftiger, als diese völlig 
nutzlosen Bilder. Erst dann lassen sich Zeitabstände im hier relevanten 
Bereich überhaupt erahnen.

[Wastl (hartundweichware)]

(prx) A. K. schrieb:
> Aber das geht auch mit diesem Gerät sehr viel besser.

Ja, aber:
Die Kunst wird wohl sein auf das richtige Ereignis zu triggern.

[Wulf D. (holler)]

Ja, auf den WE_A1_N0.PNG sieht man nicht viel, das Scope scheint nur mit 
50MHz / Kanal abzutasten. Die Flanke erstreckt sich über 200ns, das wird 
real so nicht sein.

Aber wir haben hier schon höher aufgelöste Screenshots gesehen, 
prinzipiell kann das Scope mehr. Also Scope mal so einsetzen wie A.K. 
vorschlägt.

Stimme zu, dass die LS-Gatter zu langsam sind. Da hat eines auch nicht 
weniger Delay als zwei F-Gatter.


Rick schrieb:
> Wulf D. schrieb:
>> Warum fallende Flanke? Die Setup - Zeiten sind doch alle tief im grünen
>> Bereich.
> Ich erwarte, das die Adressen vor der fallenden /WE-Flanke stabil
> anliegen. Das sah mir bei  "CE_A0_tst.jpg" (warum eigentlich jpg? ->
> Siehe Bildformate) nicht so aus. Ja, dort ist es CE, aber die Flanken
> sind mir zu nah beieinander.

Die Adress-Setup-Time t-AS ist laut Datenblatt 0ns. Die t-AW (Address 
Valid to End of Write) ist 50ns und wird locker eingehalten.

Gruß Wulf

[(prx) A. K. (prx)]

Wastl schrieb:
> Die Kunst wird wohl sein auf das richtige Ereignis zu triggern.

Eigentlich nicht. Wenn du eine Zeitdifferenz zwischen A0 und WE sehen 
willst, dann triggerst du auf WE und kriegst mal die eine und mal die 
andere Flanke von A0 mit rein, und auch mal keine. Da kann man dann 
hinsichtlich Zeitauflösung in die Vollen gehen, das sollte ziemlich gut 
wiederholbar sein.

Perfekt wird es, wenn man viele solche Zyklen überlagert, und dabei ein 
hübsches Eye Diagram rauskommt. Das ist nämlich für genau so eine 
Analyse da. Mein 20 Jahre altes Rigol kann das jedenfalls.
https://resources.altium.com/de/p/what-eye-diagram

[Johannes S. (vamogu05)]

Joachim B. schrieb:
> verdammt noch mal, warum schiebst du die Nulllinien nicht aufeinander,
> dann siehst du wo die Pegel landen und ob einer zu früh oder zu spät im
> gewünschten Bereich ist der Datenblatt high und low Pegel Grenzen.

Ok, mache ich ab nun. Nur mit der Ruhe, das kann man auch ganz sachlich 
mitteilen!

> Oszilloskop nutzt wenig wer nicht mit umgehen kann.

Ja, das hast Du ganz richtig erkannt. Ich habe das Oszilloskop noch 
nicht so oft benutzt und daher sehr wenig Erfahrung damit. Aber ich bin 
für jede Hilfe dankbar.

(prx) A. K. schrieb:
> Bissel was zum Scope: Wenn du einen langen Zeitraum sampelst und dort
> extrem reinzoomst, dann ist das wie bei einer Digicam, bei der du so
> weit reinzoomst, bis nur noch Pixelmatsch zu sehen ist.

Ja, danke für die Erklärung. War heute vormittags in Zeitnot. Wollte 
noch schnell Bilder reinstellen. Habe ich darauf gar nicht geachtet.

> Diese Bilder zeigen oben am Rand, dass es sich um einen winzigen
> Ausschnitt aus einer langen Aufzeichnung handelt. Die gezeigten
> Datenpunkte scheinen im Abstand der 200ns des Bildrasters zu liegen.
> Dass das kein Spitzenscope ist, ist klar. Aber das geht auch mit diesem
> Gerät sehr viel besser.

Sieh' dir mal die neuen Bilder an. Ich denke, die müssten jetzt besser 
aufgelöst sein.

> Das Datasheet vom Scope sagt 1 GS/s, also vmtl 2ns Sampleraster bei 2
> Kanälen. Die 50 MHz Bandbreite werden das zwar deutlich flachbügeln,
> aber das ist dann immer noch weit aussagekräftiger, als diese völlig
> nutzlosen Bilder. Erst dann lassen sich Zeitabstände im hier relevanten
> Bereich überhaupt erahnen.
Ja, Danke.

Wulf D. schrieb:
> Aber wir haben hier schon höher aufgelöste Screenshots gesehen,
> prinzipiell kann das Scope mehr. Also Scope mal so einsetzen wie A.K.
> vorschlägt.

Hi Wulf,

sind die neuen Bilder jetzt besser? Ich denke schon.

(prx) A. K. schrieb:
> Perfekt wird es, wenn man viele solche Zyklen überlagert, und dabei ein
> hübsches Eye Diagram rauskommt. Das ist nämlich für genau so eine
> Analyse da. Mein 20 Jahre altes Rigol kann das jedenfalls.
> https://resources.altium.com/de/p/what-eye-diagram

Ob das mein Rigol kann werde ich heute noch nachlesen. Wie bereits 
erwähnt, habe ich noch nicht viel damit gemessen, also kaum Erfahrung 
damit.

[H. H. (Gast)]

Johannes S. schrieb:
> Sieh' dir mal die neuen Bilder an. Ich denke, die müssten jetzt besser
> aufgelöst sein.

Nein.

[Wulf D. (holler)]

Das WE_A1_N2 ist klar besser aufgelöst, da glaube ich die 1Gs 
Abtastrate.

 Ich denke du solltest vor allem den Tastkopf vom blauen Kanal mal 
abgleichen: meist gibt es am Oszi einen Rechteckgenerator wo man den 
Tastkopf mit beiden Kontakten anschließt. Mit einem kleinen 
Schraubendreher auf saubere Flanken abgleichen.

Ich denke man kann auch schon so sagen, dass das Timing superkritisch 
ist. Die WE-Flanke sollte stabil ein paar Nanosekunden vor dem 
Adresswechsel kommen. Das ist hier nicht der Fall.

Gruß Wulf

[(prx) A. K. (prx)]

Als Beispiel für eine Scope-Messung in diesem Zeitrahmen ein ~10 MHz 
Takt am Ausgang eines ATtiny45 und hinter einem 74AC00 (invertiert 
dargestellt). Lochrasteraufbau mit suboptimalen Probes. Es ging mir um 
die Zeitauflösung, nicht um Signalqualität und Probes.

Rigol DS1102CD, 100 MHz Bandbreite, 400 MS/s, aber aufgezeichnet im 
Equivalent Time Mode, was die effektive Sample Rate gegenüber den 200 
MS/s pro Kanal wesentlich erhöht. Den hat das Rigol 1052E auch.

Mit einem 50 MHz 1 GS/s Scope werden die Flanken etwas flacher sein, 
aber eine halbwegs brauchbare Messung sollte möglich sein.

[Volker B. (Firma: L-E-A) (vobs)]

Johannes S. schrieb:

> Anbei ein paar Messungen von A0, D0, CE und Phi2 im Vergleich zum
> WE-Signal. Alles mit 1MHz Taktfrequenz.
> Passt das soweit?

Also ich sehe da einen (potentiellen) Buskonflikt beim Schreibzyklus.
Die CPU legt Zieladresse und Datenbyte auf den Bus. Kurze Zeit später 
wird /CS das RAMs aktiv. Dieses wird dann das adressierte Byte auf den 
Datenbus legen, denn sein /OE ist ja dauerhaft aktiv. Mit der steigenden 
Flanke von Phi2 wird dann /WR des RAMs aktiv und dieses schaltet nun auf 
Schreibzugriff um und liest das Datenbyte vom Bus.

Das funktioniert bei Deinem Oszillogramm wunderbar, denn das zu 
schreibende Bit D0 ist identisch mit dem, das bereits im RAM steht. Ist 
das nicht der Fall, arbeiten die Datenbustreiber von RAM und CPU 
gegeneinander. Also ich würde solche ungesunden Zustände vermeiden, auch 
wenn sie nur kurze Zeit auftreten...

Grüßle,
Volker

[(prx) A. K. (prx)]

Volker B. schrieb:
> Also ich sehe da einen (potentiellen) Buskonflikt beim Schreibzyklus.

Wurde längst besprochen.

[Johannes S. (vamogu05)]

Wulf D. schrieb:
> Ich denke du solltest vor allem den Tastkopf vom blauen Kanal mal
> abgleichen: meist gibt es am Oszi einen Rechteckgenerator wo man den
> Tastkopf mit beiden Kontakten anschließt. Mit einem kleinen
> Schraubendreher auf saubere Flanken abgleichen.

schönen Abend Wulf,

ich habe den Abgleich kontrolliert, war in Ordnung.

> Ich denke man kann auch schon so sagen, dass das Timing superkritisch
> ist. Die WE-Flanke sollte stabil ein paar Nanosekunden vor dem
> Adresswechsel kommen. Das ist hier nicht der Fall.

Das sollte aber dann, wenn ich OE nicht mehr direkt an GND lege, behoben 
sein.
Werde das dann so lösen wie w.o. beschrieben.

(prx) A. K. schrieb:
> Rigol DS1102CD, 100 MHz Bandbreite, 400 MS/s, aber aufgezeichnet im
> Equivalent Time Mode, was die effektive Sample Rate gegenüber den 200
> MS/s pro Kanal wesentlich erhöht. Den hat das Rigol 1052E auch.

Danke für den Hinweis, werde ich mal nachlesen und ausprobieren.

[(prx) A. K. (prx)]

Johannes S. schrieb:
> Danke für den Hinweis, werde ich mal nachlesen und ausprobieren.

Aber kontrolliere bei Realtime (non-EQT) Messungen, mit welcher 
Sample-Rate du bei der Messung arbeitest. Wird ja irgendwo angezeigt. Du 
bist da viel besser ausgestattet als ich, kommst auch ohne EQT über die 
Runden.

[HaraldS K. (kuske)]

Moment,
1 MHz <=> 1000 ns Taktzyklus (high und low)
2 Mhz <=> 500 ns
4 Mhz <=> 250 ns
8 MHz <=> 125 ns
16 MHz <=> 62 ns
Wenn das RAM eine Zugriffszeit von 100 ns oder auch 45 ns hat, dann 
reichen 31 ns nicht aus um es zu lesen. Oder?

[Harald K. (kirnbichler)]

Harald K. schrieb:
> Wenn das RAM eine Zugriffszeit von 100 ns oder auch 45 ns hat, dann
> reichen 31 ns nicht aus um es zu lesen. Oder?

Richtig, zumal weniger als ein kompletter Taktzyklus zur Verfügung 
steht, wie schon vor zig Beiträgen in diesem Thread mit Verweisen auf 
Datenblättern und Timingdiagrammen erwähnt wurde.

Nur: So ein RAM hält sich gemeinerweise nicht an die spezifizierte 
Zugriffszeit, sondern ist i.d.R. schneller. Nur halt nicht garantiert 
über die im Datenblatt beschriebenen Umgebungsbedingungen (Temperatur, 
Stabilität der Versorgungsspannung, Sauberkeit der Signalpegel etc. 
pp.).

Nur deswegen funktioniert diese Overcklocking-Kiste hier überhaupt 
irgendwie. Sauberes, stabiles und zuverlässiges Schaltungsdesign nutzt 
kein Overclocking, sondern hält sich an das, was im Datenblatt steht. 
Dann braucht es auch keine kleinen Kondensatoren an irgendwelchen 
Adressleitungen ...

[Johannes S. (vamogu05)]

Harald K. schrieb:
> Nur deswegen funktioniert diese Overcklocking-Kiste hier überhaupt
> irgendwie. Sauberes, stabiles und zuverlässiges Schaltungsdesign nutzt
> kein Overclocking, sondern hält sich an das, was im Datenblatt steht.
> Dann braucht es auch keine kleinen Kondensatoren an irgendwelchen
> Adressleitungen ...

Diese Platinen (mit den Kondensatoren an A1/A2) laufen mittlerweile auch 
mit 20MHz einwandfrei! Also dürfte 16MHz keineswegs overclocked sein. 
Ja, sicher, knapp ist es schon aber das RAM hat wahrscheinlich eine 
deutlich geringere Zugriffszeit als die angegebenen 55ns.
Zwischenzeitlich habe ich das Design etwas geändert. Fehler der ersten 
Version behoben (offene Eingänge), dickere Signalleitungen geroutet. 
Diese Platine funktioniert sofort ohne irgendwelche nachträglichen 
Kondensatoren an den Adressleitungen. Ich vermute, dass bei Verwendung 
eines schnelleren RAMs auch noch 24MHz möglich sind. Werde ich noch 
ausprobieren.

[Thomas W. (dbstw)]

Johannes S. schrieb:

> Diese Platinen (mit den Kondensatoren an A1/A2) laufen mittlerweile auch
> mit 20MHz einwandfrei! Also dürfte 16MHz keineswegs overclocked sein.

Das ist ja gut, zumindest eine Loesung. Hattest Du noch den Schaltplan 
ueberarbeitet (ausser die Phi2 - R/W - Schaltung)?

Hast Du noch Lust, Dein Ergebnis hier zu zeigen (Layout, Photos)?

> Ja, sicher, knapp ist es schon aber das RAM hat wahrscheinlich eine
> deutlich geringere Zugriffszeit als die angegebenen 55ns.

Die 55ns sind halt im gesamten Temperatur-, Spannung- und was auch immer 
gewaehrleistet. Overclocking kann klappen, oder auch nicht.

> Zwischenzeitlich habe ich das Design etwas geändert. Fehler der ersten
> Version behoben (offene Eingänge), dickere Signalleitungen geroutet.

Offensichtlich war Dein Design sehr sehr knapp. Haette nicht gedacht.

Nun ja: Man lernt jeden Tag was neues.

Gruesse

Th.

[Thomas W. (dbstw)]

Johannes S. schrieb:
> Ich vermute, dass bei Verwendung
> eines schnelleren RAMs auch noch 24MHz möglich sind. Werde ich noch
> ausprobieren.

Der bessere Weg waere den Algorithmus von Sargon zu verbessern. Kleiner 
Scherz. Fuer die Zeit (ca. 1980) war Sargon schon sehr gut.

Gruesse

Th.

[Wastl (hartundweichware)]

Johannes S. schrieb:
> Ich vermute, dass bei Verwendung
> eines schnelleren RAMs auch noch 24MHz möglich sind. Werde ich noch
> ausprobieren.

1 MHz ---> 16 MHz ---> Geschwindigkeitsfaktor 16
16 MHz ---> 24 MHz ---> Geschwindigkeitsfaktor 1.5

[Klaus S. (kseege)]

In allen Datenblättern von Eproms, die ich in meinem Leben vebaut habe, 
war tce größer als toe, weswegen auch in den Datenblättern immer erst 
/CE aktiv wird und dann /OE. Gibt es irgendeinen vernünftig 
nachvollziehbaren Grund, warum hier die Reihenfolge umgedreht wird? Ein 
EPROM ständig mit /CS=0 zu betreiben und /OE zu schalten funktioniert 
ebenfalls (btdt) und ist schneller. Das Umverdrahten der beiden Signale 
ist ein 10-Minuten-Test.

Just my 2 cents

[Johannes S. (vamogu05)]

Thomas W. schrieb:
> Das ist ja gut, zumindest eine Loesung. Hattest Du noch den Schaltplan
> ueberarbeitet (ausser die Phi2 - R/W - Schaltung)?

Hallo Thomas,

die R/W Schaltung ist die gleiche wie ursprünglich. Erst in Version 3 
habe ich das anders gemacht. Da ist dann OE nicht mehr direkt mit Gnd 
verbunden, sondern wird über Phi2 und CPU_RW gebildet.

> Hast Du noch Lust, Dein Ergebnis hier zu zeigen (Layout, Photos)?

Anbei die Bilder des neuen Layouts. Ist sicher nicht optimal geroutet, 
funktioniert aber tadellos.

> Overclocking kann klappen, oder auch nicht.

Wie bereits erwähnt, halte ich 16MHz für geringes Overclocking bei 
dieser CPU. Im Datenblatt der CPU ist keine maximale Frequenz angegeben. 
Vielleicht habe ich das auch nur überlesen.

> Offensichtlich war Dein Design sehr sehr knapp. Haette nicht gedacht.
Naja, die Zugriffszeit des SRAM ist halt relativ lange. Bin gespannt wie 
es mit den schnelleren Speichern aussieht. Vermute, dass dann sogar 
24MHz noch funktionieren könnten. Mal sehen.

> Nun ja: Man lernt jeden Tag was neues.
Ja, um das geht es mir auch dabei. Habe hier viele gute Tipps bekommen. 
Danke an Alle die geholfen haben.

> Der bessere Weg waere den Algorithmus von Sargon zu verbessern. Kleiner
> Scherz. Fuer die Zeit (ca. 1980) war Sargon schon sehr gut.

Ja, um das geht es letztendlich. Das Programm insgesamt etwas zu 
verbessern. In diesem Fall mit einem größeren Eröffnungsbuch und tiefere 
Zugsuche.

Klaus S. schrieb:
> Gibt es irgendeinen vernünftig
> nachvollziehbaren Grund, warum hier die Reihenfolge umgedreht wird?

Ich habe das von einer bestehenden Platine so abgeschaut, weil ich diese 
nachbauen mochte. Diese Platine funktioniert einwandfrei, nutzt aber den 
ROM-Bereich von $2000 - $3FFF nicht. Den brauchte ich aber um ein großes 
Eröffnungsbuch ins Rom zu bringen.

Klaus S. schrieb:
> Ein
> EPROM ständig mit /CS=0 zu betreiben und /OE zu schalten funktioniert
> ebenfalls (btdt) und ist schneller. Das Umverdrahten der beiden Signale
> ist ein 10-Minuten-Test.

Diese Möglichkeit hatte ich nie in Betracht gezogen. Aber ja, könnte 
klappen. Leider ist der Umbau nicht so ohne weiteres möglich. Da OE fix 
mit der GND-Plane verbunden ist. Da müsste ich ringförmig das Cu 
wegbekommen. Ist mir zu aufwendig. Trotzdem Danke für den Tipp.

[Wastl (hartundweichware)]

Johannes S. schrieb:
> Da müsste ich ringförmig das Cu
> wegbekommen. Ist mir zu aufwendig.

Potentielle Macken entdecken und ggf. ausmerzen zu aufwendig?

Wenn man IC Sockel hat kann man einen einzelnen Pin eines ICs
herausbiegen und aus dem Sockel hängen lassen .....

[Wulf D. (holler)]

Harald K. schrieb:
> Harald K. schrieb:
>> Wenn das RAM eine Zugriffszeit von 100 ns oder auch 45 ns hat, dann
>> reichen 31 ns nicht aus um es zu lesen. Oder?

Wie kommst du denn auf 31ns? Einfach die 1/Taktfrequenz /2?
Nein, so einfach ist das nicht, ein Blick ins Datenblatt hilft.
Gruß Wulf

[Johannes S. (vamogu05)]

Wastl schrieb:
> Potentielle Macken entdecken und ggf. ausmerzen zu aufwendig?

Nein, nicht unbedingt. Ich kann nur nicht jedem Tipp sofort folgen. Ich 
muss das systematisch angehen. Ich warte jetzt auf die Platinen bei 
denen OE aus Phi2 und CPU_RW gewonnen wird. CE nach wie vor aus den 
Adressen. So wird das angeblich professionell gemacht. Ich denke, dass 
ich dann eine optimale Schaltung habe.
Den umgekehrten Weg, CE an Gnd und OE aus den Adressen, sah ich noch 
nirgends im Internet. Sollte aber auch funktionieren. Werde ich 
demnächst doch mal testen.

[Klaus F. (klaus27f)]

Johannes S. schrieb:
> CE an Gnd und OE aus den Adressen

Du redest hier wohl vom Eprom?
Denn am Ram müsstest du ja dann /WR mit der Ramadresse verwursten.
Das ist alles Quark, denn du weisst ja gar nicht genau ob dein A1 A2 
Effekt vom Eprom oder Ram kommt, bei Ram von lesen oder schreiben oder 
beides.
Und aufgrund der Übertaktung ausserhalb Spec. wahrscheinlich auch 
abhängig von zufälligen "schneller als Spec." der konktet eingebauten 
Bauteile, bei deiner zufälligen Zimmertemperatur.
Freu dich einfach wenn eine bestimmte Platine mit dem Takt xx MHz läuft 
und gut.
Demnächst kannst du die neue Variante mit verbesserter Schaltung testen, 
die -vielleich- noch höher taktbar ist.
Aber das wird so immer für jede Platine und jede Bauteilcharge was 
grenzwertiges und zufälliges bleiben, wenn man eben ausserhalb der Spec. 
übertakten möchte.
Eine "Serienproduktion" mit 2 Wochen später nachbestellten Bauteilen ist 
damit kaum möglich. Aber das dürfte auch weniger dein Ziel sein.

[Johannes S. (vamogu05)]

Klaus F. schrieb:
> Du redest hier wohl vom Eprom?
> Denn am Ram müsstest du ja dann /WR mit der Ramadresse verwursten.

Nein, ich rede sowohl vom EPROM als auch vom RAM.
WR bliebe unangetastet. Wie soll ich denn WR mit der Ramadresse 
"verwursten"?

> Freu dich einfach wenn eine bestimmte Platine mit dem Takt xx MHz läuft
> und gut.
Genau so sehe ich das auch.

Klaus F. schrieb:
> Aber das wird so immer für jede Platine und jede Bauteilcharge was
> grenzwertiges und zufälliges bleiben, wenn man eben ausserhalb der Spec.
> übertakten möchte.

Wo bin ich außerhalb der Specification? Gut das RAM könnte etwas 
schneller sein. Da habe ich einen Typ mit 15ns geplant. Die F Max für 
den W65C02S wird im Datenblatt auf S24 mit 19MHz bei 4,2V angegeben. 
Interpretiere ich das Bild falsch? Siehe 
https://www.westerndesigncenter.com/wdc/documentation/w65c02s.pdf

Ich glaube nicht, dass ich irgendwo außerhalb der Spezifikation liege. 
Lasse mich aber gerne eines Besseren belehren. Ich möchte gerne wissen 
wie man so ein System aufbauen muss, dass es innerhalb der Spezifikation 
betrieben werden kann. Welche Komponenten muss man da verwenden?

[Harald K. (kirnbichler)]

Wulf D. schrieb:
> Wie kommst du denn auf 31ns? Einfach die 1/Taktfrequenz /2?
> Nein, so einfach ist das nicht, ein Blick ins Datenblatt hilft.

Den habe ich viel weiter oben schon geworfen:

Beitrag "Re: 6502 System funktioniert nicht richtig"

[Klaus F. (klaus27f)]

Johannes S. schrieb:
> Klaus F. schrieb:
>> Du redest hier wohl vom Eprom?
>> Denn am Ram müsstest du ja dann /WR mit der Ramadresse verwursten.
>
> Nein, ich rede sowohl vom EPROM als auch vom RAM.
> WR bliebe unangetastet. Wie soll ich denn WR mit der Ramadresse
> "verwursten"?


Naja, wenn du an der "alten" Platine beim RAM auch /CE dauhaft low setzt 
(Gnd) und nur dessen /OE steuerst:
Dann wird jedes /WR einer beliebigen Adresse ins Ram gescchrieben.
Z.B. auch /WR auf die I-O Chipadressen (des 65C22) ... mit dem 
jeweiligen adressspezifischem Offset.


Beim Eprom ist das egal, weil sich Eprom so nicht beschreibt.

Bisserl mehr Datenblätter lesen und verstehen lernen!

Freundliche Grüße
   Klaus

[Thomas W. (dbstw)]

Johannes S. schrieb:

> Klaus F. schrieb:
>> Aber das wird so immer für jede Platine und jede Bauteilcharge was
>> grenzwertiges und zufälliges bleiben, wenn man eben ausserhalb der Spec.
>> übertakten möchte.
>
> Wo bin ich außerhalb der Specification? Gut das RAM mönnte etwas
> schneller sein. Da habe ich einen Typ mit 15ns geplant. Die F Max für
> den W65C02S wird im Datenblatt auf S24 mit 19MHz bei 4,2V angegeben.
> Interpretiere ich das Bild falsch? Siehe
> https://www.westerndesigncenter.com/wdc/documentation/w65c02s.pdf

Du hast ein bisschen Recht: WDC gibt keine absolute Grenzfrequenz (oder 
Betriebsfrequenz) an, aber auf p.25, Fig. 6-3 sind die Zeit-Parameter 
bei 5.0V und 14MHz angegeben. Dementsprechend bestimmen sich die Zeiten.

Spannend fand ich den Inset bei p.25, Fig 6-2 dass wohl WDC die maximale 
Frequenz bei 85°C bestimmt. Das ist schon ganz schoen warm fuer 
Halbleiter.

Und eine Sache muss man sehen (bei den Grafiken 6-1 und 6-2): "Typical 
0.6u processed device" heisst "Our best device". Ist ja nicht 
gewaehrleistet.

Aber Du willst je keine Massenfertigung erstellen.

Unabhaengig von dem aktuellen Geraet: Man sollte mal ein wenig in Demut 
schweigen wg. der Leistung von Dan and Kathleen Spracklen: Mit einem 
8-Bit-Rechner mit einer Z80, der Verkaufsweg in 1978 war Verkauf der 
Assembler-Sourcen zum Selber-Eintippen, keine richtigen 
Entwicklungswerkzeuge.

Es ist eine unglaubliche Leistung gewesen, und die Spielstaerke war wohl 
nicht schlecht (wir reden von 80'er, Disco, Saturday Night Fever, Star 
Wars).

Dieses Interview kennst Du sicherlich:
http://archive.computerhistory.org/projects/chess/related_materials/oral-history/spacklen.oral_history.2005.102630821/spracklen.oral_history_transcript.2005.102630821.pdf

Und auch diesen Artikel kennst Du sicher:
https://archive.org/details/byte-magazine-1978-10/page/n87/mode/2up?view=theater

Und wenn wir jetzt schon in die 80er gehen: Ich werde jetzt einen Film 
(Einweg-Sensor mit chemischer Auslesung) in meine Kamera (Canon AE-1) 
packen.

[Johannes S. (vamogu05)]

Klaus F. schrieb:
> Naja, wenn du an der "alten" Platine beim RAM auch /CE dauhaft low setzt
> (Gnd) und nur dessen /OE steuerst:
> Dann wird jedes /WR einer beliebigen Adresse ins Ram gescchrieben.
> Z.B. auch /WR auf die I-O Chipadressen (des 65C22) ... mit dem
> jeweiligen adressspezifischem Offset.

Hallo Klaus,

ja, jetzt verstehe ich dich. Du hast vollkommen Recht. Deshalb wird 
diese Methode, CE dauerhaft auf Low zu legen und OE aus den Adressen zu 
gewinnen auch nicht funktionieren. Darum wird das auch nirgends so 
gemacht. Beim Schreiben ist es nämlich egal welchen Zustand OE gerade 
besitzt. Es wird immer ins RAM geschrieben werden!
Es hilft auch nichts das RW-Signal irgendwie mit der RAM-Adresse zu 
"verwursten". Das RW-Signal ist von der Adresse unabhängig.
Man muss einfach die Steuereingänge der Speicher so verwenden, für das 
sie vorgesehen sind. CE eben für die Auswahl, und OE zur Datenfreigabe 
des Bausteins.

[Wulf D. (holler)]

Harald K. schrieb:
> Wulf D. schrieb:
>> Wie kommst du denn auf 31ns? Einfach die 1/Taktfrequenz /2?
>> Nein, so einfach ist das nicht, ein Blick ins Datenblatt hilft.
>
> Den habe ich viel weiter oben schon geworfen:
>
> Beitrag "Re: 6502 System funktioniert nicht richtig"

Ok, das ist ein Screenshot vom alten Original, nicht der neue CMOS Chip. 
Egal: der W65C02S gibt jeder Peripherie tPWH + tPWL - tADS Zeit. Im 
Datenblatt bei 14 MHz abgelesen sind das 35ns + 35ns - 30ns = 40ns.

Bei höherem Takt entsprechend weniger. Die VIA wird vom gleichen Takt 
gespeist. Beim RAM will Johannes auf 15ns Typen gehen. Wusste gar nicht, 
dass es so schnelle mittlerweile gibt. Das sollte funktionieren.

Von Winbond habe ich auf Anhieb 45ns schnelle 27C512 gesehen. Das wird 
nicht reichen. Für höhere Frequenzen schon gar nicht, dann müsste man 
über den RDY-Eingang Waitstates einsteuern.

Ein ausführlicher Artikel zu dem Thema:
https://hackaday.io/project/174128-db6502/log/187116-wait-states-explained-14mhz-part-ii

Gruß Wulf

[Harald K. (kirnbichler)]

Wulf D. schrieb:
> Im Datenblatt bei 14 MHz abgelesen sind das 35ns + 35ns - 30ns = 40ns.

Der Threadstarter möchte den Kram mit 24 MHz betreiben.

Wulf D. schrieb:
> Beim RAM will Johannes auf 15ns Typen gehen. Wusste gar nicht,
> dass es so schnelle mittlerweile gibt.

Die gibts schon seit Jahrzehnten, so etwas war bereits in den 90ern als 
Cache-SRAM auf manchen PC-Motherboards zu finden. Verbraucht halt 
ziemlich viel Strom.

[Wulf D. (holler)]

24MHz ergibt eine Zugriffszeit von 23ns. Mit sehr schneller CS-Logik 
(AS) könnten 20ns schnelle Bausteine genügen. Habe noch nie so schnelle 
EPROMS gesehen.

Ich würde im Layout eine Waitstate-Logik an RDY vorsehen, ggf. mit 
Jumper, falls man die doch nicht haben will.

Ist im oben verlinkten Artikel wirklich gut und Schritt für Schritt 
erklärt, wie man so etwas in ein 6502 System einbaut.
Gruß Wulf

[HaraldS K. (kuske)]

Das sollte auch nur eine grobe Schätzung sein. Sollte aber klar sein was 
gemeint ist.

[Johannes S. (vamogu05)]

Wulf D. schrieb:
> 24MHz ergibt eine Zugriffszeit von 23ns. Mit sehr schneller
> CS-Logik
> (AS) könnten 20ns schnelle Bausteine genügen. Habe noch nie so schnelle
> EPROMS gesehen.
>
> Ich würde im Layout eine Waitstate-Logik an RDY vorsehen, ggf. mit
> Jumper, falls man die doch nicht haben will.
>
> Ist im oben verlinkten Artikel wirklich gut und Schritt für Schritt
> erklärt, wie man so etwas in ein 6502 System einbaut.
> Gruß Wulf

Hallo Wulf,

Danke für Deine kompetente Einschätzung. Unbedingt 24 MHz müssen es 
nicht sein. Ich habe hier eine Platine die mit 24 MHz läuft. Verbaut 
sind auf dieser ein 45ns EPROM und ein MT5C6408-15 SRAM. Die 
Adressdecoder sind ein 74F32 und ein 74F04. Gleicher Aufbau, wie mein 
Nachbau. Also OE direkt an GND. Das EPROM ist vermutlich schneller als 
45ns, sonst würde das nicht stabil laufen. Von dieser Platine wurde eine 
Kleinserie (<10 Stück) vor Jahren produziert. Die Besitzer der 
Schachcomputer, in denen diese Platine läuft kenne ich zum Großteil. Ich 
habe noch nichts negatives über deren Geräten gehört. Habe selber einen 
der stabil läuft.

Hast Du eine Idee welchen Festwertspeicher man sonst noch nehmen könnte 
der schneller ist als 45ns?
Gibt es Geräte mit denen man die Zugriffszeit von Speichern testen kann 
(für den Privatgebrauch erschwinglich)? mit meinem 50MHz Oszi werde ich 
da nicht glücklich werden.
Die Idee mit den Waitstates gefällt mir auch. Den Artikel habe ich mir 
abgespeichert. Allerdings würde die Performance darunter etwas leiden. 
Da kann man gleich bei geringerem Takt bleiben. Oder sehe ich das 
falsch?

[Carsten W. (eagle38106)]

Nimm doch ein RAM, das Du im Adressraum parallel zum EPROM legst. Du 
fährst dann das Board mit 12MHz hoch und kopierst alles ins RAM. Dann 
schaltest Du vom EPROM aufs RAM um und auf 24 MHz. Kannst Du dann gleich 
auch für die SW-Entwicklung nehmen. Also gleich ein 64k RAM, das nur an 
den gewollten Stellen in den Adressraum eingeblendet wird.

[Johannes S. (vamogu05)]

Carsten W. schrieb:
> Nimm doch ein RAM, das Du im Adressraum parallel zum EPROM legst. Du
> fährst dann das Board mit 12MHz hoch und kopierst alles ins RAM. Dann
> schaltest Du vom EPROM aufs RAM um und auf 24 MHz. Kannst Du dann gleich
> auch für die SW-Entwicklung nehmen. Also gleich ein 64k RAM, das nur an
> den gewollten Stellen in den Adressraum eingeblendet wird.

Prinzipiell keine schlechte Idee. Allerdings doch ein deutlicher 
Mehraufwand. Werde ich mir noch überlegen.
Danke für den Tipp.

[Wulf D. (holler)]

Willst du die Performance ausreizen, bleibt wirklich nur die Idee mit 
dem RAM. Waitstates kosten Geschwindigkeit, auch wenn du die „nur“ bei 
EPROM Zugriffen einfügen musst.
Du könntest auch das bestehende RAM einfach vergrößern, so dass du 
keinen weiteren CHIP benötigst. Wird aber so oder so eine SW-Erweiterung 
bedeuten. Du brauchst wahrscheinlich auch eine Art 
Speicherbank-Umschaltung, zwei 64kByte-Chips passen beim Kopieren 
vermutlich nicht in den Adressraum.

Wie auch immer, mit dem 45ns-EPROM sind ohne Waitstates für den Betrieb 
innerhalb der Spezifikation nur 12MHz drin. Bei 24MHz ist das EPROM um 
den Faktor 2 überfahren, da wundert es mich schon sehr, dass das System 
noch läuft.

Gruß Wulf

[Thomas W. (dbstw)]

Johannes S. schrieb:

> Die Idee mit den Waitstates gefällt mir auch. Den Artikel habe ich mir
> abgespeichert. Allerdings würde die Performance darunter etwas leiden.
> Da kann man gleich bei geringerem Takt bleiben. Oder sehe ich das
> falsch?

Im Endeffekt: Ja. Die 65C02 (und der WDC) ist komplett statisch, und mit 
dem RDY-Eingang kannst Du die CPU praktisch anhalten (die wilde Fahrt 
geht dann mit der naechsten Phi2-Flanke weiter).

D.h. die CPU hat (z.b.) einen Basistakt von 14MHz, beim Zugriff auf das 
EPROM dann aber nur 7MHz (die Speicherzugriffe ins RAM waeren weiterhin 
mit 14MHz).  Der Effekt ist dann natuerlich sehr abhaengig von Deinem 
Code: Laeuft das Programm im EPROM (wegen der Wait-States) hast Du 
natuerlich nur den halben Takt, kannst Du das Programm in das RAM 
kopieren (der Vorschlag von Carsten) und im RAM ausfuehren, dann 
haettest Du volle Geschwingkeit.

Ist schon ein groesserer Umbau der Schaltung.

Wie lange dauert denn ein Spielzug? Ich erinnere mich noch an meinem 
Sargon, der (bei einem TRS-80 mit 1.7MHz Z80) schon mal 10 Minuten 
"denken" musste (bei entsprechende Spielstaerke).

Eine weitere Sache: Du hast Dich auf das Memory-System konzentriert. Am 
Bus haengt auch die 65C22 mit dran, und der Timer/IO laeuft mit Phi2. 
Und der Chip ist lt. WDC mit 14MHz spezifiziert.

[Johannes S. (vamogu05)]

Wulf D. schrieb:
> Willst du die Performance ausreizen, bleibt wirklich nur die Idee mit
> dem RAM. Waitstates kosten Geschwindigkeit, auch wenn du die „nur“ bei
> EPROM Zugriffen einfügen musst.

Ja, die Idee mit dem Kopieren ins RAM ist gar nicht so schlecht. Ist 
halt wesentlich mehr Aufwand da eine funktionierende Schaltung 
aufzubauen.
Da, das Programm häufiger auf das EPROM zugreift als auf das RAM sind 
Waitstates nicht wirklich performancesteigernd.

Thomas W. schrieb:
> Wie lange dauert denn ein Spielzug? Ich erinnere mich noch an meinem
> Sargon, der (bei einem TRS-80 mit 1.7MHz Z80) schon mal 10 Minuten
> "denken" musste (bei entsprechende Spielstaerke).

Ist abhängig von der eingestellten Spielstufe. Im Turniermodus ca. 3min. 
pro Zug. Aber beim Lösen von Schachproblemen sogar mehrere Stunden.

> Eine weitere Sache: Du hast Dich auf das Memory-System konzentriert. Am
> Bus haengt auch die 65C22 mit dran, und der Timer/IO laeuft mit Phi2.
> Und der Chip ist lt. WDC mit 14MHz spezifiziert.

Ja, ich würde gerne die 65C22 mit 1MHz betreiben, damit keine 
Anpassungen des Original ROMs fällig wären. Da müsste ich dann auf jeden 
Fall mit Waitstates arbeiten.
Die höhere Taktfrequenz der 65C22 benötigt im Programmcode dann schon 
einige Anpassungen (Verzögerungen) beim Umschalten der Ports, bzw. 
Anpassungen der Tonausgabe. Außerdem muss auch die Interruptfrequenz 
geändert werden. Das könnte man sich alles sparen, wenn die VIA 65C22 
mit 1MHz laufen würde.

[Thomas W. (dbstw)]

Johannes S. schrieb:

>> Eine weitere Sache: Du hast Dich auf das Memory-System konzentriert. Am
>> Bus haengt auch die 65C22 mit dran, und der Timer/IO laeuft mit Phi2.
>> Und der Chip ist lt. WDC mit 14MHz spezifiziert.
>
> Ja, ich würde gerne die 65C22 mit 1MHz betreiben, damit keine
> Anpassungen des Original ROMs fällig wären. Da müsste ich dann auf jeden
> Fall mit Waitstates arbeiten.

Das ist eine Herausforderung: Phi2 macht das Timing fuer den Bustreiber 
und die Timer, d.h. die Timer haben keine unabhaengige Timebase (die 
Timer-Frequenz ist der Bustakt). Und die Phi2-Frequenz wird durch die 
Wait-States nicht veraendert.

> Die höhere Taktfrequenz der 65C22 benötigt im Programmcode dann schon
> einige Anpassungen (Verzögerungen) beim Umschalten der Ports, bzw.
> Anpassungen der Tonausgabe. Außerdem muss auch die Interruptfrequenz
> geändert werden. Das könnte man sich alles sparen, wenn die VIA 65C22
> mit 1MHz laufen würde.

Ich bin so oder so erstaunt, dass es ueberhaupt ohne Anpassungen 
funktioniert, denn ca. 16x Takt ist schon interessant.

[Harald K. (kirnbichler)]

Johannes S. schrieb:
> Die höhere Taktfrequenz der 65C22 benötigt im Programmcode dann schon
> einige Anpassungen (Verzögerungen) beim Umschalten der Ports, bzw.
> Anpassungen der Tonausgabe.

Du hast doch eine von einem "Elektroniker" angepasste Platine, die 
funktionieren soll. Wie geht das denn, wenn im Programmcode noch "einige 
Anpassungen" erforderlich sein sollen?

[Johannes S. (vamogu05)]

Thomas W. schrieb:
> Das ist eine Herausforderung: Phi2 macht das Timing fuer den Bustreiber
> und die Timer, d.h. die Timer haben keine unabhaengige Timebase (die
> Timer-Frequenz ist der Bustakt). Und die Phi2-Frequenz wird durch die
> Wait-States nicht veraendert.

Darum hätte ich die VIA 65C22 mit einem durch 16 geteilten Takt 
betrieben. Das war meine ursprüngliche Idee. Da wußte ich von Waitstates 
noch nichts. Habe das dann verworfen, als ich mehr über die 
Kommunikation der CPU mit der VIA herausgefunden habe. Aber jetzt denke 
ich, sollte das doch möglich sein die VIA mit 1 MHz zu betreiben, 
während die CPU mit 16MHz getastet wird. Die VIA muss halt die CPU 
anhalten während Schreib-Lesezugriffen. Das sollte doch machbar sein?

> Ich bin so oder so erstaunt, dass es ueberhaupt ohne Anpassungen
> funktioniert, denn ca. 16x Takt ist schon interessant.
Nein, ohne Anpassungen würde das nicht vernünftig laufen. Die Töne wären 
nur sehr kurze, hohe Piepser. Die Interrupts würden zu oft aufgerufen, 
dadurch würde das Programm seine Bedenkzeit nicht ausreizen und viel zu 
früh den Rechenvorgang abbrechen. Wichtig ist, die selbe IRQ-Frequenz 
wie beim Original einzustellen. Die Töne muss man dann trotzdem noch 
anpassen.

Harald K. schrieb:
> Du hast doch eine von einem "Elektroniker" angepasste Platine, die
> funktionieren soll. Wie geht das denn, wenn im Programmcode noch "einige
> Anpassungen" erforderlich sein sollen?

Der "Elektroniker" der diese 16MHz Platine gebaut hatte, hatte schon 
Anpassungen vorgenommen. Allerdings nutzte das Programm dann nicht mehr 
die den Spielstufen entsprechende Rechenzeit, was von einigen Usern 
erkannt und bemängelt wurde. Ich konnte mich dann auf die Erfahrungen 
meiner Assemblerprogrammierung mit dem C64 erinnern und den Code 
letztendlich anpassen.
D.h. je nach Taktfrequenz wären etliche Bytes im ROM zu patchen. Würde 
die VIA mit 1MHz laufen wäre das nicht der Fall und man könnte das 
Original-ROM verwenden.

[(prx) A. K. (prx)]

Johannes S. schrieb:
> sollte das doch möglich sein die VIA mit 1 MHz zu betreiben,
> während die CPU mit 16MHz getastet wird

Im Prinzip ja. Man muss den VIA mit einem permanenten 1 MHz Takt 
versorgen und bei jedem Zugriff auf den VIA muss die CPU sich so auf 
diesen Takt synchronisieren, dass das Zeitverhalten der Bussignale 
dieses 1 MHz Zyklus eingehalten wird. Also die setup/hold times bei 
phi2(1MHz) 0>1 und 1>0.

So etwas in der Art hatte die 68000 CPU intern.