Robotrontechnik-Forum

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

Robotrontechnik-Forum » Technische Diskussionen » KC87 stürzt bei Speicherzugriff ab » Themenansicht

Autor Thread - Seiten: -1-
000
08.02.2010, 00:14 Uhr
robbi
Default Group and Edit
Avatar von robbi

Ausgerechnet DER Rechner, an dem ich die KRT-Grafik ausprobiere und den ich dementsprechend präpariert habe, stürzt bei Speicherzugriffen ab und bootet neu.
Erst habe ich das auf volkerp geschoben und seinen Treiber verdächtigt. Nun tritt es aber auch woanders auf:
- Beim Starten des 80-Zeichentreibers für die KRT-Grafik wird neu gebootet
- Speicherdump unter ZM stürzt irgendwann mit Neustart ab
- Ebenso Nach dem Einschalten des Hintergrund-RAMs ab 4000H beim CP/M-Start

Ich habe schon viel gemessen (an Daten und Adreßleitungen, /RD und /WR und /MREQ und /INT und an der Betriebsspannung), weiß aber nicht weiter. Wo kann ich sinnvollerweise noch messen. Habe leider keinen Logikanalysator und keinen Speicheroszi...
Manchmal ist ein Tip sehr wertvoll.
--
Schreib wie du quatschst, dann schreibst du schlecht.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
001
08.02.2010, 09:38 Uhr
paulotto



Hallo Uli,

hast Du einen 2.Rechner zur Verfügung und wenn ja, was passiert da?

Gruß,

Klaus
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
002
08.02.2010, 10:11 Uhr
volkerp
Default Group and Edit
Avatar von volkerp

Du kannst Deinen Wellon VP-280 auch als Logikanalysator nutzen (8 Kanäle, max 100kHz Samplefrequenz, Trigger Pin P21..P28)
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
003
08.02.2010, 10:20 Uhr
volkerp
Default Group and Edit
Avatar von volkerp

tritt der Fehler immer auf oder nur, wenn die KRT-Grafik gesteckt ist?
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
004
08.02.2010, 10:35 Uhr
robbi
Default Group and Edit
Avatar von robbi

Bei einem anderen Rechner geht das natürlich (Dump und Booten), aber da habe ich keine Änderungen auf der Platine.
Das komische ist, daß der 40-Zeichentreiber problemlos arbeitet! Am Code ist nichts Auffälliges, außer, daß er etwas länger ist.

Nachtrag:
paulotto hat mich an der Beantwortung seiner Frage telefonisch gehindert...

Es tritt immer auf. Leider. Ich will ja auch die 80-Zeichenhardware unter CP/M erproben, komme aber nicht zum CP/M.
Der ROM wird abgeschaltet, der RAM freigegeben, Zugriff aufs Floppy, @cpmz9 wird in den Speicher geladen, der Hintergrund-RAM wird eingeschaltet und dann zuckt der Bildschirm und es wird neu gestartet.
Da könnte ich mal gucken, ob im Hintergrund-RAM was steht, oder ob er schon vorher abstürzt.
--
Schreib wie du quatschst, dann schreibst du schlecht.

Dieser Beitrag wurde am 08.02.2010 um 10:41 Uhr von robbi editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
005
08.02.2010, 11:25 Uhr
volkerp
Default Group and Edit
Avatar von volkerp


Zitat:
@cpmz9 wird in den Speicher geladen, der Hintergrund-RAM wird eingeschaltet und dann zuckt der Bildschirm und es wird neu gestartet.

Genau das gleiche Fehlerbild hatte ich mit meinem Megamodul. Nach dem Neuprogrammieren der EPROMs funktioniert momentan alles problemlos. Vermutlich war vorher an den EPROM-Fassungen oder am Steckverbinder ein Wackler dabei. Vielleicht ist es an Deinem Rechner auch so was triviales?

Und noch eine grundlegende Frage: die Module hast Du auch alle von vorn nach hinten gesteckt, damit die IEI-IEO-Kette funktioniert?
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
006
10.02.2010, 22:11 Uhr
Buebchen



Hallo Robbi!
Wenn Du einen Oszi hast, sieh Dir mal die Versorgungsspannung beim Booten an eventuell sind stärkere Spikes drauf. Scheinbar hat der KC damit ein Problem. Ich kämpfe damit jedenfalls gerade. Ich will den KC mal an ein Analognetzteil hängen um zu sehen was bei mir dann passiert. Eventuell muss besser abgeblockt werden.
Alles Gute!
Buebchen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
007
11.02.2010, 01:01 Uhr
robbi
Default Group and Edit
Avatar von robbi

Das hatte ich bereits untersucht:

Zitat:
Ich habe schon viel gemessen (an Daten und Adreßleitungen, /RD und /WR und /MREQ und /INT und an der Betriebsspannung)...

Die Spannungen waren absolut sauber.
Die Stromversorgung für die Laufwerke hole ich auch nicht aus dem KC.

Keiner der verwendeten Module erzeugt/nutzt einen Interrupt, weswegen die Reihenfolge nicht relevant ist.
--
Schreib wie du quatschst, dann schreibst du schlecht.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
008
11.02.2010, 06:48 Uhr
Buebchen



Hallo Robbi!
Bei mir treten Probleme beim hochfahren besonders stark auf wenn der Inverter für die Programierspannungserzeugung nicht in Betrieb ist. Deshalb vermute ich riple oder kurze Spikes auf der Betriebsspannung durch die Ladestromspitzen der Elkos. Mein Oszi macht allerdings bloß 20 MHz, da kann ich keine Spikes sehen. Ich werde mir mit schnellen Flip-Flops einen Indikator aufbauen vieleicht kann ich dann etwas feststellen.
Alles Gute!
Buebchen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
009
11.02.2010, 08:39 Uhr
Germaniumröhre



Hallo zusammen,

wenn das nur bei einem Kombjuder auftritt , würde ich mir mal das Schaltnetzteil etwas genauer ansehen . Trotz der guten Qualität der Elkos fallen doch hin und wieder welche aus. Bei einem Z9001 hatte ich sogar schon mal einen totalen Kurzschluß in einem Siebelko. Das hier klingt aber eher nach taub oder hohen ESR .
Einfach mal Stück für Stück Alle mit einem Intakten Elko überbrücken.

Viele Grüße
Bernd
--
Kombjuder sorgen für Arbeit, die man ohne Diesem sicherlich nicht hätte.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
010
11.02.2010, 13:34 Uhr
robbi
Default Group and Edit
Avatar von robbi

Das Netzteil ist absolut OK, denn ich verwende an dem Demomuster ein Netzteil aus Trafo, Gleichrichtung und analogen Regelstrecken für alle Spannungen.
Die Elkos auf der Rechnerplatime sind allesamt neueren Datums und die 100nF-Abblockkondensatoren sind auch neu, vom Typ X7R.
--
Schreib wie du quatschst, dann schreibst du schlecht.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
011
11.02.2010, 14:53 Uhr
Buebchen



Hallo Robbi!
Ich glaube mich erinnern zu können das die DS8283 und wohl auch die DS8282 unter bestimmten umständen Spikes verursachen sollen. Das spielte bei verschiedenen Anwendungen keine Rolle. Wir haben jetzt aber Teilweise recht schnelle Chips in den Erweiterungen. Wenn Du noch DS8286 hast die Du mal probeweise statt der 8282 als Bustreiber einsetzt, allerdings muss dann das Richtungsbein an High. Es gab in der RFE vor einigen Jahren einen kurzen Artikel zu diesem Fehler.
Buebchen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
012
11.02.2010, 18:49 Uhr
Andreas



Ja Buebchen,da hast Du im Prinzip Recht. In der RFE stand ein Artikel dazu.Ich weiß allerdings nicht mehr ob es der DS8282 oder DS8286 war. Als Lösung bot man auf alle Fälle den Einsatz der negierenden Variante , also DS8283 bzw DS8287 an. Natürlich hatte das Konsequenzen, aber für reine RAM-Karten war es ja egal ob die Daten negiert gespeichert werden und beim Rücklesen dann wieder stimmen.

Andreas
--
Viele Grüße
Andreas
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
013
11.02.2010, 19:17 Uhr
Buebchen



Hallo Andreas!
Es waren sicher die 8283! An einer anderen Stelle habe ich dann gefunden das auch der 8282 den selben Dreckeffekt bringt. Es soll das Register sein. Eventuell reicht es ja schon wenn das Register-Pin hart auf Masse gelegt wird? Diese Spikes sollen auch bei den Erstherstellern aufgetreten sein. In den 8286 sind ja keine Register drin deshalb wurden sie meiner Erinnerung nach als Austausch empfohlen wen das Register nicht benötigt wird.
Eine verbesserung der Abblockung hat die Effekte bei mir vermindert aber noch nicht völlig beseitigt. Mindestens auf den Adressen A0 und A1 müssen noch Spikes herumgeistern der Fehlererscheinung nach zu urteilen. Denn es scheinen auch auf dem Megarom-Modul RAM bits zu kippen. Da es bei mir ein sehr schneller Chash-Ram ist halte ich das erstmal für warscheinlich.
Alles Gute!
Buebchen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
014
12.02.2010, 10:35 Uhr
Buebchen



Hallo Robbi!
Hast Du in Deiner konfiguration auch das Megarom-Modul mit drin?
Germaniumröhre hat meine beobachtungen bestätigt das es bei einsatz des Megarommoduls mit einer weiteren Hardware zu Fehlern oder sogar abstürzen kommt.
Buebchen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
015
12.02.2010, 11:58 Uhr
robbi
Default Group and Edit
Avatar von robbi

Einen MEGA-Modul besitze und nutze ich nicht. Meine ROM-Bank aus dem Jahre 1988 arbeitet seit eh und je ohne Probleme.

Ich werde nochmal die RESET-Logik und die Betriebsspannung genauer ansehen. Es betrifft ja nur diesen einen Rechner und einen weiteren möchte ich für die Tests nicht zerpflücken.
--
Schreib wie du quatschst, dann schreibst du schlecht.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
016
12.02.2010, 17:37 Uhr
Buebchen



Hallo Robbi!
Mein Problem hat sich mit dem generellen Einsatz von HCT-Logik auf den Megarom
Karten erledigt. Funktioniert jetzt.
Alles Gute!
Buebchen
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
017
12.02.2010, 19:29 Uhr
felge1966
Default Group and Edit


Das klärt auch, weshalb ich da noch keine Probleme hatte - bei mir sind alles nagelneue 74HCT drin.
--
http://felgentreu.spdns.org/bilder/jacob120.gif
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
018
12.02.2010, 21:09 Uhr
robbi
Default Group and Edit
Avatar von robbi

Es ist sehr schön, daß der MEGA-Modul nun geht...

Das war aber gar nicht mein Anliegen. Aufgrund der sehr verschiedenen Ratschläge habe ich auch einen kleinen Erfolg. 2 (zwei!) Wickelbrücken im KC87 waren angebrochen und hingen noch an der Plastisolierung um den Wickelstift. Ich habe nämlich an den 8282 zusätzliche Stützkondensatoren angebracht, und da sind mir durch komische Effekte die defekten Wickelbrücken aufgefallen.
Damit sind das eigenartige Neustarten mit dem 80-Zeichen-Treiber für die KRT-Grafik und das Neustarten beim Speicherdump behoben.

Nach wie vor läßt sich CP/M auf diesem Rechner nicht starten. Zur Verfügung habe ich drei 64k-Speichermodule, zwei verschiedene Floppymodule und zwei ROM-Bänke, die allesamt an anderen Rechnern laufen.

Nach der Eingabe von BOOT wird der ROM ab- und der RAM eingeschaltet. Es erfolgt ein Zugriff auf die Diskette. Danach geht die LED für den Hintergrund-RAM an. Es erfolgt ein Spurvorschub auf der Diskette, der Bildschirm zuckt auf, der Hintergrund-RAM wird abgeschaltet und neu gestartet.

Im Hintergrund-RAM steht das ganze CP/M-Gerassel, ebenso ab der Adresse CC00H. Eigenartigerweise werden auf den Adressen C000H, C400H und C800H je ein anderes Byte abgelegt. Ein Vergleich der Speicherinhalte im Hintergrund-RAM und ab CC00H zeigt, daß auf der Adresse CC00H statt C3 ein 0E steht!!!

Die Umschalterei der verschiedenen Modi am 64k-Modul funktioniert mit dem ZM ohne Tadel. Lädt man den ZM in den Bereich ab C000H und schaltet dann den ROM weg und den RAM ein, läuft der ZM aus dem RAM ebenfalls korrekt.
Ich bin am Verzweifeln.

Nachtrag:
Die KRT-Grafik ist NICHT gesteckt.
--
Schreib wie du quatschst, dann schreibst du schlecht.

Dieser Beitrag wurde am 12.02.2010 um 21:28 Uhr von robbi editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
019
13.02.2010, 00:59 Uhr
robbi
Default Group and Edit
Avatar von robbi

Die Daten im Hintergrund-RAM (richtig) unterscheiden sich von den in den Bereich CC00H aufwärts kopierten Daten immer im ersten Byte auf der ersten 100H-Adresse.

Quellcode:
4000H = C3     CC00H = 07
4400H = 21     D000H = 39
4800H = 00     D400H = 53
4C00H = E2     D800H = C3

Der Rest der Daten ist gleich.
Wohin beim Start in den oberen Bereich gesprungen wird, weiß ich nicht. Jedenfalls führt der falsche Code zum Kaltstart des Systems.
Und nun???
Ist das ein falsches oder zu spät kommendes Adreßbit auf AB9?
Warum passiert das nicht beim Schreiben mit dem ZM auf diese Adressen?
--
Schreib wie du quatschst, dann schreibst du schlecht.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
020
13.02.2010, 09:58 Uhr
volkerp
Default Group and Edit
Avatar von volkerp

Bei CP/M wird der Code mit LDIR nach CC00 transportiert. Das setzt wg. der kürzeren Zugriffszeit höhere Anforderungen an den Speicher als normale Schreibzugriffe (Stichwort M1). Das könnte die Unterschiede zw. CP/M und ZM erklären. Warum aber nur die angegebenen Bytes betroffen sind, kann ich auch nicht sagen.
--
VolkerP

http://hc-ddr.hucki.net
(Z9001, Z1013, LC-80, ...)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
021
13.02.2010, 13:24 Uhr
robbi
Default Group and Edit
Avatar von robbi

Daß die Daten mit LDIR umgeladen werden, nehme ich mal an. Beim Befehl "MC000 E7FF C000" mit dem zum Beispiel der ZM sich selbst in den W/O-RAM schreibt, funktioniert ohne Probleme. Anschließend kann man mit "OUT 07" den ZM im ROM ab- und den RAM an selber Stelle einschalten und arbeitet mit dem ZM im RAM.
Ebenso funktionieren Transportbefehle beim Umladen von Speicherbereichen ohne Fehler.
Ich suche ja mit großer Akribie nach dem Fehler. Wenn man aber im eigenen Saft schmort, sind Hinweise jeglicher Art nützlich, doch mal dies oder das zu probieren.
"Wir werden dem Schwein schon schlachten, wenn ihm auch quiekt!"
--
Schreib wie du quatschst, dann schreibst du schlecht.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
022
13.02.2010, 18:32 Uhr
robbi
Default Group and Edit
Avatar von robbi

Der Code ab Adresse 4000H im Hintergrund-RAM steht bei mir ab CC00H.
Ist das richtig, oder muß der woanders stehen?
Habe im Moment kein Listing des Codes.

Es ist nämlich komisch, daß ab C000H 100H Bytes des vorher aktiven ROM-Bereichs im RAM stehen. Die müssen eigentlich FFH sein.
--
Schreib wie du quatschst, dann schreibst du schlecht.
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