Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins Willkommen Gast! RSS

Robotrontechnik-Forum » Technische Diskussionen » Phänomen: RAM U214 verliert Gedächtnis » Themenansicht

Autor Thread - Seiten: -1-
000
09.12.2019, 20:29 Uhr
wolle1945



Hallo Leute,
ich habe ein Problem mit meiner Speichererweitwerung am BCS-3.





Ich habe alle ICs ausgetauscht. Nach dem Einschalten des BCS-3 und einstellen der Zeilen wird der zur Verfügung stehende Speicher richtig angezeigt. Die Speichererweiterung ist ab 4000H festgelegt. Wenn das Basic-Programm in diesen Bereich geht, so kommt es zu Störungen nach Start des Programms (RUN). Bei List wird nur das Programm bis 3FFFH richtig angezeigt, danach erscheinen beliebige Zeichen. Ich habe nun den Bereich ab 4000H mit POKE und PEEK getestet. Ein beschriebenes Byte wurde wieder ausgelesen, aber es zeigt nicht den gleichen Wert an. Das bedeutet, daß die Werte verloren gehen.
Mit nachfolgendem Programm habe ich nun die Speichererweiterung getestet:
5 A=4000H
8 B=49H
10 C=100
15 POKE A,B
20 FOR I=1 TO C : NEXT
30 PRINT %PEEK(A)
40 GOTO 20
Ich habe also einen Wert auf eine Adresse geschrieben und nach einer Zeit wieder ausgelesen. Beim Wert von 100 kam es zu verschiedenen ausgelesenen Werten. 43H, 48H, 41H, 52H, 6AH, 4FH, ....
Ich habe die Zeit verkürzt und ab einem Wert unter 50 wurde der exakte Wert ausgelesen, nämlich die 49H. Die U214 behalten ihre Werte also nur für kurze Zeit. Ich habe die Adresse als auch den Wert verändert, der gleiche Effekt.
Bei einem Zeitwert von über 50 gibt es die Probleme. Woran kann das liegen?
Gruß Wolfgang
--
mfG wolle1945

Dieser Beitrag wurde am 09.12.2019 um 20:39 Uhr von wolle1945 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
001
09.12.2019, 20:40 Uhr
kaiOr

Avatar von kaiOr

Es gibt/gab die "U202DB" die lustigerweise Refresh benötigen, die muss man auch entsprechend verkabeln. Beim U214 bin ich nicht sicher, ob es so eine Anfall-Variante gab (wer achtet schon auf den letzten Buchstaben?).
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
002
09.12.2019, 20:47 Uhr
Rolly2



Hallo Wolle1945,
die U214 sind statische RAMs, da muss also nichts aufgefrischt werden. Das Problem könnte in der Zeilen und Spaltenauswahl liegen. Hast Du schon die Betriebsspannung an den RAMs gemessen. Die könnte nicht stimmen oder einknicken.

VG, Andreas
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
003
09.12.2019, 21:06 Uhr
Andreas



Was kaiOr schreibt stimmt. Es gab in der RFE 3/82 mal einen Artikel zum auffrischen von statischen RAM U202. Ob es aber bei U214 auch diesen Effekt gab?

Andreas
--
Viele Grüße
Andreas
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
004
09.12.2019, 22:29 Uhr
schlaub_01



So, hab's gerade mal aufgebaut. Mit einem Atmega und einem U214D20. Ich habe den mit aufsteigenden Zählerwerten beschrieben und lese den dann nur noch mit Wartezeiten zurück. Zwischendurch habe ich aber auch den Debugger mal für etliche Sekunden angehalten. Da gibt's keine Probleme. Da muß noch was in der Schaltung sein. Die Zahlen aus <000> sehen auch nicht nach gekippten Bits aus, eventuell wird da etwas überschrieben, was nicht sein soll. Wenn's nach einer Zeit erfolgt, könnte das ja auch an den Bildschirmzugriffen liegen, da ja per Interrupt in ständigen Zeitabschnitten auf den Bildschirmspeicherbereich zugegriffen wird - der liegt ja knapp unterhalb der 4000H. Aber das ist nur eine Vermutung.

Grüße,
Sven.

Edit: auf dem Bild gibt's auf der rechten Seite eine Brücke, die sieht sehr seltsam aus. Müsste ja auch die 5V für die RAMs führen.

Dieser Beitrag wurde am 09.12.2019 um 22:32 Uhr von schlaub_01 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
005
10.12.2019, 08:00 Uhr
Heiko_P



Schaut euch mal bitte den Schaltplan in (000) an. Dort geht das /RD-Signal invertiert an den WE-Eingang des RAM. Das heißt, immer wenn /RD inaktiv ist dann ist für den RAM das Schreibsignal aktiv. Das kann funktionieren, muss aber nicht ...

Gruß
Heiko
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
006
10.12.2019, 08:39 Uhr
schlaub_01



Hallo Heiko,

das ist schon richtig, aber nur in Kombination mit dem Chip Select Signal. Wenn das nicht da ist und auch nicht länger anliegt (die Zugriffszeiten sind hier zwischen 200-450 ns), dann passiert da auch nichts. Es kann hier maximal was passieren, wenn z.B. A14 klemmt (also konstant 1 ist), dann können auch Refreshs eventuell etwas auslösen. Aber mit nem Logik Analyzer könnte man sich das auch mal anschauen. Einfach auf das Chip Select triggern und dann mit dem nWE Signal zusammen anschauen, dann müsste man eigentlich etwas sehen. Ansonsten wäre noch die Betriebsspannung, so wie schon genannt, eine mögliche Ursache...

Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
007
10.12.2019, 08:47 Uhr
KK

Avatar von KK


Zitat:
Heiko_P schrieb
Dort geht das /RD-Signal invertiert an den WE-Eingang des RAM. Das heißt, immer wenn /RD inaktiv ist dann ist für den RAM das Schreibsignal aktiv.



Das ist wirklich eigenartig. Wer macht sowas und warum? Für Schreibzugriffe ist explizit /WR zuständig. Die durch das invertierende Gatter verursachte Latenz könnte durchaus dazu führen, daß /WE am RAM einen Tick zu lange aktiv ist.

Der U214 benötigt definitiv keinen Refresh. Das widerspricht der grundsätzlichen Funktion von statischen RAMs und wäre mir sicher am LC80 aufgefallen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
008
10.12.2019, 09:44 Uhr
wolle1945



Hallo zusammen,
ich muß sagen, daß die Speichererweiterung 1986, als ich den BCS3 erweitert habe mit vollen 4K gelaufen ist. Doch als ich jetzt den BCS3 wieder zum Laufen bringen will, treten die Probleme auf. Laut RFE 1986/9 zu Erweiterungen für Basic-Heimcomputer wird zur Speichererweiterung unter anderem geschrieben: "Als Schreibsignal wird nicht /WR, sondern RD verwendet. Damit können Unklarheiten zu Beginn eines Schreibzyklus vermieden werden."
Ich habe auch noch 4 andere U214, nicht von MME, ausprobiert. Diese wurden nach dem Einschalten überhaupt nicht erkannt. Die U214 sind alle D20-Typen.
Die Betriebsspannung beträgt 4,86 V mit ca. 25 mV Brummspannung. CS liegt überall an, auch die Betriebsspannung.

Gruß Wolfgang
--
mfG wolle1945

Dieser Beitrag wurde am 10.12.2019 um 09:48 Uhr von wolle1945 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
009
10.12.2019, 11:21 Uhr
otto11



Ich würde mal einige 100nF Stütz-C's an die RAM bringen und vielleicht auch den alten Elko vergrößern und/oder ersetzen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
010
10.12.2019, 11:26 Uhr
KK

Avatar von KK

Ich sehe eine dieser roten Keramikscheiben. Waren die nicht anfällig?
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
011
10.12.2019, 11:35 Uhr
Buebchen



@Wolle1945
Hallo!
Bei der geringen Spannung und nur einem Abblockkondensator brauchst du dich nicht zu wundern. Auch die Fassungen sind nicht zuverlässig. Nach meiner Erinnerung sind die Kontakte vergoldet. Das beist sich mit den verzinnten Kontakten nach dreißig Jahren Liegedauer. Die sich in dieser zeit zwischen Gold und Zinn bildenden intermetallischen Verbindungen leiten schlecht.
Wolfgang
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
012
10.12.2019, 12:00 Uhr
holm

Avatar von holm


Zitat:
KK schrieb

Zitat:
Heiko_P schrieb
Dort geht das /RD-Signal invertiert an den WE-Eingang des RAM. Das heißt, immer wenn /RD inaktiv ist dann ist für den RAM das Schreibsignal aktiv.



Das ist wirklich eigenartig. Wer macht sowas und warum? Für Schreibzugriffe ist explizit /WR zuständig. Die durch das invertierende Gatter verursachte Latenz könnte durchaus dazu führen, daß /WE am RAM einen Tick zu lange aktiv ist.

Der U214 benötigt definitiv keinen Refresh. Das widerspricht der grundsätzlichen Funktion von statischen RAMs und wäre mir sicher am LC80 aufgefallen.



Bei schnellen RAMs kann die Verwendung von /WR zu Problemen führen, da das viel später als /RD aktiv wird und ggf, die RAM Treiber Mimik die Ausgänge schon auf aktiv geschaltet hat wenn es der CPU einfällt /WR aktiv zu machen.


Die roten Cs neigen zu FEINschlüssen, bei der Verwendung als Stützkondensator macht das aber eher gar nix.

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
013
10.12.2019, 12:04 Uhr
holm

Avatar von holm

"intermetallische Gold Zinn Verbindungen die schlecht leiten"?

Du machst mich als gelernten Metallurgen echt neugierig Wolfgang, lerne ich jetzt noch was völlig Neues?

Sprich Dich mal genauer aus bitte..und nimm Bezug auf die üblichen Präzisionsfassungen deren Trichterlinge üblicherweise vergoldet sind..

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
014
10.12.2019, 12:28 Uhr
PIC18F2550

Avatar von PIC18F2550

Hallo wolle1945,

U214 und U224 unterscheiden sich das einer einen Adresslatch hat und der andere nicht.

Ich hatte damals zusätzlich noch /WR und /RD in die MREQ-Leitung eingebunden.
Die Daten und Adressen gelden erst mit den signal /WR als güldig!
Vorher sind die noch als instabiel zu betrachten.

Die Verwendung von /RD am SRAM soll nur das Datenkämpfen auf dem Bus verhindern.

Mit welchen Takt rennt deine CPU?

Der RAM muss mindestens eine Taktperiode als zycluszeit haben.

SRAM = 200ns bedeutet das die CPU mit einem Takt unter 5Mhz betrieben werden muss.
--
42 ist die Antwort auf die "Frage nach dem Leben, dem Universum und dem ganzen Rest"
Aktuelle Projektdokumentationen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
015
10.12.2019, 13:20 Uhr
KK

Avatar von KK


Zitat:
holm schrieb
Bei schnellen RAMs kann die Verwendung von /WR zu Problemen führen, da das viel später als /RD aktiv wird und ggf, die RAM Treiber Mimik die Ausgänge schon auf aktiv geschaltet hat wenn es der CPU einfällt /WR aktiv zu machen.



OK, ich glaub dir das. Aber am Verständnis fehlt es mir. WR signalisiert doch, daß der Datenbus gültig ist (siehe auch Beitrag unten von PIC). Selbst wenn die Ausgänge bereits aktiv sind, weil der Adressdecoder schneller ist als die CPU WR schaltet, dürfte den Daten im RAM doch nichts passieren, weil sich dieser im READ-Modus befindet. Das Problem müßte sich doch eher durch Verwendung von RD verschärfen, weil eventuell die Daten auf dem Bus noch nicht gültig sind, der RAM aber schon in den WRITE-Mode versetzt wird?
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
016
10.12.2019, 13:39 Uhr
Lippi

Avatar von Lippi

Wenn mich meine grauen Zellen nitcht täuschen, muss die Adresse doch vor Write oder Read gültig sein, jeweils plus Zugriffszeit?
Oder irre ich hier....?
--
MfG Mario
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
017
10.12.2019, 13:49 Uhr
mark1111



Ich habe damals ( Ende 1988) die Speichererweiterung mit 16 Stück S224 aufgebaut und diese
funktionierte damals auf Anhieb ohne Probleme. Als Erweiterung kamen später (1991) eine manuelle
Speicherbank-Umschaltung und ein 2716-Programmierteil mit auf die Platine. Im Bild: 3. von oben rechts.

Ich würde vorschlagen, die U214 beginnend von 4000H aufwärts paarweise zu stecken, um den Fehler einzukreisen.
Wenn vorhanden, auch mal U224D45 oder S224 stecken. Darauf achten, daß die Zugriffszeit größer als
350ns ist. Achtung: Das Speichermodul wird mit MREQ (high aktiv!) angesteuert,nicht mit MREQ negiert (low aktiv), wie es aus dem U880 ausgegeben wird!

Mein BCS3 funktionierte mit 2,5 Mhz Takt ohne Probleme, mit 3,5 Mhz dagegen nicht zuverlässig (Bastelschaltkreise).

Edit: Module im Bild von links oben bis rechts unten:

Netzteil für EPROM-Programmierspannung
PIO/SIO/CTC-Modul
Behelfstastatur
U555-Programmer & Monitor-EPROM-Modul
16k Speichererweiterung mit 8xU256 bzw. russ. K565RU3
8k Speichermodul mit S224 und U2716 Programmierzusatz & Speicherbankumschaltung 4k/8K mittels Schiebeschalter
U2764 Programmer mit 8k SRAM KM6264
in der Mitte Grundgerät BCS3




Dieser Beitrag wurde am 10.12.2019 um 14:06 Uhr von mark1111 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
018
10.12.2019, 14:23 Uhr
holm

Avatar von holm


Zitat:
KK schrieb

Zitat:
holm schrieb
Bei schnellen RAMs kann die Verwendung von /WR zu Problemen führen, da das viel später als /RD aktiv wird und ggf, die RAM Treiber Mimik die Ausgänge schon auf aktiv geschaltet hat wenn es der CPU einfällt /WR aktiv zu machen.



OK, ich glaub dir das. Aber am Verständnis fehlt es mir. WR signalisiert doch, daß der Datenbus gültig ist (siehe auch Beitrag unten von PIC). Selbst wenn die Ausgänge bereits aktiv sind, weil der Adressdecoder schneller ist als die CPU WR schaltet, dürfte den Daten im RAM doch nichts passieren, weil sich dieser im READ-Modus befindet. Das Problem müßte sich doch eher durch Verwendung von RD verschärfen, weil eventuell die Daten auf dem Bus noch nicht gültig sind, der RAM aber schon in den WRITE-Mode versetzt wird?




..nein, weil die Daten erst mit der steigenden Flanke des /WE am RAM übernommen werden.

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
019
10.12.2019, 16:18 Uhr
volkerp
Default Group and Edit
Avatar von volkerp

vielleicht ist etwas



drübergelaufen?

(sorry, den konnte ich mir nicht verkneifen, etwas Humor ist manchmal dennoch hilfreich)
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)

Dieser Beitrag wurde am 10.12.2019 um 16:38 Uhr von volkerp editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
020
10.12.2019, 16:35 Uhr
wolle1945



noch einige Angaben:
ich habe an der Speichererweiterung noch 1 Elko 2200 µF und eine gelbe Scheibe von 100 nF angebracht. Ich habe im Moment auch nur 2 U214 (also 1K) drauf.
Ich hatte auch mal U224 drauf, aber da ging nichts.
Ich habe einige Bilder mit Salae Logic 1.2.29 Beta gemacht.
oberer Kanal CS-Signal, unterer Kanal WE am U214

In einer Schleife eine Zelle beschrieben





In einer Schleife die Zelle gelesen





das Bild zeigt das CS-Signal, für meine Begriffe unregelmäßig



noch ein Bild, wenn die Werte nicht richtig gelesen werden



Ich möchte nur wissen, warum das CS-Signal nicht regelmäßig kommt und die Daten im RAM verschwinden? Damals lief mein BCS3 wunderbar.
die CPU läuft mit 2,5 MHz
--
mfG wolle1945

Dieser Beitrag wurde am 10.12.2019 um 16:39 Uhr von wolle1945 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
021
10.12.2019, 16:50 Uhr
schlaub_01



Also wenn das zweite Signal das /WE am U214 ist, dann sehe ich nicht einen Lesezugriff. Da wird immer nur geschrieben...

Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
022
10.12.2019, 17:15 Uhr
wolle1945




Zitat:
schlaub_01 schrieb
Also wenn das zweite Signal das /WE am U214 ist, dann sehe ich nicht einen Lesezugriff. Da wird immer nur geschrieben...

Hallo Sven,
ich sehe nur einen Unterschied, beim Schreiben 80 µs und Lesen 40 µs.
Wie müßten die Signale denn aussehen?
Ich weiß auch nicht, ob ich die Logik richtig aufgenommen habe.
Kanal 0 mit negativer Flanke getriggert und Start, für einige sec. laufen lassen
und Stop.


--
mfG wolle1945
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
023
10.12.2019, 17:19 Uhr
kaiOr

Avatar von kaiOr

40µs ist etwas lang für /CS. Evtl. tatsächlich /MREQ statt MREQ verkabelt wie schon von mark1111 vermutet?

Noch was. Bei Refresh wird MREQ aktiv ohne /RD, das führt schon mal zu /WE für die U214. Während Refresh landet Register R auf A7...A0 und Register I auf A15...A8 (hat nix mit Deiner Variable I zu tun). Wenn die Schaltung oben stimmt, könnte man z.B. das Register I auf 40h setzen ("LD A,40h" und "LD I,A") und schon wird im Laufe mehrerer Refresh-Zyklen 4000h bis 407Fh adressiert und zerstört.

MfG

Dieser Beitrag wurde am 10.12.2019 um 17:21 Uhr von kaiOr editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
024
10.12.2019, 18:05 Uhr
schlaub_01




Zitat:
wolle1945 schrieb
Hallo Sven,
ich sehe nur einen Unterschied, beim Schreiben 80 µs und Lesen 40 µs.
Wie müßten die Signale denn aussehen?
Ich weiß auch nicht, ob ich die Logik richtig aufgenommen habe.
Kanal 0 mit negativer Flanke getriggert und Start, für einige sec. laufen lassen
und Stop.



Es müsste im Prinzip das Chip Select Signal auf Low geben, während /WE am U214 auf High geht. Da das Read auch sehr frühzeitig auf Low schaltet, müsste das negierte Read-Signal (/WE am U214) ähnlich lange wie /CS anliegen. Vielleicht ist ja an kaiOr und meiner Vermutung mit dem Refresh doch was dran... Hast Du mal verschiedene EPROM Versionen probiert? Gab ja einige beim BCS3. Die langen Zugriffszeiten (sollten eigentlich eher im einstelligen µs Bereich liegen) könnten eventuell doch vom Wait bei der Bildschirmdarstellung kommen...

Grüße,
Sven.

Dieser Beitrag wurde am 10.12.2019 um 18:07 Uhr von schlaub_01 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
025
10.12.2019, 19:05 Uhr
wolle1945



ich habe jetzt den DL000 durch einen D200 ersetzt. Es ergeben sich jetzt folgende Bilder:

beim Schreiben



beim Lesen




das CS-Signal, kommt es auch öfter



Ich habe die Eprom-Vers. 3.1, die ich auch schon immer hatte. Andere Versionen
habe ich nicht.
--
mfG wolle1945

Dieser Beitrag wurde am 10.12.2019 um 19:15 Uhr von wolle1945 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
026
11.12.2019, 18:29 Uhr
schlaub_01



Hallo Wolfgang,

wenn ich mir die Zugriffe der Bilder 1 und 2 richtig anschaue, dann habe ich die Vermutung, daß das Chip Select Signal nicht 100% richtig erzeugt wird. Nimmt man eine Taktfrequenz von 2,5MHz an, so ist die Periodendauer pro Takt 400ns. Bei einem typischen Speicherzugriff werden mindestens 3 Takte benötigt, d.h. die komplette Zykluszeit dauert minimal 1,2 µs. Wenn ich mir jetzt die Bilder anschaue, sieht das so aus, als ob im T2 Zyklus das Chip Select wieder auf 1 geht und beim Bild 2 schon das Lesesignal versucht hochzukommen, wobei das auch wesentlich länger sein sollte (eventuell ist da noch etwas zwischen dem Read und dem Dekoder verbunden - Zinnbrücke?). Ich würde jetzt versuchen mit dem Analyzer alle Eingangssignale und das Chip Select Signal mal anzuschauen und auf das Chip Select zu triggern. Dann sieht man eventuell, ob da was nicht stimmt. Allerdings hattest Du mir ja mal erzählt, daß Du den Dekoder auch schon mal ausgetauscht hast.

Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
027
11.12.2019, 21:26 Uhr
P.S.



@wolle1945 <020>
Die Speicher in einer Programmschleife zur Fehlersuche anzusprechen ist im Prinzip schon der richtige Weg. Deine Taktdiagramme sehen zwar schön aus, bilden aber wahrscheinlich nicht die Realität ab. Ein LogigAnalyser idealisiert i.d.R. die Impulsform. Zu empfehlen wäre hier ein echter 2-Strahl-Oszi, zB. EO213, wo mit dem einen Signal (z.B. Takt) getriggert wird und zu den Flanken des anderen gemessen werden kann. Dabei spielt die Flankensteilheit eine nicht zu unterschätzende Rolle. Bei verschliffenen Flanken kommt der wirksame Pegel viel später als man denkt und Spikes können einem das Leben ganz schön schwer machen!
Empfehlenswert ist auch sich intensiv mit dem Impulsdiagramm des betreffenden Speicherbausteins auseinander zu setzen und ggf. mal an Hand des CPU-Taktdiagramms unter Berücksichtigung zwischengeschalteten TTL-Bausteine mit ihren Verzögerungszeiten sich das am Speicher theoretisch ergebende Taktdiagramm aufzuzeichnen. Dabei sollten unbedingt die im Datenblatt angegebenen Zeittoleranzen berücksichtigt werden, wie im Beispiel aus meiner Entwicklung des GDC-Bildwiederholspeichers zu sehen ist - siehe http://www.ps-blnkd.de/EXPR/EXPR_GDC_Takt.zip. Die Beschreibung dazu: http://www.ps-blnkd.de/EXPR/Expr.htm - hier insbesondere die Ausführungen zum RAM-Interface.

Ja, hier handelt es sich im Gegensatz zum U214D um die viel komplizierteren dynamische RAMs - aber vom Grundatz der Überlegungen kann das sicherlich hilfreich sein.

Um solche Speicherbaugruppen (u.a.) intensiv testen zu können, hatte ich in den späten 1980er Jahren einen http://www.ps-blnkd.de/CPU-Simulator.pdf entwickelt. Den hat jemand aus dem Robotrontechnik-Forum bekommen.

Viel Erfolg bei den weiteren Arbeiten ...

Das Wissen der Menschheit gehört allen Menschen! -
Wissen ist Macht, wer nur glaubt, der weiß nichts! -
Aber - Unwissenheit schützt vor Strafe nicht! -
Gegen die Ausgrenzung von Unwissenden und für ein liberalisiertes Urheberrecht!
PS
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
028
11.12.2019, 21:39 Uhr
schlaub_01



Also, ich habe vorhin mit Wolfgang gesprochen und noch selber einige Experimente mit meinem KC und der angeschlossenen Schaltung gemacht. Das Timing ist völlig entspannt, denn das MREQ Signal ist beim Lesen exakt so lang wie das Read Signal selbst und damit wird das Chip Select Signal auch nur so lang aktiv wie das /WR Signal auf high ist. Durch die Gatterlaufzeiten gibt es da auch nur minimale Zeitunterschiede der beiden Signale. Auf den Bildern von BCS3 Aufbauten habe ich da auch einen Draht am MREQ Steckverbinderpin gefunden, der richtig verdrahtet werden muß - Wolfgang schaut sich das morgen nochmal an.



Grüße,
Sven.

Dieser Beitrag wurde am 11.12.2019 um 21:40 Uhr von schlaub_01 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
029
11.12.2019, 23:17 Uhr
holm

Avatar von holm


Zitat:
P.S. schrieb
@wolle1945 <020>
Die Speicher in einer Programmschleife zur Fehlersuche anzusprechen ist im Prinzip schon der richtige Weg. Deine Taktdiagramme sehen zwar schön aus, bilden aber wahrscheinlich nicht die Realität ab. Ein LogigAnalyser idealisiert i.d.R. die Impulsform. Zu empfehlen wäre hier ein echter 2-Strahl-Oszi, zB. EO213,



OMG.

Ist Dir der Unterschied zwischen einem "echten Zweistrahloszi" und einem EO312 bekannt?

Erkläre mal woher eine D13-27GH 2 Strahlen nimmt..

Gruß,
Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
030
12.12.2019, 14:13 Uhr
wolle1945



Hallo,
eine erfreuliche Mitteilung, die Speicherkarte läuft.
schlaub_01 hat gestern Abend den Wurm gefangen. Mir hat der Logikanalysator in Zusammenarbeit mit schlaub_01 geholfen. Der Fehler lag am MREQ-Signal.
Ich habe neue Bilder gemacht.
Kanal 0 CS (Pin 8 U214)
Kanal 1 RD (Pin 10 U214)
Kanal 2 MREQ (Pin 6 DS8205)

beim Schreiben



beim Lesen



gemeinsam sind wir stark, vielen Dank an Alle !
--
mfG wolle1945
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
031
12.12.2019, 16:33 Uhr
KK

Avatar von KK


Zitat:
wolle1945 schrieb
Der Fehler lag am MREQ-Signal.



Und was genau hat den Fehler verursacht?
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
032
12.12.2019, 16:51 Uhr
wolle1945



Ich musste vor kurzem das Board wechseln. Es war noch keine Speicherkarte eingebaut. Bei der Verdrahtung habe ich MREQ und /MREQ nicht beachtet.
--
mfG wolle1945

Dieser Beitrag wurde am 12.12.2019 um 16:51 Uhr von wolle1945 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
Seiten: -1-     [ Technische Diskussionen ]  



Robotrontechnik-Forum

powered by ThWboard 3 Beta 2.84-php5
© by Paul Baecher & Felix Gonschorek