Announcement: there is an English version of this forum on 
Hallo zusammen, kennt sich jemand mit PALs aus? Ich habe ein CPU Board was Probleme mit dem Booten hat. Ich kann aber einen Selftest laufen lassen, bei dem werden mir Bad CMos Chksum und Bad Adress Cnt angezeigt. Der SRM 2016 Speicher und der NV Speicher DS1220 ist schon ersetzt, der Fehler bleibt. Dazwischen hängt noch ein PAL16L8 den ich in Verdacht habe. Wie kann ich feststellen, ob das Ic noch ok ist oder defekt? Ich habe ein Schaltbild angehängt in dem der PAL IC43 ist. Wenn ich den PAL ausschließen kann muß ich woanders weitersuchen. Das Betriebssystem selbst ist in einem Eprom abgelegt. Hat jemand eine Idee dazu? Gruß, Stefan
Angehängte Dateien:
-
pal16l8.jpg
150 KB
Das Pal scheint nur als Adressdecoder zu dienen. Was für ein Prozessor werkelt denn da?
Stefan schrieb: > bei dem werden mir Bad CMos Chksum und Bad Adress Cnt angezeigt. Der SRM > 2016 Speicher und der NV Speicher DS1220 ist schon ersetzt Nur ersetzt, oder steht im NVRAM auch wieder das drin, was das Gerät erwartet?
Stefan schrieb: > Wie > kann ich feststellen, ob das Ic noch ok ist oder defekt? Ohne weitere Informationen garnicht - der programmierte Inhalt ist ja unbekannt, selbst wenn du den auslesen kannst weisst du ja nicht, ob er noch korrekt ist. Da es sich um ein rein kombinatorsiches PAL handelt könntest du theoretisch mit einem geeigneten Programmer den Inhalt lesen oder mühsam alle 512 Kombinationen durchprobieren und dazu die Ausgänge messen, aber ohne Unterlagen darüber bei welchen Adresseingängen welche CS-Ausgänge aktiv sein sollen kannst du nur darüber nachdenken, ob die Funktion irgendwie plausibel ist, aber nicht ob das der Entwickler so beabsichtigt hat. Stefan schrieb: > Das Betriebssystem > selbst ist in einem Eprom abgelegt. Da weisst du auch nicht ohne Vergleich mit dem korrekten Inhalt ob nicht etwas defekt ist. Georg
Der Prozessor ist ein 6809. Das NV Ram ist für das ablegen von User Programmen gedacht und der SRM2016 bekommt glaube ich den Inhalt des Operating Systems.
Angehängte Dateien:
-
Schaltbild_1.jpg
320 KB
Ich habe noch den ersten Teil des Schaltbilds angehängt, darin ist der 6809 zu sehen. Käme vielleicht ausser den Eproms und dem Speicher noch ein IC in Frage was hier einen Fehler produziert?
Stefan schrieb: > Hat jemand eine Idee dazu? Das PAL erfüllt je eine Funktion, CE bei den passenden Adressen. Das kann man ganz einfach statisch kontrollieren, in dem man an die Eingänge die passende Kombination anlegt, und guckt ob der passende CE low wird. Natürlich nach Ausbau des PAL aus der Schaltung.
Michael B. schrieb: > Stefan schrieb: >> Hat jemand eine Idee dazu? > > Das PAL erfüllt je eine Funktion, CE bei den passenden Adressen. > > Das kann man ganz einfach statisch kontrollieren, in dem man an die > Eingänge die passende Kombination anlegt, und guckt ob der passende CE > low wird. > > Natürlich nach Ausbau des PAL aus der Schaltung. Kann ich denn sehen welches die passende Kombination ist? Das Schaltbild ist die einzige Dokumentation die ich finden konnte.
Den Fehler beim PAL zu vermuten halte ich für unsinnig. Wenn das Ding defekt wäre würde wohl gar nichts mehr gehen. (auch kein ChksumTest) Eine Checksumme wird üblicherweise über das ROM gebildet. Warum kannst du kein Bild posten bei dem alle Anschlüsse der PALs mit Labels zu sehen sind?
ist durchaus möglich, das man den PAL auslesen kann. Es könnte ja z.B. ein Eingang oder eine Ausgangsstufe defekt sein, ohne das die Programmierung beeinträchtigt ist. H.W.
Thomas Z. schrieb: > Den Fehler beim PAL zu vermuten halte ich für unsinnig. Wenn das > Ding > defekt wäre würde wohl gar nichts mehr gehen. (auch kein ChksumTest) > > Eine Checksumme wird üblicherweise über das ROM gebildet. > Warum kannst du kein Bild posten bei dem alle Anschlüsse der PALs mit > Labels zu sehen sind? Das Schaltbild ist leider auf zwei Seiten. Schaltbild 1 ist die erste Seite und die zweite ist das erste Bild was ich gepostet habe. Leider ist der Pal genau im Falz sozusagen...
> Das Schaltbild ist leider auf zwei Seiten. Schaltbild 1 ist die erste > Seite und die zweite ist das erste Bild was ich gepostet habe. Leider > ist der Pal genau im Falz sozusagen... Achso, das passende Rom ist U29 auf Schaltbild 1. Vielleicht liegt der Fehler eher in einem defekten Rom? Wie wird denn hier die Chksum geprüft?
Stefan schrieb: > kennt sich jemand mit PALs aus? Ich habe ein CPU Board was Probleme mit > dem Booten hat. Bei Fehlern mit unklarer Ursache kann es bei so alten Boards helfen, alle gesockelten ICs und Module aus den Fassungen zu entnehmen und wieder neu einzusetzen. Ggf. die Kontakte mit einem sauberen Tuch reinigen oder über ein Papierblatt streichen. Grüßle, Volker
Ich versuche es mal mit dem säubern, aber die ICs sehen nicht oxdidiert aus. Vielleicht auch eine kalte Lötstelle... Vielleicht muß ich noch dazusagen das das Board vorher mal gebootet hat und den Fehler erst später entwickelt hat. Schwierige Kiste.
Stefan schrieb: > Ich versuche es mal mit dem säubern, aber die ICs sehen nicht oxdidiert > aus. Ich habe schon mehrere PCs auf diese Art & Weise "repariert". Reinigen muss man allenfalls Kontakte von RAM-Modulen, die aus Lötzinn bestehen (einfach beide Seiten flach über ein sauberes Blatt Papier reiben). Die Fehler artikulierten sich jedes Mal sehr unspezifisch und vermutlich wäre die "Reparatur" auch ohne "Reinigung" erfolgreich gewesen. Kritisch sind auch die IC-Sockel mit den billigen Kontakten aus Blechstreifen. Hier kann es schon genügen, die ICs nochmal fest in die Sockel zu drücken, ohne sie zuvor aus diesen herauszuholen. Zu Deiner Eingangsfrage: Das PAL würde ich prüfen, indem ich die Logikpegel an desssen Ausgängen mit dem Oszi angucke und auf korrekte Pegel kontrolliere. Aber ohne die Logikgleichung hilft Dir das m.E. nach nicht viel. Grüßle, Volker
:
Bearbeitet durch User
Es gibt eine alte Software, um JEDEC-FIles wieder in logische Gleichungen umzuwandeln Beitrag "Re: Ein Ausgang invertieren bei vorhandenem PALCE610/EP610/iPLD610-Design" scheint verwaist, aber wozu gibts das Webarchiv https://web.archive.org/web/20190909172303/http://www.brouhaha.com/~eric/retrocomputing/mmi/palasm/opaljr21.zip da ist es noch. Aber der erste Schritt wäre das Auslesen des .JED Textes, das geht nur mit einem Universalprogrammiergerät.
Stefan schrieb: > Ich habe ein > Schaltbild angehängt in dem der PAL IC43 ist. Geschickter Weise hast Du ja die Eingänge abgeschnitten, da kann man also überhaupt nichts erkennen. Der PAL ist eine Adreßdekoder, in der Doku sollte ja stehen, auf welchen Adressen was angesprochen wird. Dann könnte man einen ATF16V8 entsprechend programmieren, den gibt es z.B. bei Mouser.
Peter D. schrieb: > in der Doku sollte ja stehen, auf welchen > Adressen was angesprochen wird. Dann könnte man einen ATF16V8 > entsprechend programmieren, den gibt es z.B. bei Mouser. Und ohne Doku?? Georg
Der PAL ist ein "L" Typ, hat also nur logische Funktionen, keine internen Flipflops. Bitmuster anlegen, Bitmuster auslesen löst das Problem des Auslesens. Pals vergessen ihre Programmierung nicht - aber Ausgänge können taub werden. Wenn alle Ausgänge am Oszi definiert zappeln, dann ist der PAL in Ordnung.
Angehängte Dateien:
Der 6809 hat einen netten undokumentierten Opcode (HCF, 0x14), brennt man ein EPROM, in dem nichts anderes als dieser Opcode drinsteht, bekommt man ihn dazu, den Adressbus linear aufsteigend durchzuzählen. Damit kann man sehr schön Adressdecoder testen, und hier also auch das PAL. Im Anhang mal ein schnell kombinierter "Schaltplan".
Achja: Das PAL ist ganz sicher nicht die Ursache für einen "CMOS Checksum Error". Das wird durch umgekippte Daten in einem batteriegepufferten Speicher verursacht werden. Das SRAM zu wechseln, ist müßig, denn so etwas geht eigentlich nicht kaputt. Was ist das für ein Gerät?
DerEinzigeBernd schrieb: > Das SRAM zu wechseln, ist müßig, denn so etwas geht eigentlich nicht > kaputt. SRAMs gehen gerne mal kaputt. Hatte ich im Arcadesektor schon dutzende Male. Mit dem Oszi nachsehen, ob das SRAM saubere Impulse bekommt, wäre mein nächster Schritt.
:
Bearbeitet durch User
Wolfgang R. schrieb: > SRAMs gehen gerne mal kaputt. Hatte ich im Arcadesektor schon dutzende > Male. Aha. Was macht der "Arcadesektor" anders als alle anderen? Ich hab' mit Steuerungssystemen zu tun, die aus den 80ern stammen, und in denen die (witzigerweise auch von einem 6809) angesteuerten SRAMs noch nie irgendwelche Probleme gemacht haben. Was soll da bitte kaputtgehen? EPROMs, insbesondere wenn sie schlecht programmiert wurden, können eine ganz andere Angelegenheit sein. Olle IC-Sockel wurden auch schon genannt. Mit dem Oszi nachsehen ist prinzipiell sinnvoll, und zwar die Qualität der Stromversorgung. Wenn Glättelkos im Netzteil schlappgemacht haben, kann das, was man für 5V Gleichspannung hält, auch ganz anders aussehen.
EPROMs neigen im Alter zu einem schlechteren Timing, also auslesen im Programmer o.k. aber keine Funktion im Board. Auf ein neues kopieren und die Kiste läuft wieder.
Sieht nach einem schönen Stück Geriatronik aus. Verrätst Du uns, worum es sich handelt? Da das Board ja prinzipiell schon irgendwie läuft, würde ich auch erst mal Kontaktprobleme, ggf auch kalte Lötstellen oder Leiterbahnunterbrechungen durch Haarisse vermuten. Die findet man z.B. durch optische Inspektion. Am besten unter dem Mikroskop. Ansonsten hilft evtl die Untersuchung aller Signale mit dem Oszilloskop. Wenn ein Signal merkwuerdig schwach daher kommt dann ist die Quelle aber auch die Senke des Signals ein Fehlerkandidat. EPROMs die das vermutete Alter der Platine (irgendwie aus den 80ern) haben, bekommen auch gerne mal Amnesie. Dagegen hilft das mehrfache Auslesen mit dem Eprom-Brenner. Da sieht man schnell durch Vergleich der verschiedenen Binfiles, ob einzelne Bits oder ganze Bytes unterschiedlich sind. Dann einfach richtigen Eprom-Inhalt erraten und wieder in ein frisches EPROM brennen. Das hält dann wieder 30 Jahre. Das PAL laesst sich nur durch die Analyse seiner Ausgangssignale auf korrekte Funktion überprüfen. Wenn der Fehler sporadisch auftritt kann man ihn evtl durch Temperaturveränderung (Kaeltespray, Warmluft) provozieren. Wenn man das punktuell anwendet, findet man evtl den Kandidaten.
Nachtrag: Das DS1220Y ist doch so ein SRAM mit draufgepappter Batterie in einem Gehäuse, richtig? Von daher war hier ein Tausch schon richtig, da die Batterie vermutlich längst (so gut wie) leer ist. Allerdings muss man aufpassen, dass man als Ersatz nicht alte Teile bekommt, bei denen die Batterie ebenfalls schon leer ist. Man kann die wohl auch auffraesen und die Batterie tauschen. Sieht nicht schön aus, dafür hält es dann wieder länger. Wenn Du das getauscht hast, so ist es verständlich, das die CMOS checksum nicht mehr stimmt. Denn der Speicherinhalt ist ja gelöscht. Da muss die Software jetzt erst mal so schlau sein, das CMOS Ram wieder frisch zu initialisieren. Was das mit dem Adresscount soll, erschliesst sich mir allerdings noch nicht. Da wäre es gut zu wissen, um was es sich eigentlich handelt. Wenn man das weiss, könnte man gezielter auf die Suche nach Doku gehen. Da die Platine ja zuerst mal funktioniert hat, halte ich es im übrigen ebenfalls für unwahrscheinlich, dass das PAL kaputt ist.
:
Bearbeitet durch User
Stefan schrieb: > Hat jemand eine Idee dazu? Bist Du Dir sicher, dass der Jumper G1, der an einem Eingang des PALs sitzt, korrekt gesteckt ist? Ich kann zwar dessen Funktion nicht erkennen, aber irgend einen Einfluss wird dieser auf den Adressdecoder wohl schon haben... Grüßle, Volker
DerEinzigeBernd schrieb: > Der 6809 hat einen netten undokumentierten Opcode (HCF, 0x14), Der Funktion nach ist das ein NOP (No OPeration). Diesen Befehl haben viele CPUs, warum sollte dieser Befehl beim 6809 undokumentiert sein?
Hallo nochmal zusammen, danke für die vielen Nachrichten. Das Gerät ist ein Eventide SP2016 und damit ein ganz frühes Studiohallgerät. Ich habe nochmal ein bißchen weitergeschaut und folgendes herausgefunden: Der Ausgang 11 vom PAL ist beim Logicprobe immer HI, der Ausgang Pin 19 ist ok. Also ist hier der PAL definitiv nicht in Ordnung. Ich hatte schon so eine Ahnung. Der Jumper G1 ist für den 6809 Prozessor gedacht, der hat mit dem PAL erstmal nichts zu tun. Jetzt ist natürlich für mich die Frage ob ich den PAL auslesen und neu programmieren kann. Was brauche ich denn dafür? -Stefan
Thomas Z. schrieb: > Stefan schrieb: >> Der Ausgang 11 vom PAL > > ist ein Eingang.... > So wird das eher nichts Vertippt. Habe Pin 12 an der Logicprobe gehabt - ist ein Ausgang - ist immer HI. Pin 19 ist ok.
Stefan schrieb: > Habe Pin 12 an der Logicprobe gehabt - ist ein Ausgang - ist > immer HI. Zugriffe auf die RTC wird es eben nicht so oft geben.
Stefan schrieb: > ob ich den > PAL auslesen und neu programmieren kann. Was brauche ich denn dafür? Ein funktionierendes PAL - ein defektes auszulesen ist sinnlos*. Wobei sowieso nicht viel für defekt spricht, aber wenn es i.O. ist bringt dir ein Austausch ja auch nichts. Und wenn du irgendwoher ein funktionierendes beschaffst brauchst du das vorhandene ja auch nicht auszulesen. Aber es kann dich niemand davon abhalten dir einen geeigneten Programmer zu kaufen, wenn dir dann wohler ist. Um endlosen weiteren Diskussionen zuvorzukommen - es ist völlig irrelevant, ob der Speicherinhalt kaputt ist oder der Ausgang, und ob man einen Programmer hat der auslesen kann oder man die Kombination manuell durchklappert, wenn an einem Ausgang nicht das richtige rauskommt hat man keine brauchbaren Daten. Georg
Georg schrieb: > Stefan schrieb: >> ob ich den >> PAL auslesen und neu programmieren kann. Was brauche ich denn dafür? > > Ein funktionierendes PAL - ein defektes auszulesen ist sinnlos*. Wobei > sowieso nicht viel für defekt spricht, aber wenn es i.O. ist bringt dir > ein Austausch ja auch nichts. In dem PAL ist doch fast nichts drin. Da werden nur die Adressbereich gemappt. Die sollte man dann aber kennen. Alte Technologie aus den 90ern des letzten Jahrtausends.
Stefan schrieb: > Der Ausgang 11 vom PAL ist > beim Logicprobe immer HI, der Ausgang Pin 19 ist ok. Sinnvoller wäre es, an den Ausgängen des PALs mit einem Oszi die Pegel zu prüfen. > Jumper G1 ist für den 6809 Prozessor gedacht, der hat mit dem PAL > erstmal nichts zu tun. Das verstehe ich nicht! G1 geht auf einen offensichtlich als Eingang konfigurierten Pin des PALs und schaltet zwischen Dauer-High und dem Ausgang eines vorgelagerten Dekoders um. Schaltet G1 den Adressdekoder um, damit entweder eine 6809 oder eine 6802 CPU verwendet werden können? > Jetzt ist natürlich für mich die Frage ob ich den > PAL auslesen und neu programmieren kann. Was brauche ich denn dafür? Wenn Du die Logikgleichungen ermitteln kannst, kann ich Dir ein GAL16V8 programmieren, ich habe davon noch jede Menge herumliegen. Grüßle, Volker
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.