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
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.
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
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.
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.
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.
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:> 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
pal16l8.jpg
(150 KB)
