Robotrontechnik-Forum

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

Robotrontechnik-Forum » Technische Diskussionen » D004 Reparatur » Themenansicht

Autor Thread - Seiten: -1-
000
07.04.2008, 18:12 Uhr
Ralph



Da ja mein D004 auf dem letzten KC-Treffen die Arbeit verweigert habe, such ich hier nun Unterstützung bei der Fehlersuche. Dazu suche ich..
1. Ein Software-Diagnosetool vom KC aus (nicht J FC FF)
2. Den Stromlaufplan für das D004
3. Tipps auf was ich achten muss, bzw. welchen Fallen es gibt.

Mein Problem ist, dass seit dem Umbau auf den aktuellen EPROM eine Fehlermeldung kommt, die besagt, dass das Koppelram SteuerProgramm defekt ist.

Danke an alle die mir helfen können.. und es auch tun :-)




Gruß Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
001
07.04.2008, 18:59 Uhr
Enrico
Default Group and Edit


Hallo Ralph,

zu 1. ist mir nix bekannt.
zu 2. ist unterwegs.
zu 3. am warscheinlichsten ist wohl eine rausgerissene Durchkontaktierung beim EPROM.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
002
07.04.2008, 19:24 Uhr
Volker

Avatar von Volker

zu 1. Clubpage - DL - 46 - pruefmod.pma ?
2. erl.
zu 3. Service-Handbuch - auch auf dem Club

viel Erfolg
mfg
Volker
--
Das Gerät selbst ist ein kompli-
ziertes elektronisches Erzeugnis, zu des-
sen Reparatur neben vielfältigen Kenntnis-
sen zum gesamten Komplex der Elek-
tronik eine Vielzahl hochwertiger Meß-
und Prüftechnik notwendig ist. Von ei-
genhändigen Eingriffen wird abgeraten.

Dieser Beitrag wurde am 07.04.2008 um 19:26 Uhr von Volker editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
003
07.04.2008, 21:30 Uhr
Ralph



So hier die erste Oszi Diagnose... CPU vom D004 läuft los und bleibt dann stehen, merkwürdigerweise ist auf allen DB Leitungen L-Pegel und sämtliche weiteren CPU Steuersignale liegen auf H-Pegel.
Allerdings haben nach dem Reset am Basisgerät alle D004 CPU Signale kurzeitig saubere Pegelwechsel... Wackeln und Druck auf die Platine ändern nichts...

Das Netzteil ist OK, hat saubere Pegel und Spannungen. Ich werde mal das GIDE rausnehmen und sehen was passiert..
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
004
07.04.2008, 21:59 Uhr
Ralph



@Enrico... Heureka er bootet wieder von Diskette... :-) !! ... aber das GIDE ist das Problem ! Immer wenn das GIDE drauf ist, geht es nicht. D004 CPU direkt im Sockel, da ist alles ok.
Zum Glück hab ich noch einen GIDE Bausatz daliegen. Den wer ich jetzt mal aufbauen und sehen obs damit dann geht...

Den EPROM hatte ich übrigens draufgelötet und die F8/FC Lösung gebastelt, die auch schon auf dem KC Treffen funzte.. :-)

Gruß Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
005
08.04.2008, 00:00 Uhr
Ralph



Juchhu ich kann Vollzug melden ! Das Ersatz GIDE funktioniert auf Anhieb!!! und damit auch mein D004 wieder !
Nun muss ich es nur noch schaffen, dass er auch von Festplatte bootet wenn keine Diskette im LW steckt. Das geht zur Zeit noch nicht, außer ich zieh das Floppyverbindungkabel zum Floppy Drive ab..
Wie könnte das gehen ? Booten kann er jedenfalls von der Festplatte!
Gruß Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
006
08.04.2008, 00:05 Uhr
Enrico
Default Group and Edit


Der EPROM F8/FC ist ja veraltet. Du brauchst nur einen EPROM. Und die Doku wie das alles eingerichtet werden muss. Hatte ich Dir das nicht zum GIDE mitgeschickt.

Weist Du schon warum das 1. GIDE nicht läuft?
Was sagt GIDETEST.COM dazu?
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
007
08.04.2008, 00:10 Uhr
Ralph



@Enrico.. wieso ist die F8/FC Lösung veraltet ? Ich hab doch vom Mario den aktuellen EPROM bekommen!
Das "alte" GIDE geht auch wieder .. Du wirst es nich glauben, aber derjenige der das gebaut hat, hat offenbar nicht richtig gelötet. Ich hab jetzt mal in Ruhe alle Lötpunkte nachgelötet und schon gings wieder. Ist das nicht fein ?

Lieber Gruß vom Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
008
08.04.2008, 00:11 Uhr
Ralph



@Enrico... Danke Dir nochmal für die "schönen" Stromlaufpläne. Hast Du die auch für das Basisgerät in so guter Qualität ? Ich hab die nur in ganz mieser Quali bisher hier.

Gruß Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
009
08.04.2008, 00:30 Uhr
Enrico
Default Group and Edit


Hi Ralph,

na wenn Du den EPROM vom Mario beim KC-Treffen bekommen hast, wird es schon der neueste sein. Aber die schreibst ja F8/FC. Also hast Du den EPROM auf den Originale gelötet, und diese Konstruktion ist schon lange veraltet. Du brauchst nur den einen EPROM und der macht alles.

Schön, dass das 1. GIDE nun auch läuft. Ich hatte schon befürchtet, dass es da auch Probleme mit den Durchkontaktierungen gibt. Bei den letzten paar GIDEs der letzten Serie hatte da der Hersteller gepfuscht. Sehr ärgerlich.

Die Pläne vom KC85/4 habe ich auch da. Eigentlich hätte ich die in viel höherer Auflösung, aber 100 MB sind etwas viel per Mail.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
010
18.05.2013, 16:11 Uhr
Lötspitze



Hallo,

mal eine Frage zum Umbau der D004 auf GIDE-Tauglichkeit. Müssen dazu Leiterzüge auf den Platinen durchtrennt werden und zusätzliche Drahtbrücken drauf? Kann ich irgendwo die Anleitung zu diesem Umbau finden? Habe schon die Forumbeiträge abgegrast, aber noch keinen Link oder Hinweis darauf gefunden.

VG Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
011
18.05.2013, 16:16 Uhr
Enrico
Default Group and Edit



Zitat:
Lötspitze schrieb
Hallo,

mal eine Frage zum Umbau der D004 auf GIDE-Tauglichkeit. Müssen dazu Leiterzüge auf den Platinen durchtrennt werden und zusätzliche Drahtbrücken drauf? Kann ich irgendwo die Anleitung zu diesem Umbau finden? Habe schon die Forumbeiträge abgegrast, aber noch keinen Link oder Hinweis darauf gefunden.

VG Matthias

Nein.
Deswegen findest Du sowas auch nicht.

Einzig sinnvolle, was Du machen solltest, ist an den entsprechenden Stellen
die Bohrungen auf 3 mm zu vergrösseren, um das GIDE festschrauben zu können.
Die Maße findest Du in der GIDE Doku.
Gibts auf der KC-Club HP, oder SUSOWAs HP.
--
MFG
Enrico

Dieser Beitrag wurde am 18.05.2013 um 16:17 Uhr von Enrico editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
012
18.05.2013, 17:49 Uhr
Lötspitze



Gibt es am originalen Gerät werksseitig irgendwelche durchgekratzten Leiterzüge? Oder kann man das ausschließen und alles was getrennt ist, muß wieder geflickt werden?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
013
18.05.2013, 18:06 Uhr
Enrico
Default Group and Edit


Da muss nichts durchgekratzt werden.
Wieso ist bei Dir was durchgetrennt?
Wer macht denn sowas?
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
014
18.05.2013, 19:52 Uhr
Lötspitze



Ja, das frage ich mich im Moment auch. Habe bis jetzt zwei Trennungen gehabt, die unter der Lupe bewußt durchgekratzt aussahen. Vielleicht stammt das von einer Fehlersuche und wurde vergessen, wieder zusammenzulöten.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
015
18.05.2013, 23:02 Uhr
Enrico
Default Group and Edit


Das kann schon sein. Ich hatte da noch nie was mit unterbrochenen Leiterbahnen in der Hand.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
016
19.05.2013, 10:06 Uhr
kaiOr

Avatar von kaiOr


Zitat:
Lötspitze schrieb
Gibt es am originalen Gerät werksseitig irgendwelche durchgekratzten Leiterzüge?

Also auf meiner sind auf der Leiterseite schon 4 Trennungen. Und da wurde fleißig umgeroutet, sind also keine Korrekturen nach dem Schwalllöten, die auch manchmal vorkommen, sondern richtige Fehler im Layout.

MfG

Dieser Beitrag wurde am 19.05.2013 um 10:07 Uhr von kaiOr editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
017
19.05.2013, 16:16 Uhr
klagk1



kaiOr, wie macht sich das dann praktisch bemerkbar?
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
018
19.05.2013, 19:23 Uhr
kaiOr

Avatar von kaiOr

MPM hat damit die Grundfunktion hergestellt. Vermutlich kam vor der Wende auch keine bereinigte Revision raus.

In den Original-Schaltplänen sind die Trennungen auch eingezeichnet.
http://robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=9539
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
019
20.05.2013, 19:51 Uhr
Lötspitze



Nach genauerem Hinsehen ist es wirklich so, daß bei jeder Trennung auch eine neue Freiluftverdrahtung an andere Pins gemacht wurde. Das bestätigt das, was kaiOr sagt.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
020
15.06.2013, 22:01 Uhr
Lötspitze



Das D004 scheint jetzt erst einmal zu laufen, nachdem ich beim Grundgerät und am D004 die Busanschlüsse sowie den DeviceConnector ordentlich gesäubert habe.
Nach JUMP FC FF läuft der Test 3.2 (28.10.2008) in allen 5 Punkten mit OK durch. Nach JUMP FC kommt dann "Not ready ERROR", was normal sein dürfte, da ja weder GIDE noch Floppy dran hängen. Ein erweitertes Menü (z.B. mit FLOAD) wird nicht angezeigt.
Ist das so erst einmal in Ordnung? Gibt es denn noch weitere Tests für das D004, bevor man ein GIDE einbaut?
Apropos GIDE - ich suche davon eine Platine (ohne DK-Probleme) für die Variante zum Aufstecken auf die U880-Fassung inkl. Aufbaubeschreibung oder ein funktionstüchtiges, fertig aufgebautes GIDE. Über Angebote per PN würde ich mich freuen.

Gruß Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
021
22.06.2013, 09:44 Uhr
Lötspitze




Zitat:
Nach JUMP FC FF läuft der Test 3.2 (28.10.2008) in allen 5 Punkten mit OK durch. Nach JUMP FC kommt dann "Not ready ERROR", was normal sein dürfte, da ja weder GIDE noch Floppy dran hängen. Ein erweitertes Menü (z.B. mit FLOAD) wird nicht angezeigt.

Ist das so erst einmal in Ordnung? Gibt es denn noch weitere Tests für das D004, bevor man ein GIDE einbaut?


Zitat:
Apropos GIDE - ich suche davon eine Platine (ohne DK-Probleme) für die Variante zum Aufstecken auf die U880-Fassung inkl. Aufbaubeschreibung oder ein funktionstüchtiges, fertig aufgebautes GIDE. Über Angebote per PN würde ich mich freuen.

Nix mehr "am Lager"?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
022
22.06.2013, 13:54 Uhr
Steffen

Avatar von Steffen

Hi,

du hast Post...

Gruss
--
Wer anderen eine Bratwurst brät, hat ein Bratwurstbratgerät...

"... sehr dunkel die andere Seite sie ist...."
"Halt's Maul Joda und iss deinen Toast!!!"
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
023
23.06.2013, 19:50 Uhr
Lötspitze



Danke Steffen!

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
024
31.08.2013, 14:31 Uhr
Lötspitze



Hallo,

nach Inbetriebnahme des GIDE habe ich ein paar neue Probleme mit dem verwendeten D004. Es arbeitet nicht korrekt und bringt selbständig Tastatureingaben (Wiederholungen) und Bildschirmausgaben. Damit ist eine Arbeit mit dem GIDE unmöglich.
Beim Beispiel unten habe ich nach dem Anzeigen vom Verzeichnis nur DRIVER M052.DRV eingegeben. Alle nachfolgenden Ausgaben hat der Rechner dann selbst gemacht.

Ein Austausch des KC85/4 und der Tastatur brachten keine Verbesserung, sodaß der Fehler höchstwahrscheinlich wirklich nur am D004 liegt. J FC FF läuft aber immer mit 5x OK durch.
Bei allen Tests waren jetzt auch keine Module mehr gesteckt. Der Start des ML-DOS funktioniert. Danach kann man auch auf c: usw. umschalten und mit D die Verzeichnisse anzeigen. Manchmal (selten) wird hierbei fehlerhaft nur ca. die Hälfte der Dateien angezeigt und der Rechner springt zu früh wieder zum Prompt. Die Treiber können weiterhin nicht ordnungsgemäß geladen werden.
Wo könnte man denn nun mit der Fehlersuche ansetzen? Kann man das aufgrund der o.g. Dinge irgendwie eingrenzen?

Viele Grüße
Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
025
31.08.2013, 14:59 Uhr
Alwin

Avatar von Alwin

Hallo Matthias,

An meinem Test KC85/5 habe ich das auch das selbständige Eingaben erfolgen unter ZSDOS. aber bei mir liegts definitiv am KC. an meinem richtigen KC85/5 läuft alles perfekt. ich habe beim Test KC das Problem, das das USB sich einschalten lässt, aber beim Aufruf von Vinculum bzw. Start unter ZSDOS sich das Dinge aufhängt und ich sehe nur noch Streifen.
--
...Z1013, KC87, KC85/5, KC Compact, C64
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
026
31.08.2013, 17:19 Uhr
kaiOr

Avatar von kaiOr

Der V24TAST.KOP auf C0: dient nur der Verarztung, wenn noch der originale D004-ROM drin steckt.
Falls der zufällig nachgeladen wird oder bei Systemgenerierung mit integriert wurde könnte schon die Fehlerursache gefunden sein.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
027
31.08.2013, 18:26 Uhr
Lötspitze



Als ROM steckt die Version 3.2 drin. V24TAST.KOP habe ich nie geladen.
Wenn Treiber (auch bei der Systemgenerierung) geladen wurden, müßten die doch mit DRIVER /L angezeigt werden, oder? Dann würde ich jetzt als nächstes mehrmals versuchen, nach dem Start von ML-DOS wenigstens einmal eine vernünftige Anzeige mit DRIVER /L zu erhalten.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
028
31.08.2013, 22:23 Uhr
Lötspitze



Keine Chance, mit DRIVER eine vernünftige Anzeige zu bekommen.
Kann man den Eprom als Fehlerursache sicher ausschließen? Ich denke schon, da dessen Checksumme ja bei J FC FF gestimmt hat.
Ich habe auch noch mal den Bussteckverbinder gereinigt. Hat nichts gebracht.
Ist im Grundgerät eigentlich ein bestimmtes CAOS notwendig? Ich habe dazu nichts gelesen. Ich hatte das D004 an einem KC mit CAOS4.1 und einem mit CAOS4.2. Beide zeigten gleiches Verhalten.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
029
31.08.2013, 22:53 Uhr
UR1968
Default Group and Edit


Hallo Matthias,

Das System sollte mit jedem CAOS funktionieren.
Du wirst nicht darum kommen eine Floppy am D004 an zuschließen. Damit schauen ob es bei MicroDos auch zu solchen Fehlern kommt.
Was hast Du für eine Tastatur dran? Original oder PS/2 über Tastaturadapter?
Test mit einem funktionierenden System wäre auch nicht schlecht, um dahinter zu kommen welches Teil nun streikt.

Tschüß
Uwe
--
https://uwes-bastelbude.ch
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
030
01.09.2013, 13:43 Uhr
kaiOr

Avatar von kaiOr

DRIVER /L zeigt nicht die integrierten Treiber, aber das System listet die eigentlich beim Start kurz auf.

Ggf. mit MPM-Prüfprogramm nochmal auf den Koppelram losgehen:
http://pontacko.tfn-clan.de/files/kc/D004IN.zip
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
031
01.09.2013, 22:19 Uhr
Lötspitze



Uwe, ich habe eine originale Tastatur dran.
Kai, danke für das Programm. Ab Mitte der Woche komme ich wieder zum Testen. Dann werde ich das mal ausprobieren.

Gruß Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
032
07.09.2013, 20:41 Uhr
Lötspitze



Ich habe mit dem Programm D004IN27 mal einige Tests gemacht. Folgendes Ergebnis hat das gebracht:

SIO funktioniert
RIO funktioniert
RTEST 38 00 21 00 00 00 03 2F 05 CF 23 D0
(diese Kombination kann ich in D004V32.KCC nicht finden)
KCL funktioniert
@PRG funktioniert
KTEST OK
FON funktioniert bei SIO aktiv
FOFF funktioniert bei SIO aktiv
KLOP Zählung in 10H funktioniert, aber in Zeile FC10h verändern sich sporadisch auch andere Bytes (ich gehe davon aus, daß das nicht so sein sollte)
DLOP Zählung in 30H funktioniert; keine weiteren Byteänderungen
DTEST funktioniert

Also für mich gibt es 2 Punkte, die erst mal geklärt werden müssen. Könnte mir jemand sagen, was bei RTEST als Bytes ausgegeben werden müßte. Weiterhin bräuchte ich eine Info, ob sich bei KLOP die anderen Bytes ändern dürfen oder ausschließlich nur das Byte, wo gezählt wird. Besten Dank schon mal vorab.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
033
08.09.2013, 14:45 Uhr
Lötspitze



Das Testprogramm ist in 030 zu finden. Vielleicht kann ja mal einer bei Gelegenheit die beiden Punkte mit funktionierendem D004+GIDE nachvollziehen. Würde mich freuen.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
034
08.09.2013, 15:03 Uhr
Alwin

Avatar von Alwin


Zitat:
Lötspitze schrieb
Das Testprogramm ist in 030 zu finden. Vielleicht kann ja mal einer bei Gelegenheit die beiden Punkte mit funktionierendem D004+GIDE nachvollziehen. Würde mich freuen.

Matthias

Hallo Matthias,

wenn ich es heut abend schaffe, werde ich es austesten an meinem fertigen D004+CF-Card. an meinem 2. D004 kann ich es auch mal testen, sobald ich die neue Z80A-CPU da habe.
--
...Z1013, KC87, KC85/5, KC Compact, C64
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
035
09.09.2013, 21:20 Uhr
Alwin

Avatar von Alwin


Zitat:
Lötspitze schrieb
Ich habe mit dem Programm D004IN27 mal einige Tests gemacht. Folgendes Ergebnis hat das gebracht:

SIO funktioniert
RIO funktioniert
RTEST 38 00 21 00 00 00 03 2F 05 CF 23 D0
(diese Kombination kann ich in D004V32.KCC nicht finden)
KCL funktioniert
@PRG funktioniert
KTEST OK
FON funktioniert bei SIO aktiv
FOFF funktioniert bei SIO aktiv
KLOP Zählung in 10H funktioniert, aber in Zeile FC10h verändern sich sporadisch auch andere Bytes (ich gehe davon aus, daß das nicht so sein sollte)

Hallo Matthias,

habe heut den Test gemacht, habe 3.3er Eprom drin
alles wie bei dir, RTEST: C3 74 1A 3E 16 ED 79 06 A7 ED 58 05
Klop auch bei FC10h nur im ersten Teil Änderungen.
DLOP auch wie bei Dir.

ich denke mal das deine D004 in Ordnung ist.

Also für mich gibt es 2 Punkte, die erst mal geklärt werden müssen. Könnte mir jemand sagen, was bei RTEST als Bytes ausgegeben werden müßte. Weiterhin bräuchte ich eine Info, ob sich bei KLOP die anderen Bytes ändern dürfen oder ausschließlich nur das Byte, wo gezählt wird. Besten Dank schon mal vorab.

Matthias


--
...Z1013, KC87, KC85/5, KC Compact, C64
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
036
09.09.2013, 21:56 Uhr
Lötspitze



Hallo Silvio,

besten Dank für Deinen Gegentest.
RTEST zeigt bei Dir wahrscheinlich wirklich die ersten Bytes des Eproms an, da es mit JMP anfängt. Bei mir mit 38 00 21 scheint das Unsinn zu sein. Könntest Du mir mal die Datei des Eprom schicken, wenn Du sie hast. Ich kenne nur den 3.2er.
Wenn sich bei Dir bei KLOP nur in FC10h das erste Byte beim Zählen ändert, scheint bei mir auch etwas mit dem Koppelram nicht zu stimmen, obwohl dessen Test i.O. ausfällt. Es ändern sich sporadisch noch 3-4 Bytes hinten in dieser Zeile.
Jetzt werde ich erst einmal den Eprom rausnehmen und testen.

Gruß Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 09.09.2013 um 21:58 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
037
10.09.2013, 05:48 Uhr
Alwin

Avatar von Alwin

im KC-Labor: susowa.homeftp.net unter Downlods-Eprom Inhalte gibts die 3.3er D004.
--
...Z1013, KC87, KC85/5, KC Compact, C64
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
038
10.09.2013, 22:26 Uhr
Lötspitze



Ich hatte den Eprom heute draußen. Es ist die Version 3.2 und war in Ordnung. Nach dem Wiedereinbau brachte RTEST wieder die gleiche falsche Bytefolge wie in 032 und das ML-DOS macht sich weiterhin selbständig. Also muß ich weitersuchen.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
039
10.09.2013, 22:46 Uhr
kaiOr

Avatar von kaiOr

Mit dem TotalCommander findest Du sowas. Die Bytefolge gehört zur USB-Software. Da prüft RTEST vermutlich nicht ob ein Modul höherer Priorität im Weg steht.

Die Koppelsteuerung ist leider nicht ganz ohne. Der Fehler tritt in dem Bereich auf in dem das D004 Schreibzugriff macht, mit Zähler einlesen, um 1 erhöhen und zurückschreiben. Schwer zu sagen ob der Fehler so auch wirklich im SRAM steht oder ob nur der KC85 an der Stelle Leseprobleme bekommt....weil die Umschaltung von Adress- oder Datenbus hinterherhinkt oder die Waiterzeugung versagt.

MfG
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
040
11.09.2013, 17:22 Uhr
Lötspitze



Kai, ich habe RTEST mal mit abgeschaltetem M052 ausgeführt. Dann zeigt er den Eprom korrekt an. Also das paßt.

Gibt es jemanden, der in der Vergangenheit nach einem Umbau ähnliche Probleme hatte und das in den Griff bekommen hat?

Gruß
Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 11.09.2013 um 17:22 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
041
11.10.2013, 19:38 Uhr
Lötspitze



Ich habe das GIDE wieder ausgebaut und erst einmal ein CHINON-Floppylaufwerk an das D004 gehangen. Das LW wird erkannt. MicroDOS läuft bis zur 3 Zeile "... (C) 1985" und bleibt dann hängen. Mit der CAOS-Diskette wird das Menü noch neu aufgerufen und FLOAD erscheint mit in der Auswahl. Wenn man FLOAD aufruft und z.B. bei Name: SERVICE eingibt, geht danach aber auch nichts mehr weiter.
Läßt sich damit ggf. schon eine Fehlerursache abgrenzen?

Sehr selten kommt beim Test mit Jump FC FF auch mal ein Fehler des dRAM-Programms. Das ist aber nicht reproduzierbar. Normal läuft der Test immer mit 5x OK durch.
Hat jemand einen Tip, wie man hier weitermachen könnte?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
042
11.10.2013, 19:45 Uhr
Enrico
Default Group and Edit


Hast Du schon die PLL eingestellt?
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
043
11.10.2013, 19:50 Uhr
Lötspitze



Nein, habe ich nicht. Ich bin davon ausgegangen, daß das in Ordnung ist, wenn das Laufwerk angewählt wird, die ersten MD-Zeilen kommen bzw. FLOAD im Menü erscheint und keine Fehlerausschrift auftaucht. Ist das richtig oder doch noch kein Zeichen dafür, daß die PLL OK ist?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
044
11.10.2013, 19:56 Uhr
Enrico
Default Group and Edit


Das kann gut sein, dass es ganau daran liegt.

So in etwa müsste das bei mir ausgesehen haben.
Mal kommen ein paar Zeilen, mal weniger.

Oder Du baust es gleich um.
--
MFG
Enrico

Dieser Beitrag wurde am 11.10.2013 um 20:00 Uhr von Enrico editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
045
11.10.2013, 20:19 Uhr
Lötspitze



Eigentlich möchte ich das D004 ja nur für´s GIDE fitmachen. Der Floppyanschluß ist zweitrangig. Allerdings habe ich noch die Hoffnung, daß ich über ihn mit der Reparatur des D004 weiterkomme. Sollte es jetzt die PLL sein, werde ich das auch in Ordnung bringen müssen.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
046
11.10.2013, 21:08 Uhr
Lötspitze



Nur noch mal zur Sicherheit nachgefragt: hat das D004 von der Floppy ordnungsgemäß gelesen, wenn die ersten drei Zeilen des MicroDOS kommen bzw. FLOAD im Caos-Menü auftaucht? Oder geht das auch bei einer fehlerhafter PLL soweit?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
047
11.10.2013, 21:33 Uhr
robbi
Default Group and Edit
Avatar von robbi

Das ist unterschiedlich:
- nackter blauer Bildschirm
- nackter blauer Schirm mit Prompt
- Meldung "can not read"
- unvollständige Systemmeldungen
in jedem Fehler war es die PLL.
--
Schreib wie du quatschst, dann schreibst du schlecht.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
048
16.10.2013, 23:40 Uhr
Lötspitze



Habe die neue PLL fast fertig. Beim Einbau hatte ich gesehen, daß abweichend zu dem Foto auf den Seiten von Götz (mpm-kc85) bei mir ein Kondensator auf Pin 20 und 21 des FDC liegt (GND zu WR CLK). Auf dem Foto im Web sitzt er augenscheinlich 5 Pins weiter. Was ist denn hier richtig oder ist jedes D004 anders abgeglichen?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 17.10.2013 um 08:46 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
049
18.10.2013, 18:04 Uhr
Lötspitze



Trotz neuer, digitaler PLL bleibt der Rechner beim Start des MicroDOS an der gleichen Stelle stehen wie vorher. Es handelt sich beim Testaufbau wie vorab nur um das Grundgerät+D004 ohne gesteckte Module.

Kann man die digitale PLL testen, ob sie funktioniert? Ich gehe zwar davon aus, aber Sicherheit darüber wäre schon besser.
Was passiert bzw. sollte an der Stelle passieren, wo der Rechner hängt? Ist das dort, wo eigentlich Laufwerk A: (RAM-Floppy) initialisiert wird? Vielleicht liegt dort das Problem. Oder gibt es irgendwelche Hardware-Abfragen, wo der Rechner hängen bleibt?
Kommt ggf. ein Softwareproblem mit der Diskette in Frage? Sicher ist, daß diese Diskette mit einem anderen D004 funktioniert. Könnte mein D004 aber ggf. andere Einstellungen der Startsoftware benötigen?
Die Frage in 048 zum Kondensator wäre auch noch offen.

Bin für jeden Tip dankbar.
Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 18.10.2013 um 18:06 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
050
18.10.2013, 19:06 Uhr
robbi
Default Group and Edit
Avatar von robbi

Habe gerade ein D004 von "Günter" hier.
Hier liegt auch ein Kondensator von 680pF am FDC von 20 nach 21.
Der FDC ist ein D765AC von NEC.

Die Bildschirmfotos von 024 und 049 sehen nicht gut aus. Geht das Bild über HF oder ist da noch etwas anderes im Argen?

Nachtrag:
Bei "Günter" waren auf der L-Seite die zwei 100pF-Kondensatoren an den Ferritperlen zu weit auf die Leiterplatte gebogen worden, hatten Schlüsse mit benachbarten Lötaugen und brachten den Effekt, daß der Bootvorgang nur mit einer Promptausgabe hängen blieb.
--
Schreib wie du quatschst, dann schreibst du schlecht.

Dieser Beitrag wurde am 18.10.2013 um 19:14 Uhr von robbi editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
051
18.10.2013, 20:03 Uhr
Lötspitze



OK, dann scheint das mit dem Kondensator kein Problem zu sein. Die anderen Bauelemente werde ich noch einmal intensiv auf Schlüsse checken (die Einbauschienen unter der Busplatine hatte ich auch schon isoliert, da ich mir nicht sicher war, ob nicht doch ein Beinchen der LS dort Kontakt hat).

Ja, der KC hängt über HF am TV. Im normalen CAOS-Modus habe ich blinkende Pixel in der 4. Spalte von links von oben bis unten sowie ab ca. Bildschirmmitte auch in der 5. und 6. Spalte. Wenn MD gestartet wird, erscheinen dann die senkrechten Striche, wie im Foto 049, wobei die beiden linken wieder die blinkenden Pixelfehler in der unteren Bildschirmhälfte haben.
Der Gegencheck mit einem anderen KC ergab aber, daß diese Fehler augenscheinlich keinen Einfluß auf das D004 haben und der Start dort ebenso wie in Bild 049 abbricht.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
052
18.10.2013, 21:35 Uhr
Lötspitze



Nachdem ich nun mehrmals JU FC bzw. JU FC FF gestartet habe, kommen Fehler im dRAM-Test bzw. -Programm.



Der Fehler Soll=00 Ist=39 kam auf den Adressen F418 und F41C. Der Fehler Soll=00 Ist=00 kam auf F41A und F416:



Es konzentriert sich augenscheinlich alles auf die Adressen F41Xh. Was könnte das sein?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 18.10.2013 um 21:38 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
053
19.10.2013, 10:24 Uhr
Lötspitze



Zur Sicherheit noch ein paar klärende Fragen zur Steckverbinderbelegung am D004:
Laut "D004-Manual", Seite 17, Tafel 1 liegt z.B. /RDY auf Pin A13. In der Zeichnung des D004 zum "Belegungsplan B-Seite" (auf Robbis Seiten) ist beim Steckverbinder X37 der Pin A1 rechts oben eingezeichnet. Das entspricht dann von außen auf den Stecker gesehen dem rechten oberen Pin. Damit liegt z.B. /RDY oben ganz links (ebenfalls von außen gesehen). Nach diesem Prinzip habe ich mein Kabel angefertigt. Das ist doch so in Ordnung, oder?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
054
19.10.2013, 18:06 Uhr
Lötspitze




Zitat:
robbi schrieb
Habe gerade ein D004 von "Günter" hier.

Hallo Ulrich, könntest Du bitte mal schauen, ob die Signale der Datenleitungen an den dRAM bei Günters D004 auch so aussehen wie bei mir?



Meines Erachtens kommen die nicht wieder schnell genug auf High.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 19.10.2013 um 18:08 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
055
23.10.2013, 19:17 Uhr
Lötspitze



Inzwischen konnte ich das D004 mit einem originalen DRIVE mit K5601 testen. Das hat funktioniert. Also die digitale PLL ist in Ordnung. Ich bekomme aber trotzdem nicht mein SHINON zum Laufen.
Es ist genauso eingestellt wie am BIC, wo es lief (DS1). Probeweise hatte ich es auch auf DS0 gestellt. Aber auch dort läuft es nur kurz an, es kommt ein blauer Bildschirm und das war´s. Den Lesekopf hört man in beiden Fällen nicht zucken, was die Laufwerke sonst am Anfang ja machen. Daraufhin hatte ich am Kabel TRACK 0 nochmals überprüft, aber das sollte auch in Ordnung sein.
Hat einer noch einen Tip für mich? Muß bei bestimmten Laufwerken ggf. noch etwas im D004 umgejumpert werden?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
056
24.10.2013, 22:47 Uhr
kaiOr

Avatar von kaiOr

Am BIC scheint es das Signal Motor-On zu geben, am D004 nicht. Ist DS0 entsprechend doppelt verdrahtet?

MfG
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
057
25.10.2013, 08:54 Uhr
Lötspitze



Ja, das Motor-On-Signal habe ich immer parallel mit an das jeweilige Select-Signal gelegt.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
058
06.11.2013, 20:18 Uhr
Lötspitze



Habe jetzt ein MITSUMI LW am KC (auf DS0). Hier kann man /RDY direkt jumpern. Nun wird das MicroDOS vollständig gestartet.
Der KC macht aber mit der Diskettenversion die gleichen Probleme wie mit dem GIDE (er entwickelt ein Eigenleben mit Selbsteingaben und Ausschriften auf dem Bildschirm).
Es kommen beim Test mit JU FC FF, wie oben schon genannt, häufig Fehler beim dRAM-Test bzw. "Soll 00 IST 39" auf Speicherplätzen F4xxH sowie ab und zu auch "Soll 00 IST 00", wobei ich letzteres gar nicht verstehe.
39h wäre ja Daten-Byte 0, 3, 4 und 5. Könnte es sein, daß die betroffenen 4 dRAM-Schaltkreise defekt sind? Sollte man hier mit einem Austausch starten?

Gruß Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 06.11.2013 um 20:18 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
059
06.11.2013, 22:36 Uhr
Digitalmax

Avatar von Digitalmax

Hallo Lötspitze,

vom D004 habe ich keine Ahnung, aber kann es sein, dass der Rechner im IM1-Mode laüft und Interrupts ausgelöst werden, die es nicht geben dürfte oder von der Software nicht vernünftig abgearbeitet werden?
Könnte die 39H im Stack durch RST38 ausgelöst werden weil auf Adresse 38H ein RST38-Befehl steht, bzw. der Zugriff auf diesen Speicherbereich immer FFH als Daten bringt(Probleme mit Bustreiber, Adressdekodierung, etc)?
War nur so eine Idee.

Gruß Matthias

Dieser Beitrag wurde am 06.11.2013 um 23:01 Uhr von Digitalmax editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
060
07.11.2013, 22:10 Uhr
Lötspitze



Hallo Matthias,

durch einen ähnlichen Hinweis von Robbi bzgl. der Adreßcodierung der dRAM´s konzentriere ich mich jetzt erst einmal darauf und werde IC D604 sowie D605 (DL257) mit dem Oszi checken bzw. diese beiden IC´s auswechseln. Von 16 Fehleranzeigen war heute nur eine bei F420h - alles andere war F41Xh, davon 5x F410h.

VG Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
061
09.11.2013, 18:39 Uhr
robbi
Default Group and Edit
Avatar von robbi

@050 Nachtrag:
"Günter"s D004 habe ich immer noch hier. Der angeblich gefundene Fehler war keiner, ebenso ein zweiter "gefundener".
Man denkt, man hat den Fehler gefunden, wenn nach einem gezielten Eingriff plötzlich alles geht, viele Male und reproduzierbar.
Das böse Erwachen kommt, wenn man das D004 am nächsten Tag noch einmal testet. Es ist ein thermischer Fehler. Erst geht gar nichts, das D004 bleibt mit blauem Bildschirm und manchmal mit Prompt hängen und nach 10 Minuten bootet es plötzlich von der Diskette.
Der CRC-Test ist manchmal falsch, der Koppel-RAM-Test ist IMMER ok, der DRAM-Test nur selten. So schön reproduzierbare Adreßwerte habe ich auch nicht. Es gibt nur gehäufte SOLL=xx und IST=7E beim DRAM-Test. Dazu kommen noch Verklemmungen und Abbrüche, manchmal mit Neustart des "J FC FF".
--
Schreib wie du quatschst, dann schreibst du schlecht.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
062
09.11.2013, 20:30 Uhr
Lötspitze




Zitat:
Man denkt, man hat den Fehler gefunden, wenn nach einem gezielten Eingriff plötzlich alles geht, viele Male und reproduzierbar.
Das böse Erwachen kommt...

Ging mir soeben genauso. Hatte die WAIT-Steuerung entsprechend http://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=10092 umgebaut und den KC gestartet. Zuerst lief alles wunderbar. Zig mal das Directory der Diskette ausgelesen und STAT ausgeführt. Wollte das Problem schon fast abhaken. Und dann nach 5 Minuten wieder diese eigenständigen Aktivitäten des Rechners.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 09.11.2013 um 20:34 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
063
10.11.2013, 00:15 Uhr
Enrico
Default Group and Edit


Dann versuch doch mal den Fehler mittels Kältespray einzugrenzen.
Allerdings wirst Du dir dazu ein Adapterkabel als Ersatz für den
Device-Connector bauen müssen.
Die Platine der D004 steckt ja leider Kopfüber drin.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
064
10.11.2013, 11:27 Uhr
robbi
Default Group and Edit
Avatar von robbi

Nach einer halben Flasche Kältespray bin ich nicht schlauer, obwohl er sich im kalten Zustand besonders bemerkbar macht.
Mit Kältespray kann ich einen kalten Rechner nicht simulieren. Bei "Lötspitze" wird es kaum anders sein.
--
Schreib wie du quatschst, dann schreibst du schlecht.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
065
10.11.2013, 11:42 Uhr
Enrico
Default Group and Edit


Mir hat das bei Temperaturfehlern immer ganz gut geholfen.
Das bringt aber nur so richtig was, wenn man stückweise gezielt auf einzelne
ICs losgeht. Flächendeckendes einnebeln bringt eher kaum was.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
066
10.11.2013, 12:17 Uhr
Rüdiger
Administrator



Zitat:
robbi schrieb
Nach einer halben Flasche Kältespray bin ich nicht schlauer, obwohl er sich im kalten Zustand besonders bemerkbar macht.

Versuche den umgekehrten Weg: Lokales Erwärmen mit Heißluft.
--
Kernel panic: Out of swap space.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
067
10.11.2013, 13:16 Uhr
kaiOr

Avatar von kaiOr

Den einzigen Bug den ich im D004 gefunden hatte war das KD7 an R301 vergessen wurde anzuschließen (Fehler im Layout). Solltet ihr ggf. auch nachholen.

Mein Temperaturfehler damals bei:
http://pontacko.tfn-clan.de/files/kc/bug1.jpg
war die EPROM-Bestückung im D004. Trotz gleicher Zugriffszeit (150ns) musste ich erst den originalen Chip löschen und neu programmieren. Schätze mal das Output-Enable ist unsauber auscodiert, hatte zum damaligen Zeitpunkt aber keinen Oszi.

Dieser Beitrag wurde am 10.11.2013 um 13:27 Uhr von kaiOr editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
068
10.11.2013, 19:00 Uhr
Lötspitze



Ich hatte den Eprom auch schon nachgebrannt und ebenso die fehlende Brücke zwischen R301 und D415 nachgerüstet.
Habe heute noch mal den KC versuchsweise gestartet und 3x hintereinander das Directory aufgerufen. Danach habe ich ihn für 2 Stunden in Ruhe gelassen. Dabei kam es zu keinen Fehlern. Erst bei erneuten mehrfachen Eingaben hat er dann angefangen, wieder Probleme zu machen.
Werde mal schauen, wo ich 8k-Eproms herbekomme und dann mal einen neuen einsetzen. Wäre ja schön, wenn´s nur daran liegt.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
069
11.11.2013, 20:17 Uhr
robbi
Default Group and Edit
Avatar von robbi

Fehlende Brücke zwischen R301 und D415? Da ist doch eine Verbindung!?

Habe einen anderen EPROM eingesetzt und siehe da, der Selbsttest mit "J FC FF" liefert keine Fehler mehr. Danke "kaiOr"!
Aber die Eigenaktivitäten unter CP/M bestehen nach wie vor.
--
Schreib wie du quatschst, dann schreibst du schlecht.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
070
11.11.2013, 21:16 Uhr
Lötspitze




Zitat:
Fehlende Brücke zwischen R301 und D415? Da ist doch eine Verbindung!?

Bei mir gab´s keine zwischen R301/Pin9 und D415/Pin12.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
071
11.11.2013, 22:22 Uhr
robbi
Default Group and Edit
Avatar von robbi

Bei mir auch nicht. Wenn man nicht richtig zählen kann, kein Wunder.
Aber sie hat nichts gebracht.
--
Schreib wie du quatschst, dann schreibst du schlecht.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
072
12.11.2013, 22:59 Uhr
Lötspitze



Habe jetzt auch den EPROM gewechselt und der KC läuft damit besser, aber immer noch nicht 100%ig. Der Start von POWER war möglich und ich konnte nahezu fehlerfrei einige Kommandos ausprobieren.
Bei FILL und DUMP ist mir aufgefallen, daß sich einige Speicherbereiche nicht richtig ändern lassen bzw. permanent den gleichen Inhalt haben. Das betrifft 0042h "Zufall", 005Dh-0067h mit "3F" und 007C mit "00". Welcher Speicher ist das dann eigentlich, der vom D004 und der vom Grundgerät? Auf jeden Fall dürfte hier etwas nicht in Ordnung sein.
Die 39h (siehe 058) standen übrigens zum Beginn bei fast jedem 2. Byte in diesem Bereich.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
073
12.11.2013, 23:24 Uhr
Enrico
Default Group and Edit


Du meinst FILL und DUMP im POWER?
Das wäre dann der RAM in der D004.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
074
13.11.2013, 12:32 Uhr
Lötspitze



Hallo Enrico,
ja, ich meine die Kommandos im POWER. Wenn das der D004-RAM ist, wäre das ja mal eine nachvollziehbare Spur. Werde mal einen Bildschirmausdruck machen und mit POWER etwas intensiver den Rest prüfen. Was ich nicht verstehe ist, daß das Testprogramm JU FC FF erst bei > F41Xh gemeckert hat, obwohl augenscheinlich der Speicher im untersten Bereich schon n.i.O. ist. Oder wird der Bereich bis 00FFh als Systembereich beim Test ausgeklammert?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
075
13.11.2013, 20:18 Uhr
Enrico
Default Group and Edit


Das ist eine Frage für Mario, kann ich Dir leider ncihts zu sagen.
Er macht I.d.R. was am System.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
076
14.11.2013, 18:14 Uhr
Lötspitze



Wie angekündigt mal ein Foto:



Hier sieht man die in 072 genannten Bytes, die nicht mit FILL unter POWER zu ändern gehen (habe hier den Bereich 0010h-00FFh mit 11 "gefillt"). Hat jemand eine Idee, was die Ursache sein könnte? Ich habe das mit verschiedenen HEX-Zahlen probiert - es sind stabil immer die gleichen Adressen, die betroffen sind.
Meine Vermutung ist, daß das die Probleme mit dem D004 verursacht.
Tips sind gern willkommen.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 14.11.2013 um 18:15 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
077
14.11.2013, 18:18 Uhr
Enrico
Default Group and Edit


Werden denn die unteren 100h nicht vom Betriebsystem für irgendwas genutzt?
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
078
14.11.2013, 18:48 Uhr
Lötspitze



Vermutlich ja. Nur warum sind z.B. die Bytes von 5Dh-67h ausgerechnet "3F" und lassen sich nicht ändern? Normal wäre ja ein Überschreiben möglich und das BS stürzt z.B. ab.
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 14.11.2013 um 18:49 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
079
14.11.2013, 18:52 Uhr
Heiko_P



Es sieht auf dem Foto so aus als wäre das der Bereich des (Standard) FCB. Hast du diesen Hexdump mit POWER gemacht? So lange POWER läuft und den Standard-FCB vom CP/M nutzt, kann es jederzeit in diesen Bereich reinschreiben. Abstürzen muss es deshalb nicht unbedingt.

Gruß Heiko

Dieser Beitrag wurde am 14.11.2013 um 18:53 Uhr von Heiko_P editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
080
14.11.2013, 19:41 Uhr
Lötspitze



(Was ist denn ein FCB?)
Ja, das ist die Ausgabe mit DUMPH aus dem Power heraus.
Ich kann "11" bzw. alles mögliche im o.g. Bereich hier reinschreiben. 5Dh-67h bleibt aber immer "3F". Ist das so, weil ein Programm (BS oder POWER) sofort wieder etwas über die "11" drüberschreibt oder weil der RAM (bzw. die Adreßdecodierung) defekt ist?
Ich versuche das gleich noch mal byteweise mit Kommando DS zu ändern (Edit: geht auch nicht).

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 14.11.2013 um 21:59 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
081
14.11.2013, 20:06 Uhr
Rüdiger
Administrator



Zitat:
Lötspitze schrieb
(Was ist denn ein FCB?)

File Control Block.
--
Kernel panic: Out of swap space.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
082
14.11.2013, 20:13 Uhr
maleuma



KC-MicroDOS nutzt den Bereich folgendermaßen:

Quellcode:
; CP/M-Vereinbarungen:
;
IOBYTE    EQU    0003H    ; System-I/O-Byte
CDISK    EQU    0004H    ; aktuelles Laufwerk
BDOS    EQU    0005H    ; BDOS-Ruf
HOUR    EQU    0040H    ; Systemuhr Stunden
MINUTE    EQU    0041H    ; Systemuhr Minuten
SECOND    EQU    0042H    ; Systemuhr Sekunden
FCB1    EQU    005CH    ; 1. FCB
FCB2    EQU    006CH    ; 2. FCB
DEFDMA    EQU    0080H    ; Standard-DMA-Puffer

Die Systemuhr läuft CTC-gesteuert, die Sekunden sollten sich also regelmäßig ändern.
Im FCB werden von CP/M die ersten zwei Eingabeparameter versucht, als Dateinamen aufzubereiten, das Fragezeichen steht dafür als Jokerzeichen.
Und ab 80H steht dann noch die komplette Eingabezeile für die Programme zum Auswerten. Ich weiß aber nicht, was POWER macht, aber auch POWER wird Arbeitszellen benötigen und die in diesem Bereich würden sich ja anbieten.

Um das endgültig zu klären, benötigst Du den Quelltext von POWER - falls den jemand hat...

Für mich sieht das also ganz "normal" aus.
--
Mario.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
083
14.11.2013, 20:46 Uhr
Lötspitze



Dann ist das augenscheinlich doch in Ordnung; 0042h ändert sich immer (Sekunden) und FCB1/FCB2 liegen in dem Bereich mit den 3Fh´s.
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
084
14.11.2013, 21:55 Uhr
Lötspitze



Könnte mir bitte einer von Euch für die weiteren Tests ein "dsk"-Image mit den UTools für das M052 zuschicken, damit ich beliebig Software laden kann? Es muß aber "dsk" sein, was anderes bekomme ich auf meinem PC z.Z. nicht auf die Floppy gebraten. Danke
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
085
14.11.2013, 23:57 Uhr
Heiko_P



@076:
Ich hab das mal an meinem AC1 nachvollzogen, mit POWER 3.07 und CP/M 2.2: das Verhalten ist identisch zu deinem Foto.
Es liegt am Programm POWER, welches die Zellen ab 58h nach dem Befüllen immer wieder genau so beschreibt.

Gruß Heiko
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
086
15.11.2013, 00:40 Uhr
Lötspitze



OK Heiko, danke.
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
087
15.11.2013, 18:00 Uhr
ManfredB



Hallo,

ich mische mich mal ein, da das Problem der wiederholten "Tastatureingaben" jetzt auch bei mir auftritt. Ich wollte mein Ersatzsystem nun auch mit einem GIDE-Interface ausrüsten und habe das System vorher aufgebaut um es noch mal zu testen. Im einzelnen handelt es sich um folgende Geräte: KC 85/5, Floppy Disk Basis (noch ohne Modifikationen) und ein Floppy Disk Drive (mit 3,5" Floppy).

Nach dem Systemstart (der ohne Probleme läuft), erscheint immer wieder eine weitere Ausgabezeile, ohne dass ich auch nur eine Tastatureingabe gemacht habe. Das sieht dann so aus:



Darauf hin habe ich mal etwas experimentiert. Wenn ich ein Modul in den Modulschacht 08 stecke, tritt der Fehler nicht auf. Dabei war es egal, ob es sich um ein M032, M052, M008 oder das M062 handelte. Der Fehler trat reproduzierbar nicht auf. Sobald kein Modul steckt, tritt er aber wieder auf.

Dann habe ich mal einen KC85/4 ohne Modufikationen eingesetzt. Auch hier tauchte der Fehler nicht auf.

Jetzt habe ich wieder den KC 85/5 im System und schon taucht der Fehler (ohne Module) wieder auf.

Nach meinen Beobachtungen liegt es also offensichtlich nicht nur am D004.

Wenn Bedarf besteht, kann ich gerne weitere Tests machen.

Gruß
Manfred

Dieser Beitrag wurde am 15.11.2013 um 18:44 Uhr von ManfredB editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
088
15.11.2013, 18:29 Uhr
robbi
Default Group and Edit
Avatar von robbi

Es werden 18 Zeichen einer 3 Zeilen darüber liegenden Bildschirmzeile ausgegeben. Nach "D" zum Beispiel das Laufwerksverzeichnis und dann wiederholt die letzten 18 Zeichen davon.

ABER NICHT IMMER! Manchmal stürzt das System auch ab.

Nachtrag:
Das untersuchte System ist aber schon ein KC85/5 und das D004 ist für die GIDE vorbereitet.

Bei MEINEM eigenen KC85/5 tritt es nicht auf.
--
Schreib wie du quatschst, dann schreibst du schlecht.

Dieser Beitrag wurde am 15.11.2013 um 18:31 Uhr von robbi editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
089
15.11.2013, 18:41 Uhr
ManfredB



Bei mir sind es auch 18 Zeichen und immer aus der dritten Zeile darüber.
Da scheint System hinter zu stecken.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
090
15.11.2013, 20:35 Uhr
Lötspitze



So einen Zusammenhang kann ich bei mir nicht erkennen. Hier sind es meist Wiederholungen vom Beginn der ersten oder Ende der letzten Ausgabezeile.
Zum Teil ist es aber sogar so, daß vorab eingegebene Befehle wieder auftauchen. Zum Beispiel wird die Eingabe von STAT neu angezeigt und von selbst gestartet, obwohl ich zwischendurch schon einmal das Directory neu aufgerufen hatte.
Ich habe auch den Eindruck, daß das System unter POWER viel stabiler läuft, als direkt unter dem MicroDOS-Prompt.

Wenn einmal "das D004 mit eigenem Rechner läuft" und im anderen Fall ein D004 mit einem in 08 gesteckten Modul, scheint die Ursache vielleicht doch am KC selbst zu liegen. Gibt es für Schacht 08 nicht eine Besonderheit (Selbststart von Modulen o.ä.)? Könnte hier bei einer fehlerhaften Systemabfrage von einem gesteckten Modul eine notwendige Rückmeldung kommen, die bei leerem Schacht fehlt? Oder "beruhigt" ein gestecktes Modul eher die Busleitungen und führt so zu einem reibungslosen Betrieb?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
091
15.11.2013, 21:33 Uhr
maleuma



So einen Effekt mit wiederholt ausgegebenen Zeichen habe ich bei mir auch schon gehabt. Das ist aber bei meinem KC sporadisch und eher selten aufgetreten. So dass sich eine Fehlersuche nicht gelohnt hätte. Kann auch sein, dass es mit der D008 nicht mehr aufgetreten ist...

Ich vermute, dass sich das Problem im Zugriff auf den Koppel-RAM erklären lässt. Da ist für alle Ein-/Ausgabekanäle ein 32-Byte Ringpuffer vorhanden. Das hat den Vorteil, dass man bis zu 32 Zeichen über die Tastatur eingeben kann, auch wenn das Programm die Tastatureingaben noch gar nicht benötigt.

Zur Realisierung dieses Ringpuffers gibt es im Koppel-RAM zwei Zeiger: Der eine zeigt dem D004-Programm an, wo das nächste Zeichen zu entnehmen ist, der andere wohin der Treiber im Grundgerät den nächsten Tastencode hin schreiben soll. Sind die beiden Zeiger gleich, ist der Puffer leer.

Wartet ein Programm im D004 auf eine Tastatureingabe, dann werden diese beiden Zeiger ständig gelesen und verglichen. Wird dann durch einen unsauberen Speicherzugriff im Koppel-RAM der Zeiger falsch gelesen, dann "schnappt" der Puffer über und die letzten 32 Tastatureingaben werden erneut aus dem Puffer geholt. Da hier auch ein paar Steuerzeichen wie Enter-Taste usw. drin sind, könnte das die 18 Zeichen erklären.

Wäre eine Idee...
--
Mario.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
092
16.11.2013, 20:53 Uhr
Lötspitze



... klingt logisch. Habe deshalb heute mal die sRAMs unter die Lupe genommen. Mir fiel auf, daß WE am Pin10 des D413 (U214) kleine Peaks Richtung LOW enthält, was in meinen Augen nicht normal ist (z.B. der rechts außen):



Dieses Signal kommt von Ausgang 2 Pin 9 des D411 (DL257). Daraufhin habe ich das Oszi erst einmal zum Vergleich an dessen Ausgang 3 Pin 12 gehalten, der theoretisch hätte auf LOW sein müssen, weil dessen Eingänge eigentlich beide auf Masse liegen. Der war aber HIGH mit den gleichen Peaks Richtung LOW, was bzgl. der Peaks vielleicht auf einen defekten DL257 hindeutet.



Ursache für das HIGH ist, daß die beiden Eingänge Pin13/14 gar nicht mit Masse verbunden sind, sondern frei hängen. Also auch ein Layoutfehler gegenüber dem Schaltplan. Nachdem dann Masse drangelegt war, lag der Ausgang 3 ruhig auf LOW.
Im Anschluß habe ich mir Pin 10 und 11 angesehen, was die Eingänge für den Ausgang Pin 9 sind. Hier liegt /FWR bzw. /KWR an. So richtig gut sehen diese Signale auch nicht aus:


/FWR

/KWR

Da ich die Vermutung habe, daß die ganz oben genannten Peaks vielleicht der Auslöser der Probleme sind, folgende Frage: sind die Signale von /FWR (WR vom D004) und /KWR (WR vom D001) schon so schlecht, daß solche Peaks generiert werden könnten oder ist der DL257 ggf. defekt? Hat da jemand Erfahrung?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 16.11.2013 um 21:01 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
093
17.11.2013, 19:36 Uhr
Lötspitze



Habe nun den D411 (DL257) gesockelt und einen anderen IC drin. Die Peaks sind geblieben. Sie entsprechen in ihrer Lage dem Signal G1_MUX, was an Pin 1 der DL257 anliegt.
Anschließend hatte ich versucht, mit jeweils 2k2 gegen 5V auf Pin 9, 10 und 11 den Signalpegel etwas anzuheben, damit die Peaks nicht bis in den LOW-Bereich kommen. Das hat aber auch nichts gebracht. Die Fehler bleiben.
Die anderen beiden DL257 (D409/D410) zeigen diese Peaks nicht. Allerdings liegen dort an allen Eingängen die Adressen, die HIGH-aktiv sind.
Leider kann ich nicht einschätzen, ob ich hier auf dem richtigen Weg bin.
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
094
17.11.2013, 22:16 Uhr
Lötspitze




Zitat:
ManfredB schrieb
Darauf hin habe ich mal etwas experimentiert. Wenn ich ein Modul in den Modulschacht 08 stecke, tritt der Fehler nicht auf.

Das habe ich jetzt ebenfalls mal getestet und nun treten auch bei mir die Fehler nicht mehr auf. Also dürfte die Ursache bei der Bustreiberplatine des D001 liegen, oder?

Edit: Wieder mal zu früh gefreut Beim Rumprobieren hat er sich wieder "verschluckt". Sch...!
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 17.11.2013 um 22:54 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
095
17.11.2013, 23:02 Uhr
Enrico
Default Group and Edit


Du scheinst Probleme zu haben, die es bis jetzt noch nicht gab.
Bei mir tritt so ein Fehler natürlich nicht auf.
Ich musste dazu erstmal die org. Tastatur wiederfinden.

Die Schächte im KC sind übrigens komplett ungetrieben.
Lt. Blockschaltplan trifft das auch auf das Expansionsinterface zu.

Wenn es daran liegen sollte, müsste der Fehler also in einer D002 oder
in der D004 und dort auf der Modulschachtplatine liegen.
--
MFG
Enrico

Dieser Beitrag wurde am 17.11.2013 um 23:03 Uhr von Enrico editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
096
19.11.2013, 22:23 Uhr
Lötspitze



Habe mir jetzt noch einmal die Spannungsversorgung beider Geräte angesehen. Wenn man sie separat betreibt, sind die +5V und Masse ordentlich geglättet. Sobald D001 und D004 aber über den Device Connector verbunden werden, gibt es Unruhe:



Ist das normal, oder sollte man hier tiefgehender prüfen, wo das herkommt?

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 19.11.2013 um 22:25 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
097
20.11.2013, 00:01 Uhr
Enrico
Default Group and Edit


Du hast 1V/T?
Dann wären das ja fast +-1V.
Das wäre schon etwas viel.

Kannzwar gerade kein Oszi ranhängen, wenn ich aber mit dem DMM die Restwechselspannung messe, habe ich da im Modulschacht der D004 nur wenige mV. Allerdings steckt bei mir auch noch der Bustreiber dazwischen.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
098
20.11.2013, 15:11 Uhr
Lötspitze



Möchte meine Anfrage aus 084 noch einmal "aufwärmen" bzgl. dem UTool-Image. Weiterhin würde mich ein dsk-Image mit einer Demo o.ä. interessieren, wo der KC mal richtig gefordert wird und auf die Disk zugreifen muß.

Inzwischen habe ich meine 2,2k aus 093 wieder am D411 (DL257) dran und außerdem die +5V sowie die Masse bei beiden Geräten noch einmal separat vom Netzteilstecker auf die Platine gezogen, wo die Expansions-Interfaces dran sind. Dem D004 habe ich zwei zusätzliche Kondensatoren spendiert. Es hängen nun in Summe 3 Module in den Schächten. So läuft das schon relativ stabil mit seltenen Aussetzern. Ich lasse die Geräte jetzt mal durchlaufen und versuche, sie ab und zu ein bischen aus dem Takt zu bringen. Mal sehen, wie das Verhalten ist.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
099
24.11.2013, 11:55 Uhr
ManfredB



Ergänzung zu 087:

Ich habe inzwischen in mein D004 den neuen Eprom mit Version 3.3 eingebaut. Das Problem mit den selbständigen Tastatureingaben besteht weiterhin (nach dem bisher hier Geschriebenen hatte ich aber auch nichts anderes erwartet). Auch ein "dazwischengeschalteter" Busdriver bringt keine Änderung.

Da für mich weiterhin die Frage offen ist, ob es am D001 oder D004 liegt, habe ich jetzt mal den KC85/5 aus meinem ersten System (in dem dieser Fehler nie auftrat) mit dem "neuen" D004 verbunden. Ergebnis: der Fehler tritt nicht auf.

Wenn ich den "neuen" KC85/5 in mein erstes System integriere, tritt der Fehler ebenfalls auf. Allerdings in der Form, dass das sich nur C0> immer wiederholt. Wenn ich ein Modul im Grundgerät stecke, läuft wieder alles tadellos.

Zusammenfassend kann ich sagen, dass der Fehler mit den selbständigen Tastatureingaben bei mir nur mit einem KC 85/5 auftritt mit einem anderen KC85/5 und einem KC85/4 nicht. Daher würde ich weiterhin vermuten, dass der verwendete Rechner eine entscheidende Rolle spielt.

Dieser Beitrag wurde am 24.11.2013 um 12:39 Uhr von ManfredB editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
100
24.11.2013, 12:22 Uhr
Alwin

Avatar von Alwin

ich hatte das Problem auch mal an einem KC85/5. damals ohne GIDE ging alles normal, GIDE dazwischengesteckt und eigenständige Eingaben.
da an dem KC85/5 der Sound über den TV-RGB nicht ging, habe ich die MOdulleiterplatte gewechselt und seitdem kommen auch mit gestecktem GIDE keine unfreiwilligen Eingaben mehr.
aber Matthias hatte ja schon einen anderen KC85 probiert gehabt.
--
...Z1013, KC87, KC85/5, KC Compact, C64
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
101
24.11.2013, 12:50 Uhr
ManfredB



So, jetzt wird es lustig...

Nachdem ich mein normales System wieder zusammengebaut habe, tritt der Fehler ohne Module jetzt auch hier auf: "C0>" wiederholt sich. Mit Modulen ist aber alles ok. Da ich dieses System nie ohne Module betreibe (bisher hatte ich mindestens das M003 wegen der Tastatur drin), ist mir der Fehler wahrscheinlich nie aufgefallen. Vermutlich wäre er auch weiterhin unentdeckt geblieben, wenn ich jetzt nicht das Tastaturinterface von DL benutzen würde. Damit ist ja kein M003 mehr nötig.

Vielleicht versucht ja mal noch wer, den KC mit D004 ohne Module zu betreiben (das GIDE scheidet meiner Meinung nach als Fehlerquelle aus, da in meinem zweiten D004 das GIDE Interface ja noch gar nicht eingebaut ist). Wäre ja mal interessant, ob das nur seltene Fälle sind (Bauteiltoleranzen o.ä.) oder ein generelles Problem. Wenn ich mal Alwin dazunehme sind es schon mindestens 5 Leute bei denen das Problem auftritt (bzw. auftrat).

Gruß
Manfred

Dieser Beitrag wurde am 24.11.2013 um 12:57 Uhr von ManfredB editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
102
24.11.2013, 14:02 Uhr
Enrico
Default Group and Edit



Zitat:
ManfredB schrieb
...

Vielleicht versucht ja mal noch wer, den KC mit D004 ohne Module zu betreiben (das GIDE scheidet meiner Meinung nach als Fehlerquelle aus, da in meinem
...
Gruß
Manfred

Das funktioniert.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
103
26.11.2013, 20:06 Uhr
Lötspitze



Habe jetzt mein GIDE wieder eingebaut. Der Systemstart funktioniert gut. Nur ab und zu kommt ein BDOS-Fehler auf A: bzw. der Prompt erscheint nicht und ich muß noch einmal RESET drücken.
Nach einer gewissen Warmlaufphase des KC gibt es aber weiterhin die Probleme mit dem Eigenleben (die ersten paar Minuten läuft er dagegen im ML-DOS gut). Das ähnelt dem Hinweis von Robbi in 061 bzgl. dem thermischen Problem, nur anders herum.

Besteht die Möglichkeit, daß über die Tastatursteuerung der PIO (D006) Fehlimpulse ausgelöst werden können, die dann zu diesem chaotischen Verhalten in Verbindung mit dem D004 führen? Über die Tastatur erfolgt ja mit ENTER z.B. auch der Start der Befehlsabarbeitung. Vielleicht gibt es da einen Zusammenhang. Ggf. hat das auch Einfluß auf den von Maleuma in 091 genannten Ringpuffer im Koppel-Ram. Kennt sich einer mit diesen Funktionalitäten aus?

VG Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
104
26.11.2013, 20:36 Uhr
susowa




Zitat:
Lötspitze schrieb
Besteht die Möglichkeit, daß über die Tastatursteuerung der PIO (D006) Fehlimpulse ausgelöst werden können, die dann zu diesem chaotischen Verhalten in Verbindung mit dem D004 führen?

Das kannst Du leicht selbst prüfen, indem Du das System unverändert im CAOS-Mode betreibst. Wenn sich im CAOS-Menü ähnliche Effekte ergeben, liegt das Problem bereits im D001 vor.
Wenn nicht, so wie von Mario beschrieben. Das Programm, welches im D004 läuft, wird durch die genannten Effekte quasi an der Nase herumgeführt.

MfG
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
105
05.12.2013, 10:42 Uhr
Lötspitze




Zitat:
maleuma schrieb
Wartet ein Programm im D004 auf eine Tastatureingabe, dann werden diese beiden Zeiger ständig gelesen und verglichen. Wird dann durch einen unsauberen Speicherzugriff im Koppel-RAM der Zeiger falsch gelesen, dann "schnappt" der Puffer über und die letzten 32 Tastatureingaben werden erneut aus dem Puffer geholt.

@Maleuma, könntest Du (oder gern auch ein anderer) mir vielleicht eine Signalleitung nennen, auf der normalerweise Ruhe ist, wenn der Prompt nach Abarbeitung einer Eingabe erschienen ist und die etwas mit der Koppelramfreischaltung zu tun hat. Vielleicht kann ich dann dort ein Fehlersignal orten und es dann rückverfolgen. Ansonsten würden mich alle notwendigen Signalleitungen zur Koppelramfreigabe interessieren, die zu Deinem genannten Koppelramzugriff bzgl. Vergleich der Zeiger führen. Meine Hoffnung ist, hier etwas ungewöhnliches im Signalbild zu erkennen. Besten Dank schon mal.

Da der KC jetzt mit einem anderen D004 problemlos funktioniert hat, konzentriere ich mich bei der Fehlersuche wieder auf´s D004.

VG Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 05.12.2013 um 10:56 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
106
05.12.2013, 21:54 Uhr
Lötspitze



Kann mir jemand für das D004 erklären, was die Leitung 153 = /80H für eine Bedeutung hat (Schaltplan von Robbi Seite 5 Feld D2)? Bei Tastatureingaben und Floppyaktivität tut sich da was in Richtung LOW. Allerdings habe ich auch ohne Tastatur und Floppy einen sehr feinen kontinuierlichen Nadelimpuls bis auf LOW auf dieser Leitung. In dem Moment, wo der KC anfängt zu spinnen, kommen wieder die breiteren LOW-Impulse.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
107
05.12.2013, 22:33 Uhr
Enrico
Default Group and Edit


Das ist vom KC- Bus.
Die Module werden alle auf der gleichen Basis-I/O-Adresse geschaltet.
das ist diese 80h. Der H Teil ist dann Abhängig auf vom Aufsatzgerät und Schacht. Also 16 Bit I/O-Adresse.
Siehe auch das HB vom M005 User.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
108
08.12.2013, 11:28 Uhr
Lötspitze



Ich denke, es gibt eine neue Spur. Und zwar ändert sich Leitung FD3 nach der Programmabarbeitung häufig von einem normalen Peak in einen Nadelimpuls. Alle anderen Datenleitungen bleiben bei den normalen Peaks.


normaler Peak auf FD3


Nadelimpuls statt Peak auf FD3 und es scheinen auch Takte zu fehlen

Hinzu kommt, daß dieser Nadelimpuls manchmal ganz genau mit dem Fehlimpuls auf der /80H-Leitung zusammenfällt. Ist hier im Bild mit dem /80H-Impuls getriggert:



An FD3 hängen der FDC (D701), ein DL175 (D711), ein dRAM (D609), die CPU (D509), die CTC (D715) und zwei Bustreiber (D414 und D603). Ich könnte mir vorstellen, daß bei diesem Nadelimpuls ggf. ein falsches Datenbit 3 übergeben wird.
Der Bustreiber D603 zieht beim Start mit JU FC die Leitung FD3 ordnungsgemäß nach Masse. An dem sollte es nicht liegen. Und da ich schon zwei unterschiedliche CPU mit dem gleichen n.i.O.-Ergebnis drin hatte, würde ich die CPU auch ausschließen.
Wo bzw. wie sollte man hier weitermachen? Sollte man als erstes D609 wechseln? Kann man den feinen Nadelimpuls auf der /80H-Leitung mit einem Kondensator abpuffern?


VG Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 08.12.2013 um 11:30 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
109
08.12.2013, 12:45 Uhr
maleuma



FD3 ist ein Bit vom Datenbus des D004. Das ändert sich bei der Programmabarbeitung laufend, je nach Befehlscode der gerade abgearbeitet wird.

Genau so schwierig ist es, ein Signal zu benennen, welches beim Warten auf eine Tastatureingabe "still" halten muss.

Hier der Code, bei dem sich der D004-Prozessor in einem solchen Fall gerade aufhält:

Quellcode:
;
; BIOS 3 (Konsoleneingabe)
; PE:    -
; PA:    A    eingegebenes Zeichen
;
CONIN:    LD    HL,INPTR+1    ; Konsoleneingabe
    LD    DE,CIBUFF
RPEING:    LD    A,(HL)        ; D004-Pointer
    DEC    HL
RPE2:    CP    (HL)        ; KC-Pointer gleich?
    JR    Z,RPE2        ; Eingabe abwarten
    ADD    A,E
    LD    E,A        ; Leseposition in Puffer
    INC    A
    INC    HL        ; D004-Zeiger
    AND    1FH        ; nicht über 32
    LD    B,A
    LD    A,(DE)        ; erst Zeichen abholen
    LD    (HL),B        ; dann neuen Pointer ablegen
    RET

Wenn keine Tastatureingabe vorliegt, dann werden ständig die beiden Befehle CP (HL) und JR Z,RPE2 abgearbeitet.
Zwischendurch kommen aber bei MicroDOS auch CTC-Interrupts von der Systemuhr. Bei ML-DOS mit GIDE dagegen nicht.
--
Mario.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
110
08.12.2013, 14:11 Uhr
Lötspitze




Zitat:
Wenn keine Tastatureingabe vorliegt, dann werden ständig die beiden Befehle CP (HL) und JR Z,RPE2 abgearbeitet.
Zwischendurch kommen aber bei MicroDOS auch CTC-Interrupts von der Systemuhr. Bei ML-DOS mit GIDE dagegen nicht.

Das Eigenleben des D004 ist mit MicroDos und ML-DOS identisch. Ich werde aber gleich mal schauen, wie sich die Nadelimpulse verhalten (oben im Beispiel war es unter MicroDos).
Wenn der Rechner in der von Dir genannten Schleife mit den beiden Befehlen steckt und auf Eingaben wartet, sollten in meinen Augen die Peaks aller 8 Datenleitungen annähernd gleich aussehen. Auch FD3 sieht manchmal ordentlich aus (siehe 1. Bild oben). Aber sporadisch wandeln die sich in diese permanenten Nadelimpulse nach Bild 2 um. Ich denke, hier stimmt etwas nicht - die Frage ist nur, wo die Ursache liegt.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
111
08.12.2013, 14:33 Uhr
Lötspitze



Unter ML-DOS treten die Nadelimpulse auf FD3 genauso auf und der Rechner hat sich auch gleich "verschluckt".
Ich würde aus dem Bauch heraus nun den einen dRAM sockeln und wechseln.

Matthias

Edit: in dem Moment, wo man RESET drückt, sind die permanenten Nadelimpulse auf FD3 wieder verschwunden und es kommen die normalen Peaks.
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 08.12.2013 um 15:09 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
112
08.12.2013, 15:27 Uhr
Enrico
Default Group and Edit


Nur anhand von FD3 drauf zu schliessen, dass der D-RAM kaputt ist, kann ich mir nicht vorstellen.

Das wird nur was mit einem Logikanalyser was werden.
Wichtig ist, dass keine Störimpulse am Ende vom Schreib- bzw- Lesezugriff auftreten. Also bei der L/H-Flanke von MREQ.
Dort übernimmt die CPU die Daten, bzw der RAM macht das.
Zu anderen Zeiten ist nicht gesagt, dass dieser Störimpuls die Ursache ist
und wirklich stört.

Die Frage ist acuh noch, was mit Deinem DSO ist.
Kann nämlich sein, dass es Käse anzeigt.
In der jeztigen CT Hardware Hacks ist ein zimlich interessanter Artikel zu Oszis.
Speziell dabei zum Thema Unterabtastung.
Ich habe sowas ja nicht.

Die D004 hat auch noch eine Servicesteckplatz. Ev. bringt es was darüber definierte Programme laufen zu lassen.
EPROM oder ein AVR der den Bus übernimmt.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
113
14.12.2013, 17:59 Uhr
Lötspitze



Noch mal ´ne Frage. Das zum Nadelimpuls veränderte FD3-Signal (rot) verhält sich frequenzseitig z.B. genauso wie der freie Ausgang des D411/Pin12 (DL257), bei dem die Eingänge im Gegensatz zum Schaltplan nicht mit Masse beschaltet sind. Vielleicht ist das ein Anhaltspunkt.



Was könnte die Ursache für dieses Verhalten sein?
Inzwischen habe ich D411 (DL257), D414 (DS8287) und D609 (U2164) gewechselt. Hat bisher keine Veränderungen gebracht.
Zum Start ist immer erst ein normales Signal da und manchmal auch zwischendurch. Wie schon geschrieben, liegt nach RESET auch immer ein normales Signal auf FD3 an. Ansonsten kommen nach einer kurzen Warmlaufphase fast immer diese Nadelimpulse.
Da der UA857 (CTC) z.B. auch mit RESET zurückgesetzt wird und an FD3 hängt, würde ich den als nächstes auswechseln.

Ich bin jetzt an einer Abweichung dran (FD3-Signal), die mir ungewöhnlich erscheint und die reproduzierbar unterschiedlich zu den vergleichbaren Leitungen ist. Hat einer schon mal so etwas gehabt? Was waren denn sonst so die Ursachen für defekte D004?

VG Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 14.12.2013 um 18:08 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
114
14.12.2013, 18:23 Uhr
Enrico
Default Group and Edit


Ich weiss nicht, wie Du bei einer Auflösung von 5 µs auch nur irgendwas erkennen kannst. Ich kanns nicht. Der Takt dauert nur 250 ns.
Das muss kein Nadel- bzw. Störimpuls sein.
Ohne Zusammenhang bringt das auch nicht wirklich viel.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
115
14.12.2013, 19:35 Uhr
Lötspitze



Die Grafik wurde nur gestaucht, damit man gut erkennen kann, daß die Taktgleichheit der Impulse kein einmaliger Zufall ist.
Ansonsten bin ich der Meinung, daß Maleumas Hinweis aus 091 die naheliegendste Erklärung für die Probleme ist. Habe nur rund um die sRAM´s noch keine weitere Ungereimtheit außer FD3 gefunden.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
116
14.12.2013, 20:01 Uhr
Enrico
Default Group and Edit


Du misst aber mit einer Auflösung pro Teil von 5 µs, der Takt hat nur 250 ns.
Das hat doch nichts mit "gestaucht" zu tun.

Zu 91.: kann schon sein. Aber so findest Du nichts, ohne Zusammenhang zu irgend etwas.

Mit dem unbenutzten Ausgang von D411 kann das ja auch kaum was zu tun haben, ist ja auch nicht benutzt. Du kannst ja die Eingänge trotzdem mal auf Masse legen.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
117
14.12.2013, 22:15 Uhr
Lötspitze



Je größer die Auflösung, desto gestauchter die Signale. War der Sinn der Übung, um mehr von den Peaks auf das Bild zu bekommen.

Ich suche eine Ursache für die Veränderung des FD3-Signales und warum es z.B. nach RESET wieder in Ordnung ist. Beim D411 sind die Nadelimpulse weg, wenn man die beiden Eingänge auf Masse legt. Das hatte ich schon gecheckt und nun vermutet, daß sich an der FD3-Leitung an irgendeiner Stelle ein Bauteil ähnlich verhält.
Ob das Ganze wirklich etwas mit den Problemen des D004 zu tun hat, weiß ich nicht.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
118
14.12.2013, 22:50 Uhr
Enrico
Default Group and Edit


Das am D411 kann Dir ja wurscht sein, da es ein unbenutzter Ausgang ist.
dadurch hat sich ja ansonsten nichts geändert, oder?
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
119
14.12.2013, 23:55 Uhr
Lötspitze



Der D411 zeigt, daß ein eingangsseitig nicht beschalteter IC am Ausgang solche Nadelimpulse erzeugen kann - mehr nicht. Diese kommen hier zeitgleich mit den Impulsen auf FD3. Ursache unklar.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 14.12.2013 um 23:57 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
120
15.12.2013, 01:12 Uhr
Enrico
Default Group and Edit


Schon klar, dass offenen Eingänge ein Problem machen können.
Aber nicht, wenn der Ausgang unbenutzt ist.
Hast Du das schon mal mit Pin 1 G1MUX verglichen?
Sollte aber auch wurscht sein, und bringt auch nicht wirklich neue Erkenntnisse.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
121
15.12.2013, 13:59 Uhr
Enrico
Default Group and Edit


Bei meiner D004 sind bei D411 die Eingänge auch offen.

Bei J FC FF kommen beim Koppel-RAM Test bei Pin 12 keine Pulse raus,
beim D-RAM-Test dagegen schon.

Wie gesagt, hat nix damit zu tun, kann ja auch nicht.
--
MFG
Enrico

Dieser Beitrag wurde am 15.12.2013 um 13:59 Uhr von Enrico editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
122
15.12.2013, 14:51 Uhr
Lötspitze




Zitat:
Bei J FC FF kommen beim Koppel-RAM Test bei Pin 12 keine Pulse raus,
beim D-RAM-Test dagegen schon.

Pin 9 des D411 verhält sich aber genauso. Das heißt, während des dRAM-Tests kommen dort falsche Impulse auf die /WE-Leitung für die sRAM. Die sRAM erhalten auf Pin 8 permanent ein /CS-Signal (rot). Dieses überdeckt sich mit den Fehlimpulsen (blau):



Ich könnte mir schon vorstellen, daß das ab und zu zur falschen Datenübernahme durch die sRAM führt und entsprechend 091 zur erneuten Abarbeitung des Ringpuffers.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
123
15.12.2013, 15:30 Uhr
Enrico
Default Group and Edit


Da muss sich ja auch was tun, da das auf die Adresse des S-RAMs geht.
Wie ich schon sagte, ohne Zusammenhang zu den Steuersignalen, bringt das nicht wirklich viel.

Da liegt doch gar nicht permanent /CS an.
Das sind Impulse. Das muss auch so sein, da die CPU der D004 aus dem Koppel-RAM herraus das Programm ab arbeitet und von den dort aus den D-RAM schreibt und liest.
Ausserdem greift auch noch der KC zeitlich versetzt auf den K-RAM zu.
Der macht ja die Anzeige.
--
MFG
Enrico

Dieser Beitrag wurde am 15.12.2013 um 15:30 Uhr von Enrico editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
124
02.01.2014, 10:25 Uhr
Lötspitze



Die Impulse aus 122 habe ich mit 1n an Pin1 des D411 gegen +5V wegbekommen; waren aber nicht die Ursache für meine Probleme mit dem D004.
Beim Test mit der Datei D004IN27.KCC zeigte sich nun ein reproduzierbares Ergebnis mit dem Unterprogramm KLOP. Wenn ich das Programm mit kaltem Rechner starte, wird das Zählprogramm korrekt in den K-RAM geladen und nur auf Adresse FC10h ändern sich die Bytes. Alle anderen Zellen sind NULL, wie es sein soll. Nach einer Weile fängt es aber damit an, daß sich auch andere Adressen in der Zeile FC1x sporadisch ändern (das hatte ich unter 032 schon mal erwähnt). Es betrifft Adresse FC11, 12, 14, 15, 18, 19, 1C und 1D. Das sieht dann so aus:



Beim Warmlaufen erscheint meist in allen (falschen) Zellen zuerst eine "08".
Nun hatte ich ja auch dRAM-Fehler beim Test JU FC FF auf F41x. Sieht da einer von Euch einen Zusammenhang, da es hier auch xx1x betraf?
Wird beim KLOP-Test auch mit dem dRAM gearbeitet, oder ist der dort nicht aktiv und ich kann mich bei der Fehlersuche weiter auf den sRAM konzentrieren? Zur Zeit spiele mich mit dem Gedanken, die sRAM auszutauschen, möchte aber vorab gern noch mal Eure Meinung hören.
Ich will das Ding vor´m nächsten Jahreswechsel laufen haben .

VG Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.

Dieser Beitrag wurde am 02.01.2014 um 10:29 Uhr von Lötspitze editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
125
02.01.2014, 11:35 Uhr
Buebchen



Hallo!
Zu 120
Es ist ein weit verbreiteter Irrtum das ein Schaltkreis dessen Ein und Ausgänge nicht beschaltet sind keine Auswirkung auf das Gesamtsystem haben kann. Über die gemeinsame Spannungsversorgung des Chips kann eine Kopplung auf weitere Gatter des Chips erfolgen. Meist sind die entstehenden Störnadeln bei ausreichender Abblockung des Chips nicht störend. Es kann aber auch zu den auftretenden Beeinflussungen kommen. Deshalb sollten unbenutzte Eingänge in jedem Fall auf ein festes Potential gelegt werden auch bei nicht verwendetem Ausgang. 74LS und HCT Schaltkreise sind dafür besonders anfällig. Diese Nadeln entstehen wenn das Potential an dem unbeschalteten Eingang in den Übergangsbereich zwischen High und Low driftet. Das kann durch statische Einkopplungen erfolgen. Die im Chip entstehenden Nadeln sind meist so kurz (um 1nsec) das sie an den Anderen Gattern mit normalen Messmitteln nicht festzustellen sind aber weil sie bei entsprechenden Eingangspegeln Störungen besonders in Flip-Flops und RAMs erzeugen können durchaus sehr unangenehm und die Ursachen schwer zu finden.
Oft werden dann wegen der Auswirkungen eigentlich intakte Schaltkreise als Ursache ausgewechselt, die aber nur unter der Wirkung dieser Störimpulse falsch funktionieren.

Dieser Beitrag wurde am 03.01.2014 um 11:18 Uhr von Buebchen editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
126
02.01.2014, 12:48 Uhr
Rüdiger
Administrator



Zitat:
Lötspitze schrieb
Zur Zeit spiele mich mit dem Gedanken, die sRAM auszutauschen, möchte aber vorab gern noch mal Eure Meinung hören.

Ich hatte schon andere Geräte, bei denen sich der SRAM-Inhalt von selbst geändert hatte. Ursache waren immer die RAMs selbst.
Alle RAMs zu wechseln ist nicht sinnvoll. Die Kunst besteht also darin, herauszufinden, welcher genau kaputt ist.
--
Kernel panic: Out of swap space.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
127
02.01.2014, 14:05 Uhr
meikel

Avatar von meikel


Zitat:
Rüdiger schrieb
Die Kunst besteht also darin, herauszufinden, welcher genau kaputt ist.

Wenn Du Pech hast, isses der Letzte.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
128
02.01.2014, 14:14 Uhr
Rüdiger
Administrator



Zitat:
meikel schrieb
Wenn Du Pech hast, isses der Letzte.

In den meisten Fällen lässt sich durch das Schreiben und Gegenlesen von Prüfmustern eingrenzen, wo der Fehler steckt.

Ich hatte kürzlich einen AC1 repariert mit 32 SRAM-Chips drin, von denen immerhin 6 Stück kaputt waren.
--
Kernel panic: Out of swap space.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
129
02.01.2014, 16:04 Uhr
meikel

Avatar von meikel


Zitat:
Rüdiger schrieb

Zitat:
meikel schrieb
Wenn Du Pech hast, isses der Letzte.

In den meisten Fällen lässt sich durch das Schreiben und Gegenlesen von Prüfmustern eingrenzen, wo der Fehler steckt.

Wenn ein Bauteil einer Gruppe aus derselben Schachtel ausfällt, isses höchst unwahrscheinlich, daß die restlichen 31 Käfer nochmal 30 Jahre länger leben.

Zitat:
Ich hatte kürzlich einen AC1 repariert mit 32 SRAM-Chips drin, von denen immerhin 6 Stück kaputt waren.

Rechne doch mal so:
4 Speicherbänke mit jeweils 64kbit dRAM => 4 * 8 = 32
Dazu kommt mit Sicherheit noch ein Sack voll Beifang -> Adreßmultiplexer und Bussteuerung. Und das alles kannste mit einem lausigen Chip erledigen.
http://www.reichelt.de/DRAM-FRAM-SRAM/628512-55/3/index.html?&ACTION=3&LA=2&ARTICLE=40088&GROUPID=2954&artnr=628512-55

Der 628512 beinhaltet 512 kbyte (256er ham die gerade nicht) und braucht gerade mal 55ns...
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
130
02.01.2014, 17:20 Uhr
Lötspitze




Zitat:
Die Kunst besteht also darin, herauszufinden, welcher genau kaputt ist.

Da es immer die rechte Bytehälfte ist, würde ich den D412 vermuten, der Datenbit D0-D3 erzeugt. Den werde ich wechseln.
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
131
02.01.2014, 18:02 Uhr
Rüdiger
Administrator



Zitat:
meikel schrieb
Und das alles kannste mit einem lausigen Chip erledigen.

Sogar ohne Chip: mit dem Emulator auf dem Smartphone.
Mit geht es aber darum, ein historisches Gerät originalgetreu zu restaurieren.
--
Kernel panic: Out of swap space.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
132
02.01.2014, 18:33 Uhr
Enrico
Default Group and Edit


Bei mir stehen auf FC00-FC06 feste Werte.
Lt. Doku ist das auf der FC10 der Schleifenzähler.

DLOP soll das für den D-RAM sein.
Es wäre ja nicht sinnvoll, wenn des Testprogram was anderes macht, als in der Doku steht.
--
MFG
Enrico

Dieser Beitrag wurde am 02.01.2014 um 18:49 Uhr von Enrico editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
133
02.01.2014, 21:35 Uhr
Lötspitze



Es war der D412 - das D004 läuft jetzt 1A!
Habe über die Floppy soeben problemlos alle Dateien auf das DOM LW C: neu aufgespielt und vom USB-Stick einige größere Dateien fehlerfrei nachgeladen.
Letztendlich war es die Bildschirmanzeige im KLOP, die mich auf den Fehler gebracht hat.
Besten Dank an alle, die mir hier Tips gegeben haben.

Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
134
02.01.2014, 21:39 Uhr
Alwin

Avatar von Alwin


Zitat:
Lötspitze schrieb
Es war der D412 - das D004 läuft jetzt 1A!
Habe über die Floppy soeben problemlos alle Dateien auf das DOM LW C: neu aufgespielt und vom USB-Stick einige größere Dateien fehlerfrei nachgeladen.
Letztendlich war es die Bildschirmanzeige im KLOP, die mich auf den Fehler gebracht hat.
Besten Dank an alle, die mir hier Tips gegeben haben.

Matthias

Glückwunsch und das vor Jahresende.
--
...Z1013, KC87, KC85/5, KC Compact, C64
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
135
03.01.2014, 10:45 Uhr
Henning




Zitat:
Ralph schrieb
Da ja mein D004 auf dem letzten KC-Treffen die Arbeit verweigert habe, such ich hier nun Unterstützung bei der Fehlersuche. Dazu suche ich..
1. Ein Software-Diagnosetool vom KC aus (nicht J FC FF)
2. Den Stromlaufplan für das D004
3. Tipps auf was ich achten muss, bzw. welchen Fallen es gibt.

Mein Problem ist, dass seit dem Umbau auf den aktuellen EPROM eine Fehlermeldung kommt, die besagt, dass das Koppelram SteuerProgramm defekt ist.

Danke an alle die mir helfen können.. und es auch tun :-)




Gruß Ralph

Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
136
03.01.2014, 10:51 Uhr
Henning



Hallo Ralph und alle KC- User,

ich möchte euch allen noch ein gesundes, glückliches und erfolgreiches Neues Jahr 2014 wünschen.

Ja, Ralph, bei Deinem Problem am D004 kann ich als Nicht ! Hardwareexperte Dir leider nicht helfen. Zum Glück funktioniert mein D004 noch sehr gut.
Deshalb habe ich derzeit auch (noch) keinen Bedarf an D008. Ich habe mitbekommen, dass die Entwicklung am D008 eingestellt worden ist. Ich habe aber wohl verpasst, was hierfür der Grund ist. Kannst Du mir den kurz nennen ?

Im voraus besten Dank.

Mit freundlichem Gruss

Henning.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
137
03.01.2014, 11:47 Uhr
ManfredB



@ Lötspitze:

Tritt nach deiner Reparatur (D412)der Fehler mit den sich wiederholenden Tastatureingaben auch nicht mehr auf?

Gruß Manfred
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
138
03.01.2014, 12:04 Uhr
Lötspitze



Hallo Manfred,

ja, dieses Eigenleben gibt´s nicht mehr.

VG Matthias
--
___________________
...geboren, um zu löten.

Wer rennen soll, muß auch mal stolpern dürfen.
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