atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Lukas Frank am Di 18.10.2022, 17:40:04
-
Habe ein Atari Falcon Mainboard in Reparatur. Das Board war tot als es ankam bei mir, ich habe ein Testmodul eingesteckt und damit hätte das Board booten müssen da das Testmodul das NVRAM auf US Standard Werte zurücksetzt. Über ein Nullmodem Kabel mit Testmodul kommen nur zwei einzelne Zeichen ansonsten alles tot.
Habe dann mal das NVRAM gegen ein neues mit neuer Batterie ersetzt. Das ging mit reichlich neuem Lötzinn und Entlötstation bis auf einige wenige Pins ganz gut. Es war ein Motorola NVRAM verbaut bei dem die Pins frei lagen von oben sodass ich die abkneifen konnte und einzeln auslöten konnte. Das ist besser um die Platine zu schonen.
Habe mal mein Oszi ausgepackt und schaue mir als nächstes morgen mal die Clocks die aus dem Combel kommen und verteilt werden an ...
-
Clocks ...
-
Der Monitor wird grün und bekommt also ein Sync , die Info sagt 640x240 Pixel bleibt aber Schwarz ...
Der erstmal 8Mhz Clock aus dem Combel ist da und wird auch über den F04 verteilt.
-
Ich würde vermuten Kabelbruch oder kalte Lötstelle. Hat der Besitzer da irgendwo Hand angelegt... aus welchem Grund auch immer? Ich würde auch mal einen NVRAM Reset machen... ist ja kein Aufwand.
-
Man sieht es schlecht auf den Bildern, da ist obenhalb vom Clockpatch eine Leiterbahn weg ist aber gepatcht indem der Anschluss direkt aus der Durchkontaktierung genommen wird. Beim SDMA ist ebenfalls eine Leiterbahn durchtrennt aber mit einem schwarzen Kabel gebrückt. Am AJAX Floppy Controller zu einen Transistor ist ein Patchkabel. Es ist ein C-LAB Falcon Board. Der Rechner wurde als funktionsfähig gekauft war aber immer schon tot ...
Der NVRAM Reset wird ja automatisch gemacht auf US Standardwerte wenn das Testmodul im Romport steckt ...
Verbaut ist jetzt ein neues NVRAM Modul von Centuriontech
-
Habe mal den Reset Pin18 am NVRAM kurz auf GND gelegt aber ohne Änderung. Das hatte bei meinem Falcon geholfen. Habe mal den 32Mhz Haupttakt vergleich mit meinem Falcon der läuft gemacht und das sieht gut aus. Mein Oszi hat eine zu geringe Bandbreite.
Da ist ein Geisterbild auf dem Monitor ...
Reset und Halt sind beide runter auf 0Volt. Address und Daten Leitungen sind alle in Ordnung und haben keinen Schluss. Habe mal die Ramkarte und das TOS PROM rausgenommen aber ohne Änderung bei Reset und Halt. Das Service Manual sagt Combel tauschen?
-
Da fehlt L3 und L4 auf der Platine. L3 steht in Verbindung mit R18 (220R) und L4 mit R4 (220R) ...
Muss das so? Ist das ein C-Lab Patch?
Die beiden Schaltpläne die ich habe sind recht schlecht Leserlich ...
-
Hallo Frank, ein Bild von meinem MKII Board...vielleicht hilft Dir das weiter.
Habe das Board leider nicht bei mir, weil der NVRam getauscht wird, sonst hätte ich ein besseres Bild gemacht.
Gruß Uwe
-
Schlecht lesbarer Schaltplan hin oder her; es ist erkennbar, dass L3 und L4 Filter für Midi-Out sind. Falls die nicht (auf der Rückseite) gebrückt wurden, wird diese Buchse nicht korrekt funktionieren. Aber für den grundlegenden Betrieb des Falcon sind sie nicht nötig.
EDIT: Sind bei kohli79's Board ja auch nicht bestückt. Vielleicht tatsächlich gebrückt?
-
Geht denn Reset jemals auf High? Falls ja: Für wie lange? Scope auf Single-Shot, Reset-Taste drücken und wieder loslassen. Vielleicht ist ja einfach die Reset-Schaltung kaputt. Oder jemand, der vor Dir daran herumgebastelt hat, hat eine Leitung durchtrennt.
-
Noch ein Bild von unten ...
-
Ja in der zwischen Zeilt dachte ich auch an Midi wegen der 220R Widerstände.
@czietz Reset verstehe ich nicht. Wenn der Taster nicht gedrückt ist, ist Halt und Reset beides Low also 0V. Wenn ich den Taster drücke gehen Halt und Reset auf High also +5V. In meinem Verständnis verhält sich alles genau falsch herum?
-
Wo genau(!) misst Du diese Signale denn?
-
Bei dem ganzen SMD Zeug schwierig deshalb messe ich mit dem Multimeter am Expansion Connector J16 XRESET und XHALT ...
-
@czietz ... alles Blödsinn habe falsch gezählt.
Reset und Halt sind in Ordnung also beide High also +5V und wenn ich den Taster drücke Low also 0V
-
Das mit L3/4 scheint ein C-Lab patch zu sein. Also geht bei dem Rechner der Midi Out nicht? Da ist keine Brücke auf der Platinenrückseite.
Das Service Manual sagt immer noch Combel Tausch ...?
-
Mein nächster Schritt in so einem Fall wäre: CPU-Aktivität testen. Wenn Reset und Halt high werden, 5V und Takt vorhanden sind, sollte die CPU anfangen, Buszugriffe zu machen. AS, DS, DSACK ansehen. Die ersten Zugriffe gehen aufs ROM. Dessen CE-Signal testen.
Midi-Out: Wegen L3 und L4, fehlen die Verbindungen zu Pins 1 und 3 der Buchse. Keine Ahnung, welche Funktion sie haben.
-
Hier mal eine Messung ...
Reset ist komisch weil auf dem LA Bild low aber das Multimeter zeigt +5V also high
-
Dann solltest Du nochmal das Messsetup prüfen, d.h. z.B., ob Du an den richtigen Pins misst. Die Reset-Leitung kann ja nur low oder high sein; nicht beides gleichzeitig.
Abtastrate 8 MS/s ist etwas wenig, aber ich meine schon Zugriffe auf das ROM zu sehen. Ist das ROM vielleicht defekt? Oder eine Verbindung in dessen Sockel wackelig?
-
Reset ist J16 Pin17 ...
Das mit dem PROM ist schwierig weil ich keinen passenden Adapter für meinen GALEP habe. Kann ich also nicht prüfen.
Müsste ein neues TOS 4.04 kaufen oder jemanden haben der mir eines macht?
-
Im Bild von kohli79 sind mehrere rote Kabel am SCSI-Adapter.
Bei dem MKII fehlen die Kabel am SCSI-ADapter
-
Ein neues TOS 4.04 kann ich dir schicken.
-
Alles in Ordnung ...
0 = CPUCLK_C J16 Pin23
1 = AS U63 Pin9 oder U68 Pin3
2 = DS030 U62 Pin3
3 = DSACK0 U63 Pin2
4 = ROM CE (XROM2) VIA U41 Pin3
5 = Reset J16 pin17
@czietz ...Reset wird erst später high siehe Bild zwei
-
Ein neues TOS 4.04 kann ich dir schicken.
Schick mal ...
-
Müsstest Du Dir bei einem 16 bit Zugriff, wie aufs ROM, nicht DSACK1 angucken?
-
mit DSACK1 ...
-
Höhere Auflösung ...
-
Okay, der Zugriff der CPU aufs ROM wird zwar dekodiert, aber nie mit DSACK1 quittiert. Ich habe meinen Falcon nicht zur Hand (und hätte sowieso in den nächsten Tagen keine Zeit für Messungen), aber ich meine, im Falcon wird DSACK1 vom GAL U63 als Reaktion auf DTACK (was vom Combo kommt) generiert. Stellt sich also die Frage: Was passiert an DTACK (U63, Pin 8) nach dem Reset?
-
Incl. DTACK ...
DTACK und DSACK1 und DSACK0 abgenommen an U63
Da die Pegel da wechseln ist das GAL U63 ja wohl in Ordnung, da kann ich mir einen Austausch ersparen? Bis auf DSACK1 das ist immer High auch wegen Pullup Widerstand. Vielleicht doch U63 defekt der Pin19 (DSACK1) müsste ja ein Ausgang sein.
-
Das GAL U63 müsste DTACK vom Combel (was ja kommt) nehmen und in DSACK1 für den 68030 übersetzen (was ja nicht kommt). Die genauen Gleichungen dafür sind mir aber nicht bekannt. Dennoch deutet mit Deiner letzten Messung einiges auf ein Problem mit diesem GAL. GALs können im Laufe der Jahrzehnte leider ihre Programmierung verlieren.
PS: Wie schon erwähnt, ist das alles aus dem Gedächtnis, ohne eigene Messungen.
-
Das GAL kann ich neu programmieren wenn die JED richtig sind. Da der Clockpatch aber oben drauf gelötet ist wird das nicht so einfach. Ich tausche den normalen Federsockel gegen einen Präzision Sockel und stecke da ein Modul von ...
https://centuriontech.eu/product/falcon030-clockpatch/
... rein, dann kann ich das GAL U63 einfach oben auf stecken und tauschen.
@drelius ... bestellt mir das mal und schicke mir das zu ...
FALCON 030 V1.0 - U63 - May 30, 1997
*IDENTIFICATION
F30_U63;
*TYPE
GAL16V8;
*PINS
/DSK0 = 2,
/Z3A = 3,
HIGHZ = 4,
EDSP = 5,
DLYAS = 6,
/BERR = 7,
/DTK = 8,
/AS = 9,
P12.r = 12,
/EDTK.t = 13,
P14.t = 14,
/EBERR.t= 15,
P16.r = 16,
/EXP.t = 17,
P18.t = 18,
/DSK1.t = 19;
*BOOLEAN-EQUATIONS
DSK1.e = P18;
DSK1 = AS;
P18.e = VCC;
P18 = /HIGHZ * AS * Z3A
+ /HIGHZ * AS * DTK * DLYAS * /EDSP * /EXP
+ /HIGHZ * AS * EDTK * DLYAS;
EXP.e = GND;
P16 = AS * DLYAS;
P12 = AS * P16 * BERR * /EDSP * /EXP
+ AS * P12;
EBERR.e= AS * DLYAS * /DSK0 * /EDTK * /EDSP * /EXP;
EBERR = BERR * DTK
+ /DSK0 * /EDTK * P12
+ EBERR * AS;
P14.e = VCC;
P14 = HIGHZ * AS * Z3A
+ HIGHZ * AS * DTK * DLYAS * /EDSP * /EXP
+ HIGHZ * AS * DSK0
+ HIGHZ * AS * DSK1;
EDTK.e = P14;
EDTK = AS;
*END
-
Hallo Frank!
DTACK und DSACK1 und DSACK0 abgenommen an U6
Wenn ich mir Deine bisherigen Messungen alle anschaue, habe ich eher den Eindruck, dass Dein Falcon schon beim Zugriff auf Adresse 0 hängen bleibt. Sprich, wenn er auf die gespiegelten ersten 6 Byte vom Betriebssystem zugreift. Hinzu kommt, dass - auch beim Falcon - die Sync-Signale für den Monitor (HSYNC und VSYNC) schon aktiviert werden, auch wenn der Rechner noch gar nicht richtig gestartet ist. Das erklärt auch, warum Du ein "Geisterbild" von einem Desktop auf Deinem Monitor angezeigt bekommst.
Da ist noch irgend etwas anderes im Argen. Eine Ferndiagnose ist schwierig.
Was ich eher vermute ist, dass der Prozessor gar nicht richtig los läuft. Von den bisherigen Messungen scheint der 68030 schon noch die Bussignale anzulegen. Insofern scheint der Prozessor - als solches - noch in Ordnung zu sein. Meine Vermutung:
Entweder fehlt dem Prozessor ein Control-Signal. Das könnte /BR, BG, /BGACK, /AS, /DS, ... sein. Bitte kontrolliere mal die Beinchen vom Prozessor, ob die alle festgelötet sind oder zum benachbarten Pin (oder Pad) eine Verbindung haben.
Alternativ stimmt etwas mit dem Betriebssystem bzw. mit dem ERPOM nicht. Messe bitte auch mal die Leitungen vom EPROM durch, ob die auch wirklich alle Kontakt haben und dort ankommen, wo sie hin sollen.
Gruß Robert
-
Vielen Dank für die Tipps auch die von Christian ...
Alles rund um die Pads für den Clockpatch ist alles recht verbastelt. Ich warte jetzt erst mal bis ich das neue Clockpatch Modul habe und das eingebaut habe. Bei der Gelegenheit schaue ich nochmal ganz genau wegen der CPU Pins und bis dahin habe ich auch ein neues TOS PROM.
Hatte schonmal ganz zu Anfang alles unter einer Lupe angeschaut und alle Bausteine wie SDMA Videl und auch der Combel sind alle ungefähr ein drittel neben der Pads verlötet. Sah aber alles gut aus?
-
Hallo Frank,
Danke für die das Bereitstellen der ZIP-Datei mit Falcon-GALS auch im Quelltext, ich hatte bisher nur aus den original GALs ausgelesene JEDEC-Files, da Atari damals ja dankenswerterweise auf das Brennen des Ausleseschutzes verzichtet hatte.
Nun etwas OT:
Dabei ist mir eine alte Information in den Sinn gekommen, dass der Entwickler der CT6x-Erweiterungen "erhebliche?" Verbesserungen an den Falcon GALS entwickelt hätte.
Sind diese verbesserten GALS frei verfügbar? Ich habe auch die schnelle nichts dazu gefunden.
Laufen die überhaupt in einem Falcon ohne ein CT6x-Board?
Hintergrund: ich habe hier auch ein knapp 30 Jahre totes Falcon Board, welches ebenso lange auf Zuwendung wartet. Dein Thread hier macht mir etwas Mut.
Viel Erfolg mit dem Board!
edit: CT6x-Verbesserung auf CT6x-Board geändert
-
Clockpatch ist eingebaut, habe dazu den alten IC Sockel ausgelötet und einen Präzisionsockel eingelötet. Die alten Kabel habe ich drin gelassen und nur angepasst.
An U62 wurde auch gelötet an den Pins GND und VCC. U63 kann ich jetzt Testen und eventuell austauschen.
-
@drelius ... läuft wieder.
Die Vermutung von @czietz war richtig und die GALs defekt. Habe mit dem GABI am Atari TT alle GALs ausgelesen und bei U62 und U68 hat die Software zur Hälfte ausgelesen und dann gemeckert das GAL sei Kopiergeschützt. Die GALs sind original Atari wegen den Atari Nummern drauf vermute ich und meines Wissens nicht Kopiergeschützt. Bei dem originalen U63 sagt GABI im Vergleich mit U63 aus Beitrag #30 Unterschiede.
Habe U62, U63, U67 und U68 auf Lattice 16V8-15ns aus dem Beitrag #30 neu programmiert. Habe jetzt nicht solange getauscht um herauszufinden welches original GAL oder GALs defekt bzw. Fehlerhaft sind/waren. Alle vier neu und jetzt läuft es ...
-
Super.
Gruß Wolfgang
-
Freut mich. (Sowohl, dass ein Falcon gerettet werde konnte, als auch, dass ich korrekt geschlussfolgert habe.)
-
Das mit L3 und L4 ist glaube ich Midi Thru was jetzt nicht mehr geht. Warum C-Lab das gemacht hat, keine Ahnung?
-
Gute Arbeit ! ! ! 8)
-
Sehr cool 8)
-
U63 scheint beim schnellen drüber schauen gleich zu sein, U67 scheint abweichend zu sein im Vergleich mit den Dateien aus Post #30. Und U62 und U68 waren defekt oder kopiergeschützt ...
-
@Lukas Frank ich gratuliere Dir zu dieser Wiederbelebung.
-
Danke Frank.
Hab dir eine PM geschrieben.
-
drelius berichtet das nach dem Zusammenbau das NVRAM nicht mehr richtig läuft. Selbst bei dem spezial flachem Sockel für den neuen NVRAM Baustein kommt es zu einem Kurzschluß an der Batterie und der oberen Blechabdeckung des Falcon Computer. Die Batterieoberseite ist der Pluspol der Batterie. Bei so einem Fall würde ich die Batterie auf jeden Fall erneuern. Da hilft nur eine Isolierung der Blechabdeckung von Innen im Bereich der Batterie oder man müsste das NVRAM Modul direkt ohne Sockel einlöten was ich auch schon gemacht habe ...
-
Also, habe das Blech isoliert und damit das Problem gelöst. Alles läuft jetzt gut.
CF-Karte und die SCSI-Platte funktionieren, NVRAM ist ok.
Danke für die Erklärung und den Tip.
-
Ja, das Problem mit der offen liegenden Batterie beim neuen NV-RAM kenne ich. Ich hab die Version von Exxos (https://flic.kr/p/2geyBpY) drin und zwar ohne Sockel.
Hab das Blech an entsprechender Stelle mit Klebeband isoliert, der Batterie-Kontakt hat aber trotzdem so gerade eben das Blech berührt. Im Klebeband war nach dem Zusammenbau (und anschließender optischen Kontrolle) ein kleiner Abdruck des Kontakts zu sehen.
Ich habe letztlich eine kleine Beule (https://flic.kr/p/2gUS36e) ins Blech gekloppt. Sieht unschön aus, aber Funktion geht halt vor Optik. ;D
-
Was dickeres als Klebeband wäre gut z.B. was aus dem Joghurt Deckel ausschneiden und rein kleben.
Ich finde die Sachen von https://centuriontech.eu/ besser ...