Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » [Z9001] LPRO Fehler » Themenansicht

Autor

Thread - Seiten: -1-

000
18.06.2017, 16:06 Uhr
bstrobel

Mein Z9001 ist offensichtlich wohl doch nicht ganz in Ordnung. Er verhält sich sehr "launig". Manchmal funktionieren bestimmte Programme, manchmal nicht. Manchmal kann ich Programme über die PC-Soundkarte laden, manchmal kommen Fehler [BOS-Error]. Die, wenn sie auftreten immer häufiger werden.

Den Kassetteneingang habe ich mit dem Oszi überprüft. Der B761-Komparator schaltet sauber und die Interrupts werden vom PIO korrekt ausgelöst.

Das Grundlegende auf dem Mainboard habe ich abgecheckt. Die Betriebspannungen sind ok. Mit dem Oszi habe ich die Daten-, Adress- und sonstigen Signale angeschaut, keine Auffälligkeiten. Ok, die steigende Flanke des 2,5MHz Taktes ist zu flach, aber ich denke, das ist ein Designproblem und immer so.

Aus Verzweifelung habe ich das Testprogramm LPRO von Ulrich Zanders Seite auf EPROMs gebrannt und siehe da, es scheint Fehler zu melden. Allerdings kann ich auf Ulrichs Seite keine Anleitung zu ELPRO finden und daher die Meldung nicht wirklich interpretieren.

So sieht die Ausgabe aus:

Ich habe den Modus "T" gewählt, die Frage nach dem Dauertest verneint und dann bei der Testauswahl "C" und "A" eingegeben, was die ersten 16KByte RAM und die letzten 4KByte ROM tested, wenn ich es richtig verstanden habe.

Ich denke, der RAM-Test ist erfolgreich (keine Fehler), aber der ROM-Test meldet:
Fehler 000001 2
Fehler 000002 1

Und das absolut reproduzierbar, d.h. jedesmal wenn ich ihn ausführen lasse.

Bevor ich jetzt die EPROMs auslöte und durch neu gebrannte ersetze, wollte ich erstmal verstehen, was dieser Fehler genau bedeutet.

Kann mir jemand dabei weiterhelfen? Habt ihr noch andere Ideen?

Vielen Dank schonmal!

Bernd

PS: Ich spreche nicht von dem KC85/3, der auf dem Foto zu sehen ist. Der dient hier nur als Bildschirmständer.

Dieser Beitrag wurde am 18.06.2017 um 17:04 Uhr von bstrobel editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
18.06.2017, 18:10 Uhr
robbi
Default Group and Edit

Es sieht so aus, als wären die EPROMs fehlerhaft.
Allerdings habe ich mit "LPRO" auch noch keine Erfahrungen und fehlerhafte EPROMs sind mir seeehr selten untergekommen (2x ?).
--
Schreib wie du quatschst, dann schreibst du schlecht.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
18.06.2017, 19:11 Uhr
bstrobel

Ja, ich denke, ich benötige ein Idee, wie ich fehlerhafte EPROMs ausschließen kann. Unnötig möchte ich sie jedenfalls nicht auslöten, auch wenn das für mich kein Problem ist, da ich alle Werkzeuge und Ersatz-ICs habe. Der Z9001 ist noch so schön unverbastelt und mechanisch in sehr gutem Zustand.

Mein Batronix-EPROM-Brenner zeigt verschiedene Checksummen an. Es gibt neben den hier nicht anwendbaren MD5, SHA-1, CRC-32 auch zwei, die Summe(16) und Summe(32) heißen.

Ich gehe mal davon aus, dass das einfache 16 oder 32 bit breite Prüfsummen sind. Das müsste in BASIC relativ einfach gehen. Werde mal versuchen, selbst was zu schreiben.

Hat jemand eventuell sowas schon in fertig? Eventuell auch in Assembler. Könnte das im IDAS oder EDAS eintippen.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
18.06.2017, 20:16 Uhr
bstrobel

Gut dass ich die EPROMs nicht so schnell ausgelötet habe. Die Checksummen stimmen!

Hab folgendes kleines Programm benutzt, um sie zu berechnen:

Laut dem Batronix Prog-Express haben die 1.2 Versionen der EPROMs folgende Checksummen:
ROM1 F000-F7FF: 0x3B850 -> 243792
ROM2 F800-FFFF: 0x3876E -> 231278

Und genau das rechnet mein Progrämmchen auch aus.

Allerdings bin ich nun wieder "back to square one", wie der Engländer sagt.

Nochmal genauer das Fehlerbild:
Laden über PC-Soundkarte von COM-Programmen funktioniert kurz nach dem Einschalten fehlerlos. Wenn der Rechner eine Weile gelaufen ist, dann kommen beim Laden immer häufiger BOS-Errors, die sich durch "zurückspulen" übergehen lassen. Allerdings funktionieren die Programme dann oft nicht mehr, der Rechner reagiert nicht mehr und muss mit Reset wiedererweckt werden.

Laden von BASIC-Programmen scheint am Anfang zu funktionieren (also keine BOS-Errors), allerdings startet das Programm nie nach dem letzten Block und es kommt auch kein Prompt. Wenn ich das Laden mit der STOP-Taste beende, kommt der BASIC-Prompt. Starte ich dann das Programm mit der RUN-Taste, bekomme ich immer einen UL-Error in irgendeiner Zeile. Will ich das Programm LIST-en, dann sehe ich meist nur Teile des Quelltextes und ansonsten wilde Grafikzeichen und es piepst wild.

RAM kann es natürlich auch sein, auch wenn ELPRO den als gut getestet hat. Habt ihr da Empfehlungen für einen EPROM-basierten RAM-Test?

Ansonsten werde ich mir doch nochmal den Kassettenaufnahmezweig anschauen, inklusive der Interruptsignale von PIO und CTC. Wo beginne ich da am besten? Hat jemand Erfahrung damit? Logikanalysator und Oszi sind vorhanden.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
18.06.2017, 21:08 Uhr
schlaub_01

Bezüglich des RAM Tests kann ich Dir nur das Programm von Volker's Seite empfehlen: http://hc-ddr.hucki.net/wiki/doku.php/z9001:software:ramtest
Das hat mir schon oft geholfen, defekte RAMs zu lokalisieren. Der Test ist sehr intensiv und wird mit diversen Bitmustern durchgeführt.
Kassetteninterface kann, wie Du schon vermutest, auch an PIO oder CTC liegen. Vielleicht kannst Du mit Kältespray da etwas lokalisieren - klingt ja fast wie ein Problem, was nach Erwärmung erst auftritt.

Grüße,
Sven.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
19.06.2017, 01:59 Uhr
robbi
Default Group and Edit

Was sagt denn die Betriebsspannung? Ist sie verbrummt?
--
Schreib wie du quatschst, dann schreibst du schlecht.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
19.06.2017, 07:50 Uhr
volkerp
Default Group and Edit

In der Service-Reparaturanleitung zum Z9001 ist die Benutzung des Programms LPRO beschrieben. Unter http://hc-ddr.hucki.net/wiki/doku.php/z9001:software:testprg hab ich reassemblierte Quellcodes der Testprogramme. LPRO entspricht i.w. FTEST13.

TPROM1 testet nur die Summe über dem OS (F000-FFFF).
Wenn hier Fehler auftreten, die PROMs aber i.O. sind, scheint das Problem eher in der Adressbus- bze. Datenbussteuerung oder den Datenbustreibern zu liegen?
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
19.06.2017, 12:06 Uhr
bstrobel

Danke an alle für eure Tipps!

Neben der Arbeit lasse ich gerade deinen RAM-Test laufen, Volker. Parameter von 1400-3FFF, Blockgröße 400, alle Tests. Nach etwa 2,5 Stunden noch keine Fehler. Ich denke, die RAMs kann ich auch erstmal ausschließen. Da bin ich froh, denn die sind heutzutage wirklich schwer zu beschaffen.

Die Betriebsspannung werde ich mir mit dem Oszi auf jeden Fall auch nochmal anschauen. Hab sie damit seinerzeit kontrolliert, als ich den Rechner ganz neu hatte. Kann durchaus Sinn mache, nach einiger Zeit in Betrieb nochmal nachzuschauen. Werde ich heute Abend nochmal versuchen. Den Rest der Woche bin ich wiedermal auf Dienstreise, da muss der KC erstmal ruhen.

Ulrichs Reparaturlanleitung habe ich gelesen und auch deine oben verlinkte Seite, Volker. In der Reparaturanleitung wird nur von Test 1, Test 2, usw gesprochen und vor allem die Signaturen aufgezählt. Soweit ich das verstehe beziehen sich diese Tests auf das Testprogramm 2E11. Da ich den Signaturanalysator nicht habe, hilft es mir daher nicht weiter.

ELPRO (und FTEST13) gibt aber die Tests mit nicht näher erläuterten Kürzeln an (TPCEA, TPKAS1, usw.). Außerdem gibt es verschiedene Testvarianten:

Dabei habe ich festgestellt, dass es keine Fehler beim Test ROM1 gibt, wenn ich Variante 3 auswähle. Ich gehe deshalb erstmal davon aus, dass diese für einenZ9001 mit Monitor Version 1.2 wie meinen gedacht ist.

Wenn ich alle angebotenen Tests laufen lasse, dann kommen in allen Varianten bei TPCEA und TPKAS1 Fehler:

Wobei nach einigen Durchläufen bei TPCEA aus "3 5" ein "3 5 7" wird.

Was aber bedeuten TPCEA und TPKAS1?

TPCEA könnte Console Ein-/Ausgabe sein und der Fehler könnte daher kommen, dass ich die Prüfstecker nicht aufgesteckt habe.

TPKAS1 könnte das Kassetteninterface sein. Was aber bedeutet der Fehler?

Viele Grüße

Bernd

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
20.06.2017, 10:06 Uhr
volkerp
Default Group and Edit

Ich hab die Reassemblings der LPRO-Programme überarbeitet und bei mir abgelegt. Zumindest die Varianten kann ich erklären.

• 1: Ursystem? OS 1.0?
• 2: Z9001.84, OS 1.1, BASIC 84 (M497-M501)
• 3: Z9001.85, OS 1.2, BASIC 85 (M507-M511)
• 8: KC85/1, OS 1.2, BM600+BM602
• T: KC87.2x, OS 1.3, BM600+BM608

TPCEA testet CTC u. PIO. Dazu werden die Prüfstecker benötigt (s. Service-Anleitung).
TPKAS1 und 2 testet das Kassetteninterface. Was da im einzelnen passiert und wo Fehler auftreten können, habe ich im Detail noch nicht analysiert.

Gibt es bei einem Test Fehler, so wird lfd. Fehlernummer ausgegeben.
Beim TPROM1/2-Test wird zusätzlich die Nummer des 2K-ROMs angegeben, in dem der Fehler aufgetreten ist.
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)

Dieser Beitrag wurde am 20.06.2017 um 10:10 Uhr von volkerp editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
23.06.2017, 17:20 Uhr
bstrobel

Zitat:

volkerp schrieb
Ich hab die Reassemblings der LPRO-Programme überarbeitet und bei mir abgelegt. Zumindest die Varianten kann ich erklären.

Danke Volker! Das ist ja Wahnsinn! Ich hoffe, ich komme dieses Wochenende dazu, mir das anzuschauen. Durch deine Disassemblings bin ich auch schon mal kurz gegangen. Aber mein U880-Assembler ist ganz schön eingerostet (wie mein Russisch). Sicher ist es eigentlich selbsterklärend, aber dass ich mit einem Blick erkennen könnte, was da vor sich geht ist vorbei. Vor 30 Jahren war das besser.

Bei TPKAS1, das ich mir auch angeschaut hatte, konfiguriert er, glaub ich, auch PIO und CTC. Eventuell wird ein Testsignal erwartet. Sowas wie 1kHz Sinus oder so. Wenn ich meinen Kassetteneingang repariert habe, werde ich das mal testen.

Melde mich dazu auf jeden Fall.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
25.06.2017, 20:32 Uhr
bstrobel

So, das Rätsel ist gelöst, es war ... was ganz anderes.

Als Hintergrund: Zum Testen habe ich zum einen die WAV-Files von Ulrich Zanders Seite und zum anderen KCSAVE von Hendrik Haftmann, welches auf meinem Windows 10 Rechner in einer Dosbox-VM läuft (hab ich im anderen Thread schon drüber geschrieben).

Wie gesagt, funktionierten früher COM-Dateien problemlos, nur BASIC nie. Später gab es dann auch bei COM-Dateien BOS-Errors. Bei BASIC-Programmen gab es das Phänomen, dass der Cursor beim letzten Block einfach stehen blieb und das Programm nicht vollständig geladen wurde.

Lösung für BOS-Errors bei COM-Dateien: Kabel kaputt, kalte Lötstelle.

Lösung für BASIC-Programme: Die TAP-Dateien (und damit auch die WAV-Dateien, welche Ulrich offensichtlich daraus erstellt hat) sind defekt. Konkret dürfen bei BASIC-Dateien keine relevanten Daten im letzten Block mit Nummer 255 enthalten sein, da dieser ignoriert wird. Ich habe mir die TAP-Dateien im Hexeditor angeschaut und einfach die Blocknummer des 255er Blocks auf den fortlaufenden Wert nach der vorletzten Blocknummer gesetzt, und tatsächlich werden die Dateien jetzt vollständig geladen und funktionieren. Das erste mal nach 30 Jahren wieder CLIMBER gespielt!

Hat ne Weile gedauert, bis ich darauf gekommen bin...

Die ganzen Forschungen mit LPRO und dem Oszi waren aber nicht umsonst. Jetzt weiß ich wenigstens, dass der Z9001 noch gut in Schuss ist und bin für die Zukunft gerüstet. Und was gelernt hab ich ja auch dabei.

Den LPRO Assemblercode werde ich mir noch näher anschauen, denn so ein Test-ROM ist wirklich recht nützlich.

Nochmals vielen Dank an Volker und alle die mir Tipps gegeben haben!

Bernd

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
27.06.2017, 09:02 Uhr
volkerp
Default Group and Edit

Das mit defekten TAP-Dateien kann ich so nicht nachvollziehen: BASIC interessiert die Blocknummer FF nicht, das Ende wird über die Programmlänge bestimmt. Programme wie TATUM (>32KByte) haben einen FF-Block mitten in der Datei, und auch das wird problemlos geladen.

CLIMBER.WAV ließ sich ohne Probleme komplett einlesen und spielen, sowohl mit Z9001.85 wie auch KC87.21.
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
27.06.2017, 10:43 Uhr
robbi
Default Group and Edit

Das ist der "finale Knackser", wenn das Einlesen scheinbar nicht beendet wird.
Es hängt wahrscheinlich davon ab, mit welcher Flanke die Datei aufhört. Das kommt bei der Umwandlung von Kassettenaufnahme zu WAV zustande.
Wenn man das Band zwei Zentimeter zurückspult und noch einmal die Wiedergabe startet, wird die Bedingung erfüllt und der Prompt erscheint.
Ich müßte da alle Dateien nochmal ansehen, das ist mir aber zuviel Arbeit.
--
Schreib wie du quatschst, dann schreibst du schlecht.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
02.07.2017, 17:01 Uhr
bstrobel

Zitat:

volkerp schrieb
Das mit defekten TAP-Dateien kann ich so nicht nachvollziehen: BASIC interessiert die Blocknummer FF nicht, das Ende wird über die Programmlänge bestimmt. Programme wie TATUM (>32KByte) haben einen FF-Block mitten in der Datei, und auch das wird problemlos geladen.

Genauso ist es. Das hab ich ja auch geschrieben. Der FF-Block wird ignoriert. Das heißt, dass darin eventuell enthaltene Daten nicht geladen werden.

Dies ist die CLIMBER.TAP, die ich soeben nochmal von Ulrich Zanders Seite heruntergeladen habe:

Wie man deutlich sieht, sind im FF-Block noch Daten enthalten. Wenn ich diesen Block in 54h umnummeriere, funktioniert es. Ich gehe davon aus, dass Ulrich die WAV-Dateien mit einem Tool aus den TAP-Dateien erstellt hat.

Zitat:

CLIMBER.WAV ließ sich ohne Probleme komplett einlesen und spielen, sowohl mit Z9001.85 wie auch KC87.21.

Hast du auch diese http://www.sax.de/~zander/z9001/basprog/CLIMBER.zip getestet? Bei mir funktioniert sie nicht.

Zitat:

robbi schriebDas ist der "finale Knackser", wenn das Einlesen scheinbar nicht beendet wird.

Das habe ich auch gedacht, mir ist es jedoch nie gelungen, diesen manuell zu erzeugen, auch nicht durch mehrmaliges Einlesen, wie du beschreibst.

Dieser Beitrag wurde am 02.07.2017 um 17:01 Uhr von bstrobel editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

014
04.07.2017, 15:00 Uhr
robbi
Default Group and Edit

Da muß ich wohl alle mit dem "kcsave" behandelten Dateien nochmal kontrollieren.
Der Hinweis mit dem finalen Knackser bezog sich auf Bearbeitung aus "analogen" Quellen erstellter und bearbeiteter WAV-Dateien.
Ich wußte im Moment nicht mehr, daß ich davon viele - wegen der geringeren Dateigröße der erzeugten Dateien - mit kcsave neu bearbeitet hatte.
Im Moment habe ich Sommerpause und komme so gut wie nicht zu Basteleien.

--
Schreib wie du quatschst, dann schreibst du schlecht.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

015
04.07.2017, 16:52 Uhr
volkerp
Default Group and Edit

@013: mit der Blocknummer FF hat das nichts zu tun.
Frage: wie liest du TAP ein bzw. wie konvertierst du das?

Das alte KCLOAD von H.Haftmann kennt kein TAP. Da kommt Müll raus.
Du kannst mit dem JKCEMU tap zu WAV konvertieren (Tools/Dateikonverter). Allerdings haben diese Waves einen Gleichspannungsanteil addiert. Dennoch funktioniert auch das Einlesen dieser so erzeugten Waves. Alternative Programme sind KCSAVE von meiner Seite oder meine Kommandozeilen-Tools.

Auch der JKCEMU Emulator ist pingelig und möchte gern eine halbe Schwingung mehr auf dem Wave, um das Ende zu erkennen. Bei meinen Kommandozeilen-Tools in Perl hab ich deshalb eine Halbschwingung angehängt.
Wenn diese zusätzliche Schwingung (der Knackser) fehlt und das Laden noch nicht beendet ist, musst du einfach die Wiedergabe des Wavs erneut anstarten. Mit dem ersten eintreffenden Signal wird das Einlesen des letzten Blocks beendet. Durch Rauschen oder das Abschalten des Kassettenrekorders gab es in den analogen Zeiten immer eine zusätzliche Schwingung, oder aber man hat das Bank kurz zurückgespult, so dass wieder Ton zu hören war und damit die fehlende Schwingung eingelesen wurde.
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

016
04.07.2017, 21:04 Uhr
robbi
Default Group and Edit

@bstrobel
In der WAV-Datei in CLIMBER.zip habe ich einen Knackser angefügt. Sie sollte jetzt funktionieren. Bitte testen.

Volker hat sich mehr mit der Problematik beschäftigt. Ich vergesse langsam die Zusammenhänge und reime mir da etwas zusammen. Ja, es war wohl so, wie von ihm beschrieben.
Da müßte ich also nur die WAV-Dateien mal anfassen und ein Knackser am Ende ist schnell angefügt.
--
Schreib wie du quatschst, dann schreibst du schlecht.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

017
12.07.2017, 08:51 Uhr
bstrobel

Kurze Zwischenmeldung von mir. Vielen Dank für eure Hilfe Volker und robbi(=Ulrich Zander?

).

Leider bin ich gerade beruflich sehr eingespannt und komme nicht zum Testen/Weiterforschen. Ich hoffe, nächstes Wochenende ein bisschen mehr Zeit zu haben. Melde mich auf jeden Fall!

Bernd

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]