atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Lukas Frank am Di 09.07.2019, 18:52:48
-
Mein Mega STE ist kaputt gegangen. Ich habe eine defekte Magnum STE eingesteckt, seitdem ist der Rechner tot. Beim einschalten bekommt der Monitor ein Signal aber kein Bild. Auf ST-Hoch sagt mein Monitor 640x200 und der Schirm bleibt schwarz. Bei ST-Gering wird der Bildschirm weiß. Bei der Verwendung eines MSTE Testmodul und Nullmodem Kabel plus anderer Rechner ist auch alles tot.
Ich vermute die CPU läuft nicht. Ich vermute einer oder alle der drei Bussteuer GAL 22V10 sind kaputt, keine Ahnung.
Die Magnum STE ist repariert durch Austausch des MACH210 Bausteines und zwei neue 74F157. Ich vermute die Erweiterung läuft wieder weil das Verhalten das gleiche ist mit oder ohne Magnum STE.
Der PLCC Adapter bei der Magnum STE ist hochwertig und von daher der CPU PLCC Sockel in Ordnung.
Ich weiss jetzt nicht wie ich bei der Fehlersuche und Behebung Vorgehen soll da ich auch keine Ersatzteile (GALs) habe?
-
Hallo Frank, das ist nicht so gut wenn das Diagnose-Modul auch nicht's mehr aus gibt.
Im MegaSTE Service Manual (https://docs.dev-docs.org/htm/search.php?find=MegaSTE) ab PDF-Seite 34 Punkt 3. wird ausführlich darauf eingegangen.
-
Das Hilft nicht weiter da man so die MCU/GLUE austauschen soll und ich kann mir nicht vorstellen das die kaputt sein soll ...
-
Das Hilft nicht weiter da man so die MCU/GLUE austauschen soll und ich kann mir nicht vorstellen das die kaputt sein soll ...
Dann überspringst du diesen Punkt wenn die GSTMCU nicht gesockelt sind und du keine aus einem anderen MegaSTE zum testen hast.
Hast du eigentlich ein Oszi um den Takt zu checken?
-
Ja ich prüfe erstmal CLK, RESET und HALT ...
-
Ist natürlich schwierig dem Meister noch meisterliche Tipps zu geben.
Wenn Du auf die Gals tippst siehts wirklich schlecht aus. Andererseits ist die Frage was die magnum da angestellt haben soll. Vielleicht liegts am Einbau und es hat sich was verbogen. Überspannung ist doch eigentlich nicht möglich. Ich glaube Du wirst den Fehler finden und denke das die Gals nichts haben.
Die Kisten sind robuster als man denkt.
-
Welche PALs/GALs sind es denn? Zu einigen gibt es doch die Sourcen.
-
Die drei PAL/GAL 22V10 der Bussteuerung. Die gibt es nicht als Sourcen soweit ich weiss. Holger Zimmermann hat ja die vier Atari TT GALs nachgebaut vielleicht hat er da auch etwas gemacht. Ich frage mal ...
Ich muss erstmal mit dem Oszi schauen was sich an den GALs tut und an der CPU ...
-
Am Mega STE hat er nix nachgebaut, nur die Pals des TT.. ja check erst einmal die Halt Reset/Halt/ Leitung und so.. hast du einen Logic Analyzer ? Wenn ja ran damit an den Bus, zumindest Controll Signale und ein Paar untere Adressen.
-
Am Mega STE hat er nix nachgebaut, nur die Pals des TT..
Ich finde das ist schon eine klasse Leistung. Ich stelle mir das auch recht aufwendig vor. Nur aus den Signalen auf den "Programm-Code" zu schließen. Autsch.
-
CLK ist da, Reset ist 5V und Halt ist 0V. Also läuft die CPU nicht, da kann auch das Test Modul nicht helfen. Ich kann da jetzt nichts machen da ich weiterhin vermute das einer der fünf GALs kaputt ist rum um die CPU. Ich könnte nur durch austauschen den Fehler finden aber ohne Teile geht das nicht.
-
Ich habe nur U11 (C301898) als Source.
-
Die GALs sind U002, 003, 006, 011 und U012
U003, 006 und U011 sind die 20V10
@Idek Tramielski ... dein U11 ist wohl U011, bitte schicke mir das mal ...
Laut Service Manual soll man bei Halt die MCU oder den 68k tauschen. 68K habe ich drei Stück. MCU glaube ich nicht weil ich mal versucht habe zwei MSTE Boards von Guus zu reparieren und die waren auch tot und ich hatte bei beiden die MCU neu gemacht. Aber Chandler aus England hat keine mehr. Und so einfach ist das nicht die mal eben zu tauschen da die MCU 144 Pin aufgelötet ist genau wie beim Atari TT auch.
@tuxie ... was/wie bringt mich der Logic Analyzer weiter? Wie kann ich heraus finden was die Ursache ist das die CPU das HALT Signal auf low zieht?
-
Generell ist es so das ja die CPU beim start verschiedene dinge macht. Irgendwas läuft schief und da zieht sie die Halt Leitung auf Null. Interessant wäre was die Reset leitung macht. Wenn man dann mit dem LA ran geht sieht man was sie als letztes macht und kann die adresse ausfindig machen wo sie als letztes zugegriffen hat.
-
Laut Multimeter ist Reset nach Drücken der Resettaste low und wird dann sofort high nach loslassen und bleibt auch die ganze Zeit Zeit high. Halt bleibt auch beim Resettaste drücken low. Wenn man ein paar mal drückt wird Halt high und geht dann sofort auf low.
Mein Analyzer hat nur bei brauchbarer Bandbreite 8 Kanäle. was soll das bringen?
-
Damit könntest du wenigstens die Control Signale aufzeichnen.
-
Das ist ja einiges an Aufwand. Bringt mich das weiter? Was weiss ich dann?
-
Ob er überhaupt etwas tut! Kannst auch die unteren Adressleitungen anzapfen...
-
Ob er überhaupt etwas tut! Kannst auch die unteren Adressleitungen anzapfen...
Eben. Auch mit 8 Kanälen kann Frank gucken: Was macht /AS auf CPU-Seite? Was macht /AS auf Bus-Seite? Was macht /DTACK auf CPU-Seiten? Was macht /DTACK auf Bus-Seiten? Was machen /LDS und /UDS auf CPU- bzw. Bus-Seite. Gibt es überhaupt einen Zugriff auf dem ROMs (/OE-Signal)?
-
Die erste Frage ist m.E., ob die CPU überhaupt richtig anläuft. Die MMU muß auf den Adressen 0-7 den initialen SP und den initialen PC aus den ROMs einblenden. Wenn das (bzw. der anschließende Memory-Fetch von dort) schief geht, gibt's den doppelten Bus-Fehler und BERR wird ganz zurecht aktiv.
-
Wenn ich die drei Bussteuer GALs U3, 6 und U11 rausnehme geht Halt high und reagiert auch wieder auf den Resettaster. Keine Ahnung was das bedeutet?
Den Logic Analyzer schließe ich nicht an weil mir das zu mühselig ist da ich alles an die Boardrückseite anlöten müsste. Von oben kommt man da wegen der PLCC Sockel nicht ran. Ich stecke da nichts in die PLCC Sockel um die nicht auch noch kaputt zu machen.
Besorge mir lieber ein anderes Board wenn ich eines bekomme?
-
Die erste Frage ist m.E., ob die CPU überhaupt richtig anläuft. Die MMU muß auf den Adressen 0-7 den initialen SP und den initialen PC aus den ROMs einblenden. Wenn das (bzw. der anschließende Memory-Fetch von dort) schief geht, gibt's den doppelten Bus-Fehler und BERR wird ganz zurecht aktiv.
Deshalb ja der Blick auf /AS, /DTACK, /DS, ROM-/OE.
Den Logic Analyzer schließe ich nicht an weil mir das zu mühselig ist da ich alles an die Boardrückseite anlöten müsste. Von oben kommt man da wegen der PLCC Sockel nicht ran. Ich stecke da nichts in die PLCC Sockel um die nicht auch noch kaputt zu machen.
Alle von mir genannten Signale findest Du auch an DIL-Bausteinen, wo sie per Logic-Analyzer-Probe abgreifbar sind. Aber wenn Du lieber ein neues MSTE-Board kaufen möchtest...
-
@czietz ... bitte sehr
Antriebslosigkeit etwas überwunden und den Logic Analyzer mal angeschlossen.
Bevor Halt auf Low gezogen wird tut sich jede Menge. ROM /OE sollte ich das Signal ROM2 von Pin 22 anstatt 24 nehmen, oder?
-
Was kann die defekte Magnum STE nur kaputt gemacht haben?
-
Sorry, /OE war in der Tat ein Tippfehler von mir und ich meinte /CE, also das Signal, das von /ROM2 angesteuert wird, d.h. Pin 22.
EDIT: Oh, und kannst Du Trigger + Aufzeichnungsdauer so wählen, dass Du alles vom Start des MegaSTE (d.h. Reset wird high) bis zum Hänger (d.h. Halt wird low) aufnimmst. Interessant wäre nämlich, wie viele Pulse auf /CE sind, d.h. wie viele Worte aus dem ROM geladen werden.
-
ROM2 wird angesteuert so wie es aussieht.
-
Du känntest mal einen Trigger auf fallende Flanke HALT setzen! und nochmal aufzeichnen
-
EDIT: Oh, und kannst Du Trigger + Aufzeichnungsdauer so wählen, dass Du alles vom Start des MegaSTE (d.h. Reset wird high) bis zum Hänger (d.h. Halt wird low) aufnimmst. Interessant wäre nämlich, wie viele Pulse auf /CE sind, d.h. wie viele Worte aus dem ROM geladen werden.
Wenn Du mir den Trace aus Deinem letzten Posting (im Saleae-Format) zur Verfügung stellst, kann ich auch die /CE-Pulse zählen.
-
Geht nicht weil über 700MB oder was meinst du?
-
Bedeutet das nicht das wenn ROM2 bedient wird (3x Pegelwechsel) das die GLUE in Ordnung ist und Arbeitet?
-
Du hast ja oben unnötigerweise 180 s aufgezeichnet. Mich interessieren die paar hundert Mikrosekunden von Reset->high bis Halt->low. Setze Trigger und Aufzeichnungszeit entsprechend und gib mir bitte dann diese dann viel kleinere Datei. Wie viele /CE-Pulse sind in jenen Mikrosekunden?
-
Ich muss 9 Sekunden aufzeichnen bis Halt auf Low gezogen wird. Trigger steht auf fallende Flanke bei CLK.
Ich weiss nicht was ich machen soll. Ich kann da nicht mit umgehen. Musst mir das schon haarklein beschreiben was ich wie und wo machen soll ...
-
Auch 9 Sekunden ergäbe schon eine kleinere Datei als 180 Sekunden.
Du setzt den Trigger auf steigende Flanke bei Reset und die Aufzeichnungsdauer sagen wir auf 50ms. Dann drückst Du Reset und lässt es wieder los. Erst in diesem Moment sollte Dein Logicanalyzer triggern und alles aufzeichnen bis Halt low wird.
-
Anbei ein Bild ...
So ein 9s Mitschnitt ist knapp 700MB und der 50ms knapp 12MB
-
Anbei ein Bild ...
So ein 9s Mitschnitt ist knapp 700MB und der 50ms knapp 12MB
Gestern waren 180Sekunden noch 700MB, da kommt man durcheinander.
Ist das ein komprimierendes Format?
-
nein, das war nur eine Annahme von czietz, ich hatte nie so lange aufgezeichnet.
9s = 700MB
50ms = 12MB
-
nein, das war nur eine Annahme von czietz, ich hatte nie so lange aufgezeichnet.
9s = 700MB
50ms = 12MB
Aber 700MB ist ja heutzutage kein Hexenwerk mehr. Bei einem Hoster oder in deine Cloud hoch laden und hier den Link rein stellen.
-
Das sieht ganz gut aus, schau mal ob du das dann als CSV exportieren kannst. Dann klemmst du mal LDS - A7 an
Also LDS als A0 - A7 und zeichnest auf, dann auch wieder als CSV speichern, wenn du mir versuchst dazu zu senden dann schaue ich mal ob ich das in Excel zusammen bekomme. Hast du externen Trigger eingang ? Externen Clock ? Externen Clock kannst du CLK8 setzen... wenn du einen externen Trigger eingang hast dann könntest du diesen auf AS legen oder Reset.
-
CSV kenne ich nicht und glaube nicht das sowas geht.
Handbuch -> https://support.saleae.com/user-guide
Bei LDS bis A7 geht nicht weil ich dann keinen Triggerkanal/Signal habe. Gehen würde CLK, LDS und A1 bis A6 ...
16 Kanäle gehen auch aber dann reicht die Bandbreite nicht mehr aus! Und mehr als 12 Prüfklemmen habe ich nicht.
-
CSV geht doch als Export ...
Allerdings ist das 50ms CSV Export rund 107MB groß!
-
Frank hat mir den Trace geschickt. Das habe ich ihm per E-Mail geantwortet. Damit aber alle an der Fehlersuche teilhaben können, hier meine Antwort:
"Sehr schön. Das ist der Ausschnitt, den ich haben wollte! Ich sehe darin, dass die wichtigsten Steuersignale des Bus (AS, DS, DTACK) an sich zu funktionieren scheinen.
Auch werden ein paar Worte aus dem ROM gelesen, bevor der Rechner sich weghängt. Wenn ich das aber das Timing (wie lange low, wie lange high) von /AS mit meinem MegaSTE vergleiche, ist es deutlich anders. Der ausgeführte Code bestimmt das Timing von /AS. Daher meine Schlussfolgerung: Es wird zwar Code aus dem ROM gelesen, aber irgendwie falsch.
Ich hatte mal einen vergleichbaren Fall bei einem STE: Dort hatte eine Datenleitung im CPU-Sockel keinen Kontakt mehr. Damit wurde das entsprechende Bit falsch gelesen, es wurden folglich falsche Instruktionen von der CPU ausgeführt und der Rechner ging nach wenigen Zugriffen in den HALT-Zustand, wie Dein MegaSTE. Ebenso denkbar wäre ein Kontaktproblem bei einer Adressleitung.
Du solltest also als nächstes die Verbindung aller Daten- und Adressleitungen von der CPU (nicht vom CPU-Sockel!) zu anderen ICs (z.B. zu den ROMs) testen. Das ist leider nicht einfach, evtl. schaffst Du es, mit einer ganz feinen Nadel gezielt die Kontakte der PLCC-CPU zu berühren."
-
Das ist übrigens eine Messung ähnlich wie sie Ingo vorschwebt, bloß an meinem (funktionierenden) MegaSTE. Man sieht hier die unteren Stellen der Adressen, die die CPU lädt. Erst den initialen SP und PC von 0, 2, 4, 6. Dann TOS-Code ab (0xE000)30.
Man sieht auch, dass bei einem korrekten Bootvorgang nach dem neunten Zugriff eine lange Pause mit AS=high kommt: hier führt die CPU die RESET-Instruktion aus, die mehr als 100 Zyklen dauert. Diese Pause sehe ich in Franks Aufzeichnung nicht, woraus ich schlussfolgere, dass die CPU keine RESET-Instruktion geladen hat.
Also entweder lädt die CPU Instruktionen von der falschen Adresse oder sie liest ein oder mehrere Datenbits falsch und dekodiert daher die Instruktionen falsch.
In Franks Trace sieht man hingegen sehr schön zwei lange Pausen mit AS=low: mutmaßlich den ersten und den zweiten Bus-Error. Letzterer führt zum HALT.
-
Super, vielen Dank ...
Ich hatte mir den CPU Sockel schon unter einer Lupe mit Licht angesehen und konnte nichts entdecken. Ich löte mir mal eine Prüfnadel, mal schauen ...
-
Christian du bist ein Held.
Rechner läuft wieder, die Kontaktfeder von D12 war ein ganz wenig nach innen gebogen. Nur ein wenig nicht der Rede wert. Habe ich erst mit einer Brille anstatt 1,5 mit 2,5 bemerkt. Diese Mist Sockel ...
-
Cool! Freut mich.
-
Sehr cool! Ein MSTE der schon abgeschrieben wurde läuft wieder.
Und super erklärt, so lernt man auch noch was. Ich habe meinen LA Teil des Oszi bisher nie vewendet. Jetzt sehe ich mal wie man so was macht. DANKE!
-
Ich habs mir fast gedacht, so schnell bekommst du den nicht ins Jenseits ;)
Glückwunsch damit ist das Wochenende gerettet. :D
-
Dachte ich mir schon das da nicht so viel großes ist :) Glückwunsch..
-
Der Sockel sah auf den ersten Blick gut aus. Die Magnum STE hatte die Pins in den Ecken auf einer Seite angelegt.
Meine Laune ist besser, bin Glücklich ...
Die Magnum STE läuft trotz zwei neuen F157 und MACH210 immer noch nicht. Mal schauen ob sich da etwas finden lässt? In meinem MSTE packe ich die aber erstmal nicht mehr rein. Habe noch ein Board von Guus und bekomme noch ein anders ...
-
Wenn ich in letzter Zeit dank der Arbeit mit Holger und Christian gelernt habe ist, das ein LA ein unverzichtbares Werkzeug bei der Fehlersuche ist. Weil man da wirklich sehen kann, wo der Rechner falsch abbiegt Am optimalsten wenn man einen hat wo man alle Adressen anschließen kann und so sogar die Adresse sieht wo es zum Crash kommt.
-
Wenn ich in letzter Zeit dank der Arbeit mit Holger und Christian gelernt habe ist, das ein LA ein unverzichtbares Werkzeug bei der Fehlersuche ist. Weil man da wirklich sehen kann, wo der Rechner falsch abbiegt Am optimalsten wenn man einen hat wo man alle Adressen anschließen kann und so sogar die Adresse sieht wo es zum Crash kommt.
Und, was wäre deine Empfehlung?
-
Gibt da so 36 Kanal Analyzer, sind zwar jetzt nicht high end aber ausreichend... hab da auch so einen bekommen der Tut ganz gut
-
Ich habe jetzt einen weiteren defekten Mega STE. Ich hatte schonmal die Combo MCU/GLUE/Blitter erneuert. Bin aber nicht weitergekommen damit. Das Board ist auch mit Testcartridge und Nullmodemkabel tot. Die GALs sind getestet und alle gut, die CPU ist ok und der MC68901 ist gut. Halt und Reset sind beide high. Daten und Adressen liegen alle zwischen CPU und CLUE Combo fehlerfrei an. Habe jetzt aus lauter Verzweiflung normal die GLUE Combo erneuert mit einem C302183-002/B Chip.
Habe den Logicanalyzer mal an /AS, A1 bis A5, Reset und Halt angeschlossen mit Trigger auf AS. AS geht kurz auf High und gleichzeitig die Adressen ansonsten passiert nichts.
Jemand eine Idee wie ich dem Fehler (Fehlern?) auf die Spur kommen kann?
-
Miss mal /AS und /DTACK, einmal an der CPU und einmal am Combo-Chip MCU/GLUE/Blitter.
Ich nehme an, dass die ICs mit 5V versorgt werden und dass an der CPU und am Combo-Chip jeweils der Takt anliegt, hast Du längst geprüft?
-
Halt geht auf low bei dem Board ...
Beim DTACK Signal von der CPU tut sich nichts und ist dauernd high.
-
Dass HALT und RESET in einem Trace ein paar mal zusammen den Pegel wechseln, ist vermutlich nur auf Prellen des Reset-Tasters zurückzuführen. Sehe ich in manchen meiner STs auch.
Aber dass DTACK an der CPU nie "low" wird, erklärt, dass einfach nichts passiert. Da am Combo-IC hingegen ein DTACK kommt, ist dieser glücklich und generiert keinen Bus-Error. Die CPU wartet somit einfach endlos auf Daten.
Da Du weiter oben schriebst, dass die GALs sicher i.O. sind, sind die Verbindungen und Sockel die nächsten Verdächtigen. Miss bitte nach, dass DTACK vom Combo/Mainboard an allen GALs anliegt, an denen es laut Schaltplan anliegen muss. Dann miss nach, dass DTACK von der CPU mit allen GALs verbunden ist, mit denen laut Schaltplan verbunden sein muss.
-
/DTACK CPU -> U3-5 -> U6-16
/DTACK Combo -> U6-9 -> U11-21 -> U12-16 -> R223 (1,2k) -> 68901-50 -> U801-6
... alles da und gut. DTACK Combo gemessen gegen GND (VCC) hat 700 irgendwas Ohm und CPU DTACK ist unendlich also ohne Widerstand.
Die GALs habe ich mit meinem funktionierenden MSTE getestet.
-
es ist ja durchaus möglich, dass die GALs DTACK von der MMU nur unter bestimmten Bedingungen durchschalten (dazu sind sie ja schliesslich da) und eine dieser Bedingungen nicht erfüllt ist.
VME-Bus z.B. wäre eine Möglichkeit, die dir potentiell in die Suppe spuckt?
-
Ich muss das normal kontrollieren aber ich meine die CPU bekommt auf Dauer 16Mhz ab dem Moment des Einschaltens. Ich meine der Rechner bootet aber nur wenn er 8Mhz bekommt !?!
-
Ja ist so das die CPU sofort und dauerhaft mit 16Mhz läuft.
-
Die Auswahl, ob die CPU 8 MHz oder 16 MHz Takt bekommt, obliegt PAL U012. Je nach Pegel an Pin 13 (CLK8SEL_L) wird an Pin 19 der eine oder der andere CPU-Takt ausgegeben. Den Pegel an Pin 13 von PAL U012 wird wiederum von PAL U011 bestimmt, in dem das "Mega STe Cache/Processor Control"-Register implementiert ist. Pin 22 von PAL U011 ist dafür mit Pin 13 von PAL U012 verbunden. Ich würde mir diese zwei PALs ansehen; nicht nur diese eine Verbindung sondern allgemein alle ihre Lötstellen. Evtl. auch mal die Pegel vergleichen mit Deinem funktionierenden MegaSTE.
-
Mega STE GAL Verbindungen rund um die CPU
U2
1/ U12-19, CPU-15
2/ U1-18, U3-22, U6-20, U11-6
3/ U11-17
4/ U1-8, U3-2, U6-8, U12-11, CPU-9
5/ U1-4, U12-9, R3 2,2k, CPU-7
6/ U1-4, U12-8, R2 2,2k, CPU-8
7/ U1-2, U3-4, , U6-2, R1 2,2k
8/ U3-8, U4u5-20, U8u9-20, U11-23
9/ CPU-11
10/ GND
11/ GND
12/ U3-13, U6-15, U8u9-26, U12-6, R5 330R
13/ U8u9-1
14/ U3-10
15/ U3-9
16/ n.c.
17/ U3-7, U6-13
18/ U11-5
19/ U6--23, CPU-24
20/ VCC
U3
1/ U6-1, U12-12
2/ siehe U2
3/ U12-4, U802-3
4/ siehe U2
5/ U6-16, CPU-10
6/ U11-16
7/ siehe U2
8/ siehe U2
9/ siehe U2
10/ siehe U2
11/ U6-7, U11-11, U202-2, CPU-20
12/ GND
13/ siehe U2
14/ n.c
15/ n.c
16/ n.c
17/ n.c
18/ UB01-12, FPU-Jumper, FPU-29
19/ U1-14
20/ U1-16, U11-13
21/ U1-12, U11-7
22/ siehe U2
23/ U6-11, U11-22, U905-15 (U905-15 und 5 sind nicht belegt. direkt Verbindung U11-22 auf U12-13)
24/ VCC
U6
1/ siehe U3
2/ siehe U2
3/ U11-18
4/ U205-39, U801-7
5/ CPU-21
6/ CPU-22
7/ siehe U3
8/ siehe U2
9/ U11-21, U12-16
10/ FPU-32
11/ siehe U3
12/ GND
13/ siehe U2
14/ n.c
15/ siehe U2
16/ siehe U3
17/ n.c
18/ n.c
19/ U4u5-22
20/ siehe U2
21/ n.c
22/ n.c
23/ siehe U2
24/ VCC
U11
1/ U802-4
2/ UB01-13
3/ UA02-17
4/ CPU-12
5/ siehe U2
6/ siehe U2
7/ siehe U3
8/ n.c
9/ n.c
10/ n.c
11/ siehe U3
12/ GND
13/ siehe U3
14/ CPU-5
15/ CPU-4
16/ siehe U3
17/ siehe U2
18/ siehe U6
19/ U205-28, R224
20/ U1-1
21/ siehe U6
22/ siehe U3
23/ siehe U2
24/ VCC
U12
1/ CPU-55
2/ CPU-54
3/ CLK16, U905
4/ CLK8 siehe U3
5/ CPU-53
6/ siehe U2
7/ CPU-51
8/ siehe U2
9/ siehe U2
10/ GND
11/ siehe U2
12/ siehe U3
13/ siehe U3
14/ U5-27
15/ U4-27
16/ siehe U6
17/ n.c
18/ U8u9-27
19/ siehe U2
20/ VCC
-
Alles da. Habe auch jeden Pin gegen GND gemessen und da ist nichts ungewöhnliches. Alles zwischen 1k und 16k wenn kein anderer Widerstand vorhanden ist.
Ist wie verhext ...
Wie kann ich weiter vorgehen?
-
Alles da. Habe auch jeden Pin gegen GND gemessen und da ist nichts ungewöhnliches. Alles zwischen 1k und 16k wenn kein anderer Widerstand vorhanden ist.
Ist wie verhext ...
Wie kann ich weiter vorgehen?
Den Zeitverlauf der relevanten (oder aller) Signale an den GALs beim Booten des funktionierenden Rechners mitschreiben und mit dem Sorgenkind vergleichen? Irgendwo muß ja eine Abweichung auftauchen.
-
Ich glaube nicht das ich dem Fehler/Fehlern/Problem so auf die Spur kommen kann. Die GALs hatte ich ja schon probiert und die liefen alle. Ich habe ja auch die JED Files der meisten GALs und auch neue programmiert.
Den Zeitverlauf der relevanten (oder aller) Signale an den GALs beim Booten des funktionierenden Rechners mitschreiben und mit dem Sorgenkind vergleichen? Irgendwo muß ja eine Abweichung auftauchen.
Das Problem wird sein das sich da nichts tut ausser bei /AS /DTACK von der GLUE die kurz mal high gehen und dann wieder weg sind.
Eine Unsicherheit ist der CPU PLCC Sockel, die Dinger sind die Pest! Es gibt ganz Alte aus den STs bei denen man die Pins aufbiegen kann. Die neueren Modelle im MSTE sind so gebaut das man die Pins/Federkontakte nicht mehr aufbiegen kann. Die CPU geht auch recht leicht in den Sockel. Die sind halt schnell ausgeleihert. Vielleicht bekomme ich mal zwei neue in GOLD von BEST. Aber ich weiss nicht ob ich die dafür benutzen möchte.
-
Ich hatte jetzt einen 1040ST der durch eine ausgelaufenden Uhrenbatterie tot war. Auch mit Nullmodemkabel und Testcartridge war alles tot. Grund war eine unterbrochene Verbindung von FC1.
Werde jetzt mal beim Mega STE die CPU Steuersignale nachmessen zum Combo Baustein ...
-
U903, eines der beiden VME Bus PALs war als PAL eingelötet. Ich habe das mal gesockelt und ohne U903 kommen über das Nullmodem Kabel anstatt tot gar nichts jetzt zwei Punkte. An das U903 gehen FC0,1 und FC2 und auch unter anderem XDTACK ...
-
IPL0 - U801-63
IPL1 - U801-64
IPL2 - U801-65
XBR - U205-30, RP21-2, Combo-101
XVPA - R801, U801-84
XVMA - Combo-96
FC0 - U205-45 RP27-3, Combo-112, U801-50, U903-7, UA02-14
FC1 - U205-44 RP27-2, Combo-111, U801-51, U903-8, UA02-23
FC2 - U205-43 RP27-4, Combo-110, U801-52, U903-9, UA02-16
XLDS - U1-16, 68901-51, U801-14, U904-14
XDTACK - U6-9, 68901-50, U801-6, U903-12
Alles da und in Ordnung, spricht Pullup Werte sind auch alle richtig.
Ich habe noch ein zweites kaputtes MSTE Board das genau so tot ist mit dem gleichen GAL Satz aber der Monitor bekommt beim Einschalten ein Sync Signal unter ST Hoch und bei ST Gering kommt ein weißes Bild. Da war die Verbindung FC0 zum Combo Baustein unterbrochen, genau unter dem Chip. Konnte das aber mit Fädeldraht Instandsetzen. Dieses Board hat noch den originalen Combo Chip drauf C302183-001. Habe dazu auch Ersatz in Form eines C302183-002/B. Tausche aber besser erstmal nicht.
-
Machen wir doch nochmal mit der Frage weiter, warum der MSTE mit 16 MHz startet. Evtl. ist die Ursache dafür ja auch schon die Ursache für den ganzen Rest. Bitte miss nach, beim kaputten MSTE und bei Deinem heilen MSTE (hier: beim Booten, d.h. vor einer evtl. Umschaltung nach 16 MHz):
- Spannungpegel an Pin 13 von PAL U012,
- Spannungspegel an Pin 22 von PAL U011,
- Clockfrequenz an Pin 19 von U012.
Hast Du die Verbindungen, die Du alle überprüft hast, von IC-Beinchen zu IC-Beinchen nachgemessen oder von Lötstelle zu Lötstelle? Falls letzteres, könnte ja immer noch ein Beinchen keinen Kontakt im Sockel haben.
-
Nur mit großem Widerstreben wegen der Magnum STE ...
la_mste_ok ist von dem Funktionieren Mega STE
U012-13 und U11-22 sind auch in der Bootphase kurz nach dem Einschalten beide Low. Rechner bootet ohne alles von HDD.
la_mste_def ist von dem kaputten Mega STE. Da ist U012-13 und U11-22 immer high egal zu welchem Zeitpunkt.
-
Gemessen habe ich immer an den Beinchen der ICs.
Habe gerade noch mal den ganzen GAL Satz umgesteckt und der war in Ordnung ausser U903 und U904.
Läuft die Umschaltung 8/16Mhz nicht über D0 und D1? Wenn die CPU nicht arbeitet kann dann die Umschaltung doch auch nicht funktionieren, oder´?
-
Warum ist denn jetzt beim Trace des defekten MegaSTE RESET (dauerhaft) low? Egal, bei Reset=low müssen jedenfalls U012-13 und U11-22 low werden, unabhängig von der CPU und sonst allem; so ist es in den PALs/GALs codiert. Und dann bleiben sie low, bis ein Zugriff auf das entsprechende Register den Takt umschaltet.
-
Und dann bleiben sie low, bis ein Zugriff auf das entsprechende Register den Takt umschaltet.
Ja aber wenn die CPU gar nicht arbeitet ist das doch normal so oder nicht? Die GLUE erzeugt auch kein Sync aber das ist wahrscheinlich etwas anderes ...
-
Es ist nicht normal, dass die Signale in Deinem Trace des kaputten MSTE high sind!
-
Jetzt ist es richtig denke ich. Da war doch was mit U011 nicht in Ordnung. Ich musste das nochmal neu programmieren. Das C301898-001 von der Atari HQ CD ist aber fehlerhaft. Das JED läuft aber der Rechner läßt sich per CPX nicht auf 16Mhz umschalten, er springt immer wieder auf 8Mhz zurück. Das "la_mste_def_m018939" ist das Mainboard von dem hier immer die Rede war/ist.
-
Jetzt ist es richtig denke ich. Da war doch was mit U011 nicht in Ordnung.
Hm, in Post #52 hieß es noch: "Die GALs sind getestet und alle gut." Wir hätten uns viel Zeit ersparen können, wenn Du die GALs nicht von Anfang an ausgeschlossen hättest. :( Vielleicht ist ja noch ein weiteres GAL nicht gut. Z.B. ist an der Umschaltung -- wie schon mehrfach erwähnt -- auch U012 beteiligt.
-
Ich habe alle GALs am Anfang als erstes probiert und alle waren in Ordnung, sprich der funktionierende Rechner hat damit einwandfrei gebootet. Vielleicht durch das ganze Umstecken immer wieder und probieren ist da was passiert mit dem selbst programmierten U011. Vielleicht ist die programmierung irgendwie verloren/beschädigt gegangen. Keine Ahnung. Habe das mit dem gleichen Chip neu programmiert dann ging es wieder. Habe nur ein originales U011 aus dem funktionierenden Rechner, das will ich nicht benutzen weil Ersatz dafür nur aus den USA bei BEST zu bekommen ist.
Gestern Abend alle GALs probiert und alle laufen.
Hatte nur ein einzelnes GAL22V10-15ns. Habe heute 4 weitere bekommen und mache mir mal ein weiteres C301898 (U011) ...
-
Obwohl ich das schonmal gemacht hatte ...
Combo Chip
139 XAS U1-18 U407-5
141 XLDS U1-16 U407-4
139 XUDS U1-14
139 RXW U1-12 U407-6
139 XDTACK U6-9 U407-16
110 FC2 CPU-28
111 FC1 CPU-29
112 FC0 CPU-30
96 XVMA U6-5
98 XBGK R222
101 XBR RP21-2
71 Hsync U801-80
70 Vsync U801-81
... alles da. Ebenso alle Daten und Adressverbindungen da und in Ordnung.
Das Board ist ja bekanntlich tot und gibt auch keine Sync Signale aus. Ich habe da noch ein anderes totes Board das aber Sync Signale über den Videoausgang ausgibt, die Monitor BetriebsLED wird grün.
-
Das andere kaputte Board bringt jetzt über Nullmodem das raus ... (läuft Endlos)
Da waren am 68901 zwei Adressen weg.
Schaut nach defekter Speicheransprache aus also vielleicht Combo Chip defekt und Probleme mit der seriellen Schnittstelle !?! Das Board hat original den C302183-001
-
Jetzt bin ich bei dem Board so weit ... Da hängt es dann und es geht nicht weiter. Videoausgabe funktioniert auch.
Es fehlten die beiden CTRAMs U8 und U9
-
Ein kleines Stückchen weiter ...
Oben auf dem Bildschirm steht zusätzlich noch "Testing MFP, Glue timing, Video".
-
Das ist der letzte Stand bei dem anderen defekten Board. Wo kann ich denn jetzt noch nach Fehlern suchen?
Test Cartridge und Mega STE ist wenig hilfreich weil wenn irgendwas fehlt wie die Cache Ram, DMA, Floppy Chip oder eines der GALs bis auf die beiden VME Bus PALs der Rechner völlig tot ist auch über Nullmodem.
-
So das andere Board läuft jetzt ...
Da war einiges an Verbindungen weg. Sieht nicht schön aus, überarbeite ich noch jetzt wo es sich lohnt. FPU Sockel muss wieder eingelötet werden und die VME Kabel müssen neu. Das Board war ursprünglich komplett entkernt. Sockel alle runter incl. kaputten Lötaugen usw. ...
Der Fehler mit der Test Cartridge aus Betrag #81 bleibt. Ich vermute wegen dem Teilfunktionsfähigen GAL U011 mit dem sich der Rechner nicht auf 16Mhz schalten lässt.
Das Board läuft soweit mit Floppy und ACSI Festplatte. Das war jetzt das M036900 Mainboard. Ist jetzt eine gute Grundlage für die Instandsetzung des ursprünglichem Board ...
-
Habe das Board noch mal überarbeitet und sieht jetzt besser aus. Einige Verbindungen habe ich über Durchkontaktierungen hergestellt und bemerkt das die schwarz wurden beim Löten. Also ist da wohl mal die Uhrenbatterie ausgelaufen. Da war ja auch unter dem Combo GLUE Baustein die FC0 Verbindung nicht mehr da. Batteriesäure ist der Tot für so ein Board ...
-
Das hier ursprunglich besprochene MSTE Mainboard M018939 scheint über Nullmodem einwandfrei zu laufen. Schuld das nichts ging war der CPU Atari PLCC Sockel. Habe einen neuen von BEST eingelötet und läuft. Ohne die Testcartridge bekommt der Monitor kein Bild und keine Sync Signale. Mit Testcartridge bekommt der Monitor Sync Signale aber kein Bild. Der Shifter Baustein ist in Ordnung und die GLUE ist Neu. Jetzt gilt es den Fehler zu suchen ...
Das andere Board M036900 läuft ja offentsichtlich aber hat bzw. bleibt mit der Testcartridge bei dieser "Checking Bus error handling" Meldung hängen. Scheint also nicht das GAL 011 zu sein. Ich habe halt nur einen Satz GALs für den Mega STE. Da ist noch etwas anderes im Argen!
-
Jemand eine Idee was der Fehler mit der Videoausgabe sein könnte ?
-
Laut TTL Tester ist der U504 (F257) und der U308 (LS86) in Ordnung. Alle Steuersignale vom Shifter sind auch da und die Monitorbuchse ist in Ordnung und hat Kontakt. Daten und Adressen sind alle da.
Die Testcartridge sagt beim ST-HOCH Test obwohl ein Monitor (ST-Hoch) angeschlossen ist man solle einen Monitor anschliessen !?!
-
Laut TTL Tester ist der U504 (F257) und der U308 (LS86) in Ordnung. Alle Steuersignale vom Shifter sind auch da und die Monitorbuchse ist in Ordnung und hat Kontakt. Daten und Adressen sind alle da.
Die Testcartridge sagt beim ST-HOCH Test obwohl ein Monitor (ST-Hoch) angeschlossen ist man solle einen Monitor anschliessen !?!
Für das Monochrome-Detect Signal ist der MFP zuständig. Dort mal I7 prüfen.
Wenn das passt, kann es durchaus sein, daß der IRQ-Request es nicht bis zur CPU schafft (da ist wieder /DTACK im Spiel).
-
Alle Verbindungen da. 68901 getauscht und der HCT04 ist in Ordnung. XSINT von der GLUE ist High und der HCT04 Ausgang ist Low. LS86 Eingänge sind beide genau wie der Ausgang hin zum MFP sind beide low.
An meinem Bastelraum BENQ Monitor wird die LED grün also bekommt der Monitor ein Signal aber an einem NEC 1970NX tut sich bei ST-Hoch und ST-Low nichts, kein Signal.
Vielleicht doch die GLUE kaputt !?!
-
Wenn ich "G" für den kurzen Blittertest eingebe kommt ein "pass" und die Monitor BetriebsLED wird grün also bekommt er dann ein Signal ...
-
U504 (F257) Pin7 geht auf low für ST-Hoch auf high bei ST-Gering
U308 (LS86) Pin11 geht bei ST-Hoch auf low und bei ST-Gering auf High
... alles richtig soweit, oder?
-
... der IRQ-Request es nicht bis zur CPU schafft (da ist wieder /DTACK im Spiel).
XDTACK am MFP sollte ja in Ordnung sein, ebenso am GLUE Combo und an den GALs rund um die CPU. Ansonsten würde ja gar nichts gehen. GAL Satz ist komplett auch in Ordnung weil das andere Board damit läuft. Bleibt vielleicht noch die TTSCU U801, oder? Wobei die aauch in dem anderen Board läuft. Die Verbindungen kann ich noch prüfen ...
Das Mainboard M018939 um das es hier geht hat bis jetzt keine Fehlerhafte Verbindung gehabt.
-
... der IRQ-Request es nicht bis zur CPU schafft (da ist wieder /DTACK im Spiel).
XDTACK am MFP sollte ja in Ordnung sein, ebenso am GLUE Combo und an den GALs rund um die CPU. Ansonsten würde ja gar nichts gehen.
Ich war da schief gewickelt, das Monochrome Detect Signal löst im TOS keinen Interrupt aus (der ist gesperrt), sondern wird (im VBL-Interrupt) direkt am MFP-Register gepollt. Das wird wohl auch die Diagnose-Cartridge so machen. Wenn da nie ein Signal ankommt, ist m.E. entweder die Verbindung von der Monitor-Buchse zum MFP irgendwo unterbrochen oder der MFP kaputt.
-
Der MFP funktioniert in einem anderen Board. An einem RGB Monitor bei ST-Gering kommt ja auch kein Bild und der Monitor bleibt schwarz.
U504 (F257) Pin7 geht auf low für ST-Hoch auf high bei ST-Gering
U308 (LS86) Pin11 geht bei ST-Hoch auf low und bei ST-Gering auf High
... alles richtig soweit, oder?
Auch mit der Testcartridge macht der MSTE bei einer Umschaltung RGB auf Mono einen Reset. Das kaputte Board macht das aber nicht.
-
Video läuft jetzt wieder. Es war der Serienwiderstand R531 von 33Ohm defekt und hatte über 20k. Ebenfalls defekt weil RGB Darstellung nicht ging waren alle drei Treiber Transistoren für Rot, Grün und Blau. Das RGB Bild flimmert aber, da muss ich weiter nach Fehlern suchen. Und der VME Bus funktioniert nicht.
-
Das Video flackert ein wenig. Hatte schon die Monitorbuchse gegen eine neue getauscht aber daran lag es nicht. Der VME Bus ging nicht, das lag daran das U903 Pin1 keinen richtigen Kontakt zum Sockel hatte.
Das geflickte M036900 Board läuft soweit auch wieder. LDS war nicht am Romport und an U904. Jetzt geht der VME Bus dort auch wieder. Das einzige was bleibt ich der Fehler mit der Testcartridge die bei "Checking Bus error handling" hängen bleibt. Alle Signale am Romport sind da.
-
Das Video Flackerproblem ist repariert. Weiss jetzt nicht genau woran es lag, habe den 33Ohm Schutzwiderstand auf dem H-Sync Signal erneuert und den Transistor für das Mono Video Signal erneuert.
Das geflickte M036900 Board hat immer noch den Test Cartridge Fehler. Wenn der Rechner stundenlang ausgeschaltet war bootet die Cartridge komplett durch. Danach hängt es bei "Testing MFP, Glue Timing, Video". Über Nullmodem Kabel fehlt die MFP Meldung. Wenn man da mal einige Male resetet kommen zwei zusätzliche Fehlermeldungen. Danach ein Reset und er hängt wieder wie zuvor bei der MFP Meldung.
Ohne Testmodul läuft das Board von Diskette und auch von Festplatte.
----------- Das ist alles was das Chips&Chips Dokument hergibt ...
E9= Bad instruction fetch. Interne Fehlermeldung der CPU.
EA= Address error. Siehe E9.
EB= Bus error. Pin 22 CPU, Pin 30 Glue und Pin 39 am Blitter (sofern
der Rechner einen Blitterchip hat) überprüfen.
EB Bus Error Access Address: FF8604 Program Counter: FA2B1A
Diese Fehlermeldung wird ausgegeben, wenn ein defekter Floppycontroller
vorhanden ist bzw. wenn das System OHNE diesen gestartet wurde.
Der Floppycontroller wird nämlich vom DMA-Chip aus angesprochen.
Testing MFP, Glue timing, Video
T5 PSG Bus Test PassT6 1772 Bus Test
EB Bus Error Access Address: FF8604 Program Counter: 004016
EB Bus Error Access Address: 000392 Program Counter: FA2A7C
Pass
Der Soundchiptest ist erfolgreich, während beim zugriff auf den
Floppycontroller ein Bus Error auftritt. Bei diesem Beispiel wurde
ein Rechner überprüft der OHNE Floppycontroller gestartet wurde.
EB Bus Error Access Address: FA09D4 Program Counter:FA09D4
EB Bus Error Access Address: 0C0011 Program Counter:FA09CE
Dies ist normal, weil das Testmodul nur durchgehenden Speicher testen
kann und einen Fehler ausgibt wenn eine Bank anders bestückt ist als
die andere.
-
Beim Uhrentest kommt ein "pass" und dann hängt er manchmal, ich überprüfe mal alle Verbindungen da am Chip ...
Chandler aus dem Englischen Forum hatte den gleichen Fehler und bei ihm waren es die beiden Cache Rams U4 und U5. Habe bei mir alle vier schon getauscht also U4,5,8 und U9
Habe eigentlich schon alles überprüft !
-
An dem Uhrenteil ist alles in Ordnung.
EB = Bus error. Generated internally by the 68000 or externally by GSTMCU. Usually caused by device not responding. Displays the address of the device being accessed.
E9 = Bad Instruction Fetch.
EB welches Gerät antwortet nicht? 01FFFC PC: FA3760
Was ist genau gemeint mit dem E9 Error?
-
Die Mega STE Test Cartridge bootet ja von 50mal Reset einmal durch. Habe alle Tests durchgeführt und so weit alles Fehlerfrei mit einem "pass". Der Audiotest sieht auf dem Oszi auch gut aus.