Fehlersuche

mit Detlefs Ramtest war die Fehlersuche ein kleineres Problem als vorher

Da war in Bank drei der letzte IC defekt

nach Tausch des RAM

und das andere Board

da ist in Bank 0 der dritte IC defekt

Mustertest,Ausgabe CRT+V.24

TestROM V1

TestROM V2

Anzeige:00000000 00000000 00000001 00000000

Darstellung immer bit 0 - 7 0=OK 1=Fehler hier, Block3 (8000-bfff) bit 7 Fehler. Getestet werden Block 4,3,2 aus dem ROM, dann erfolgt eine Verschiebung in den RAM und Block 1 wird getestet, bei defekten in Block 2+3+4 wird Block1 nur verkürzt getestet,da kein Verschieben erfolgt, also erst obere Blöcke reparieren dann noch mal testen. Wiederholung Test bei ROM mit Reset bei V.24 durch neu laden…

written by D.Lepies 25.04.2010 nach der Idee RAM-Testprogramm als Start-EPROM für A5120 von H. Bretfeld/R.Kurth

Die Nutzung des Programmes erfolgt auf eigene Gefahr!

Es gibt Keine Gewähr für 100%ige Funktion!

Test ROM für den 1715 mit Tests für RAM, FDC, CTC und SIO? Läuft über V24/PRN und Monitor.

xp1715romv0.1.zip

Checksumme ist C5FA (laut Modprom)

zuerst wird 0xff an Adresse 0x34/Bildwiederholspeicher-Page (als P.O.S.T.) ausgegeben. Ebenso Leitung 111. Danach wird 0x34 auf 0 gesetzt und mit den CPU-Tests begonnen. Folgende Ergebnisse werden als POST gemeldet:

AF/AF'         defekt 1,     i.O. 2
BCDEHL/BCDEHL' defekt 3,     i.O. 4
IX/IY/SP       defekt 5,     i.O. 6 (bisherige Fehler führen zum CPU HALT)
ROM checksum   defekt 7,     i.O. 8

Danach werden der Bildschirm und die seriellen Schnittstellen initialisiert. Der Bildschirm wird allerdings noch nicht freigegeben, da bei der 250kbps Rate des FDC definitiv ein DMA underrun des CRT-Controllers eintritt, was zu störendem Flackern führen würde.

Startmeldung ist entweder:

xp1715 ROM V0.1    wenn ROM und CPU Register in Ordung sind

oder entsprechend der angegebenen Rangfolge

ROM error          wenn ein checksum Fehler erkannt wurde
INT error          wenn ein NMI oder I Register Fehler vorliegt.

In den folgenden 4 Zeilen wird der Initialzustand der 4 PIOs und der augenblickliche Zustand an deren Port-Eingängen dargestellt. Der Initialzustand (links) hat nur bei Power-On eine Bedeutung und zeigt durch Änderung, dass überhaupt ein PIO-Baustein reagiert und dass das Strobe-Signal demzufolge inaktiv ist.

• PIO0A hat an ihren Eingängen 8 Pull-ups und sollte dementsprechend 0xFF im 2.Byte haben. Das linke Byte kann dabei auch nach Power-on identisch mit dem rechten sein.
• PIO0B sollte vom Floppy-/Shugart-Bus über das 20bit Schieberegister ebenfalls 0xFF einlesen.
• PIO1A hat 8 Ausgänge und liest bei mir ebenfalls 0xff über die angeschlossenen TTL-Gatter ein. PIO1B hat 5 Ein- und 3 Ausgänge und liest 0xfd ein, da MKE in der Regel nicht gesetzt sein darf.
• PIO0A: Schreibdaten für SReg Eingang 0/2..14 (und MFM-ROM A0..7), Pull-ups
• PIO0B: Lesedaten (SReg Ausgang bits 4/6..18, PB0..5 mit Pull-up am Marken ROM)
• PIO1A: /ST|/HL|SD/MR|MK1|STR|/FR|MK|/WE (Drive Index /IX am Strobe Eingang)
• PIO1B: /T0|/FW|/WP| FO|PRE|MFM |MKE|/RDY

Zur Kontrolle des 20bit Schieberegisters werden an PIO0A alle Werte von 0..255 ausgegeben und an PIO0B wieder eingelesen. Das erste Ergebnisbyte zeigt dabei alle Bitfehler, das zweite Byte alle mind. einmal als Eins gelesene Bits (ODER-) und das dritte Byte alle Nullen (UND-Verknüpung). Sollte das Programm hier hängen bleiben, dann empfiehlt es sich auf dem FDC den /PS Schalter umzulegen. Eventuell wird ein Endlos-Wait durch PIO0A ausgelöst. Der /PS Schalter hat zur Folge, dass Daten von PIO0A sofort gelatched werden. Fehlerbits 0 und 1 sind somit ungültig.

Bei der Schreibrate wird mit CTC0 Kanal3 ein Intervall von 125Hz eingestellt und das innerhalb von 8ms zum FDC transportierte Datenvolumen in Bytes gemessen. Numerischer Überlauf tritt bei 1020kbps ein und wird als EEEE angezeigt. Bei 1Mbps benötigt jedes Byte nur 16us, für den Z80 ohne CTC-Interrupt schon etwas schnell, bis 1.27Mbps (derzeitige Grenze des Algorithmus) ist noch etwas Luft.

Der MFM-ROM wird komplett gelesen und eine 16bit Prüfsumme gebildet. Wenn Schreibraten- und Schieberegister-Tests ok sind, dann sollte bei Fehlern der ROM getauscht bzw. in einem U555 tauglichen Lesegerät geprüft werden.

Der MKE Test ist etwas wackelig, da sich die Phase zwischen PLL und Schreibtakt nicht vorhersehen lässt. Es wird dazu 0xc7 an PIO0A ausgegeben und im richtigen Moment zwischen Schreiben und Lesen umgeschaltet. Nach 3 Versuchen konnte in der Regel „Marke Erkannt“ gesetzt werden. 00 Versuche bedeutet MKE high (defekt), FF dass MKE immer noch low ist.

Der Leseraten-/PLL-Frequenztest setzt voraus das MKE high ist. Es wird beim ersten Schritt das MFM Teiler Flip-Flop gesperrt (gesetzt) und im zweiten Schritt das F0 Flip-Flop. Wenn CTC0 Kanal 3 defekt ist, kommt es genauso wie bei der Schreibrate zu Fehlern. Bei größeren Abweichungen von 496kbps muss der VCO kontrolliert werden.

Der CTC Test wird im Interrupt-Mode 1 durchgeführt und unterbricht eine 16bit Zählschleife. Der Wert von 0x09D9 bei Abbruch kann um +/- 1 tolerieren.

Der SIO Test wird mit Hilfe der CTC(linkes Byte) und einer Zeitschleife (rechtes Byte) durchgeführt. Das linke Byte misst 15 Bytes per CTC wenn der Interrupt vorher ordnungsgemäß ausgelöst wurde. Das rechte Byte misst das letzte gesendete Byte per CPU. Beide Angaben zählen rückwärts. Bei Fehlern größer +/- 1 bitte CTC und evtl. SIO putzen falls gesockelt.

Der initiale RAM-Test war anfänglich nur interressehalber reingekommen. Warum nach Power-on 0- und 1-bits fast gleich verteilt sind (evtl. weis das ein Mikrosystemtechniker) kann ich mir nicht erklären. Möglicherweise taugt der Test noch um einen defekten Bus-Treiber von der CPU zum RAM zu erkennen, deshalb ist er nicht rausgefallen. Adressbereiche 0..800 und F800..FFFF werden ausgespart. Oben stehen 0, unten 1 Bits. Seriell werden nur die 1 Bits ausgegeben, beginnend mit DO0 bis DO7 der 1. Bank.

Im zweiten Teil wird der RAM mit „walking bit/inverse“ getestet. Welche Bitmaske benutzt wird steht hinter der oberen Adressangabe (zu testende Adresse). Darunter steht der Bildwiederholspeicher Start. Vor jedem Testdurchlauf ist der RAM bereits initialisiert (mit 0 oder FF). Wird an einer Speicherstelle zu Beginn des Test ein anderer Wert gelesen, dann versucht das Programm einen Addressline-Fehler zuzuordnen, wenn es sich nicht um einen Bit-Fehler (gekennzeichnet durch H/L) handelt. Konnte kein Fehler zugeordnet werden, wird ein '?' gesetzt. Der Addressline-Test kann dabei schon ein paar Minuten pro Bank dauern. A14-/A15-Fehler wollte ich eigentlich weglassen, weil ich dazu meine Initialisierung innerhalb der Bank zwischen 0 und FF wechseln, oder den Schnelltest-Modus weglassen müsste, sodass der Addressline-Test immer durchgeführt würde. In der jetzigen Version ist zu beachten, dass A14 Fehler alleine nur in Bank 2..4 und A15 Fehler ohne weitere Fehler nur in Bank 3/4 erkannt werden. Bei der seriellen Ausgabe wird immer zuerst der Bildwiederholspeicherstart und dann Bank 1 bis 4 ausgegeben:

Adresse,Bitmaske  Adressfehler(16),unbestimmte(8),high-Fehler(8),low-Fehler(8)

Nach 31 Durchläufen ohne Fehler wird das Programm (welches bei der Checksummen-Prüfung kopiert wurde) im RAM gestartet, wenn nicht das I-Register defekt ist.

Falls alle RAM-chips in einer Zeile/Spalte als defekt erkannt werden und den selben Bitfehler/Adressfehler ausgeben, sollte man mal nach den Treibern schauen. Folgende RAMs könnten im 1715 verbaut sein, laut DB-MR-Schaltkreise/Kramer&Würtenb.:

        '2116,'4116, ('2118 5V-Typ!)
AMD      9016
DDR      U256C/D
Fujitsu  MB8116E, MB8126, MB8216
Hitachi  HM4716
Mostek   MK4116N-3GP
Motorola MCM4516, MCM4517
National MM5290N-3
NEC      uPD416, uPD2116
Tesla    MHB4116
Toshiba  TM416
UdSSR    KR565RU3A, K565RU3
         (K565RU6 hat 5V am Pin 8)

Bei Ersatzteilmangel kann man eventuell auch einen U2164/K565RU5, mit Pin8 umgebogen und auf Pin9 (5V) gelegt, verwenden.

Für das Schreiben der Tests habe ich mehr als 2 Wochen vollzeit investiert. Als ich dann den 1715 reparieren wollte stellte sich heraus, dass der Defekt in der Display-Steuerung zu suchen war. CRT-Register auslesen ist meines Wissens im Design nicht vorgesehen und in meinem speziellen Fall war es auch nicht nötig. Bildfrequenzen stimmten nur der Inhalt verstreute sich dynamisch über den Bildschirm. Nach einem kompletten Durchlauf des RAM-Tests ohne Fehler, stürzte das Programm ab sobald es eigentlich vom RAM laufen sollte. Da ich einen Defekt der ersten 2kByte für unwahrscheinlich hielt habe ich mir nach längerem Suchen mal das /RAS in Verbindung mit M1 angeschaut und siehe da, der /RAS-Impuls ging von einem M1-Zyklus bis zum nächsten. Statt der Bildschirmadresse wurde also immer der Programmzähler in den unteren 7bit benutzt. Defekt war letztendlich A3.2 D108 oder besser gesagt K155LI1. Ein weiterer 1715 hatte einen defekten RAM, den ich für meine Tests gleich durch einen Sockel ersetzt habe. Ab und zu musste ich auch mal etwas am gesockelten CTC wackeln, damit das Timing stimmte.

Eventuell schreibe ich noch eine Routine um den Bildzähler durch „out (0x3c)“ rückzusetzen oder Zeichen über Keyboard einzugeben während das Hauptprogramm im HALT ist. Oder man könnte den PC durch Aneinanderreihung von HALTs bei jedem Tastendruck langsam erhöhen. Sinnvoll wäre sicherlich FDC- und Mainboard-Test in 2 getrennten ROMs unterzubringen bzw. den FDC-Test per V24 in den RAM zu laden. Dann könnte man neben der Display-Steuerung auch den vom Bootloader verdeckten RAM richtig testen und den maximalen Refresh-Zyklus ermitteln.

Zur Programmierung habe ich den ELV EPS1 Simulator und den A80Z Assembler von „PseudoCode“ benutzt. Dank der freundlichen Spende von Herrn Uhlig aus Grimma konnte ich im Kieser/Meder des öffteren mal Befehlszyklen und I/O Registerbelegungen nachschauen. Ich übernehme keine Garantie auf Fehlerfreiheit der Software. Das Bildschirmtiming habe ich aus den CP/A Sourcen entnommen und an 2 Geräten über mehrere Stunden mit einem echten 1715 Monitor getestet. Der Reset und Neustart des CRT Controllers zwischen den Testzyklen könnte theoretisch Stress für den Monitor erzeugen durch kurzzeitig zu niedrige Zeilenfrequenzen. Bei einem Dauertest ist es nicht nur deshalb besser ohne Monitor zu arbeiten (schont auch das Netzteil und den Geldbeutel).