Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins Willkommen Gast! RSS

Robotrontechnik-Forum » Technische Diskussionen » Reparatur EC1834 » Themenansicht

Autor Thread - Seiten: -1-
000
05.05.2025, 17:24 Uhr
Ordoban



Ich habe einen EC1834 geschenkt, und ein zweites EC1834-Mainboard zur Reparatur bekommen.

Vorgehen nach Schema F:

1. Netzteil
Netzteil läuft nicht richtig, sondern pulsiert. Braucht das vielleicht eine Last? Ok, Lastwiderstand rangehangen. Das ändert nichts. Auseinandergebaut, spannungsfrei gemessen, alles OK, mit Spannung gemessen, keine Ursache zu finden.
Eine Weile gemessen, aus einmal machts "Pling", der 5V-Ausgang ist ganz finster und das Netzteil macht komische Geräusche. MIST. Spannungsfrei gemessen, der SU169 der 5V-Seite ist hin. Natürlich kein Ersatz im Haus. Also neuen bestellt.
Paar Tage später ist der da, eingebaut, weitergemessen. Die Spannung an der 5V-Seite steigt bis auf genau 5V, dann regelt das Feedback immer weiter runter, bis es schließlich ganz aus geht. Hier im Forum gelesen. Ja. Lastwiderstand. Vielleicht ist meine Last noch zu klein?
Ich habe nix größeres hier. KFZ-Scheinwerfer-Lampen habe ich keine mehr. Extra welche kaufen? Die sind ganz schön teuer geworden. Wie wäre es mit Haushalts-Halogen? Im Baumarkt geguckt: es gibt noch 12V 50W Halogenlämpchen. Sogar recht günstig.
Die als Lastwiderstand angeschlossen, Netzteil läuft. Jetzt komm ich mir ziemlich dumm vor. Egal. Netzteil zusammenbauen, weiter im Text.

2. Takt an der CPU
4,9Mhz Verhältnis 2:3 - perfekt

3. Reset and der CPU
Kommt beim Einschalten und geht nach 7 Sekunden. Ganz schön lang. Je öfter ich probiere, desto kürzer wird die Reset-Zeit. Anscheinend muss sich der Kondensator in der Reset-Schaltung erst wieder an Strom gewöhnen. Reset ist Ok.

4. S0-S2 Steuersignale an der CPU
Hier ist schonmal Action. Aber nicht so wie es sein soll. Ein paarmal Programmcode aus dem Speicher lesen ist richtig, aber dann gleich in den Speicher schreiben?

Laut BIOS müsste eine ganze Weile nur Programmcode lesen kommen.
Mal an den Adress/Datenpins der CPU messen.

Die Anfrage der Adresse ist ok, man sieht sogar, wie die hochzählt. Aber als Daten kommt erstmal immer FFFF zurück. Das ist definitv falsch.
Die Steuersignale an den Bustreibern zwischen CPU und ISA-Datenbus sind korrekt. Auch auf dem ISA-Datenbus liegt schon FFFF an.
Die Steuersignale an den Bustreibern zwischen ISA-Datenbus und Mainboardspeicher sind korrekt.
Die Steuersignale und der Adressbus an den Eproms sind korrekt. Und der Datenbus an den Eproms? Immer FFFF. Eproms leer?
Achja ich habe ja jetzt einen Eprom-Brenner (siehe Classic-Computing-Forum). Ausgelesen.

Quellcode:

0x00000000: ff ff ff ff 7f ff 3f ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 7f ff ff ff ff 7f ff 7f ff  .....?......................
0x00000020: ff ff ff 7f ff ff ff 7f ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ..............................
0x00000040: ff ff ff ff ff ff 7f 7f ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ..............................
0x00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
0x00000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
0x000000a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
0x000000c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
0x000000e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................


Ja, die sind beide fast leer. Die waren wohl nicht immer so gut zugeklebt wie jetzt. Eproms neu gebrannt. Juhu, das Brennen hat geklappt! Eingebaut - Mainboard läuft aber immer noch nicht.
Das war gestern Abend, jetzt gehts weiter.
--
Gruß
Stefan

Dieser Beitrag wurde am 05.05.2025 um 17:26 Uhr von Ordoban editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
001
05.05.2025, 21:07 Uhr
MarioG77

Avatar von MarioG77


Zitat:
Ordoban schrieb
Ich habe einen EC1834 geschenkt, und ein zweites EC1834-Mainboard zur Reparatur bekommen.


Mit dem Titel hast du sofort meine Aufmerksamkeit...
Mein defekter Floppy Controller kommt in kürze auch wieder auf den Tisch - wenn der frei ist.


Zitat:

...
1. Netzteil
...


Hier hatte ich Glück gehabt - ich hatte eine DDR Rückleuchte die ich als Last dran gehangen habe. Ist mir mittlerweile zu hell/warm. Ich habe eine elektronische Last aufgerüstet.
Bei mir war es übrigens nur der vergammelte Sicherungshalter.


Zitat:

...Ja, die sind beide fast leer. Die waren wohl nicht immer so gut zugeklebt wie jetzt. Eproms neu gebrannt. Juhu, das Brennen hat geklappt! Eingebaut - Mainboard läuft aber immer noch nicht.
Das war gestern Abend, jetzt gehts weiter.


ok, krass. Aber sei froh, dass das so eindeutig war und nicht nur ein paar Bits gekippt waren...

Mein EC1834 Reparatur-Blog ist leider noch nicht groß weiter gekommen...
https://mgoegel.github.io/ec1834-troubleshooting/DE/troubleshooting.html
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben

Dieser Beitrag wurde am 05.05.2025 um 21:07 Uhr von MarioG77 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
002
05.05.2025, 22:59 Uhr
Ordoban



Das sieht schon besser aus. Es wird nun der richtige Code aus dem BIOS gelesen und ausgeführt.



Kurz darauf bleibt der dann stehen. An den zuletzt geladenen Rom-Adressen kann man sehen, dass der irgendwo hier stecken geblieben ist



Die zuletzt gelesene Adresse ist E172. Das ist ziemlich irreführend, Der ist tatsächlich schon bei E16D stehen geblieben. Der 8086 macht schon code prefetch - Daten auf Verdacht zum Vorrat lesen.
Kurz davor wird der Speichertest der ersten 64KB gemacht, und der scheint einen Fehler als Ergebnis zu melden, ansonsten würde der Sprung bei E167 ausgeführt, und es würde weiter gehen.



Ich habe eine ganze Weile gebraucht, ehe ich diesen Speichertest verstanden habe. Der schreibt erst 55AA in den gesamten Speicherblock. Dann liest der die einzelnen Worte, vergleicht die mit 55AA, bricht ab wenn das nicht übereinstimmt, und tauscht den Wert im Speicher gegen AA55 aus.

So sieht das ganze im Logikanalyzer aus:



Aus diesem Signal-Salat das richtige zu finden ist gar nicht so einfach. Der vorletzte Speicher-Lese-Vorgang war noch OK:



Der letzte Speicher-Lese-Vorgang:



Hier fehlt ein Bit ! Als Speicheradresse steht da 0DFC.
In Mario's wunderschönen KiCad-Plänen kann man schnell finden welcher Speicherbaustein das sein müsste.


Der da!


Bevor ich jetzt anfange wild Speicherbausteine von dem Board zu schnipseln will ich sicherstellen dass es wirklich der ist. Also nochmal messen:



Schreibvorgang "1"



Und gelesen wird "0"



Der Austausch kommt dann morgen...
--
Gruß
Stefan

Dieser Beitrag wurde am 05.05.2025 um 23:01 Uhr von Ordoban editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
003
05.05.2025, 23:08 Uhr
MarioG77

Avatar von MarioG77

Das freut mich jetzt richtig, dass diese Arbeit nicht nur mir weiter hilft

Ich bin dann im Verlauf auch so vorgegangen. Den BIOS Code verglichen - wo es ungefähr hängt.
Dank an Hobi
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben

Dieser Beitrag wurde am 05.05.2025 um 23:09 Uhr von MarioG77 editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
004
06.05.2025, 09:02 Uhr
wpwsaw
Default Group and Edit


moin Stefan,

ja der 1834 kann auch eine schöne Baustelle sein.

das mit dem RESET ist so wie so komisch, nur das Board ist ja O.K. und nachvollziehbar, aber wenn Karten stecken, vor allem die COL, dann führt der RESET manchmal (meistens) zu Störungen wie kein Bild und das entsprechende piepen. Der Rechner läft trotzdem hoch und wenn er oben ist und ich mache einen Warmstart ist alles wieder O.K. und das ist bei allen drei 1834 so. Wahrscheinlich hat man deshalb den RESET Anschluss nicht mit einem Taster angeschlossen herausgeführt ;-)

Deine Tests sehen interessant aus, vor allem der IC-Stecker .

"Ich weiß nicht ob sie es schon wußten" .....

Das BIOS am 1834 hat auch eine POST Ausgebe und man kann eine POST Karte dafür nutzen.

Der Port A der PPI auf Adresse 60h zeigt den Abschluss der Prüfabschnitte.

Es existiert eine genaue Beschreibung des Prüfablaufes vom BIOS, hast du diese PDF?

da ich immer noch ein modifiziertes 1834 Board (1835 Vorgänger) defekt liegen habe, welches ich mir ab und zu hervor hole, hatte ich auch schon andere kleine Prüfprogramme geschrieben, weil ich aus dem BIOS Test nicht heraus komme.

Es existieren auch schon einige Beiträge hier im Forum darüber

Gruß
wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
005
06.05.2025, 20:55 Uhr
Ordoban




Zitat:
wpwsaw schrieb
ja der 1834 kann auch eine schöne Baustelle sein.


Wie fast alles.

Zitat:

das mit dem RESET ist so wie so komisch, nur das Board ist ja O.K. und nachvollziehbar, aber wenn Karten stecken, vor allem die COL, dann führt der RESET manchmal (meistens) zu Störungen wie kein Bild und das entsprechende piepen. Der Rechner läft trotzdem hoch und wenn er oben ist und ich mache einen Warmstart ist alles wieder O.K. und das ist bei allen drei 1834 so. Wahrscheinlich hat man deshalb den RESET Anschluss nicht mit einem Taster angeschlossen herausgeführt ;-)


Die Reset-Situation scheint sich bei dem Board normalisiert zu haben.

Zitat:

Deine Tests sehen interessant aus, vor allem der IC-Stecker.


Ja, die sind sehr praktisch, aber auch schweineteuer. Zumindest wenn man bedenkt, dass das nur ein Stückchen Plastik mit ein paar Metallstiften ist.

Zitat:

"Ich weiß nicht ob sie es schon wußten" .....

Das BIOS am 1834 hat auch eine POST Ausgebe und man kann eine POST Karte dafür nutzen.

Der Port A der PPI auf Adresse 60h zeigt den Abschluss der Prüfabschnitte.


So eine Post-Karte muss ich mir glaubich mal besorgen. Danke für den Tip!

Zitat:

Es existiert eine genaue Beschreibung des Prüfablaufes vom BIOS, hast du diese PDF?


Hab ich, war aber nur mäßig hilfreich.

Zitat:

da ich immer noch ein modifiziertes 1834 Board (1835 Vorgänger) defekt liegen habe, welches ich mir ab und zu hervor hole, hatte ich auch schon andere kleine Prüfprogramme geschrieben, weil ich aus dem BIOS Test nicht heraus komme.

Es existieren auch schon einige Beiträge hier im Forum darüber

Gruß
wpw


Ich werd glaubich den EC reparieren und dann in die Ecke stellen. Ich finde die A71x0-Serie deutlich interessanter.


So, zum aktuellen Stand:

RAM-IC getauscht, läuft nun deutlich weiter, brachte am Anfang einen blinkenden Cursor, und lief dann in einer Endlosschleife. Hab ich eine Weile gesucht, und mich dann entschlossen, mich erstmal über den EC schlau zu machen. Wozu sind zum Beispiel diese DIP-Schalter da? AHA! Unter anderem auch zum einstellen der Grafkkarte. Eingestellt war 80x25, das hier ist aber eine MON-Karte. Die eingstellt, und siehe da:

Der meckert einen Keyboard Error an (Klar - ist keine angsteckt...).
Dann zählt der den RAM-Test hoch.
Dann Bootdisk-Error (Joa, kein Floppykontroller dran).
Also Tastatur, Floppykontroller und Floppy angeschlossen.
Er meldet nun keinen Tastaturfehler mehr, Zählt RAM, und macht dann was auf der Diskette. (frisch erstellte DOS-Bootdisk)
Und bleibt da stecken.
Ich muss morgen mal gucken ob die Diskettenlaufwerke in Ordnung sind. Ich kann die ja im A7150 testen.
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
006
06.05.2025, 21:04 Uhr
MarioG77

Avatar von MarioG77

Ein passende POST Platine hätte ich .
Leider nicht mehr alle Bauteile für eine komplette Platine.

Hilft dir aber an dieser Stelle nicht mehr weiter. Da sind ja auch nur die Werte/Schritte 01 - 03.
Sagt er 04 hast du einen Parity Fehler...

Ein BIOS mit mehr Ausgabe ist auch noch auf der Todo-Liste...
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
007
07.05.2025, 06:55 Uhr
wpwsaw
Default Group and Edit


...so viel ist doch auf der POST Karte nicht drauf und auch nichts exotisches. Meine Eine war ein Bausatz....

eigentlich sagen die Zahlen welcher Test fehlerfrei abgeschlossen und bei 03 ist er erst einmal durch und die Grafik ein und danach kommen Tastatur und RAM Test.....

DIP Schalter .... auch eine Sache wie man sich Fehler einbauen kann..... man muss darauf achten welche DIP Schalter und wie rum sie eingelötet sind

es können ja beide Karten drin sein (COL und MON) dann entscheiden die DIP Schalter welcher primär ist und der andere blinkt mit dem Kursor bis er angesprochen wird. Z.B. bei MCAD oder GEDIT mit 2 Monitoren, einer für die Grafik und einer für die Befehle.... das funktioniert super!!!

wenn die Software das unterstützt...

wpw

so, jetzt los nach SDL, der Prüfling wartet auf seine C-Prüfung
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
008
07.05.2025, 19:48 Uhr
Ordoban



Die Diskettenlaufwerke funktionieren beide im A7150.

Ich habe jetzt mal Datenbus und Steuersignale wärend des Disketten lesens angesehen:



An dem DREQ und DACK kann man den Zeitpunkt für den Datentransfer sehr gut erkennen.



Die Daten, die hier per DMA übertragen werden, stimmen exakt mit dem Bootsektor der Diskette überein.

Danach passiert irgend etwas komisches mit dem Interrupt-Request des Floppykontrollers.



Danach kommt nur noch sowas: Das sieht aus, als wenn die CPU durch einen Speicherbereich voller "00" läuft - das ist eine Art von ADD.



Dann ist noch das her auffällig:



Der macht sehr oft etwas, was ich für den Speicher-Refresh halte. Aber so oft? Alle 15µs? Und ist es normal, dass dazu das IOW gesetzt wird?
--
Gruß
Stefan

Dieser Beitrag wurde am 07.05.2025 um 19:49 Uhr von Ordoban editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
009
07.05.2025, 19:50 Uhr
wpwsaw
Default Group and Edit


...schau die mal die Interrupt-Kontroller an....

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
010
07.05.2025, 21:54 Uhr
Ordoban



Ja, die guck ich mir dann auch noch an, aber ich hab erstmal eine andere Spur gefunden:

Beim DMA-Transfer zählt die Speicheradresse nicht richtig hoch. Anscheinend klappt die Zuweisung des Adressbus nicht so richtig.

Zwischen DMA-Kontroller und Adressbus hängt dieser Bustreiber:



Vergleicht man die Eingänge mit den Ausgängen wenn OE aktiv ist, dann stimmt Ausgang B5 nicht immer mit dem Eingang A5 überein. Das B5 ist immer High.



Also mal den 8286 tauschen - morgen.
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
011
08.05.2025, 09:06 Uhr
wpwsaw
Default Group and Edit


...ist so wie so alles sehr verzwickt mit dem inneren und äußeren Bus. Bei meinem defektem Board habe ich Probleme im inneren BUS auf dem Datenbus. Da müssen Treiber gegeneinander Arbeiten und die Daten in Wärme umwandeln. Ich habe schon viele Anläaufe gemacht und immer wieder aufgegeben.

Vielleicht sollte ich dir mal das Board schicken ;-)

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
012
08.05.2025, 20:42 Uhr
Ordoban



Nach dem Tausch des 8286 stimmen nun die Adressleitungen A0-A7.
Das Verhalten ist aber unverändert.
Wie sieht es denn mit A8-A19 aus? So:



Man sieht, dass der DMA-Transfer des Bootsektors noch F7C00 erfolgt. Das ist unsinnig, da liegt gar kein Speicher! Nach dem Laden des Bootsektors wird dann 07C00 ausgeführt - wo der Bootsektor eigentlich hin sollte.

Wie werden denn die oberen 4 Bits der DMA-Adresse erzeugt? Das machen diese 3 Schieberegister, die hier als D-Register missbraucht werden.



Der mittlere ist für den DMA-Kanal 2, und somit für den Disketten-Transfer verantwortlich.

So sehen die Signale an diesem Schieberegister aus:



Man kann erkennen, dass während des DMA-Transfers die Adresse mittels CS-Signal abgerufen wird. Es wird aber nie etwas mit dem C-Signal in das Register gespeichert.

Also das C-Signal weiter rückwärts verfolgen:



Das Problem ist dieses NOR-Gatter, das bringt immer LOW, obwohl beide Eingänge zeitweise auch mal beide auf LOW sind. Also: Gatter getauscht.

Ergebnis: Bootsektor wird nun gestartet, lädt 4 weitere Sektoren von Diskette, und das System bleibt dann mit
Quellcode:

PARITY CHECK SYSTEM BOARD
20000


stehen. Ok, dann morgen weiter mit dem Systemspeicher.
--
Gruß
Stefan

Dieser Beitrag wurde am 08.05.2025 um 20:44 Uhr von Ordoban editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
013
09.05.2025, 07:28 Uhr
wpwsaw
Default Group and Edit


Guten Morgen Stefan

....das sieht ja schon super aus. Aber der RAM Test ist doch vor dem Booten? Wo kommt denn jetzt die Fehlermeldung her?

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
014
10.05.2025, 13:06 Uhr
Ordoban



Es sieht so aus, als wenn der RAM-Test vor dem Booten den Fehler feststellt, und die RAM-Größe begrenzt. Das DOS nutzt den RAM dann trotzdem und läuft in einen Parity-Fehler.
Man kann an den Parity-Generatoren sehen, in welcher Bank der Parity-Fehler auftritt, aber nicht welcher Speicher-IC genau die Ursache. Ich hatte geglaubt zu erkennen welches Bit, und somit welcher IC das ist. Ich habe den getauscht, aber das hat nichts gebracht. Ich brauche eine bessere Methode zur Fehlersuche!

Die Idee ist nun, alle Signale an jedem Speicher-IC mit dem Logikanalyzer aufzuzeichnen als Textdatei zu exportieren, und dann per Programm auszuwerten.

Die Export-Textdatei ist pro Speicher-IC etwa 3GB groß, und der Export dauert pro IC etwa 3 Minuten.

Das Auswerte-Programm "Quick and Dirty" besteht aus 179 Zeilen Java. Das Programm wertet die Steuerleitungen (RAS, CAS, WE...) aus und ermittelt daraus die Reihen und Spaltenadressen. Bei einem Schreibvorgang merkt sich das Programm das Datenbit. Wird später wieder von dieser Adresse gelesen, dann wird das gemerkte Datenbit mit dem vom IC gelesenen verglichen. Am Ende wird eine Statistik ausgegeben.

Quellcode:

D73.csv: reads=439492, writes=427764, blinds=6, used=65536, fehler0=0, fehler1=0
D74.csv: reads=439494, writes=427740, blinds=6, used=65536, fehler0=0, fehler1=0
D75.csv: reads=439400, writes=427670, blinds=6, used=65536, fehler0=0, fehler1=0
D76.csv: reads=439420, writes=427670, blinds=6, used=65536, fehler0=0, fehler1=0
D77.csv: reads=439492, writes=427730, blinds=6, used=65536, fehler0=0, fehler1=0
D78.csv: reads=439550, writes=427796, blinds=6, used=65536, fehler0=0, fehler1=0
D79.csv: reads=439494, writes=427730, blinds=6, used=65536, fehler0=0, fehler1=0
D80.csv: reads=439506, writes=427740, blinds=6, used=65536, fehler0=0, fehler1=0
D81.csv: reads=439467, writes=427710, blinds=6, used=65536, fehler0=0, fehler1=0
D91.csv: reads=8211, writes=131799, blinds=0, used=65536, fehler0=0, fehler1=0
D92.csv: reads=8211, writes=131799, blinds=0, used=65536, fehler0=0, fehler1=0
D93.csv: reads=8211, writes=131799, blinds=0, used=65536, fehler0=0, fehler1=0
D94.csv: reads=8211, writes=131799, blinds=0, used=65536, fehler0=0, fehler1=0
D95.csv: reads=8211, writes=131799, blinds=0, used=65536, fehler0=0, fehler1=0
D96.csv: reads=8211, writes=131799, blinds=0, used=65536, fehler0=0, fehler1=0
D97.csv: reads=8211, writes=131799, blinds=0, used=65536, fehler0=0, fehler1=0
D98.csv: reads=8211, writes=131799, blinds=0, used=65536, fehler0=0, fehler1=8202
D99.csv: reads=8211, writes=131799, blinds=0, used=65536, fehler0=2, fehler1=1
D102.csv: reads=514294, writes=429015, blinds=6, used=65536, fehler0=0, fehler1=0
D103.csv: reads=523454, writes=429169, blinds=6, used=65536, fehler0=0, fehler1=0
D104.csv: reads=510219, writes=428993, blinds=6, used=65536, fehler0=0, fehler1=0
D105.csv: reads=525218, writes=429037, blinds=6, used=65536, fehler0=0, fehler1=0
D106.csv: reads=512852, writes=429015, blinds=6, used=65536, fehler0=0, fehler1=0
D107.csv: reads=521703, writes=429048, blinds=6, used=65536, fehler0=0, fehler1=0
D108.csv: reads=525103, writes=429169, blinds=6, used=65536, fehler0=0, fehler1=0
D109.csv: reads=515639, writes=429015, blinds=6, used=65536, fehler0=0, fehler1=0
D110.csv: reads=520691, writes=429037, blinds=6, used=65536, fehler0=0, fehler1=0
D117.csv: reads=10259, writes=133848, blinds=0, used=65536, fehler0=0, fehler1=0
D118.csv: reads=10259, writes=133848, blinds=0, used=65536, fehler0=0, fehler1=0
D119.csv: reads=10259, writes=133848, blinds=0, used=65536, fehler0=0, fehler1=0
D120.csv: reads=10259, writes=133848, blinds=0, used=65536, fehler0=0, fehler1=0
D121.csv: reads=10259, writes=133848, blinds=0, used=65536, fehler0=0, fehler1=0
D122.csv: reads=539572, writes=562885, blinds=6, used=8, fehler0=2, fehler1=2
D123.csv: reads=10259, writes=133848, blinds=0, used=65536, fehler0=0, fehler1=0
D124.csv: reads=10259, writes=133848, blinds=0, used=65536, fehler0=0, fehler1=0
D125.csv: reads=10259, writes=133848, blinds=0, used=65536, fehler0=0, fehler1=0


Auffällig sind hier 3 IC's. Um Fehlmessungen auszuschließen noch einmal widerholt:

Quellcode:

D98a.csv: reads=8211, writes=131799, blinds=0, used=65536, fehler0=0, fehler1=8202
D99a.csv: reads=8211, writes=131799, blinds=0, used=65536, fehler0=0, fehler1=0
D122a.csv: reads=10259, writes=133848, blinds=0, used=65536, fehler0=0, fehler1=0


Bei D122 gab es vermutlich Kontaktprobleme. Diese Mess-Klips haben sowas manchmal.
Bei D99? Keine Ahnung, scheint bei der 2. Messung OK zu sein. Das ist der eine den ich schon sinnloser Weise getauscht habe.
Der D98 liefert auch bei mehrfachen Wiederholungen das gleiche Ergebnis.
Ich gebe zwar nichts auf Äußerlichkeiten, aber der sieht nicht besonders gesund aus.


--
Gruß
Stefan

Dieser Beitrag wurde am 10.05.2025 um 13:07 Uhr von Ordoban editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
015
10.05.2025, 13:45 Uhr
Ordoban



Na also




--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
016
10.05.2025, 13:46 Uhr
RP



Ich habe im EC1834 und BIC fast alle kaputten RAM mit der Wärme Bild Kamera gefunden

Rolf
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
017
10.05.2025, 16:27 Uhr
MarioG77

Avatar von MarioG77

Weiß nicht, ob ich das soweit getrieben hätte - klingt aufwendig. Glückwunsch!

Klasse Screenshot...
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
018
10.05.2025, 17:46 Uhr
wpwsaw
Default Group and Edit


hallo Stefan , ist ja super,

eigentlich hätte er ja nach dem letzten Teil des Selbsttest (die unteren 64k auf dem Board) bei einem Fehler schon anhalten müssen. Aber wer weiß warum nicht.

jetzt läuft er ja. Hast du den auch einen HDD Kontroller dafür?

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
019
10.05.2025, 20:25 Uhr
Ordoban



Keine Ahnung... jetzt braucht der für den Speichertest deutlich länger, und zählt den richtig hoch.
Die BIOS-Version ist S723/S723. Gibt es da auch neuere, und kann man die einfach so updaten?

MFM-HDD-Kontroller waren sogar 2 Stück drin. Allerdings läuft die eingebaute MFM-Festplatte gar nicht mehr an. Zum Testen von dem Mainboard werde ich eine andere MFM-Platte nehmen. Ich freue mich aber schon darauf, die defekte MFM-Platte in die Zange zu nehmen. Wär doch cool, die wieder zum Laufen zu krigen.

Mit der Speicher-Erweiterung bringt der diesen Fehler:



Lässt sich aber trotzdem booten, und hat dann 320K:



Komischerweise erkennt der nach einem Warmstart plötzlich die vollen 640K:



Kennt einer von euch den CTRAM Speichertest? Weiß jemand wie man den auf dem EC zum laufen krigt? Bringt ein Runtime Error (genauso wie auf dem A7150)


--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
020
10.05.2025, 20:31 Uhr
MarioG77

Avatar von MarioG77

Letztes BIOS war s731/s732.
Kann man einfach so updaten.

Du brauchst wohl RAMBUG.EXE, da kannst du den RAM IC direkt erkennen und musst nicht suchen.
Viel mir gerade erst wieder ein. Ich sende dir eine Mail...
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
021
11.05.2025, 09:34 Uhr
Ordoban



Vielen Dank. Mit dem RAM-Test hab ich den defekten RAM gefunden, getauscht, und nun gehen 640K.

Der Festplatten-Kontroller scheint auch zu gehen, allerdings kann ich die Festplatte nicht lesen. Die hat noch das Low-Level-Format vom A7150 drauf. Das wird nicht kompatibel sein.

Wie kann man beim EC1834 ein Low-Level-Format durchführen?
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
022
11.05.2025, 10:14 Uhr
RP



hast du DCP 3.3 für den EC1834?
Auf der Diskette sollte hdinit.com oder hdinit.exe sein, auch ein Grafikkarten Driver für den COL Adapter

Rolf
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
023
11.05.2025, 10:25 Uhr
ralle



Ich kann nur ein Image beistellen.
--
Gruß Ralle

Wenn Sie dazu neigen, Bedienungsanleitungen zusammen mit dem Verpackungsmaterial wegzuwerfen, sehen Sie bitte von einem derart drastischen Schritt ab!...
... Nachdem Sie das Gerät eine Weile ausprobiert haben, machen Sie es sich am besten mit dieser Anleitung und ihrem Lieblingsgetränk ein oder zwei Stunden lang in Ihrem Sessel bequem. Dieser Zeitaufwand wird Sie dann später belohnen...

aus KENWOOD-Bedienungsanleitung TM-D700
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
024
11.05.2025, 10:43 Uhr
wpwsaw
Default Group and Edit


hdinit kann ich dir schicken....

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
025
11.05.2025, 10:48 Uhr
wpwsaw
Default Group and Edit


email ist raus, oder brauchst du ein Startdiskettenimage mit DCP3.3 ?

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
026
11.05.2025, 10:48 Uhr
Ordoban



Jetzt wo ihr es sagt... ich habe ja die Festplatte von dem ersten EC vom Bäckermeister gesichert. Da war auch eine HDINIT.COM dabei

Formattiert grad



Das sind übrigends die Screenshots direkt von der neuen Firmware-Version des VGA-Adapters.

Edit:
Danke Wolf, kommt aber 20min zu spät
--
Gruß
Stefan

Dieser Beitrag wurde am 11.05.2025 um 10:49 Uhr von Ordoban editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
027
11.05.2025, 13:28 Uhr
Ordoban



Aha, das "D" auf dem Slotblech heißt "defekt".



Der andere Kontroller sieht besser aus





Ok, damit würde ich sagen: Mainboard läuft. Der Nächste bitte!
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
028
11.05.2025, 13:34 Uhr
wpwsaw
Default Group and Edit


....meinst du mich ;-) ?

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
029
11.05.2025, 13:35 Uhr
Ordoban



Noch nicht, ich hab ja 2 Mainboards

Edit:
Nummer 2 hat aber auch so irre Nachverdrahtungen wie du von deinem erzählt hast.



Und der hat eine Russen-CPU drauf. Die sehe ich das erste Mal in Natura


--
Gruß
Stefan

Dieser Beitrag wurde am 11.05.2025 um 13:50 Uhr von Ordoban editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
030
11.05.2025, 14:40 Uhr
MarioG77

Avatar von MarioG77


Zitat:
wpwsaw schrieb
....meinst du mich ;-) ?

wpw


Bei mir hattest du ja damals Angst, dass ich dir den auf 16 Bit IO Aufrüste...
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
031
11.05.2025, 14:48 Uhr
RP



"Und der hat eine Russen-CPU drauf. Die sehe ich das erste Mal in Natura "

https://www.arithmeum.uni-bonn.de/sammlungen/rechnen-einst/objekt.html?tx_arithinventory[object]=160

da bekommst sicher auch noch Ersatz Kugeln, für die Russen CPU

Rolf
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
032
11.05.2025, 15:39 Uhr
wpwsaw
Default Group and Edit


@MarioG77

keine Ahnung was du meinst.......


@RP

ich habe auf einem Board auch eine russische CPU

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
033
11.05.2025, 15:55 Uhr
MarioG77

Avatar von MarioG77

wolltest das Board auch mir schon Mal zusenden, aber hast dann gekniffen...
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
034
11.05.2025, 16:10 Uhr
wpwsaw
Default Group and Edit


...das war die Zeit wo ich selber mal wieder gesucht habe. Das Board hatte/hat einige Fehler, nur den entscheidenden letzten Fehler immer noch nicht gefunden hatte. :-((

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
035
11.05.2025, 16:19 Uhr
Dresdenboy




Zitat:
RP schrieb
"Und der hat eine Russen-CPU drauf. Die sehe ich das erste Mal in Natura "

https://www.arithmeum.uni-bonn.de/sammlungen/rechnen-einst/objekt.html?tx_arithinventory[object]=160

da bekommst sicher auch noch Ersatz Kugeln, für die Russen CPU

Rolf


Als ich Mitte der 80er mit Familie in Moskau war, rechneten die Kassiererinnen manches auch schnell mal auf diesen Dingern.
--
___________________________________
Produktionen im Rahmen der "The Computer Art Community" (Demoszene): https://demozoo.org/sceners/64936/, YT-Kanal: https://www.youtube.com/@4lpha0ne/videos
Programmierung seit '86 in BASIC: KC85/3, C64, A1200, PC | ASM: LC-80, C64, KC87, A1200, NeoGeo, PC, Mega 65, µC | Turbo Pascal: BIC, PC | C: RS/6000, Alpha, PC, µC | C++, Java, Javascript, Rust, Lua, Perl, PHP u.a. auf PC
HW: LC-80, BIC A5105 komplett, KC87, KC85/2-4, KCC, C64s, C16, Plus/4s, A500s, A1200, Mega 65, ESP32s, RasPis, PCs, Laptops, MR 610, ...
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
036
11.05.2025, 16:29 Uhr
Ordoban



Wenn es funktioniert... warum nicht?

Ich war 2000 bei der Bundeswehr in einer Instandsetzungskompanie, und mein Opa hatte mich gefragt was ich denn da so mache. Hab ich ihm Bilder von den Feldtelefonen (FFOBZB "Ackerschnacker") gezeigt. Der meinte dann "Waaas? Die Dinger gibts noch?"


Zitat:
MarioG77 schrieb
Bei mir hattest du ja damals Angst, dass ich dir den auf 16 Bit IO Aufrüste...


Der Bus ist schon 16 Bit. Die oberen 8 Bit sind nur dooferweise auf der mittleren Stiftleiste statt auf der 16-Bit-ISA-Verlängerung. Also ein rein mechanisches Problem.
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
037
11.05.2025, 17:48 Uhr
MarioG77

Avatar von MarioG77

Der EC1834 kann kein 16 Bit IO, weil ihm ein kleiner Rest der Logik fehlt (IOCH16 Signal).
Für diese Logik hatte ich vor 2 Jahren eine kleine ("Tronix"-)Mod Platine gebaut.
Speicherzugriffe gehen schon in 16 Bit, deshalb schrieb ich oben 16 Bit IO

Letztendlich konnte ich den 16 Bit Zugriff bis heute noch nicht endgültig testen.
Der NE2000/RTL8019 16 Bit Treiber schmiert bei 16 Bit Zugriffen generell ab, weil er wohl einen 286er (286/386 Op-Codes?) voraussetzt. Der 8 bit Treiber macht alles generell in 2x 8Bit Portzugriffen.

An meiner Modifikation und 16 Bit NE2K Karte wird jedenfalls der 16 Bit Zugriff vom RTL8019 auch erkannt.

Bin da noch nicht wieder dazugekommen. Das steht auf der Todo Liste neben meiner VGA Karte...
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
038
12.05.2025, 21:57 Uhr
Ordoban



Achja stimmt. IO ist nur 8 Bit.

Ok, weiter mit der Reparatur vom 2. Board.

Wie immer als erstes Takt, Reset und Steuersignale an der CPU (in dem Fall S0-S2)



Takt OK, Reset OK.

CPU macht 3 Kommando Lesen und dann Speicher schreiben? Das hatten wir doch schonmal! Diesmal direkt die Eproms in den Brenner gesteckt und ausgelesen.


Quellcode:

0x00000000: 45 43 31 38 33 34 20 20 31 32 20 20 31 39 38 38 20 41 55 47 20 30 38 20 43 31 33 20 20 20 20 20  EC1834  12  1988 AUG 08 C13    
0x00000020: 20 20 20 20 20 20 20 20 79 03 ef ef ef ef ef 55 50 ed 55 55 57 53 8b 1e e8 39 fc 72 b4 80 01 11          y......UP.UUWS...9.r....
0x00000040: fc 74 80 03 07 fa 76 b4 8a 32 d0 bb c0 d9 e6 f6 f0 fa e7 00 bd 8a 41 c6 41 00 ff 50 a0 00 80 08  .t....v..2............A.A..P....
0x00000060: e8 00 a2 00 31 9d 5e 59 5a 5d 5d 5d 5d ca 00 c1 c1 c1 c1 c1 c1 c2 c2 c2 c2 c2 c2 c2 c2 c2 c2 c2  ....1.^YZ]]]]...................
0x00000080: c2 c2 c2 c2 c2 c2 c2 c2 3f 24 c6 3e 00 f6 fa 8a 90 24 3c b0 74 b0 e8 07 40 a7 e4 24 e6 fb 50 72  ........?$.>.....$<.t...@..$..Pr


Sieht soweit OK aus. Und das andere?

Quellcode:

0x00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
0x00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
0x00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
0x00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................
0x00000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................................


Aha. Ok, ich wollte sowieso das neuseste BIOS drauf haben. Gebrannt.

Eingebaut. Immer noch das selbe. Also an den AD0-AD15 messen.



Der 8086 hat einen gemultiplexten Adress und Datenbus. Auf diesem Bus werden also abwechselnd die Adresse und Daten übertragen. Ich sehe auf der Messung nur die Adressen. Warum?



Die Bustreiber werden nicht korrekt angesteuert. Schuld ist ein russischer 7404. Getauscht. Siehe da: jetzt wird zumindest mal BIOS-Code ausgeführt. Aber nicht lange.

Es werden viele IO-Operationen ausgeführt, und dann bleibt er stehen. Ich hab mich nun verwirren lassen, und eine ganze Weile auf dem Datenbus gesucht. Schließlich habe ich den Programmcode angeguckt, bei dem der stehenbleibt - und mich erinnert: das ist genau das selbe Problem wie bei dem ersten EC1834. Siehe hier Ja, genau der selber IC (D10) ist auch hier defekt. Getauscht. Der kommt nun etwas weiter und bleibt dann wieder stehen. Gemessen. Gewundert: der bleibt jetzt wieder an der selben Stelle stehen wie vor dem D10-Tausch.
Nochmal den D10 gemessen. Der ist wieder hin. Und dann sehe ich: Oh Sch....t - Der ist verkehrt herum eingelötet. Also nochmal getauscht. Nun kommen wir bis zum ersten Speichertest. Und bleiben hier stecken.
Also morgen Spass mit Speicherbausteinen
--
Gruß
Stefan

Dieser Beitrag wurde am 12.05.2025 um 22:03 Uhr von Ordoban editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
039
13.05.2025, 12:35 Uhr
MarioG77

Avatar von MarioG77

Interessant, dass der D10 gleich so oft auftaucht... Und das ist so ein blöder Fehler...
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
040
14.05.2025, 08:56 Uhr
Bert



Schön, daß Du die Fehlersuche so systematisch betreibst und bis zum Ende durchziehst.
Das gefällt mir!
--
Viele Grüße,
Bert
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
041
14.05.2025, 18:28 Uhr
Ordoban



Der D10 war ein Russe... kommt es mir nur so vor, oder fallen die besonders oft aus?

Ich habe gestern den halben Abend nach Speicherfehlern gesucht. Das höhere Byte "55" wird korrekt gelesen, aber das untere Byte ist immer "00" statt "AA". Ich habe schließlich herausgefunden, dass tatsächlich "00" in die unteren Bytes geschrieben wird. Ich hatte erst einen Bustreiber in Verdacht, den getauscht, aber das war es nicht.

Der D22 ist zum gleichen Zeitpunkt wie der D111 aktiv und erzeugt so eine Art Kurzschluss auf dem Datenbus. Der D22 sendet "55" und D111 sendet "AA". Beide Bustreiber haben mehr Kraft das Signal auf Low zu ziehen. Und so wird "55" und "AA" zu "00". Aber warum ist der D22 aktiv? Es sah so aus, als wenn der D63 defekt ist, getauscht, immer noch nix. Dann mal gleichzeitig am Ausgang des D63B und am OE-Eingang das D22 gemessen. Die Signale sind unterschiedlich! Leiterbahnen auf dem Boad verfolgt - der Stromlaufplan stimmt hier nicht mit dem Board überein.

Heute gehts weiter
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
042
15.05.2025, 20:15 Uhr
Ordoban



ES LEBT!



Naja zumindest ein bischen. Ich hatte ja beim letzten Mal schon entdeckt, dass die OE-Ansteuerung des Bustreibers D22 nicht korrekt ist, und dass die Pläne nicht mit der Platine übereinstimmen. Also die Leiterbahnen des OE-Signals auf der Platine verfolgt, Die Logikgatter gemessen, und auf Plausibilität geprüft. 2 Gatter weiter dann ein defektes NAND gefunden (wieder ein Russe K555LA3), getauscht. Der Speichertest der ersten 64K läuft nun vollständig durch, schlägt aber trotzdem Fehl. Die Ursache dafür ist, dass irgendwo wärend den Speichertests der Parity-Check anspricht. Wenn der Speichertest selbst OK ist, und das Parity anspricht, dann kann es nur der Parity-RAM sein (hab ich gedacht). Also beide Parity-RAM's aufgezeichnet, und mein Auswerteprogramm drübergejagt. Das zeigt eindeutig den Parity der unteren 8 Bits als fehlerhaft an. Also getauscht (da ich RAM-IC's mit meinem Tester nicht ausprobieren kann, auf Sockel). Funktioniert immer noch nicht. Noch 2 andere RAM-IC's probiert - immer das selbe. Ich habe dann eine Weile an der Parity-Schaltung herumgemessen und mich immer wieder über das irgendwie komisch aussehende Ausgangssignal des Parity-Generators D113 gewundert. Stellt sich heraus: der D113 (ein Russe...) ist defekt. Dass ich einen 74*280 auf Lager habe ist unwarscheinlich, also erstmal den Ausgang mit einem Widerstand auf Masse gelegt, und siehe da: läuft wieder ein Stück weiter. Ok, das war dann ein guter Zeitpunkt um ins Bett zu gehen.

Heute die Idee: ich hatte doch eine Lagerliste von den ganzen alten 74ern gemacht. Die ist zwar nicht mehr aktuell, aber mal reingucken kann man ja mal.

Quellcode:

4x2 NAND            als00      iii                          s00      ii                 ls00      iiiiii                f00      i
4x2 NOR             ls02      i                         hct02      i                    als02      i
6x  NOT             f04      iii                04      i           s04      i          als04      ii           ls04      iiiiiiiiiiiiiiiiiii
6x  NOT OC ls05      i
6x  NOT OC  06      iiiiiiiiiiiiiiiiiiiiiiiiiiiii
6x  NOT OC  07      iii
4x2 AND    s08      iii        ls08      iiii          f08      iii
3x3 NAND            f10      iii            s10      iii
3x3 AND             ls11      i         f11      ii
6x NOT Schmitt Trigger ls14      iiiiii            hc14      i         c14      i      hct14      i
2x4 NAND            ls20      ii
2x4 AND             hc21      i
4x2 OR              s32      i          ls32      iii           f32      i
4x2 NAND            ls37      i     s37      i
4x2 NAND OC         38      iiiiii          ls38      iiiii
2x2x2 AND/OR 50     i
1x3 1x2 AND/NOR s51      ii         ls51      iiiii
2x RS-FF s74      ii         f74      iiiiiiiiiiii           ls74      iiiii         hct74      ii           hc74      ii            als74      iii          74      iiii
4x2 XOR s86      ii         ls86      iiii
1 BCD-Counter ls90      i
MONOFLOP    121     i
4x Treestate Buffer hct125     i            ls125     iiiiiiii          f125     ii
2x2/4 Multiplexer ls158     i
8bit Schieberegister s.in-p.out ls164     ii
4x d-ff ls175     i
4bit bustransceiver ls243     i
9bit parity checker/generator s280     i      f280     ii


ganz unten
Von den 3 Stück in der Liste ist nur noch einer auffindbar. Egal, reicht.



Damit läuft das Board auch mit Parity. Dann wäre nur noch der Fehler im oberen Block den Mainboard-Rams.

Mir ist bei den Russen-IC's aufgefallen, dass ab und zu der Verguss nicht vollständig ist, und unten Löcher bis zum Trägerblech sind. Könnte es sein, dass dort Feuchtigkeit eindringen kann?



--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
043
16.05.2025, 01:08 Uhr
KCMattze



Möglich, ich werfe immer alle Russen IS raus und mache DL oder 74LS rein....

Die ärgern mich einfach zu sehr. Die Malzriegel waren sogar mal eine Zeit lang lichtempfindlich.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
044
17.05.2025, 09:12 Uhr
Ordoban



Nach Austausch eines RAM IC's läuft das 2. Mainboard vollständig. Wie ich den gesucht und gefunden habe, ist schon in #14 beschieben.

Die original Tastatur geht zusammen mit dem 1. Mainboard zurück an Günther. Ich habe also DL nach einem Adapter nach PS2 gefragt, und er hat mich auf diese Lösung hingewiesen: https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=12722

Eine neue Firmware für den Tastaturkontroller von srmeister. Genial! Einfach EPROM brennen und PS2-Tastatur direkt anstecken.



Funktioniert super.
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
045
23.05.2025, 19:37 Uhr
Ordoban



Als nächstes ist nun das Mainboard von wpw dran.

Ein sehr interessantes Board. Das hat deutlich mehr Patch-Verdratung als die anderen, auch auf der Rückseite. Das Datum auf dem EPROM ist 27.03.90, und er Inhalt weicht etwas von den bisherigen BIOS-Versionen ab.



Die erste Messung an den AD-Pins der CPU zeigt, dass der direkt nach dem EPROM-CRC stehen bleibt. Wenn man genauer hinsieht, dann erkennt man, dass die letzte Operation eine IO-Ausgabe an den DMA-Kontroller ist.



So sieht das Programm an der Stelle aus



Aber warum bleibt der da stehen? Naja, mal am DMA-Kontroller messen.



Hier wird es irre. An dem CS des DMA-Kontrollers passiert gar nichts. Also an dem IO-Adressverteiler (D89) gemessen. Hier sieht man nun schön die Aktivitäten auf den CS-Signalen der einzelnen IO-IC's. Durchgang der CS-Leiterbahn vom D89 zum DMA-Kontroller gemessen - ist OK. Nochmal am DMA-Kontroller gemessen, diesmal kommt hier das CS. Messung mehrmals wiederholt.
AHA! Die Messung ist sehr inkonstistent. Wie weit das BIOS im Hardwaretest kommt ist jedes mal unterschiedlich. Und der Datenbus am DMA-Konroller stimmt nie.
Also kontetrieren wir uns auf den Datenbus. Eine gute Möglichkeit die Datenbusse zu messen ist es, mit dem Testclip direkt auf den Bustreiber zu klammern.
(Ich hab vergessen davon einen Screenshot zu machen, das nächste Bild ist gestellt - das sah auf dem Original noch etwas komischer aus)



Auffällig ist, dass der Richtungs-Eingang immer auf HIGH steht.



Damit ist immer ein Transfer von A nach B, also vom XD-Bus auf den D-Bus aktiv. Das dürfte einen Kurzschluss auf dem Datenbus ergeben. Warum ist der immer HIGH? Messen!



Also mal wieder ein Russe.



Getauscht - nun sieht das besser aus.


--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
046
23.05.2025, 20:20 Uhr
Ordoban



Das Board läuft aber immer noch nicht. Das BIOS läuft nun an genau die Stelle wie bei der ersten Messung, bleibt dort eine Weile stehen, und läuft dann weiter. Immerhin sehr konsistent, der macht bei jedem Lauf das selbe.
Es war nicht schwer herauszufinden, was der in der Zeit macht - einen DMA-Transfer. Aber warum? Der macht an der Stelle die Initialisierung des DMA-Kontrollers, was den eigendlich erstmal komplett stoppen sollte. Das Kommentar, "2: disable controller" für den Wert 04h, (den der IDA Disassembler automatisch setzt) klingt logisch.
Also mal das Datenblatt für den i8257 lesen. Das sagt "Enables DMA Channel 2" für dieses Bit.



Das stimmt nicht mit dem Kommentar in der IDA überein. Warum? Und warum schreibt der 04h in das Kommandoregister? Damit startet der einen DMA-Transfer, ohne vorher mit den anderen DMA-Registern bestimmt zu haben woher und wohin. Dann sehe ich es: das Kommentar in der IDA bezieht sich auf den i8237, nicht auf den i8257.
Was ist der i8237 für einer? Das ist der DMA-Kontroller, der ursprünglich in dem ersten IBM-PC's eingesetzt war. Der i8257 war wohl eher für 8080 und 8085-Systeme gedacht.

Vergleicht man das BIOS dieses Boards mit dem original EC1834-BIOS, dann wird langsam klar, was hier los ist. (links dieses Board, rechts orignal EC1834)



Das ist also ein Detail was in diesem Board geändert worden ist. Meine Nachfrage an wpw ergab, dass auf dem Board tatsächlich ursprünglich ein i8237 aufgelötet war. Anscheinend ist dieses Board ein Prototyp, und durch Einsatz den "richtigen" DMA-Kontrollers sollte das mehr IBM-Kompatibel werden.

Ich habe nun erstmal die original-EC1834 ROMS eingesetzt, um weiter zukommen, bis ich einen i8237 habe (schon bestellt). Damit scheint der DMA-Kontroller richtig initailisiert zu werden, und startet den RAM-Refresh.
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
047
23.05.2025, 20:32 Uhr
wpwsaw
Default Group and Edit


...es ist schon gewaltig, was du alles da heraus gefunden hast....

vielen Dank für deine Mühe, soweit und so tief wäre ich nicht gekommen....

gruß
wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
048
23.05.2025, 21:02 Uhr
Ordoban



Der Hardware-Test kommt nun weiter - bis zur Initialisierung des Tastatur-Kontrollers. Danach fährt der sich irgendwo fest.

An der Stelle passiert es...



Anscheinend wird die Rücksprung-Adresse nicht korrekt vom Stack gelesen. Ein Speicherfehler? Sollte der nicht vorher getestet worden sein?

Ja, wird getestet. Aber nach einem erkannten Fehler wird einfach weiter gemacht. Ein Bug im BIOS. Loool.



Was ist nun mit dem Speicher los? Das CAS-Signal beider Speicherblöcke ist tot, immer HIGH.



Was nun? Richtig! Messen!



Also ist der OSC-Ausgang des 8284 tot. Einen 8284 hab ich nicht da. Muss ich erst bestellen.
--
Gruß
Stefan

Dieser Beitrag wurde am 23.05.2025 um 21:20 Uhr von Ordoban editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
049
25.05.2025, 16:13 Uhr
MarioG77

Avatar von MarioG77

Ein wenig beneide ich dich gerade um dieses Rätsel...
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
050
25.05.2025, 17:26 Uhr
Enrico
Default Group and Edit


Um die Rätsel eher weniger, sondern um die Lösungen und Lösungswegmöglichkeiten.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
051
25.05.2025, 17:28 Uhr
MarioG77

Avatar von MarioG77

Wenn man das Rätsel gelöst hat, ist die Lösung dann fast langweilig... nein, ich meine das Rätsel - ich denke immer noch gerne an die Reparatur von meinem Board zurück.
Der Weg dahin war verdammt spannend und lehrreich.
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
052
27.05.2025, 19:02 Uhr
Ordoban



Heute sind die 8284 gekommen, der 8237 lässt noch auf sich warten. Sehr merkwürdig.

Also 8284 eingebaut - nix. Kein CAS, kein Takt, kein OSC.
Zweiten 8284 eingebaut - das selbe.
Oszi aufgebaut, am Quartz gemessen - alles OK
Am OSC gemessen - mit dem Oszi sehe ich Takt. Aber warum nicht mit dem Logikanalyzer?
Samplerate 50Mhz sollte die 14Mhz messen können. Samplerate hochgestellt, auf einmal sehe ich mit dem an OSC auch Takt. Einstellungen überprüft, Glitchfilter ist aktiv! Und der hat wohl den 14Mhz Takt herausgefiltert.

Und warum ist dann auf CAS kein Takt? Der sollte nicht gefiltert werden. Nochmal wie in #048 gemessen. Der D57A ist der Übeltäter! Getauscht, und siehe da:







Morgen gehe ich dann auf Speicherfehler-Jagd.

@wpw: weißt du was über die Lieferung von dem 8237?
--
Gruß
Stefan

Dieser Beitrag wurde am 27.05.2025 um 19:03 Uhr von Ordoban editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
053
27.05.2025, 19:11 Uhr
wpwsaw
Default Group and Edit


...laut Sendungsverfolgung müsste der schon da sein. Nichts im Briefkasten?

und super, das es weiter geht ;-)))

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
054
28.05.2025, 00:20 Uhr
KCMattze




Zitat:
MarioG77 schrieb
Wenn man das Rätsel gelöst hat, ist die Lösung dann fast langweilig... nein, ich meine das Rätsel - ich denke immer noch gerne an die Reparatur von meinem Board zurück.
Der Weg dahin war verdammt spannend und lehrreich.



Ja, ist wie eine Sucht oder?

Da sind die Sonett, SKR, KR und R160 an denen ich gerade arbeite ja schon fast langweilig. Immerhin konnte ich nach einer Elkokur des Sonett die übelsten Kassetten sauber in den KC lesen! Respekt vor dem kleinen Teil!
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
055
28.05.2025, 18:34 Uhr
susowa




Zitat:
KCMattze schrieb
... Respekt vor dem kleinen Teil!


Also das "kleine" Teil war das Minett - das steht bei mir noch irgendwo herum

MfG

Dieser Beitrag wurde am 28.05.2025 um 18:34 Uhr von susowa editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
056
28.05.2025, 22:09 Uhr
Ordoban



Obwohl erst für Freitag angekündigt, ist heute doch noch der 8237 gekommen. Hab ich natürlich direkt zusammen mit den Original-ROM's ausprobiert.

Scheint auch zu funktionierten, aber irgendwie ist die Anzeige der Speichergröße fehlerhaft. Es ist hier noch keine Speichererweiterung gesteckt, es sollte also nur 256K vorhanden sein.



Der gelegendliche System Board Error 101 ist auch immer noch da. Ich hatte gedacht, dass der mit dem Original-ROM nicht mehr kommt. Naja ist halt ein Prototyp.

Ich hab mein Speichertest-Ding mit der unteren Bank gemacht.


Quellcode:

D73.csv: reads=177154, writes=174229, blinds=7, used=65536, fehler0=0, fehler1=0
D74.csv: reads=173033, writes=162008, blinds=7, used=65536, fehler0=0, fehler1=0
D75.csv: reads=156967, writes=181696, blinds=7, used=65536, fehler0=0, fehler1=0
D76.csv: reads=67647, writes=91914, blinds=7, used=65536, fehler0=0, fehler1=0
D77.csv: reads=67647, writes=91931, blinds=7, used=65536, fehler0=0, fehler1=0
D78.csv: reads=175095, writes=164074, blinds=7, used=65536, fehler0=0, fehler1=0
D79.csv: reads=180173, writes=169147, blinds=7, used=65536, fehler0=0, fehler1=0
B80.csv: reads=177092, writes=166084, blinds=7, used=65536, fehler0=0, fehler1=0
D81.csv: reads=67647, writes=91914, blinds=7, used=65536, fehler0=1, fehler1=1
D102.csv: reads=48604, writes=167811, blinds=7, used=65536, fehler0=0, fehler1=0
D103.csv: reads=2459, writes=92181, blinds=7, used=65536, fehler0=0, fehler1=0
D104.csv: reads=12896, writes=165656, blinds=7, used=65536, fehler0=0, fehler1=0
D105.csv: reads=34523, writes=153720, blinds=7, used=65536, fehler0=0, fehler1=0
D106.csv: reads=57341, writes=176563, blinds=7, used=65536, fehler0=0, fehler1=0
D107.csv: reads=2459, writes=92191, blinds=7, used=65536, fehler0=0, fehler1=0
D108.csv: reads=2459, writes=92209, blinds=7, used=65536, fehler0=0, fehler1=0
D109.csv: reads=2459, writes=92187, blinds=7, used=65536, fehler0=0, fehler1=1
D110.csv: reads=2459, writes=92737, blinds=6, used=65536, fehler0=0, fehler1=0
D109a.csv: reads=36335, writes=155543, blinds=7, used=65536, fehler0=0, fehler1=4
D109b.csv: reads=33962, writes=153143, blinds=7, used=65536, fehler0=0, fehler1=4
D109c.csv: reads=42601, writes=161799, blinds=7, used=65536, fehler0=0, fehler1=4
D81a.csv: reads=67647, writes=91927, blinds=7, used=65536, fehler0=1, fehler1=1
D81b.csv: reads=173297, writes=162285, blinds=7, used=65536, fehler0=5, fehler1=0
D81c.csv: reads=67647, writes=91950, blinds=7, used=65536, fehler0=1, fehler1=1



D81 und D109 sind beides Austauschkandidaten - morgen.
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
057
28.05.2025, 22:15 Uhr
ggrohmann




Zitat:
KCMattze schrieb
Da sind die Sonett, SKR, KR und R160 an denen ich gerade arbeite ja schon fast langweilig. Immerhin konnte ich nach einer Elkokur des Sonett die übelsten Kassetten sauber in den KC lesen! Respekt vor dem kleinen Teil!



Also im Sonett hatte ich selten andere Fehler als die weißen Frolyt und die Russen-Elkos. OK, einen gemeinen Fehler im Sonett und Anett gibt es: den Schnellstop-Schaltkontakt in der Mikrofonbuchse! Das Ding kann Ursache für ein Leiern sein, welches nur sporadisch, in Abhängigkeit von der Geräteaufstellung oder gänzlich erratisch auftritt. Da sucht man den Fehler im Laufwerk, am Motor, an der Motorelektronik vergebens. An diesen dämlichen Kontakt denkt niemand!

Im SKR 7xx gibts schön viele verschiedene Fehler, so richtige Gemeinheiten kenne ich da eher nicht. Wobei: die SMD-Version kann wiederum schon sehr gemein werden. Da einen Kracher zu suchen, kann schon abendfüllend sein.

Ein schöner Fehler im R160 ist immer wieder eine Teleskopantenne, die Kontakt zum Netzteil-Blech hat, an welchem die Antenne eigentlich isoliert angeschraubt ist.

Guido
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
058
29.05.2025, 06:34 Uhr
wpwsaw
Default Group and Edit


Guten Morgen Stefan,

bezüglich 1834M

wie schon geschrieben, das mit den Briefpaketen ist so eine Sache für sich. Man brauch nicht unterschreiben und sie werden als "Zugestellt" makiert wenn sie im Zielbriefzentrum sortiert werden (24.05.2025). Und dann verliert sich immer die Spur bis sie plötzlich im Briefkasten liegen.....Das Gestern mit der Änderung auf Zustellung "Freitag" ist ja auch komisch. Aber gut, ist ja angekommen.

Was ist denn das für ein Speichertest? Er zeigt dir die Bausteine an? Irgend wo stand mal, das eigentlich der komplette Speicher ONBOARD sein sollte. Auf der BK600 sollte ja auch 1MB drauf sein, leider hat sich Claus (cw) noch nicht gemeldet. Es sollte auch möglich sein 2 384kB Karten stecken zu können.

das mit dem 101 ist auch komisch, ob es doch an den Timern liegt? War nicht an einem ein extra Draht angelötet?

Gruß und Danke
wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP

Dieser Beitrag wurde am 29.05.2025 um 06:46 Uhr von wpwsaw editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
059
29.05.2025, 10:02 Uhr
Ordoban



So, die beiden Speicher sind getauscht, nun sind wir wieder weiter:



Ok, ne Tastatur anstöpseln.



Keine Fehlermeldung wegen Diskettenkontroller nicht vorhanden? Nix?
Nagut, mal einen Diskettenkontroller stecken. Mit dem vom normalen EC1834 tut sich gar nichts, bleibt auch nach dem Speichertest stehen.

Dann den, den du mitgeschickt hattest:



Der sucht auf der Diskette, aber kann anscheinend nichts lesen.
Wie sieht es mit Speichererweiterung aus?



Gut! Wie ist das mit dem Festplattenkontroller? Ich probiere zuerst deinen aus.



1701 ? Hmm. Ich probiere meinen Festplattenkontroller.



Startet immerhin von Festplatte, aber irgendwas stimmt mit der Grafik nicht.
DIR



Oha...
Beim Ausführen von Programmen stürzt der immer ab.

Was für Diskettenlaufwerke waren/sind denn in dem EC1834M? Noch die (für Robotron) normalen 80Spur,- 2Seiten,- DD-5.25Zoll, -720KB,- Laufwerke? Oder schon 1,2MB oder 1,44MB?

Das 101-Systemboard-Error scheint nicht mehr zu kommen.

Den Speichertest hatte ich in #014 beschrieben. Im Prinzip zeichne ich den Durchlauf des BIOS-Speichertests mit dem Logikanalyzer direkt an jedem Speicherbaustein auf, und werte die Aufzeichnung mit einem kleinen Java-Programm aus. Das Programm sieht und merkt sich was in jede Speichzelle geschrieben wird und vergleicht das, wenn es wieder gelesen wird. Der Vorteil dieses Verfahrens ist, dass es auch ohne ein laufendes Betriebssystem funktioniert.

Der komplette Speicher Onboard? Auf dem Board hier sind nur 36 x 4164 drauf. Das sind mit Parity genau 256KBytes. Vielleicht war geplant, die irgendwann mit 36 x 256KBit zu bestücken.

Ich werde auf jeden Fall noch die obere Bank des Onboard-Speichers prüfen müssen. Der bringt ja den Parity-Error.
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
060
29.05.2025, 10:25 Uhr
wpwsaw
Default Group and Edit


...das sieht richtig gut aus...

das mit den Laufwerken, keine Ahnung... vielleicht 360/720k LW wie beim XT...da muss ja dann auch die Diskettenformatierung stimmen DOS-Format

ich werde mal was vom 1835 heraussuchen. Vielleicht steht da etwas...

1701 ist ein XT-Fehler im Zusammenhang mit dem HDC, der vieles sein kann... Kabel, Festplattentyp falsch gejumpert...... muss also nicht unbedingt ein Defekt sein.

gruß
wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
061
29.05.2025, 10:32 Uhr
wpwsaw
Default Group and Edit


....Nachtrag zum FDC, da er modifiziert ist könnte der auch für 1,2MB oder 1.44MB LW so ist es für den 1835 vorgesehen gewesen.....

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
062
29.05.2025, 12:33 Uhr
RP



1,44 und 1,2 gehen im XT nur mit driver oder Zusatz BIOS.
Der EC 1834 war ein AT Rechner.

Rolf
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
063
29.05.2025, 12:46 Uhr
felge1966
Default Group and Edit


Der 1834 war doch kein AT sondern ein XT. Die AT waren doch erst ab 80286er . Da verwechselt du es vermutlich mit dem EC1835 auf 286er Basis.

Gruß Jörg
--
http://felgentreu.spdns.org/bilder/jacob120.gif
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
064
29.05.2025, 12:48 Uhr
wpwsaw
Default Group and Edit


...du meinst sicherlich den 1835 als AT....

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
065
29.05.2025, 12:49 Uhr
wpwsaw
Default Group and Edit


Jörg, da waren wir wohl gleichzeitig am schreiben....
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
066
29.05.2025, 13:00 Uhr
RP



Selbst verständlich 1835, Alzheimer lässt grüßen

Rolf
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
067
29.05.2025, 13:01 Uhr
Ordoban



Das sind alles Prototypen. Die Bestückung von dem Floppykontroller ist Standard, aber einiges an Patchdrätchen auf der Rückseite.



Ich habe ein 1.44MB Laufwerk probiert, geht auch nicht. Entweder ist der Floppykontroller defekt, oder hat nie funktioniert, oder ist auf ein 1.2MB-Laufwerk eingestellt. So eins habe ich nicht. Eventuell kann der Laufwerkstyp auch mit DIP-Schaltern eingestellt werden. Wo und wie weiß keiner - das BIOS ist auch ein Prototyp.
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
068
29.05.2025, 13:07 Uhr
RP



360k werden von AT und XT understüzt
Was sagt den DOS Format zur BIOS Angabe

c:/ Format a:


Rolf

Dieser Beitrag wurde am 29.05.2025 um 13:14 Uhr von RP editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
069
29.05.2025, 13:07 Uhr
MarioG77

Avatar von MarioG77

Wohl eher defekt. Das gleiche Problem habe ich doch auch noch hier liegen...
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
070
29.05.2025, 13:40 Uhr
wpwsaw
Default Group and Edit


...DOS ist Software und hat nichts in diesem Sinne mit der Hardware zu tun. Unter DOS kann/lege ich mit Schaltern /.... Formate beim Formatieren fest.

so wie Stefan schrieb rödelt er ja drauf herum. Wenn kein 1,44 vielleicht doch ein 1,2MB. Wird ja hier vom ROM beeinflusst. Ausserdem sind ja auch DIPs drauf.

Achso, Stefan, schau doch noch einmal auf die DIP Schalter vom Board, einer (nr.1) ist für das Booten zuständig (sollte AUS sein).

Auf dem FDC... was für ein 8272 ist da drauf? 4 oder 8MHz

DIP Nr. 8 auf FDC 4MHz = on und 8Mhz = off
DIP Nr. 1 unbedingt on
DIP Nr. 2-7 unbedingt off

gruß
wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
071
29.05.2025, 13:49 Uhr
RP



DOS Format liest die im BIOS eingestellten Werte für das Disketten Laufwerk und meldet formatiere im Laufwerk A: 720k bzw. 360k, usw.
Ein falsches Laufwerk wird mit fehlerhafter Diskette oder Parameter werden nicht unterstützt gemeldet.

Kaputte Hardware wird von Format mit, "nicht bereit", gemeldet

Rolf

Dieser Beitrag wurde am 29.05.2025 um 13:59 Uhr von RP editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
072
29.05.2025, 15:41 Uhr
Ordoban




Quellcode:

D91.csv: reads=48, writes=131339, blinds=1, used=65536, fehler0=0, fehler1=0
D92.csv: reads=48, writes=131274, blinds=1, used=65536, fehler0=0, fehler1=0
D93.csv: reads=48, writes=131357, blinds=1, used=65536, fehler0=0, fehler1=0
D94.csv: reads=48, writes=131241, blinds=1, used=65536, fehler0=0, fehler1=0
D95.csv: reads=48, writes=131284, blinds=1, used=65536, fehler0=0, fehler1=0
D96.csv: reads=48, writes=131358, blinds=1, used=65536, fehler0=0, fehler1=0
D97.csv: reads=48, writes=131286, blinds=1, used=65536, fehler0=0, fehler1=0
D98.csv: reads=48, writes=131252, blinds=1, used=65536, fehler0=0, fehler1=0
D99.csv: reads=48, writes=131451, blinds=1, used=65536, fehler0=8, fehler1=0
D117.csv: reads=2096, writes=133411, blinds=1, used=65536, fehler0=0, fehler1=0
D118.csv: reads=2096, writes=133456, blinds=1, used=65536, fehler0=0, fehler1=0
D119.csv: reads=2096, writes=133489, blinds=1, used=65536, fehler0=0, fehler1=0
D120.csv: reads=2096, writes=133473, blinds=1, used=65536, fehler0=0, fehler1=0
D121.csv: reads=2096, writes=133342, blinds=1, used=65536, fehler0=0, fehler1=0
D122.csv: reads=2096, writes=133496, blinds=1, used=65536, fehler0=0, fehler1=0
D123.csv: reads=2096, writes=133473, blinds=1, used=65536, fehler0=0, fehler1=0
D124.csv: reads=2096, writes=133466, blinds=1, used=65536, fehler0=0, fehler1=0
D125.csv: reads=2096, writes=133351, blinds=1, used=65536, fehler0=0, fehler1=0



Den Fehler hätte ich fast übersehen. Ich brauch langsam ne Lesebrille.


Quellcode:

D99a.csv: reads=48, writes=131312, blinds=1, used=65536, fehler0=8, fehler1=0
D99b.csv: reads=48, writes=131272, blinds=1, used=65536, fehler0=8, fehler1=0
D99c.csv: reads=48, writes=131266, blinds=1, used=65536, fehler0=8, fehler1=0



Getauscht...
Na also!



640K Speicher. Bemerkenswert ist, dass der Kursor nicht korrekt gesetzt wird.



Die Norton Utilities laufen, und zeigen das Diskettenlaufwerk als 360er an. Das ist der Default-Wert, wenn DOS den Diskettentyp nicht erkennen kann.



Der Bootsektor ist nicht lesbar.



Komischerweise aber alle anderen Sektoren. Betroffen ist der Sektor 1 Kopf 0 bei jeder Spur.



Der Beweis, dass diese Daten tatsächlich von der Diskette stammen: das ist das Hauptverzeichnis.


--
Gruß
Stefan

Dieser Beitrag wurde am 29.05.2025 um 15:50 Uhr von Ordoban editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
073
29.05.2025, 16:00 Uhr
Ordoban



Hmm zu früh gefreut. Das kommt bei "format a:"


--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
074
29.05.2025, 17:06 Uhr
RP



wo findet die DOS Format.com ein Gerät aux?

Rolf
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
075
29.05.2025, 17:42 Uhr
sylvi



Hallo,

>"bezüglich 1834M"

Beim EC1834M oder auch EC1834.01 waren 640kb auf dem Board bestückt.
Wenn das nicht so ist, ist es kein EC1834M.
Ich würde gerne mal ein gut aufgelöstes Bild von dem Board sehen, wo man
Einzelheiten erkennen kann.
lg
sylvi
--
Meine Uhr ist eingeschlafen
Ich hänge lose in der Zeit
Ein Sturm hat mich hinausgetrieben
Auf das Meer der Ewigkeit
Asyl im Paradies, Silly
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
076
29.05.2025, 18:35 Uhr
wpwsaw
Default Group and Edit


@sylvi

woher willst du das wissen?? hast du einen .01 oder M ?

solche Bilder hatte ich alle schon vor 10 Jahren im Forum

mein M hat nur 256k RAM ONBOARD...dann gibt es eben wohl einen Unterschied zwischem dem ".01" und dem "M". Meines ist definitiv ein M, weil es im BIOS ROM so bezeichnet wird.

Ich hatte damals (2016) mit cw verglichen und er bezeichnete seines als .01 und die Boards sahen unterschiedlich aus. Und nur bei meinen FDC und HDC waren Modifikationen.


https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=13351?threadid=20537

https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=20537
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP

Dieser Beitrag wurde am 29.05.2025 um 18:48 Uhr von wpwsaw editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
077
29.05.2025, 18:53 Uhr
wpwsaw
Default Group and Edit


...ich werde noch wahnsinnig, dauernd sind Zeilen hier weg.........


Bild1:

https://magentacloud.de/s/QqtYALRCWJeB6gC


Bild2:


https://magentacloud.de/s/BTrMi4jjbpt9ygE

gruß
wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
078
29.05.2025, 18:55 Uhr
Ordoban



Jetzt wirds ganz verrückt.

Der Parity-Error tritt nur auf wenn die Speichererweiterung gesteckt ist. Hast du zu diesem Board eine Speichererweiterung bekommen? Wenn ja: ist die modifiziert?

Wenn die nicht gesteckt ist, lässt sich die Diskette problemlos formatieren und beschreiben.
Die so erstellte Diskette lässt sich im A7150 lesen und beschreiben. Die mit dem A7150 geschriebenen Dateien lassen sich dann auf dem EC1834x wieder lesen und ausführen. Es ist auch möglich von dieser Diskette zu booten.
Umgekehrt lassen sich mit dem A7150 formatierte Disketten auf dem EC1834x nicht lesen. Der jeweils erste Sektor einer Spur wird nicht gefunden. Ich vermute mal dass hier irgend etwas mit dem Indexloch nicht stimmt.

Ich habe dann noch versucht mit dem Festplattenkontroller, der zu diesem Bord gehört eine Platte zu Low-Level-Formatieren. Das Programm sagt jedoch, dass keine Festplatte erkannt wurde.

Die geätzten Leiterbahnen dieses Boards entsprechen genau denen von meinem EC1834. Allerdings hat dieses Board deutlich mehr Drähtchen drauf, einen 8237 DMA statt 8257, und im BIOS steht EC1834M drin. Ich denke das hier ist ein Prototyp aus der Entwicklung des M.
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
079
29.05.2025, 19:45 Uhr
RP



wpw

sind das EC1834 Teile die du von mir bekommen hast ?

Das Board ging 1989 und 1990 bei mir ohne Probleme und wurde dann von einen 386 abgelöst.
Den PC hatte mir ein Freund, der bei Robotron arbeitete, zusammengebaut, sicher aus Überplanbeständen.
1995 wollt ich den EC verschenken, aber er hat sich nur noch mit Parity Error gemeldet, bis er dann nur noch einen Kursor anzeigte. Es ist möglich das ich da die BIOS IC versuchsweise eingebaut habe und die nicht zum Board gehören.

Rolf
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
080
29.05.2025, 19:55 Uhr
sylvi



Hallo,
"Um diese Kompatibilitätslücke bis zur Serienfertigung einer „echten Nachfolge“ (siehe weiter EC1835) zu überbrücken bzw. nicht weiter wachsen zu lassen, begann man deshalb noch 1989 in einer Zwischenetappe mit der Weiterentwicklung des EC 1834 zu einer „modernisierten“ Version, dem EC 1834.01 (andere, äquivalente Bezeichnung ist EC 1834.M). Ziel dieser Entwicklung war das Erreichen direkter XT-Kompatibilität durch Einsatz von Adapterkarten mit originalen direkten Steckverbindern sowie kompatiblen BIOS-Schnittstellen. Durch Modifizierung der Systemplatine des EC 1834 konnte man u. a. neben einem nunmehr vollständig auf einer neuen Systemplatine untergebrachten RAM von 640 KByte und neuen Adapterkarten vor allem auch Steckerkompatibilität gewährleisten (direkte Steckverbinder für allerdings auch nur standardmäßig 2 (max. 4 Steckpositionen möglich; es gab verschiedene Kombinationen Steckverbinder)). Das erreichte Kompatibilitätsniveau zum IBM-Original wurde im Rahmen des K5-Testes erfolgreich nachgewiesen." (Zitat von ESER- irgendwas)

Danke für die Bilder!

Auf dem Board von CW sind 640kb bestückt. .01 und .M ist das selbe. M war wohl für den Export nach Osten, das war beim PC1715W auch so, für den Export hieß der dann PC1715M, was ich dir auch beweisen kann. Aber nicht mehr heute. Was mir noch auffällt ist die Tatsache das dein Board keine LED für die Betriebsspannungen hat. So ein Board habe ich auch und ich hielte das eher für eine frühe Revision. Das Bios kann sonstwer da rein gesteckt haben, aber am Ende wissen wir das alle nicht. Ich bekam auch mal ein Board mit der VGA-Karte und der IO-Karte vom 1835, es bleibt dennoch ein 1834.
Das ist aber alles egal, Hauptsache dein Board läuft wieder und du hast Spass damit.
lg.
sylvi
--
Meine Uhr ist eingeschlafen
Ich hänge lose in der Zeit
Ein Sturm hat mich hinausgetrieben
Auf das Meer der Ewigkeit
Asyl im Paradies, Silly
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
081
29.05.2025, 21:12 Uhr
wpwsaw
Default Group and Edit


@Rolf

nein, die "M" Sachen habe ich 2014/2015 gekauft. Der Verkäufer hat mir gesagt, dass das alles bei ihm gelaufen ist. Leider war das die Unwahrheit :-(

von dir habe ich am 17.01.2016 EC1834-Teile gekauft.


@Sylvi

nein, die ROMs gehören da rein, weil ohne die ROMs läuft das Board nicht mit dem 8237, so wie Stefan das auch getestet hat. Auch der modifizierte FDC läuft nur mit dem 1834M BIOS. Also ist das von mir beschriebene und von Stefan getestete "M"-BIOS richtig für das Board.


gruß
wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP

Dieser Beitrag wurde am 30.05.2025 um 08:18 Uhr von wpwsaw editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
082
02.06.2025, 23:45 Uhr
wpwsaw
Default Group and Edit


Guten Abend,
ich möchte mal über meine Tests mit dem von Stefan zum Laufen gebrachtes Board berichten:

als 1. ins Gehäuse eingebaut und MON Karte drauf, Tastatur dran und eingeschaltet....
wie Stefan berichtet hat, startet und zählt den RAM hoch bis 256kB und bleibt stehen.

2. RAM 384kB gesteckt, ....zählt bis 640kB hoch....

3. 2. RAM-Karte ab 640kB gesteckt..... im Vordergrung gibt es Probleme mit dem Speicher der MON Karte, also das klappt nicht. Werde ich später noch einmal DOS als "Hintergrundspeicher" testen.

3. FDC gesteckt, zählt hoch und dann Diskettenfehler wie bei Stefan...

4. HDC gesteckt MFM Platte dran, DIP Schalter auf HDC der Festplatte angepasst, BOOTreihenfolge (Zugriff) LW A, LW B, LW C erfolgt, aber kein booten >> Meldungen auf dem Bildschirm...Diskettenfehler und dann nach Festplattenzugriff "Fehler beim Laden"

Den Fehler 1701 bei Stefan hatte ich nur wenn beim Hochfahren nur 256kB getestet wurden und wahrscheinlich die Festplatte noch nicht mit Rattern fertig war. Nach einem RESET bzw. bei 640kB RAM kam der Fehler nicht.

5. statt HDC ISA-Karte mit CF (DOS6.22) gesteckt, LW A= 3,5"1,44 LW B=5,25 800kB

der Rechner fährt hoch, will von A und B booten = Diskfehler und bootet dann von CF Karte

danach kann ich problemlos 720K Disketten vom 3,5 " LW und auch von LW B 5,25" Disketten Lesen und Programme auf ihnen Starten und ausführen.

will ich dann mit einem Programm wie Format auf die Diskettenlaufwerke zugreifen dann hält der Rechner mit Parityfehler Systemboard 00400 an und hängt. Ich habe alle gängigen RAM-Tests laufen lassen, aber alles O.K. beim Hochzählen macht er bei 112kB einen Sprung auf 144kB aber Stefan schrieb ja auch schon über eine wahrscheinlich fehlerhafte Sache beim Selbsttest des RAMs

das passiert mit und ohne 384kB RAM Karte.

eine normale FDC Karte funktioniert garnicht.


jetzt etwas komisches laut meinen Unterlagen beginnt die Zählweise des DIP-Schalters von vorne aufs Board gesehen mit 8-7-6-5-4-3-2-1

auf diesem Board ist es umgekehrt, vorne ist 1 und innen ist 8. Ich glaube, ich habe das vor Jahren auch schon einmal bei einer anderen 1834-Geschichte geschrieben

ich habe natürlich deutlich mehr hin und her gesteckt......

und meine COL-Karte konnte ich nicht zum Arbeiten überreden.


Morgen mache ich weiter, muss aber auch wieder wie heute tagsüber draußen arbeiten und komme erst gegen Abend wieder zum Testen......

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP

Dieser Beitrag wurde am 02.06.2025 um 23:45 Uhr von wpwsaw editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
083
03.06.2025, 07:42 Uhr
wpwsaw
Default Group and Edit


so, mir hat das alles keine Ruhe gelassen und ich wollte heute vor meiner Aussentätigkeit noch einmal testen und mit Erfolg,

ich hatte ja heute Nacht schon die Anordnung der DIP Schalter angesprochen und noch einmal in meinen eigenen Forenbeiträgen gesucht und alles über die DIP Schalter gefunden. Natürlich hatte ich heute Nacht die DIP Schalter umgestellt aber den "1" wohl übersehen. Er verhindert das Booten von LW A, wenn er auf ON steht. Und dann kommt noch dazu, das derBOOT ROM der ISA-CF Karte das Booten von Disketten-LW auch verhindert wenn nicht die Taste A gedrückt wird. Und natürlich auch, wenn man glaubt eine bootfähige Diskette im LW zu haben. Aber auch die Jumperei an den LW .

Alles Fehler zusammen genommen, eine elende Sucherei......

ABER jetzt bootet er auch fehlerfrei von Diskette mit 256 und 640kB.

wpw


P.S. der Paritätsfehler beim LW-Zugriff ist auch verschwunden... ;-))
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP

Dieser Beitrag wurde am 03.06.2025 um 07:44 Uhr von wpwsaw editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
084
03.06.2025, 08:18 Uhr
wpwsaw
Default Group and Edit


...hier mal eine verwirrende Art der DIP Schalterdarstellung mit "1" und "0" statt ON und OFF der Schalter




das bezieht sich wohl darauf, das wenn der DIP Schalter ON ist die P5 über den R auf "0" gezogen wird


gegenüber aus den letzten Dokus die Darstellung





hier wird ON / OFF dargestellt

es ist natürlich nur verwirrend, wenn man nicht lesen kann ;-))

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
085
03.06.2025, 14:11 Uhr
wpwsaw
Default Group and Edit


...jetzt habe ich den HDC getestet, er bootet zwar nicht, aber ich konnte von der Festplatte lesen und starten. Aber nicht immer, irgendwo ist ein Wackelkontakt am HDC wenn man die LP bewegt.

Mit einem normalen HDC bootet er auch nicht ich kann aber wieder doe Daten lesen und nutzen.

und dann, nun hatte ich die LP alles festgeschraubt, wieder gestartet und dann erst RAM Fehler und dann garnichts mehr. POST bleibt bei 4 hängen, also fehlerhafter RAM Test. Aber es scheint nichts mehr zu gehen, Analysator an den Steckkarten-BUS gehängt, so wie es aussieht sind A08, A10 und A11 defekt (erste Vermutung) könnte also ein 8282 (D25) sein. Ich werde mal Stefan fragen....




Gruß
wpw
:-(((((
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP

Dieser Beitrag wurde am 03.06.2025 um 14:12 Uhr von wpwsaw editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
086
03.06.2025, 22:19 Uhr
ambrosius



Sind die Fehler alle erst aufgetreten, als Du die Platine richtig festgeschraubt hattest? Dann könnte es sein, daß Du irgendwo einen Masseschluß auf dem Mainboard (oder besser gesagt unter dem Mainboard) beim festschrauben erzeugt hast.
--
viele Grüße
Holger
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
087
03.06.2025, 23:50 Uhr
wpwsaw
Default Group and Edit


...das Board sitzt doch auf Plasteninippel und hat nur an 2 Stellen große Masseflächen wo eine direkte Verbindung zur Gehäusemasse erfolgt.

es kann mit der mechanischen Belastung durch festschrauben der Steckkarten etwas passiert sein, es kann aber auch wieder irgend ein IC gestorben sein oder eines der vielen Drähtchen ab sein, welches ich aber noch nicht gefunden habe.

Im Moment ist mir aufgefallen, das nach dem RESET kein Zugriff auf die Eproms erfolgt und die CPU wohl einfach so vor sich hin rennt.

Das auf der PPI 4 ausgegeben wird, keine Ahnung warum ist aber nicht wirklich hilfreich....

wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
088
04.06.2025, 14:34 Uhr
MarioG77

Avatar von MarioG77

PPI 4 heißt: Parity Error
--
Gruss Mario

Betriebsbereit: KC85/3, 2x [KC85/4, D004+Floppy, D008], PPC512, PC1512, 2xEC1834, Soemtron 286, 3x PC1715, picoAC1
Zu restaurieren: 1x A5120 und hin und wieder was von oben
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
089
04.06.2025, 15:21 Uhr
wpwsaw
Default Group and Edit


In den Systemunterlagen steht RAM Test mit Fehler abgebrochen CPU im Halt...

aber leider wie ich schon geschrieben hatte, alles Murks, weil die CPU irgend welchen Mist macht und garnicht so weit kommt. Ich habe mir gerade einen Adapter gebaut um zuverlässig ddie CPU an den Analysator anschließen zu können. Habe den CO-Prozessor gezogen für den Adapter.

Jetzt versuche ich heraus zu bekommen wo er rödelt, bzw. Stefan macht das gerade...

hier mal der Adapter im Einsatz


wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
090
04.06.2025, 22:29 Uhr
wpwsaw
Default Group and Edit


Guten Abend....

was sagt euch dieses Bild?


ja, genau, er läuft wieder. Nach dem plötzlichem Tod und meiner überaktiven Suche nach dem Fehler und einigen Fehleinschätzungen hatte ich heute Morgen ein Stop eingelegt, alles aufgeräumt und dann wieder den Startknopf gedrückt. Der eigentliche Durchbruch kam durch den zuverlässigen Anschluss der CPU über meinen neuen Adapter statt der empfindlichen Klammern, konnte ich (wir) jetzt wirklich jedes Byte vom ROM bis zur CPU nachverfolgen und konnten so (Stefan) den Code auswerten und mit dem Original vergleichen. So stellte sich heraus, das die CPU dann doch im Halt stand. Und zwar im RAM-Test. Dadurch war die POST-Anzeige doch richtig. Ich habe dann Stefan die Aufzeichnung als CSV geschickt. Stefan konnte anhand der Adresse, wo die CPU in den HALT ging ermitteln um welches Bit und damit um welchen IC es sich handelt.

Hier mal AD0-7 und AD8-15 an der CPU nach einem RESET



man kann schon sehen das mit FFF0h begonnen wird


und hier


sieht man gut, wir er dann auf E05B springt.

und hier sieht man


wie die CPU dann im RAM Test auf der Adresse E18E in den HALT geht .


Den IC getauscht und ... das Ergebnis sieht man auf dem Bild. Nur, das er noch nicht von C bootet, aber das teste ich am WE in der Hoffnung nicht wieder einen Toten auf dem Tisch zu haben ;-)) Aber ich kann auf die Festplatte (Lag im Lager von einem 1834 der jetzt eine CF Karte hat) zugreifen und mit arbeiten. Er wäre jetzt komplett funktionstüchtig mit dem modifizierten FDC. Der modifizierte HDC funktionierte ja nur ab und zu. Habe jetzt einen normalen drin.

so, morgen und übermorgen muss ich mich wieder auf die Fahrschule konzentrieren, am WE geht es dann weiter.

Gruß und herzlichen Dank auch an Stefan noch einmal für die Unterstützung. Ich habe auch sehr viel dazu gelernt.
wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP

Dieser Beitrag wurde am 04.06.2025 um 22:33 Uhr von wpwsaw editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
091
05.06.2025, 16:40 Uhr
Ordoban



Von mir noch die Erklärung dazu, wie man mit dem Logikanalyzer herausfinden kann, was so ein Prozessor macht, und -in diesem Fall- welcher Speicherschaltkreis beim Selbsttest versagt hat.

Das hier ist ein 8086, wir haben die Pins AD0 bis AD15 aufgezeichnet. Beim 8086 sind hier abwechselnd die Adresse und die Daten drauf. Es wäre noch gut gewesen, die restlichen Adress-Pins A16-A19 und einige Steuersignale in der Aufzeichnung zu haben, aber der Logikanalyzer hat nur 16 Kanäle.

Hier das letzte Stück aus dem Logikanalyzer. Die erste Zahl ist die Zeit *100ns, die zweite ist der Pegel an den Pins in Hexadezimal-Schreibweise


Quellcode:

25843    F5E2
25848    ED08
25851    47FC
25856    FF04
25858    AA55
25864    ED0A
25888    AAFF
25890    8B47
25901    D08F
25909    ECFD
25912    ADFD
25917    ECFE
25920    C233
25925    ED00
25929    FF02
25933    55AA
25937    ED00
25941    5775
25945    ED02
25949    55B8
25954    ED04
25957    ABAA
25962    ED06
25965    F5E2
25970    ED08
25973    47FC
25978    FF02
25980    AA55
25986    ED0A
25990    8B47
26002    ED0C
26006    FD8F
26007    D08F
26015    ECFD
26031    8BFD
26032    ADFD
26039    ECFE
26042    FF37
26043    C233
26047    ED00
26051    FF00
26055    55AA
26059    ED00
26063    5775
26068    ED02
26071    55B8
26076    ED04
26079    ABAA
26084    ED06
26087    F5E2
26092    ED08
26095    47FC
26100    FF00
26102    AA55
26108    ED0A
26112    8B47
26125    ED0C
26129    D08F
26137    ECFD
26140    ADFD
26145    ECFE
26148    C233
26153    ED00
26157    FEFE
26177    C2FF
26180    558A
26186    ED00
26189    5775
26194    ED02
26197    55B8
26202    ED04
26205    ABAA
26214    D02F
26222    ED59
26226    3C59
26230    ED5A
26234    7500
26238    6D58
26239    ED5C
26242    8AFA
26247    ED5E
26250    EBC4
26255    ED60
26259    D5DF
26267    ED57
26270    FC57
26275    ED58
26279    3CC3
26283    ED5A
26287    7500
26291    ED5C
26295    E85C
26296    E018
26299    E185
26304    ED5C
26310    E185
26329    E585
26330    7485
26336    E186
26340    B009
26344    E188
26348    E604
26352    E18E
26353    E18A
26356    F460
26361    E18C
26364    C02B
26369    E18E
26373    0060
26375    0004
26383    E18E
26386    ABF3
26393    E18E (bleibt bis zum Ausschalten auf diesem Pegel)



Beginnen wir von hinten, da wo der Prozessor stehen bleibt.

Wir wissen, dass hier abwechselnd Adresse und Daten kommen. Aber was ist was?

Da gibt es eine Zahl die sich immer um 2 erhöht. Das ist die Adresse!

Quellcode:

26310    E185 <--
26329    E585
26330    7485
26336    E186 <--
26340    B009
26344    E188 <--
26348    E604
26352    E18E
26353    E18A <--
26356    F460
26361    E18C <--
26364    C02B
26369    E18E <--
26373    0060
26375    0004
26383    E18E <--
26386    ABF3


Es ist auffällig, dass die Adressen nicht exakt alle 2 Samples kommen, sondern manchmal auch mehrere Samples dazwischen liegen. Das können I/O-Operationen, Speicheroperationen oder Glitches sein. Glitches sind Messfehler, die sind meist relativ kurz.

Die Adressen liegen innerhalb des Bios-ROMs. Dann vergleichen wir mal die Daten mit dem ROM-Image. (Das Image beginnt im Speicher ab C000, man muss also erst die Position umrechnen)


Quellcode:

00002180  18 e0 e9 4a 0b 74 09 b0  04 e6 60 f4 2b c0 f3 ab  |...J.t....`.+...|
00002190  89 1e 72 04 83 fd 10 74  02 2b ed 89 2e 96 04 2b  |..r....t.+.....+|




Quellcode:

26310    E185 <-- Adresse (ungerade)
26329    E585 <-- Glitch
26330    7485 <-- ROM-Daten (8-Bit Zugriff, da ungerade Adresse. Es sind nur die höheren 8 Bit gültig, korrekt)
26336    E186 <-- Adresse
26340    B009 <-- ROM-Daten (korrekt)
26344    E188 <-- Adresse
26348    E604 <-- ROM-Daten (korrekt)
26352    E18E <-- Glitch
26353    E18A <-- Adresse
26356    F460 <-- ROM-Daten (korrekt)
26361    E18C <-- Adresse
26364    C02B <-- ROM-Daten (korrekt)
26369    E18E <-- Adresse
26373    0060 <-- ????
26375    0004 <-- ????
26383    E18E <-- Adresse
26386    ABF3 <-- ROM-Daten (korrekt)



Bis auf Sample 26373 und 26375 ist soweit klar, was das ist. Schaun wir uns das disassemblierte Programm an


Quellcode:

seg000:E17F                 mov     sp, offset off_FE018
seg000:E182                 jmp     Memtest
seg000:E185 ; ---------------------------------------------------------------------------
seg000:E185
seg000:E185 loc_FE185:                              ; DATA XREF: seg000:off_FE018?o
seg000:E185                 jz      short loc_FE190
seg000:E187                 mov     al, 4
seg000:E189                 out     60h, al         ; 8042 keyboard controller data register.
seg000:E18B                 hlt
seg000:E18C ; ---------------------------------------------------------------------------
seg000:E18C
seg000:E18C loc_FE18C:                              ; CODE XREF: seg000:E17D?j
seg000:E18C                 sub     ax, ax
seg000:E18E                 rep stosw



Damit wird klar, was Sample 26373 und 26375 sind: die Ausführung des OUT 60h,AL.
Es fällt außerdem auf, dass das nicht in die Reihenfolge der ROM-Lese-Operationen passt. Gesehen am ROM-Lesen müsste das Programm schon etwas weiter sein.
Hier sieht man eine der Neuerungen des 8086 in Aktion. Der 8086 hat einen kleinen Instruktion-Cache. Der liest schon auf Verdacht Befehle aus dem Speicher, damit diese sofort ausgeführt werden können wenn sie dran sind. Das bringt den 8086 gegenüber seinen Vorgängern ganz schön auf Trab, aber erschwert uns hier die Fehlersuche.
In dem Sample 26369 legt die CPU die nächste ROM-Adresse auf den Bus, wartet dann jedoch nicht auf die Daten, sondern unterbricht die Übertragung für die I/O-Operation. So etwas werden wir noch öfter sehen.

Ausgeführt wurde also das OUT und anschließend das HLT.
Davor kommt der Speichertest der ersten 64K, und das Programm endet in diesem Code-Pfad, wenn das Ergebnis nicht gut ist.
Wir können mit der Logikanalyzer-Aufzeichnung rückwärts bis in den Speichertest hinein folgen.


Quellcode:

25843    F5E2
25848    ED08 <-- ROM-Adr
25851    47FC <-- ROM-Daten (korrekt)
25856    FF04 <---- RAM-Adr
25858    AA55 <---- RAM-Daten schreiben
25864    ED0A <-- ROM-Adr
25888    AAFF <-- Glitch
25890    8B47 <-- ROM-Daten (korrekt)
25901    D08F <-- Glitch
25909    ECFD <-- ROM-Adr (ungerade)
25912    ADFD <-- ROM-Daten (8 bit, korrekt)
25917    ECFE <-- ROM-Adr
25920    C233 <-- ROM-Daten (korrekt)
25925    ED00 <-- ROM-Adr
25929    FF02 <---- RAM-Adr
25933    55AA <---- RAM-Daten lesen
25937    ED00 <-- ROM-Adr
25941    5775 <-- ROM-Daten (korrekt)
25945    ED02 <-- ROM-Adr
25949    55B8 <-- ROM-Daten (korrekt)
25954    ED04 <-- ROM-Adr
25957    ABAA <-- ROM-Daten (korrekt)
25962    ED06 <-- ROM-Adr
25965    F5E2 <-- ROM-Daten (korrekt)
25970    ED08 <-- ROM-Adr
25973    47FC <-- ROM-Daten (korrekt)
25978    FF02 <---- RAM-Adr
25980    AA55 <---- RAM-Daten schreiben
25986    ED0A <-- ROM-Adr
25990    8B47 <-- ROM-Daten (korrekt)
26002    ED0C <-- ROM-Adr
26006    FD8F <-- Glitch
26007    D08F <-- ROM-Daten (korrekt)
26015    ECFD <-- ROM-Adr (ungerade)
26031    8BFD <-- Glitch
26032    ADFD <-- ROM-Daten (8 bit, korrekt)
26039    ECFE <-- ROM-Adr
26042    FF37 <-- Glitch
26043    C233 <-- ROM-Daten (korrekt)
26047    ED00 <-- ROM-Adr
26051    FF00 <---- RAM-Adr
26055    55AA <---- RAM-Daten lesen
26059    ED00 <-- ROM-Adr
26063    5775 <-- ROM-Daten (korrekt)
26068    ED02 <-- ROM-Adr
26071    55B8 <-- ROM-Daten (korrekt)
26076    ED04 <-- ROM-Adr
26079    ABAA <-- ROM-Daten (korrekt)
26084    ED06 <-- ROM-Adr
26087    F5E2 <-- ROM-Daten (korrekt)
26092    ED08 <-- ROM-Adr
26095    47FC <-- ROM-Daten (korrekt)
26100    FF00 <---- RAM-Adr
26102    AA55 <---- RAM-Daten schreiben
26108    ED0A <-- ROM-Adr
26112    8B47 <-- ROM-Daten (korrekt)
26125    ED0C <-- ROM-Adr
26129    D08F <-- ROM-Daten (korrekt)
26137    ECFD <-- ROM-Adr (ungerade)
26140    ADFD <-- ROM-Daten (8 bit, korrekt)
26145    ECFE <-- ROM-Adr
26148    C233 <-- ROM-Daten (korrekt)
26153    ED00 <-- ROM-Adr
26157    FEFE <---- RAM-Adr
26177    C2FF <-- Glitch
26180    558A <---- RAM-Daten lesen
26186    ED00 <-- ROM-Adr
26189    5775 <-- ROM-Daten (korrekt)
26194    ED02 <-- ROM-Adr
26197    55B8 <-- ROM-Daten (korrekt)
26202    ED04 <-- ROM-Adr
26205    ABAA <-- ROM-Daten (korrekt)
26214    D02F <-- Glitch, die CPU führt hier gerade den Sprung aus
26222    ED59 <-- ROM-Adr (ungerade)
26226    3C59 <-- ROM-Daten (8 bit, korrekt)
26230    ED5A <-- ROM-Adr
26234    7500 <-- ROM-Daten (korrekt)
26238    6D58 <-- Glitch
26239    ED5C <-- ROM-Adr
26242    8AFA <-- ROM-Daten (korrekt)
26247    ED5E <-- ROM-Adr
26250    EBC4 <-- ROM-Daten (korrekt)
26255    ED60 <-- ROM-Adr
26259    D5DF <-- ROM-Daten (korrekt)
26267    ED57 <-- ROM-Adr (ungerade)
26270    FC57 <-- ROM-Daten (8 bit, korrekt)
26275    ED58 <-- ROM-Adr
26279    3CC3 <-- ROM-Daten (korrekt)
26283    ED5A <-- ROM-Adr
26287    7500 <-- ROM-Daten (korrekt)
26291    ED5C <-- ROM-Adr
26295    E85C <-- ROM-Daten (korrekt)
26296    E018 <-- ROM-Adr
26299    E185 <-- ROM-Daten (korrekt)
26304    ED5C <-- ROM-Adr
26310    E185 <-- ROM-Adr (ungerade)
26329    E585 <-- Glitch
26330    7485 <-- ROM-Daten (8 bit, korrekt)
26336    E186 <-- ROM-Adr
26340    B009 <-- ROM-Daten (korrekt)
26344    E188 <-- ROM-Adr
26348    E604 <-- ROM-Daten (korrekt)
26352    E18E <-- Glitch
26353    E18A <-- ROM-Adr
26356    F460 <-- ROM-Daten (korrekt)
26361    E18C <-- ROM-Adr
26364    C02B <-- ROM-Daten (korrekt)
26369    E18E <-- ROM-Adr
26373    0060 <-- IO-Addr
26375    0004 <-- IO-Daten
26383    E18E <-- ROM-Adr
26386    ABF3 <-- ROM-Daten (korrekt)



Das Ramtest-Programm (zumindest der relevante Teil)


Quellcode:

...
seg000:ECE4                 mov     ax, 55AAh
seg000:ECE7                 mov     dx, ax
seg000:ECE9                 rep stosw
...
seg000:ECFD loc_FECFD:      lodsw
seg000:ECFE                 xor     ax, dx
seg000:ED00                 jnz     short loc_FED59
seg000:ED02                 mov     ax, 0AA55h
seg000:ED05                 stosw
seg000:ED06                 loop    loc_FECFD
...
seg000:ED59 loc_FED59:      cmp     al, 0
seg000:ED5B                 jnz     short loc_FED57
seg000:ED5D                 mov     al, ah
seg000:ED5F                 jmp     short loc_FED57
...
seg000:ED57 loc_FED57:      cld
seg000:ED58                 retn
...



Als erstes wird 55AA in alle zu testenden Speicherzellen geschrieben. Dann wird in einer Schleife jede Speicherzellen wieder ausgelesen, mit 55AA verglichen und dann mit AA55 überschrieben. Die AA55 werden im nächsten Testschritt geprüft, aber soweit kommen wir garnicht.
In der Logikanalyzer-Aufzeichnung kann man das für die letzten 3 Schleifendurchläufe sehen. Da der Test bei Fehler abbricht, sieht man auch was und wo falsch gelesen worden ist.

Der Durchlauf war OK

Quellcode:

26051    FF00 <---- RAM-Adr
26055    55AA <---- RAM-Daten lesen



Und nach dem hier wird die Schleife beendet

Quellcode:

26157    FEFE <---- RAM-Adr
26180    558A <---- RAM-Daten lesen



Da fehlt ein Bit! 558A sollte 55AA sein. Das ist Bit 5 im unteren Speicherblock, also IC D105.
--
Gruß
Stefan
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
092
05.06.2025, 17:24 Uhr
HeikoS



Sehr schön, dass du das noch einmal ausführlich erklärt hast ! Das ist sehr interessant. Danke !

"Den IC getauscht und ... das Ergebnis sieht man auf dem Bild." ... ist damit auch plausibel. Tolle Teamarbeit.

Viele Grüße, Heiko
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
093
05.06.2025, 18:47 Uhr
schlaub_01



Ja, aber man sieht auch leicht, daß das Hauptproblem die Analyse der Aufzeichnungen ist. Hatte da auch schon mal an einem PC1715 mit einem Z80 alles mitgeschnitten und händisch ausgewertet. Leider musste ich mir da einen anderen Logicanalyzer borgen, denn mit meinen 16 Kanälen reicht das oft nicht aus. Durch die ganzen Refresh und Interrupt-Sachen beim Z80 muss man schon genau sehen, ob gelesen/geschrieben wird oder ein Interrupt kam. Durch die zusammenhängenden Daten und Adressen beim 8086 macht es das auch nicht leichter. Vielleicht wäre es in der Hinsicht fast besser, mal einen eigenen Analyser zu machen, der die Sachen gleich in einem FPGA vor Ort dekodiert und man nur noch die Aktionen aufzeichnen kann, komplett mit Adressen, Daten und Steuersignalen. Aber ist am Ende doch wieder viel Arbeit. Ich gehe ja immer gerne den anderen Weg und bilde mit extra Hardware die CPU nach. Beim Z80 geht das noch sehr einfach über das Busrequest, da kann man sich dann auf die CPU draufschalten. Beim 8086 müsste man das sich mal überlegen, wie das machbar ist. Im Zweifelsfall habe ich auch mal einen Adapter gebaut, der statt der CPU auf den Sockel gesteckt wird, falls da ein Sockel verbaut ist. Gerade RAM Tests lassen sich so sehr einfach und viel genauer durchführen. Adressprobleme findet man dann sehr schnell, wenn man mit geeigneten Pattern die Tests durchführt.
Aber ansonsten ist das hier mal ein sehr schöner informativer technischer Beitrag und kein unsinniger Youtube-Link Post. Danke an Stefan für die tolle Aufbereitung, so gefällt mir das!

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
094
05.06.2025, 19:34 Uhr
wpwsaw
Default Group and Edit


...ja, finde ich auch und es hat ja auch geholfen und bringt mich dazu noch ein oder 2 Boarde zu reparieren. Baustelle ist schon eingerichtet, aber heute war Fahrschultag.

Mal sehen ob ich Stefan nicht zu sehr belästigen muss ;-)

Gruß
wpw
--
RECORD, CRN1; CRN2; PicoDat; LC80; Poly880; KC85/2,3,4,5 ; KC87; Z1013; BIC; PC1715; K8915; K8924; A7100; A7150; EC1834; und P8000 ab jetzt ohne Tatra813-8x8 aber mit W50LA/Z/A; P3; ES175/2 und Multicar M25 3SK; Barkas B1000 HP
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
095
05.06.2025, 20:06 Uhr
Bert




Zitat:
schlaub_01 schrieb
...mit einem Z80 alles mitgeschnitten und händisch ausgewertet.


Wenn man einen LA hat, der von Sigrok (open source) unterstützt wird, kann man auch den tollen Z80-Protokoll-Dekoder verwenden, der die Refresh-/ Opcode- und Datenzugriffe richtig zerlegt:
https://sigrok.org/wiki/Protocol_decoder:Z80

Es reichen auch 11 LA-Kanäle:

Quellcode:

The data bus lines plus the control signals /M1, /RD and /WR are sufficient to display full disassembly.


--
Viele Grüße,
Bert

Dieser Beitrag wurde am 05.06.2025 um 20:06 Uhr von Bert editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
096
05.06.2025, 20:12 Uhr
schlaub_01



Ja, die Sigrok Tools kenne ich gut, aber mit meinem Saleae hakt es da immer mal und die Werte passen nicht richtig zusammen oder die Software stürzt ab. Aber ich hätte halt lieber Adressen und Daten mal komplett und da reichen meine 16 Kanäle eben nicht mehr aus. Leider hat unser Tektronix Analyzer mit 64 Kanälen auf Arbeit den Geist aufgegeben und keiner kann oder will das mehr reparieren. War für solche Sachen ideal, weil man auch schön auf mehrere Sachen folgend triggern kann und vernünftige Busansichten hatte.

Viele Grüße,
Sven.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
Seiten: -1-     [ Technische Diskussionen ]  



Robotrontechnik-Forum

powered by ThWboard 3 Beta 2.84-php5
© by Paul Baecher & Felix Gonschorek