Forum: Mikrocontroller und Digitale Elektronik Wie kann ich einen PAL 16L8 testen?


You were forwarded to this site from EmbDev.net. Back to EmbDev.net
von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

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

von Cheesus (Gast)


Lesenswert?

Hast du keinen LA, um dessen Funktion zu testen?

von H. H. (Gast)


Lesenswert?

Das Pal scheint nur als Adressdecoder zu dienen.

Was für ein Prozessor werkelt denn da?

von Hmmm (Gast)


Lesenswert?

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?

von Georg (Gast)


Lesenswert?

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

von Stefan (Gast)


Lesenswert?

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.

von Stefan (Gast)


Angehängte Dateien:

Lesenswert?

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?

von Michael B. (laberkopp)


Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

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.

von Thomas Z. (usbman)


Lesenswert?

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?

von H.W. (Gast)


Lesenswert?

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.

von Stefan (Gast)


Lesenswert?

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...

von Stefan (Gast)


Lesenswert?

> 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?

von Volker B. (Firma: L-E-A) (vobs)


Lesenswert?

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

von Stefan (Gast)


Lesenswert?

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.

von Volker B. (Firma: L-E-A) (vobs)


Lesenswert?

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
von Christoph db1uq K. (christoph_kessler)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Georg (Gast)


Lesenswert?

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

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Lesenswert?

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.

von DerEinzigeBernd (Gast)


Angehängte Dateien:

Lesenswert?

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".

von DerEinzigeBernd (Gast)


Lesenswert?

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?

von Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)


Lesenswert?

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
von DerEinzigeBernd (Gast)


Lesenswert?

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.

von Rüdiger B. (rbruns)


Lesenswert?

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.

von Andi M. (andi6510) Benutzerseite


Lesenswert?

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.

von Andi M. (andi6510) Benutzerseite


Lesenswert?

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
von Volker B. (Firma: L-E-A) (vobs)


Lesenswert?

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

von Peter N. (alv)


Lesenswert?

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?

von Stefan (Gast)


Lesenswert?

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

von H. H. (Gast)


Lesenswert?


von Thomas Z. (usbman)


Lesenswert?

Stefan schrieb:
> Der Ausgang 11 vom PAL

ist ein Eingang....
So wird das eher nichts

von Stefan (Gast)


Lesenswert?

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.

von H. H. (Gast)


Lesenswert?

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.

von Georg (Gast)


Lesenswert?

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

von noreply@noreply.com (Gast)


Lesenswert?

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.

von Volker B. (Firma: L-E-A) (vobs)


Lesenswert?

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

Bitte 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
Noch kein Account? Hier anmelden.