PPG Waveterm EUROCOM Board Busproblem

[intercorni]

Ich hatte alle ICs die gesockelt sind, schonmal draußen. Allerdings ohne die PINs zu säubern. Das werde ich aber auch am Wochenende nachholen.

LG

Cornel

 

[intercorni]

Hier mal ein Bild von der Monitoranzeige:

Sehr schön die digitalen Fragmente erkennbar.

Auf der Suche nach den GAP-Signal habe ich nochmal die PALs ausgemessen.
PAL1

PIN01 CPU AdresseA15: messbarer Impuls
PIN02 CPU AdresseA14: messbarer Impuls
PIN02 CPU AdresseA13: messbarer Impuls
PIN04 CPU AdresseA12: messbarer Impuls
PIN05 CPU AdresseA11: messbarer Impuls
PIN06 CPU AdresseA10: messbarer Impuls
PIN07 CPU AdresseA09: messbarer Impuls
PIN08 CPU AdresseA08: messbarer Impuls
PIN09 CPU AdresseA07: messbarer Impuls
PIN10 GND
PIN11 /PS, NAND aus PS1,2: kein Impuls, 0,08V messbar
PIN12 E, E-Signal von CPU: messbarer Impuls
PIN13 4KE, A11 f. EPROM: messbarer Impuls
PIN14 /GAP, Vordekodierung: kein Impuls, 3,71V messbar
PIN15 /GAPR, RAM-Ausblendung: messbarer Impuls
PIN16 /GAPF, Floppy-CNTRL-Lücke: kein Impuls, 3,74V messbar
PIN17 /P2, Select EPROM2: messbarer Impuls
PIN18 /P1, Select EPROM1: kein Impuls, 3,7V
PIN19 EPD, EPROM deselect: kein Impuls, 3,63V messbar
PIN20 VCC +5V

Ein Austausch des EPROMs sowie der CPU brachte leider auch nichts.
Also ich die RAMs austauschte, veränderte sich das Muster auf dem Monitor, jedoch kein Bootet bz. Promt. Also hab ich die alten RAMs wieder eingesetzt.

Jetzt frage ich mich, warum /GAP nichts ausgibt, denn laut Handbuch müsste hier eine im Adressbereich des EPROM2 liegende, bei $FC80 beginnende, 128 Byte breite Lücke /GAP dekodiert werden. MAcht er aber anscheinend nicht.
Leider bekomme ich erst in den nächsten Tagen die Images der PALs, sodass ich diese dann erstmal durch neue ersetzen kann.
Aber da PIN 14 das /GAP Signal nicht kodiert, an den Eingängen jedoch alle Signale anliegen, liegt die Vermutung doch nahe, dass PAL1 (IS52) defekt arbeitet.

Gruss,

Cornel

 

[Anonymous]

Könnte auch sein, das die CPU den Adressbereich gar nicht anspricht, weil sie vorher abkackt.

Die unterschiedlichen Muster bei Ramtausch lassen das nicht ganz unplausibel erscheinen, den RAM-Teil hab ich mir aber noch gar nicht angesehen.

Evtl. ist auch da was defekt:
CPU läuft los, alles prima.... CPU will was vom RAM, das liefert aber nur Mumpitz zurück... CPU stürzt ab oder rennt wirr durch den Code.

Da ich die Bootreihenfolge des Systems nicht kenne, weiß ich auch nicht wie man da jetzt weiter schlaue Messungen austüfteln kann...
(So nach dem Motto: er kommt bis zum EPROM (klar, sonst passierte nix), er kommt bis zum RAM, er kommt bis zum Floppy Controller, er schmiert ab...)

Das Bild sieht zumindest so aus als ob die Grafik nicht korrekt initialisiert wird. (Steht das Bild denn prinzipiell oder ist das eher flimmerig/Fahrstuhlfahren/umklappen?)

Bootet die Kiste normalerweise von Floppy? (Und spricht jetzt das Laufwerke nicht mal mehr an?)

 

[intercorni]

Ja so ist es: das Bild steht fest in dieser Form. Läuft also nicht sondern wirkt stabil.
Der Waveterm hat zwei Floppylaufwerke: eins für das Betriebssystem zum booten und das andere um Daten zu speichern.
Die Lauferke werden ja nicht mehr angesprochen, daher passiert beim starten auch nichts, daher kein booten etc.
Ich hatte von anderer Seite auch den Tipp bekommen, dass vielleicht der Videointerrupt nicht funktioniert oder das der Post scheitert noch bevor das VIDEORAM initialisiert und die Vidoeeinheit nur die uninitialisierten Speicherinhalte auslesen kann.
Allerdings hat EPROM2 an PIN20 (CS) einen messbaren PS Puls:

Hier nochmal einige vielleicht interessante Auszüge aus dem Manual:

Gruss,

Cornel

 

[intercorni]

Wie gesagt bereitet mit PAL1 Sorgen:

Wie man sieht fehlt hier /GAP am Ausgang und kann darum nicht zum PAL2 gelangen. /GAP sollte die Devicelücke für den Floppydisc-Controller erzeugen.
Warum hier 3,7V ausgegeben werden (log1 ?) ist mir unklar. Oder muss das so sein?

Gruss,

Cornel

 

[intercorni]

Ich werde mal am Wochenende das Netzteil zerlegen und die alten Becherelkos gegen Neue ersetzen.
Vielleicht war es ja das schon. Die Spannungen sahen mir alle schon ziemlich wellig aus.

Gruss,

Cornel

 

[Anonymous]

Dioden vom Netzteil prüfen.

Wenn eine Diode im Brückengleichrichter hin ist kann das durchaus reichen um fast genug Strom mit fast genug Spannung bereitzustellen. Je mehr die CPU dann so an Peripherie in Betrieb nimmt desto knapper wird das dann, irgendwann bricht die Spannung (im 50Hz Takt: Skope, nicht Multimeter!) soweit ein das es nicht mehr richtig geht.
Das ist allerdings *frühestens* bei 4,75V der Fall, normalerweise laufen solche Karten auch noch mit unter 4.5V.

 

[intercorni]

Hallo,

neben einem K3 112 A3 B 40 Gleichrichter sind auch noch 3 Exemplare des PK10 EDI 8221 (runde Bauform) verbaut:

Hat einer eine Ahnung, was das für Typen sind?

Gruss,

Cornel

 

[intercorni]

Ich hatte die freien Osterfeiertage dazu genutzt, um die alten Siebelkos in der PSU durch neue Typen zu ersetzen. Dabei habe ich auch gleichmal die Gleichrichter gegen neue Typen ersetzt.
Leider brachte dies auch keinerlei Besserung bzw. Fehlerbehebung.
Komisch ist jedoch, dass die Augabe auf dem Monitor jetzt anders aussieht. Ich mach mal dazu in Kürze ein Foto.
In Kürze bekomme ich (hoffentlich) die neu programmierten GALs die ich an Stelle der PALs einsetze. PAL1 ist ja für /GAP und damit für die Vordekodierung verantwortlich. Hier wurde jedoch kein Impuls ausgegeben was einen Defekt im PAL vermuten läßt. Ich hoffe dies zumindestens.
Wie aufwändig wäre es denn, extra ein EPROM zu programmieren, welches die einzelnen Gruppen des Boards abcheckt?

Gruss,

Cornel

 

[intercorni]

So, hier das neue Bild vom Monitor: sind aber immer noch "digitale" Fragmente zu sehen:

 

[intercorni]

Und wie kann ich eigentlich überprüfen, ob die 2 zu 1 Multiplexer (IS10 - 13) welche die RAM Adressen erzeugen, korrekt arbeiten?

Gruss,

Cornel

 

[intercorni]

Nochmal etwas anderes. In der Serviceanleitung steht:

PAL1 (IS52) ist ein PAL 12L6 (12 Eingänge, 6 Ausgänge, negative Logik).
In PAL1 werden die Select-Leitungen für die EPROM-Steckplätze /P1 + /P2 und eine im Adressbereich des EPROM2 liegende, bei $FC80 beginnende, 128 Byte breite Lücke /GAP dekodiert. Außerdem wird eine Devicelücke /GAPF ($FD00 - $FD7F) für den Floppy-Disk-Controller erzeugt, sowie ein Signal /GAPR generiert, das RAM im EPROM-Bereich ausblendet.

Wenn ich allerding mit dem Oszilloskop die Pins von PAL1 checke, erhalte ich keinerlei Pulse an den /GAP und /GAPF Ausgängen.
Sollte hier nicht ein Puls messbar sein?
/GAPR wird generiert, hier sehe ich einen Puls.

Cornel

 

[tomcat]

Ein Austausch des EPROMs sowie der CPU brachte leider auch nichts.
Also ich die RAMs austauschte, veränderte sich das Muster auf dem Monitor, jedoch kein Bootet bz. Promt. Also hab ich die alten RAMs wieder eingesetzt.

Als Halbwissender Wenn der Fehler nicht bei den Rams liegt dürfte doch ein Wechseln der Rambausteine (andere Reihenfolge) keine Änderung des Fehlerbildes verursachen, oder irre ich da? Vor allem wenn das NT ok ist. Andererseits schreibst du ja das sich das Bild auch nach dem Austausch der NT Elkos geändert hat. ???? War es vorher immer gleich?

 

[Anonymous]

Das Muster ist vermutlich nicht initialisierter Speicher, weil die CPU gar nicht so weit kommt bis der Bildschirm das erste mal gelöscht wird.
Der Bildschirminhalt ist also mehr oder weniger Zufall und hilft bei der Diagnose nicht wirklich weiter.

 

[intercorni]

Mich beschäftigt ja immer noch das /GAP-Problem wie oben beschrieben.
Würde mich über eine fachliche Meinung dazu freuen.

Die Orangenen PINs haben keinen messbaren Impuls, stehen irgendwie auf "High".
Und ich frage mich, ob ich die 128 Byte große Lücke mit dem Oszi messen könnte.

Gruss,

Cornel

 

[intercorni]

Habe gerade zu dem fehlenden /GAP Problem folgendes erfahren:

Die Adressen laufen ja nicht ständig von Anfang bis Ende durch, aber wenn der entsprechende Adressbereich mal Softwaremäßig angesprungen wird, sollten da entsprechende Signale messbar sein.

 

[Anonymous]

Genau das zeigt dein Problem: du weißt nicht was Ursache und was Folgefehler ist.
Die CPU rennt los, kommt ein Stück weit und schmiert dann ab, weil etwas defekt ist. Ab dann rennt sie durch sinnlosen/falschen Code oder arbeitet mit falschen Daten und tut sonstwas - oder auch nicht.

Ich hab leider keine Idee wie du da jetzt nur mit Scope und ohne allzuviel µP/System Kenntnisse weiterkommen kannst.

 

[intercorni]

Na ich glaub, dass solangsam auch meine Kenntnisse da nicht mitkommen, da es schon sehr speziell wird:

Schau im Opcode list und suche den NOP.
Entferne den Eprom und ersetze den mit einen Sockel.
In diesen Sockel sollten Wiederstände den NOP-code herstellen an die Datenleitungen. (Verbinde mit Plus oder GND wie nötig)
Jetzt wird das System immer ein NOP sehen und alle Addressen generieren. (Auch alle I/O auschalten ! )

Dann meine Frage was denn Opcode und NOP bedeuten:


OP-Code = OperationCode -> das Maschinenspracheprogram, welches in binärer Form in dem Eprom steht.

NOP = No OPeration -> ist eine "leere Anweisung" die in einem Assemblerprogram dazu benutzt wird Platz "freizuhalten" für spätere evt. Änderungen, wenn z.B. nachträglich noch Befehle in ein Program eingesetzt werden müssen.

Bei einer "NOP"-Anweisung macht der Prozessor nix außer den nächsten Befehl im Speicher auszulesen, d.h. der Adresszähler wird um eins erhöht.

Wenn Du nun das Eprom mit dem Program entfernst und mit Hilfe von Low(GND)- bzw. High(+5V)-Pegeln den NOP-Befehl (in binärer Form) an den Datenleitungen des Eproms erzeugst, wird der Prozessor den ersten Befehl lesen (NOP), den Adresszähler erhöhen, den nächsten Befehl lesen (NOP), den Adresszähler erhöhen, u.s.w.

-> er wird die Adressen einfach hochzählen.

Dabei fällt mir ein: Es gibt Prozessoren die, um Beinchen am Gehäuse zu sparen, sich einen Teil des Adressbusses an der CPU mit den Datenleitungen "teilen", d.h. bei einer 8-Bit-CPU mit dieser Technik sind die Bits 0-7 sind entweder Adress- oder Datenleitungen.

Wenn Du die Adressleitungen direkt an der CPU mißt kontrolliere erst mal ob die CPU getrennte Daten- & Adressleitungen hat.

Ggf. werden die Leitungen erst durch eine Logic aufgesplittet.

An den Adresseingängen der Eproms sollten aber nur die Adresssignale anliegen.