Es gibt Elektroniker die schwören darauf defekte D-RAM-ICs dadurch zu ermitteln, dass ein funktionstüchtiger RAM nacheinander über alle eingelötete RAM-ICs geklemmt wird. Das habe ich aber selbst noch nicht ausprobiert - klingt aber, als ob es einen Versuch wert ist.
Matthias
Irgendwie sieht das nicht korrekt aus...
Ein RAS Signal müsste doch dann Aktiv sein, wenn das CASL aktiviert wird?
Die unteren 8 Bit sind vom DS8287 D3 (D0-D7)
Irgendwie sieht das nicht korrekt aus...
Ein RAS Signal müsste doch dann Aktiv sein, wenn das CASL aktiviert wird?
Ja, laut Datenblatt sollte RAS aktiv sein, wenn CAS aktiv ist.
Nicht zwingend, falls es mehrere Bänke gibt, kann durchaus CAS kommen ohne RAS, weil eben diese Bank nicht selektiert ist.
Nicht zwingend, falls es mehrere Bänke gibt, kann durchaus CAS kommen ohne RAS, weil eben diese Bank nicht selektiert ist.
Prinzipiell richtig, aber oben werden alle Bänke (RAS0, RAS2, RAS4) gleichzeitig aktiviert und CAS erst einen Zyklus später - ohne RAS und da kommt auch das Chip Select für den 8287.
Man könnte den Eindruck gewinnen, dass die Verzögerung des RAS Signals nicht passt.
Das Problem ist, dass ich die Schaltung nicht ganz durchschaue...
Hier mal die zusammengefügten Scans des Schaltplans....
Moin,
vielleicht hat hier jemand Erfahrung mit 8086 Assembler...
Mein Testprogramm funktioniert (theoretisch) in der DOS-Box.
Praktisch nicht auf dem EC1834.
Beim Test wird der Code einfach nicht ausgeführt.
Die prozedur wird aufgerufen, der erste Text wird ausgegeben und dann springt die Routine zurück in das Hauptprogramm.
Der vollständige Code ist hier zu sehen:
Mein Code zeigt noch den Text "msg_test1_1" an. Die Zeile
call OUTPUT_HEX_DIGIT4 ; <--------- WIRD NIE ERREICHTwird nicht aufgerufen.
; TEST SEGMENT 4xxxx with even numbers
; set di to start offset
TEST1:
mov si, msg_test1_1
call OUTPUT_TEXT
mov BYTE [cnt_error], 0
mov BYTE [sig_abort], 0
mov BYTE [tst_byte], 0
push bx
push es
push di
cld
; init offset/data
; sub di,di
sub ax,ax
mov cx,LOOPSIZE
mov dl,8
; init start segment
mov bx,RAMEXT_START
mov es,bx
mov ah,BYTE [tst_byte] ; init compare value for test
mov al,BYTE [tst_byte] ; init value for test
call OUTPUT_HEX_DIGIT4 ; <--------- WIRD NIE ERREICHT
call OUTPUT_CR
.loop_test1:
mov al,BYTE [tst_byte] ; init value for test
mov es:[di],al
mov al,es:[di]
push ax
xor al,ah ; Zero flag set, when equal
pop ax
jz .OK1 ; zero, so value is equal
; ERROR CONDITION HERE
call PRINT_ERRADDR
call ERRORCNT_WAIT ; press "q" for abort
cmp BYTE [sig_abort], 1
jz .loop0_end ; abort requested
.OK1:
inc di
inc di ; inc by 2
mov ax, 0
loop .loop_test1
; print current test offset
sub di,2
call OUTPUT_HEX_DIGIT4
call OUTPUT_CR
add di,2
; decrease outer loop counter
dec dl
jz .loop0_end ; exit when done
mov cx, LOOPSIZE
jmp .loop_test1 ; another round
.loop0_end:
pop di
pop es
pop bx
call OUTPUT_CRLF
call OUTPUT_CRLF
retIch weiß, der Code ist alles andere als schön.
Verbesserungen nehme ich gerne an... 
Ursprung ist die Testroutine vom BIOS. Die arbeitet mit dem DS Register, da ich das aber öfter zur Ausgabe benötige, habe ich das ES Register genommen.
Wie gesagt - in der DOS Box funktioniert der Code so.
Gruß
Mario
Da ich gerade mit dem Code nicht weiter kam, habe ich die Karte mit dem defekten RAM IC zur Vergleichsmessung ran genommen.
Das bestätigt erst Mal das, das RAS+CAS normal gleichzeitig aktiv sein sollte.
Das gibt mir Hinweise, wenn ich das weiter ausgewertet habe. Bei dieser Karte wäre mein Tool ganz hilfreich, den defekten zu bestimmen... 
Die nächste Platine ist repariert.
Auf der heutigen waren 2 ICs (D28, D35 = RAS0, CASL: D1 + Parity E) defekt.
Ausgetauscht und im RAM Test danach alle Tests bestanden.
Bleibt noch eine Erweiterungsplatine.
Dort wurden quasi alle Adressen als Defekt markiert. Da ist auf jeden Fall was in der Ansteuerung defekt.
Vielleicht schaffe ich morgen den Schaltplan noch, aber mein Männerschnupfen fordert vermutlich langsam seinen Tribut. Muss erst Mal kürzer treten.
Ein Glück, dass ich gestern entschieden habe, nicht nach Hannover ins Büro zu fahren... In mehrfacher Hinsicht...
Mario
RAMBUG.EXE & Die Karte nach der Reparatur
Mein Schaltplan der RAM Karte ist leider immer noch nicht komplett fertig digitalisiert, aber ich habe den Drang, die 2. Karte zu reparieren.
Da das RASx Signal nicht passend triggert, habe ich nochmal nachgeschaut und im Plan auf D15 Ein FlipFlop in dem Bereich entdeckt, der den 8205 für das RAS steuert.
Ich habe das zwar bereits im RCT geprüft, aber das muss nichts heißen. Da will ich nochmal schauen. Im Sockel ist das ja eine Minuten-Sache...
Unerwartet aber der DS8205 auf D22 ist komplett Stumm....
hier RAS0-1 - RAS0 geht nur Zeitweise aktiv, weil der Ausgang permanent auf H ist und die NAND Gatter entsprechend Schalten. Nur nicht im rechten Moment...
Jetzt fliegt er raus, in 45 Minuten weiß ich mehr...
Krass... Etwas weniger als 45 Minuten später bootet er mit 640KB.... 
Zur Beruhigung aller... Jetzt habe ich noch einen defekten Floppycontroller hier.
Und dann ist da noch der HD Controller, wo ich noch keine Ahnung habe, was der macht...
Ach ja - die Monochrom Karte ist ja auch noch da.
Hab da noch ein paar Sachen in petto...
Das heißt, du hast den DS8205 getauscht und jetzt geht er?
Jupp, hab die Bilder oben gerade noch nachgeschoben...
Ich würde mal auf ein Adresskonflikt zwischen der XTIDE-Karte und der Monochrom-Karte tippen...
Die Quellcodes anzuschauen - wenn man die hat - ist ganz oft eine geniale Idee...
Ich musste beim XT-IDE BIOS gar nicht weit lesen, bis ich einen Geistesblitz hatte:
Zum Test der Karten habe ich an den DIP Switches am Board gedreht - die Doku ist furchtbar, weil die nicht ganz eindeutig, vor allem mit dem Wissen, dass die manchmal falsch herum eingebaut sind.
Jedenfalls verglich ich nun die DIP Switches der Boards und stellte das zweite nun gleich, wie beim anderen ein und es bootete wieder von CF Karte! 
Was habe ich entdeckt?
Es gibt im XT-IDE eine Konfiguration, die Variablen im BIOS RAM Bereich setzt.
Diese werden aber auch von den DIP Switches beeinflusst.
Anscheinend überschreibt das BIOS diese Variablen, wenn mehr als 2 Floppies in den DIP Switches konfiguriert sind!
Dann scheitert das BIOS mit Error 1h, weil es die Einträge nicht findet. Die Ports hingegen funktionieren tadellos!
Man, was für ein Ding - und wieder etwas schlauer geworden.
Also mit dem Floppy weiter...
Mit provisorisch (Lageplan temporär mit farbigem Stift beschriftet ) neuen Plänen mal wieder in die Werkstatt...
Weitere Messungen ergaben, dass die 4MHz an A22 auch anliegen, dass der DL074 nicht schaltet liegt an dem DL175, der die Frequenzumsteuerung schalten soll.
Vergleiche mit der funktionierenden Platinen ergaben, dass der A13.2 einfach nicht auf H Pegel gehen sollte, was er tut.
Meine Güte, wie hat sich der Einkauf im polnischen Onlineshop letztes Jahr gelohnt. Bis jetzt habe ich alles da...
.....
Oh man... Das erste mal, dass ich die Durchkontaktierung bei einem IC mit eliminiert habe, zumindest auf der Oberseite.
Der wollte nicht raus... Im Nachhinein hätte ich ihn mit dem Seitenschneider erledigen sollen.
Und das schlimmste. A12 und A13 sind in anderer Richtung eingelötet.
Ich sehe jetzt erst, dass da einige um 180° gedreht sind.
Damit ist die Messung natürlich auch sinnlos - auch wenn ich da unterschiedle Ergebnisse zur anderen Platine hatte.
Zum Glück betrifft es nur eine Leiterbahn, wo der Via keine Verbindung mehr hat...
......
Und wann man viel misst....
ok, jetzt richtig herum gemessen. Der Reset Eingang floatet.
Der Reset kommt von einem NAND (A23, rechts neben dem neuen NAND), dass am Bus-Reset hängt.
Wenn ich nur 5V auf das Mainboard gebe, dürfte da nichts passieren...
Pöhser Pursche...
Morgen dann den nächsten Auslöten. Hoffentlich ohne weitere Schäden....
ok, Messung ergab Probleme an weiteren Gattern. IOR/IOW kam Anfangs mal, dann aber nicht mehr.
Man, was muss das Teil durch gemacht haben... Der Keller in Bayern war wohl feuchter, als gedacht...
Also weiter Stück für Stück prüfen. Den nächsten finde ich sicher.... 
