Problem mit GIDE-Festplatteninterface am mc-CP/M-Computer

  • Hallo zusammen,


    Ich habe hier einen mc-CP/M-Computer, der mir ein paar Sorgen macht. Das Ding ist seit den frühen achtzigern eigentlich dauernd in Betrieb, allerdings ist vor einem Jahr ein Problem aufgetreten, daß ich einfach nicht eingrenzen kann.


    Leider ist der Computer nicht exakt nach den mc-Bauvorlagen gebaut, sondern von verschiedenen Herstellern (SYS1 als CPU von GES, FDC3 von Dobert&Bitsch, der

    Rest ist eine Eigenentwicklung. 2001 habe ich von Tillmann Reh die GIDE-Platine erworben und dazu gebaut. Das BIOS dazu mußte ich selbst schreiben, um schließlich ZS-DOS zum Laufen zu bringen. Da auf dem EPROM im Monitor natürlich keine Funktion enthalten ist, von der Festplatte zu booten, lädt der Rechner das Betriebssystem

    von der Diskette, zusammen mit dem BIOS für die Festplatte. Ab dann kann er den CCP beim Warmstart direkt von der Festplatte laden.


    Aber genau diese GIDE-Platine macht jetzt Ärger, vermute ich. Vor einem Jahr habe ich mir nämlich meine Boot-Diskette geschrottet. Die ist wohl einfach nach 10 Jahren an Altersschwäche hops gegangen. Ganz geschickterweise war das tatsächlich die einzige Boot-Diskette, die ich hatte. Ich habe zwar noch mehr, aber die paßten nicht zu dem CCP auf der Festplatte. (Ich habe von den Boot-Disketten natürlich noch den Assembler-Code, das kriege ich alles wieder hin..)


    Im Folgenden gelang es mir aber nicht mehr, den CCP auf die Festplatte zu schreiben. Wenn ZS-DOS einmal hochgefahren ist, hängt sich das System nach einem Warmstart

    immer auf. Ich habe dann rausgefunden, daß das, was ich von der Festplatte wieder auslese, nicht ganz mit dem, was geschrieben worden ist, übereinstimmt.


    Also dachte ich, daß die Festplatte hinüber ist und habe eine andere eingebaut. Interessanterweise zeigt die genau das gleiche Problem. Wenn ich auf die Platte schreibe, ist das nachher gelesene teilweise unterschiedlich.


    Die alte Platte, die ich dann wieder eingebaut habe, kann ich übrigens vollständig lesen. Die Fehler scheinen also beim Schreiben zu passieren, nicht beim Lesen.


    Jetzt habe ich mir die Fehler mal ganz genau angesehen und ein Programm geschrieben, daß die geschriebenen mit den gelesenen Sektoren vergleicht (siehe Bilder). Das obere

    ist das Soll-Feld, das untere das Ist-Feld. Die hellen Stellen sind unterschiedliche Bytes. Interessanterweise sind es immer nur einzelne Bytes, die fehlerhaft sind. Und immer werden sie zu 00! Und sie kommen oft nach C3- oder CD-Bytes! Je nachdem wie oft ich schreibe, werden es auch schonmal unterschiedliche Bytes, die sich ändern. Ca. die Hälfte der Sektoren ist auch vollkommen korrekt.


    Kann sich da jemand einen Reim drauf machen? Das IDE-Kabel habe ich schon gewechselt, ansonsten ist an der Kiste seit 10 Jahren nichts geändert worden. Mir ist das höchst

    rätselhaft...


    Beste Grüße,


    Thomas

  • Hallo,


    danke für die Antworten. Was genau sollte ich denn beim GIDETEST laufen lassen? Das Programm hat ja so einige Funktionen..

    Meint Ihr wirklich, daß es da ein Gatter oder so erwischt hat? Hab' ich bisher noch nie erlebt, daß da ein einziges ausfällt. Auf den ersten Blick hatte ich eher an so ein Timing-Problem gedacht, sowas wie: CPU schreibt schneller Daten als der GIDE zur Festplatte schickt. Nur wäre das nach all der Zeit merkwürdig, wenn das jetzt erst auftritt.

    Als ich damals das BIOS für die Kiste angepaßt habe, konnte ich auf jeden Fall nicht den BIOS-Code, der von Tillmann Reh für das GIDE vorgeschlagen wurde, verwenden. Ich mußte einige NOP-Schleifen einbauen, sonst wurden immer ein paar Zeichen verloren...

    Kalte Lötstellen und die Bauteile sehe ich mir bei Gelegenheit mal an...


    Schönen Sonntag noch,


    Thomas

  • Genau, Bilder wären gut und auch von der SYS1 ... und ein paar weitere Daten zur Konfiguration!


    Würde einfach mal mit dem Lesetest beginnen, also (4) Read disk linear.


    PS: Wenn es bereits am Anfang Timing-Probleme gab, ist da etwas grundlegend im Argen bzw. nicht optimal.

    Durch Bauteilealterung kann sich der Effekt noch verstärken!


    Gruß

    Alfred

  • Hallo zusammen,


    also, ich glaube nicht, daß das die gleiche wie vom KC85 ist. Meine ist ja mit ECB-Bus-Anschluß und sieht so aus:



    die CPU-Platine ist diese hier:


    (ich hab's mal so gedreht, daß man die Beschriftungen lesen kann). Als CPU ist eine Z80B eingebaut und der Quarz hat 10 MHz. Das ganze hat ja wie gesagt, so schon 20 Jahre lang funktioniert.

    Es könnte natürlich sein, daß da irgendeine kalte Lötstelle ist. Ich werde mich die Tage mal dranbegeben.

    Mit dem Timing-Problem war ich mir seinerzeit auch schon unsicher. Damals gab's ja praktisch kein Internet, sodaß ich keinen Fragen konnte, wie ich das BIOS umschreibe. Also habe ich solange rumprobiert, bis es ging. Ich habe vom GIDE-BIOS, das dabei war, auch nur ein paar Zeilen geändert:


    hier das Original:

  • Hallo Fritz,


    danke für die Link-Liste. Die kannte ich noch nicht. Ich dachte immer, das Ding hieße GIDE, weil ich damals die Software dazubekommen habe, die so hieß. Das deutsche Handbuch habe ich hier aber schon.

    Ich habe die Bauteile alle überprüft, die passen alle. Und mit dem Blitz habe ich es schon probiert, das sah auch nicht besser aus. Da muß ein Scheinwerfer her...

    Ich probiere die Tage mal das GIDETEST-Progrmm, dann weiß ich mit dem Timing-Problem vielleicht mehr..


    Thomas

  • Ich hatte in 1992 die CPU280 auch aufgebaut weshalb ich etwas über das System weiss.

    Das erste Treffen hatten wir 1990, ich habe die IDE Karte aber nur an der CPU280 genutzt.


    Ich denke aber auch dass wir dein Problem beheben können.

  • Hallo,


    gerade habe ich mal einen Test mit GIDETEST gemacht. Das funktionierte tatsächlich genausowenig: GIDETEST schreibt ja die ganze Platte mit Zufalls-Bytes voll und prüft, ob das Ergebis nach dem Lesen wieder das gleiche ist. Das ist tatsächlich auch nicht der Fall, manche Bytes werden wieder 00h! Wieder interessant: der Programmpunkt "write/read test linear" schreibt bei mir nur "#"-Zeichen auf die Platte und prüft, ob die richtig geschrieben wurden. Das funktioniert. Irgendwie scheint mir der Fehler von den vorauseilenden Bytes abhängig zu sein.


    Ich habe mir mal die Dokus angesehen. Die IDE-Platine ist ja wohl für das Z280-System gebaut zu sein. Ich habe ja eine normale Z80-CPU. Außerdem habe ich ja diesen ominösen 10 MHz-Quarz eingebaut. Kann das damit zusammenhängen? Ist das Taktsignal auf dem Bus vielleicht nicht passend für die IDE-Platine?

    Möglicherweise habe die einfach immer total am Limit betrieben und durch Materialalterung kracht es jetzt, weil das Ding jetzt einfach eine Grenze überschritten hat. Es ist auch nicht so, daß ich nie mal fehlerhafte Daten auf der Platte hatte; es kam durchaus ab und an mal vor, daß es die ein oder andere Datei zerschossen hat.


    Beste Grüße,


    Thomas

  • Hallo Thomas,


    warten wir mal ab, bis Fritz sich meldet.


    Vermute aber, daß es an deinem 10-Mhz Quarz nicht liegen kann, sind ja nur 5-Mhz für den Z80,

    also im Verhältnis eher etwas zu langsam.


    Die SYS1 funktioniert mit 'F'-Bausteinen, 120ns Ram's und 200ns Eprom auch mit 14-Mhz Quarz stabil.

    Es gibt also noch Luft nach oben ;-)!


    Gruß

    Alfred

  • Moin Thomas,


    das riecht eher nach einem zu stark gealtertem Chip z.B. wie dem 74ls245 oder 74ls375, die zu lang brauchen, um ein Datenwort zwischen zu speichern. Die Aussage von dir mit dem "#"-Testmuster hat mich auf diese Vermutung gebracht. Hast du einen RCT? Dann prüfe doch mal die ICs, wenn sie gesockelt sind.



    Norbert

  • Wenn die ICs zu lang brauchen, um die Pegel mit zu bekommen (die Daten werden bei einer Taktflanke oder Pegel übernommen), dann sollte der RCT das mitbekommen, wenn das Datenwort falsch gespeichert wird, unabhängig davon, wie viel Nanosekunden der Prüfling hat. Der Chip kann ja auch einen Bit-Fehler aufweisen, der sich mit dem "#"-Testzeichen nicht finden lässt.


    Alternativ könnte man (wenn der Gide-Test es zulässt) mit dem Kmplementär-Zeichen testen...

    • Official Post

    IDETEST schreibt ja die ganze Platte mit Zufalls-Bytes voll und prüft, ob das Ergebis nach dem Lesen wieder das gleiche ist.

    Weisst du denn ob falsch geschrieben oder falsch gelesen wird?

    Ich wuerde erst mal den Lesetest ergaenzen, das mehrmals der gleiche Sektor gelesen wird und das Ergebnis geprueft wird.

  • Aus meiner Einnerung:

    Da Tilmann damals Probleme mit seine HD hatte wurde zur HD hin ein Filter verbaut um Spikes zu elimieren.

    Anfangs hatte ich eine OMTI5520 verbaut bis Tilmann die IDE-HD fertig hatte.


    Bei mir lief als IDE:

    ;11.02.2005

    ;Toshiba: Model MK1724FCV

    ;default mode CHS 842,16,38


    Auch wenn das direkt nicht weiter hilft aber vielleicht könnte.

    Ich habe aus https://www.retrobrewcomputers…php?t=msg&th=195&start=0& von Lamar Owen noch die Teile

    für 2 HD-IDE Karten, die noch immer nur halb zusammengebaut sind, hier liegen.

    Inzwischen bin ich ja mit CF Karte am Prof unterwegs und meine CPU280 warten wohl noch länger auf Reparatur da mir die Kenntnisse fehlen und corona und so.


    Auch würde ich es mal anstelle HD mit einer CF-Kart testen.

  • Hallo zusammen,


    danke für die Tipps! Aber neue Fragen tun sich auf. Was ist denn ein RCT? Ich muß zugeben, daß ich keinen Schimmer habe, was das ist. Auch eine Google-Suche hilft mir nicht so recht auf die Sprünge...


    Also, ein gealterter Chip könnte es wohl sein, das macht Sinn. Leider finde ich in der Bastelkiste keine der Chips auf dem IDE-Board. Da muß ich wohl eine Bestellung aufgeben. Das Zeug kostet zum Glück ja nix...


    Also, der Fehler tritt ziemlich sicher beim Schreiben auf: wenn ich ein und denselben Sektor immer wieder schreibe, kriege ich beim Lesen immer wieder ein anderes Ergebnis. Wenn ich immer nur wieder Lese, bleibt alles gleich.


    Was mir jetzt aber aufgefallen ist, sieht man auch auf den Fotos, wenn ein Byte falsch geschrieben wurde, wird es beim Lesen immer zu einer 00h. Das darauf folgende Byte ist aber auch immer eine 00h! Das sieht mir jetzt fast schon wieder nach "zu schnell geschrieben" aus.


    ich habe gerade mal das GIDETEST-Programm abgeändert und die einzelnen Bytes ganz langsam übertragen. Da ist das Problem genau das gleiche. Die CPU sendet die Daten also nicht zu schnell.


    Also, ich besorge mir mal ein paar neue ICs, danach kann ich immer noch mal gucken, ob ich das GAL erneuere (das wäre dann auch etwas Neues, das ich lernen müßte...).


    Danke schon mal für die Hilfe,


    Thomas

  • Okay, verstehe. Nee, sowas habe ich nicht.. Ganz sooft bin ich in dieser Materie auch nicht unterwegs, daß ich den dringend brauchen würde..

    Ich hatte mich schon gewundert, daß mir, trotz E-Technik-Ausbildung so ein Begriff komplett an mir vorbeigegangen sollte. Aber den Retro-Chip-Tester hat sicherlich nicht jeder E-Techniker im Keller stehen...


    Thomas

  • Moin,


    ich konnte das Problem lösen! Da der Local-Elektronik-Händler zu weit weg war, um mit dem Fahrrad durch den Sturm zu fahren und außer den ICs auch nichts auf meiner Bestelliste gestanden hat, habe ich mir den Schaltplan nochmal angeguckt. Vielleicht hatte ich ja Glück und ich kann zwei ICs mal tauschen und sehe dann zumindest, wo der Fehler liegt. Auf der Platine sind ja einige doppelt. Und ich hatte tatsächlich Glück: wenn ich IC13 (74HCT244) mit IC2 tausche, läuft die Kiste wieder! Den Zustand kann ich sogar erstmal so lassen, denn das IC13 ist nur für die Centronics-Schnittstelle und die brauche ich sowieso nicht. GIDETEST ist 20 Minuten gelaufen und hat Schreib-/Lesetests gemacht, wobei dort keine Fehler mehr aufgetaucht sind. Auch das ZS-DOS läßt sich wieder in die Systemspuren schreiben und alles andere geht auch wieder.

    Danke Euch für's helfen, ich hätte tatsächlich ein "normales" IC erstmal nicht verdächtigt.


    Schönes Wochenende weiterhin,


    Thomas