Suche 8 Zoll CP/M-Boot-Disketten oder ISIS-II Boot Disketten für Intellec MDS

  • Vielleicht traut sich ja doch der Eine oder die Andere mit Ideen zur Problemlösung.

    Weitergeleitet:


    --------><--- schnipp

    Hallo

    Der widerspenstige Floppy Disk Controller der Firma Lakosa überträgt die Daten von/zur Floppy per DMA (BUSREQ_N/BUSAK_N).

    Der Hauptprozessor bereitet einen I/O-Parameter-Block (7Bytes) im Speicher vor und übergibt dessen Anfangsadresse

    über zwei I/O-Zeilen an den Floppy Disk Controller.

    Der FDC liest und interpretiert den IOPB und überträgt die Daten von/zur Floppy per DMA in den Speicher.

    Der Hauptprozessor pollt ein Status-Register des FDC, um das Ende der Operation festzustellen.

    Nach dem Ende der Operation liest der Hautprozessor zwei Status-Register des FDC, um festzustellen. ob die Operation

    ohne Fehler ausgeführt wurde.

    IOPB und Register-Layout des Lakosa FDC sind kompatibel zum FDC des Intellec MDS Entwicklungssystems für 8080/85, 8086 aus den 70er Jahren.

    Somit kann man das ISIS-II Betriebssystem booten.

    Anfang der 80-er Jahre hatte ich auch eine Floppy, von der ich CP/M booten konnte.


    Es ist ein Monitorprogramm vorhanden, mit dem Speicher angezeigt und verändert werden kann.

    Den Monitor habe ich Ende der 70-er, Anfang der 80-er Jahre durch Aufbohren des Intel MDS Monitors selbst geschrieben.

    Leider existieren die Sourcen und auch die Listings nicht mehr.

    Ich habe den Monitor im letzten Jahr vor Ostern disassembliert und das Ergebnis so lange getunt, bis ich ein bit-genaues Abbild des EPROMs erzielt habe.

    Ich weiss zwar immer noch nicht, genau, wie alle Routinen des Monitors funktionieren, wäre aber theoretisch in der Lage Veränderungen, Verbesserungen vorzunehmen.


    Über den Monitor können Kommandos zum Floppy Disk Controller abgesetzt werden wie SEEK, Format, READ Sector, WRITE Sector.

    Kommandos, wie Format und Seek, welche keine Datenübertragung zwischen Speicher und Floppy erfordern, funktionieren in der Regel.

    Das Lesen und Schreiben einzelner Sektoren bereitet schon mehr Schwierigkeiten.

    Manchmal funktioniert das Lesen eines Sectors einwandfrei, manchmal hängt sich der FDC auf.

    Das häufigste Symptom ist, daß der Motor der Floppy kurz anläuft und das System dann hängt.

    BUSAK_N ist dann low, MREQ_N ist low, WR_N ist low.


    Das Lesen von FD auf Memory Adresse A000 funktioniert besser als das Lesen von FD auf Memory Adresse 4000.

    Das Lesen von FD funktioniert besser, wenn mehr Karten auf dem Bus eingesteckt sind, z.B. Bus Extender.

    Auch funktioniert das Lesen von FD besser wenn 2 Stück 32K SRAM-Karte eingesteckt sind statt einer 128K SRAM-Karte.


    Es deutet vieles auf ein Signal-Integrity- oder ein Timing-Problem hin.


    ISIS-II von Floppy zu booten funktioniert nur in ganz wenigen Fällen.

    Meist hängt sich der FDC auf, mit den oben geschilderten Symptomen.

    Manchmal werden alle erforderlichen Sektoren geladen, ISIS-II Ver. 4.3 gibt seine Meldung aus, stürzt dann aber ab.

    In dem Fall sind vermutlich falsche Daten geladen worden, oder die Daten wurden auf falsche Adressen geschrieben.


    Mir steht ein Tektronix MSO-4054 zur Verfügung.

    Das MSO hat 4 Analoge Kanäle, einen Trigger-Eingang und 16 digitale Kanäle.


    Nachdem mit der Chinesischen Methode (Tausch der Bauteile) nichts auszurichten war, habe ich einige Messungen am ECB-Bus durchgeführt.

    Was ist mir aufgefallen:

    1.

    Der ECB-Bus ist mit einer aktiven Terminierung versehen, 110 Ohm gegen 2,5 Volt.

    Wenn die Signale RD_N, WR_N, MREQ_N weder von der Z80-CPU Karte noch vom FDC getrieben werden, sehe ich einen sehr hohen Ripple auf

    diesen Signalen (Taktfrequenz 8 MHz oder 4 MHz). Die Z80-CPU-Karte läuft mit 8 MHz)

    Ich bin nicht sicher, ob das ein Messfehler ist. Ich greife die Signale von einem Bus Extender ab. Die 2,5 Volt Terminierungsspannung ist sauber.

    2.

    Der FDC kann die RD_N, WR_N, MREQ_N nicht auf den gleichen HIGH-Level treiben wie die Z80 CPU-Karte.

    Ein Austausch der Treiber 74LS244 gegen 74F244 hat keine grundsätzliche Verbesserung gebracht.


    Frage:

    Muss man RFRSH_N in die Adressdekodierung einer Speicherkarte einbeziehen oder kann man darauf verzichten,

    weil beim Refresh WR_N nicht aktiviert wird?


    Ich hänge die Screenshots einiger Messungen an.

    • Offizieller Beitrag

    Ich hab den Thread gar nicht mitgekommen. Ist ja richtig spannend.


    Du hast ja wenigstens ein gutes Messgeraet und gute Messungen gemacht.


    Mich verwirrt das digitale Signal bei WR_N. Welches ist das?

    Bei der V/div Angabe (unten links) steht meist ein Ohm Zeichen und A=Ampere. Was hat das zu sagen? Was misst du da? Steht auch bei den Cursormessungen.



    Wenn die Signale RD_N, WR_N, MREQ_N weder von der Z80-CPU Karte noch vom FDC getrieben werden, sehe ich einen sehr hohen Ripple auf

    diesen Signalen

    Das Ripple sieht nicht schoen aus, wurde mich aber nicht beunruhigen. Uebersprechen gibt es immer, je nach Qualitaet der Backplane mehr oder weniger, aber vor allem bei nicht getriebenen Signalen.


    Ein Austausch der Treiber 74LS244 gegen 74F244 hat keine grundsätzliche Verbesserung gebracht.

    Wuerde ich auch nicht machen bzw. wieder zurueckbauen.

    Desto schneller die Bausteine, desto mehr Stoerungen.


    Wie gross ist der High-Unterschied und auf welchem Screenshot kann man das sehen.

    Wuerde ich mir aber auch keine Sorgen wegen machen. Du hast eine Terminierung, die belastet den High-Pegel Ausgang natuerlich auch. Aber alles ueber 3V ist unkritisch.




    Was mich sehr wundert ist, warum wird der Bus nicht die ganze Zeit getrieben.

    Entweder sollte das die CPU machen (BUSREQ_N/BUSACK_N = 1) oder der DMA-Master (BUSREQ_N/BUSACK_N = 0).

    Woher kommt das Signal MEMTR_N (letzter Screenshot)?

    An den Stellen waere das BUSACK_N Signal sehr interessant.


    Muss man RFRSH_N in die Adressdekodierung einer Speicherkarte einbeziehen oder kann man darauf verzichten,

    weil beim Refresh WR_N nicht aktiviert wird?

    Nein, bloss nicht!

    Dann muesstest du ja fuer jede Speicherkarte einen eigenen Refresh erzeugen.

    Und mit dem WR_N wurdest du ja schreiben.

    Der Refresh wird meistens mit RAS-only gemacht und das kommt aus dem MREQ_N. Also alles gut.


    Also entweder die Speicherkarte macht ihren eigenen Refresh, dann muss sie ggf. das WAIT_N aktivieren koennen, oder sie nimmt den Z80-Refresh mit.

    Beim Z80-Refresh auf jeden Fall auf die DRAMs achten. Bei den 64kbit Typen (z.B. 4164) muessen diese mit einem 7bit Regresh auskommen.


    Viel Erfolg

  • Ich habe inzwischen die Hälfte der ECB-Bus Signale direkt an der DIN41612 Steckleiste des Floppy Disk Controllers

    gemessen ohne dass die ECB-Bus Extender Karte eingeschoben war.

    Die Scope Probe habe ich über ca. 5 cm lange Drähte mit der Scope Probe verbunden.

    Auf diese Weise gemessen sehen die Signale am ECB-Bus recht gut aus.

    Nur bei wenigen ist noch ein wenig des Ripples zu messen, der mich bei meinen früheren Messungen beunruhigt hat.


    Der FDC-Controller kann nach den neuen Messungen die Signale auf den gleichen high-Level, ca. 3,6 Volt, treiben wie die Z80-CPU.


    Der ECB-Bus wird bei meinem System nicht dauernd getrieben. Deshalb ist ein aktiver Bus-Abschluß ganz praktisch.

    Wenn der FDC den IOPB aus dem Speicher liest oder wenn der FDC Daten von/zur Floppy transferiert holt er sich den ECB-Bus,

    den die Z80-CPU dann nicht mehr treibt. Der FDC treibt den ECB-Bus in dieser Phase nur während der

    eigentlichen Datenübertragung.

    Die Bustreiber des FDC für Adressen und Kontrollsignale werden enabled solange das FDC-interne Signal MEMTR_N low ist.

    Deshalb habe ich das Signal MEMTR_N in meine Messungen mit einbezogen.


    Der FDC nimmt den Takt für seine Z80 CPU vom ECB-Bus. Ich war etwas überrascht, zu entdecken, dass der Takt am ECB-Bus nur mit 4 MHz

    läuft. Ich hatte bisher angenommen, dass der ECB-Bus mit dem gleichen Takt läuft wie die CPU-Karte. Das wären in diesem Fall 8 MHz.

    Ich glaube, die 4 MHz sind ein Erfordernis des FDC. Würde der Takt schneller laufen würden vermutlich einige Zeitschleifen des FDC nicht mehr passen.


    Meine Frage, ob des RFRSH_N Signal in die Adressdekodierung einbezogen werden muß, bezieht sich auf die angehängte Schaltung.

    Ich habe einen Jumper vorgesehen, über den ich auswählen kann, ob das der Fall ist oder nicht.

    In der Praxis ergeben sich keine Unterschiede.


    Das Scope ist ein Tektronix MSO4054 mit 4 analogen Eingängen, einem Triggereingang und 16 digitalen Eingängen.

    Ich habe habe es als defekt bei Ebay ersteigert. Richtig reparieren kann ich es nicht, weil einige Kontakte unter einem hochpoligen Finepitch Stecker abgerissen sind. Ich habe Stecker und Platine auf Spannung montiert. So läuft es zunächst einmal und hält hoffentlich noch länger durch.


    Die Kalibrierung eines Kanals des Oszilloskops in A/Ohm statt in Volt ist ungewollt. Ich weiss nicht, wo man das bei dem Scope umstellen kann.

    • Offizieller Beitrag

    Die Scope Probe habe ich über ca. 5 cm lange Drähte mit der Scope Probe verbunden.

    ??? Rekursive Messung? :)



    Der ECB-Bus wird bei meinem System nicht dauernd getrieben. Deshalb ist ein aktiver Bus-Abschluß ganz praktisch.

    Halb richtig.

    Ohne Bus-Abschluss wurde das System wahrscheinlich gar nicht funktionieren.



    Wenn der FDC den IOPB aus dem Speicher liest oder wenn der FDC Daten von/zur Floppy transferiert holt er sich den ECB-Bus,

    den die Z80-CPU dann nicht mehr treibt. Der FDC treibt den ECB-Bus in dieser Phase nur während der

    eigentlichen Datenübertragung.

    Die Bustreiber des FDC für Adressen und Kontrollsignale werden enabled solange das FDC-interne Signal MEMTR_N low ist.

    Deshalb habe ich das Signal MEMTR_N in meine Messungen mit einbezogen.

    Leider seh ich das Signal MEMTR_N nur im letzten Screenshot.


    Wenn der FDC sich den Bus mit BUSREQ_N und BUSACK_N holt, warum wird der Bus nur waehrend MEMTR_N getrieben?

    Warum haelt der FDC den Bus und macht nur alle 5us eine Datentransfer? In der Zeit kann doch die CPU weitermachen.

    Ich will nicht sagen das ist ein Fehler. Aber macht fuer mich z.Zt. keinen/wenig Sinn.


    Kannst du mal Messungen mit BUSACK_N und MEMTR_N machen/mailen?



    Meine Frage, ob des RFRSH_N Signal in die Adressdekodierung einbezogen werden muß, bezieht sich auf die angehängte Schaltung.

    Ist das die gesamte Schaltung oder nur ein Ausschnitt?

    Falls die gesamte Schaltung: Was willst du mit dem RFSH_N bei einem SRAM?



    Die Kalibrierung eines Kanals des Oszilloskops in A/Ohm statt in Volt ist ungewollt.

    Um die Kalibrierung wird es wohl nicht gehen.

    Aber falsche Einstellungen der Kanaele und/oder Tastkoepfe koennen massive Messfehler ergeben.



    der Takt am ECB-Bus nur mit 4 MHz

    Kannst du bitte mal klaeren, was mit welchem Takt laeuft.

    Auch hier kann es Probleme geben, wenn die CPU schneller laeuft als der ECB.



    Ich denke das reicht fuer heute.

    Viel Erfolg

  • 1. Messung mit 5 cm langen Anschlussdrähten vom Messobjekt zum Tastkopf.


    Ich benutze Tektronix TAP1500 Probes mit 1,5 GHz Bandbreite.


    Die Standard Clips für die aktiven Tastköpfe haben eine Länge von ca. 5 cm.


    Natürlich würde man realistischere Signalverläufe messen, wenn man die Tastköpfe direkt mit dem Messobjekt verbindet.


    Bei einer Taktfrequenz von 8 MHz sollten die 5 cm langen Leitungen aber kein Problem darstellen.




    2. Aktiver Busabschluss.


    Stimmt, ohne Busabschluss würde es nicht funktionieren.




    3. Der ECB-Bus wird nicht immer getrieben, nachdem der FDC sich den Bus geholt hat.


    Das ist halt so. Das Design des FDC kann ich nicht ändern.




    4. Kalibrierung des Oszilloskops.


    Ich habe die Probe jetzt auf V umgestellt. A/Ohm war aber auch kein Problem.




    5. RFRSH_N Signal in die Adressdekodierung einer SRAM-Karte einbeziehen oder nicht.


    Die Schaltung der 128 KB SRAM Karte, die ich hochgeladen habe ist komplett. Mehr benötigt man nicht.


    Meine Frage war, ob man die Adressdekodierung so designen sollte, dass RFRSH_N high (inaktiv) ist,


    wenn das SRAM selektiert ist (CS_N 0 low).


    Normaler Zugriff: A19-A17 =0 (über I/O-Port gesteuert), MREQ_N = 0, RFRSH_N = 1

    Refresh: A19-A17 =0 (über I/O-Port gesteuert), MREQ_N = 0, RFRSH_N = 0




    Wenn ich RFRSH_N = 1 also nicht dekodiere, wird der Chip-Select Eingang des SRAMs auch bei einem REFRESH aktiviert.

    Da passiert wohl nichts, weil WR_N während des REFRESH nicht aktiv ist.



    Weiss jemand, auf welchen Logikpegel A15-A8 des Z80 getrieben werden, während RFRSH_N aktiv (low) ist?



    6. MEMTR_N Signal.

    Das MEMTR_N Signal ist ein FDC-internes Signal und öffnet die Treiber für A(15:0) und für die Control-Signale wie WR_N, RDN,

    wenn es low ist. Es ist an dem OE_N Eingängen der 74LS244 angeschlossen.


    Ich lade zum Verständnis einige Messungen hoch. Bitte nicht zu kritisch betrachten, nur MRQ_N ist über kurze Strippen

    mit dem Tastkopf verbunden.

    Die Messung FDC_Hang.png zeigt eines meiner Probleme.

    Der FDC holt sich den Bus, schreibt einige Bytes in den Speicher und hängt dann, BUSAK_N = 0, MEMTR_N = 0, MREQ_N = 0, WR_N = 0.

    In diesem Fall gerät auf dem FDC etwas aus dem Tritt und der FDC hängt.


    Es gibt auch einen anderen Fehler.

    Der Datentransfer kommt von Floppy endet normal.

    Das Betriebssystem ISIS-II gigt seine Sign-on Meldung "ISIS-II Ver. 4.3" aus, stürzt dan aber ab.

    In dem Fall sind vermutlich falsche Daten in den Speicher übertragen worden.


    Für die weiteren Messungen habe ich in den Trace gezoomt.

    FDC_RD_IOPB-01 - FDC_RD_IOPB-01 zeigen, wie der FDC den Bus holt und sieben Bytes, den I/O-Parameter-Block aus dem Speicher liest.

    Der FDC interpretiert den I/O-Parameter-Block und führt die angeforderte Operation durch.


    FDC_WR_MEM-01 - FDC_WR_MEM-06 zeigen, wie der FDC den Bus für einen Datentransfer von der Floppy zum Speicher holt.

    Dann werden einigen Bytes vom FDC in den Speicher übertragen.

    Schon nach wenigen Bytes hängt der Transfer.


    Das soll erst einmal alles sein für heute.

    • Offizieller Beitrag

    Ich benutze Tektronix TAP1500 Probes mit 1,5 GHz Bandbreite.

    Ich habe die Probe jetzt auf V umgestellt. A/Ohm war aber auch kein Problem.

    Tolle Ausruestung mit den Probes.


    A/Ohm gibt's nicht und ist Bloedsinn.

    Das Ohm-Zeichen ist bei meinem DPO4104 das Zeichen, wenn der interne 50Ohm Abschlusswiderstand aktiv ist. Das wuerde bei passiven Probes zu Messfehlern fuehren. Aber wahrscheinlich ist das durch die aktiven Tastkoepfe inaktiv/egal/sonstwas.


    5. RFRSH_N Signal in die Adressdekodierung einer SRAM-Karte einbeziehen oder nicht.

    Ich wuerde den RFSH mit auf den Adressdekoder legen. Also Jumper unten im Schaltplan.

    Funktional ist es egal (du hast es mit WR_N ja schon erklaert), es entstehen aber weniger Signalwechsel.

    Eigentlich ist das RFSH an der Stelle sogar gut eingesetzt. Da hatte ich gestern einen Denkfehler.

    Weiss jemand, auf welchen Logikpegel A15-A8 des Z80 getrieben werden, während RFRSH_N aktiv (low) ist?

    Ja, keiner! :)

    A7 ist '0', ausser jemand hat 0x80-0xFF ins R-Register geschrieben.

    A8-A15 sind nicht definiert. D.h. die Leitungen haben selbstverstaendlich einen stabilen Zustand, aber einen zufaelligen Wert.


    6. MEMTR_N Signal.

    Ich habe eine Vermutung.

    Der FDC hat keinen DMA, sondern die FDC-Interne CPU greift als Busmaster auf den Speicher. Zwischen den Lesezyklen muss die CPU ihren eigene Code abarbeiten, das dauert eben etwas. Sieht komisch aus, aber aendern ist nicht.


    Leider haben wir damit bisher keine Fehleranalyse, aber wenigstens handfestes Wissen.


    Wenn der Datentransfer haengt, sieht der Bus dann immer so aus?

    Hintergrund: Auf dem letzten Screenshoot bleibt der Transfer waehrend eines Speicherzugriffs (der FDC-CPU) haengen. Die einzige Moeglichkeit die CPU anzuhalten ist was WAIT_N Signal an der CPU. Oder es gibt irgendeine Logikschaltung auf dem FDC, die noch dazwischen haengt.

    Hast du einen Schaltplan des FDC? Hast du Bilder, auf denen man die Bausteile gut erkennen kann?


    Schoenen Abend

    • Offizieller Beitrag

    Ich habe mal die beiden Seiten des FDC "fachgerecht" zusammen montiert.





    Ich will Fritz' seine Standardfrage nicht wegnehmen: :)
    NIXDAS Hast du das EPROM schon ausgelesen und gesichert?

    Kannst du die PROMs auslesen?

  • Ich habe mir einen Minipro TL866CS Programmer zugelegt.

    Für den attraktiven Preis kann er viel, aber nicht alles.


    Ich lade das Binary der Floppy Controller Firmware mal hoch.

    Ich habe mir vor einiger Zeit mal die Mühe gemacht, das Binary zu disassemblieren.

    Leider musste ich feststellen, daß das Binary nicht mit meinem Listing übereinstimmt.

  • Ich möchte noch eine Erkenntnis nachliefern, die vielleicht hilfreich für die weitere Fehlersuche ist.


    Ich habe komplette Tracks (Track 0, 1, 2) mit Hilfe des Monitorprogramms in den Speicher gelesen.

    Wenn ich in den Speicher ab Adresse 8000h einlese, funktioniert das meist problemlos.

    Wenn ich die Daten in den Bereich A000h - AFFFh einlese funktioniert das sehr zuverlässig.


    Wenn ich in den Speicher unter 8000h einlese, z.B. ab Adresse 7000h oder ab Adresse 4000h funktioniert das meist nicht.

    Auf dem FDC wird Adresse 15 zur Adressdekodierung für SRAM und EPROM verwendet.

    SRAM = Adresse 0000h - 7FFFh, EPROM = Adresse 8000h-FFFFh.


    Vielen Dank Fritz, für die Bereitstellung der weiteren Informationen, wie Schaltplan, Beschreibung etc. !

    • Offizieller Beitrag

    Wer treibt eigentlich die Adressleitungen A16 bis A19? Sind hierfuer Terminierungen vorhanden?

    Die werden auf der RAM-Karte benutzt. Der FDC kann sie nicht treiben.

  • A19 - A16 werden von einem 74LS273 auf dem Motherboard getrieben.

    A19-A16 werden durch den RESET-Impuls auf 0000 initialisiert.

    A19-A16 weden ständig von der Z80 CPU-Karte getrieben, unabhängig von BUASK_N.

  • Hallo Fritz,

    vor etwa einer Woche habe ich mich wieder mit dem Thema beschäftigt, nachdem ich ein Assembler-Listing des CP/M Bootloaders für

    das Intellec MDS 800 im Internet gefunden habe.

    Anders als ich in einem meiner Posts geschrieben habe, befindet sich exakt dieser Bootloader in Track00/Sektor 1 einer der CP/M-Disketten,

    die du für mich generiert hast.

    Im Listing habe ich gesehen, dass im Bootloader der Status des Boot-Swítch des MDS-800 unter I/O-Adresse 0FFh abgefragt wird.

    Beim MDS-800 muss man zunächst den Boot-Switch einschalten, dann den RESET-Switch betätigen und anschliessend den Boot-Switch

    wieder ausschalten.

    Bei meinem Rechner wird der Boot-Switch nicht unterstützt.

    Ich habe die Abfrage des Boot-Switch durch NOPS ersetzt.

    Leider wird CP/M auch nach dieser Massnahme nicht geladen.

    Der Bootloader fällt gleich beim ersten Versuch mit einem Fehlerstatus (Drive not Ready) durch.

    Ich habe nun die Sektoren, welche der Bootloader laden würde mit Hilfe von Kommandos meines Boot-Monitors in den Speicher geladen und

    habe einen GO-Befehl auf die entsprechende Einsprung-Adresse durchgeführt.

    Die Meldung "CP/M 62K Ver 2.2" (oder so ähnlich) erscheint, dann passiert nichts mehr.


    In der nächsten Woche enden Die Ferien in NRW.

    Dann werde ich weiter forschen.


    Viele Grüße

    Franz

  • Ich möchte hier kurz den Projekt-Status dokumentieren.

    Leider kann ich nicht von Projektfortschritt sprechen, weil es auch einen derben Rückschlag gegeben hat.


    Ich hatte die beiden TM848 8-Zoll Diskettenlaufwerke aus dem 19-Zoll-Gehäuse des Rechners ausgebaut, um besser messen zu können.

    Eines der beiden Laufwerke funktionierte anfangs ganz leidlich, nachdem ich die Mechanik beider Laufwerke gefettet und die Schreib-Leseköpfe gereinigt hatte. Die zweite funktioniert nur ganz schlecht und blinkte nach dem Einschalten oft Error-Codes auf der Front-LED.


    Immerhin konnte ich dank der von Fritz generierten ISIS-II Floppies ganz sporadisch ISIS-II Ver. 4.3 booten, manchmal sogar ein DIR-Kommando absetzen oder den Editor CREDIT aufrufen. Mit der Zeit funktionierte das immer schlechter.

    Messen war bei dem Aufbau, Rechner im 19-Zoll Rack und Floppies oben auf dem Gehäuse nur sehr umständlich möglich.

    Zudem war das Frontpanel, das über ein 50-Poliges Flachbandkabel am Z80-CPU-Board angeschlossen ist, ständig im Weg.

    Also habe ich mir ein Debug-Frontpanel gefädelt, so daß die ECB-BusKarten des Rechners nun einfacher zugänglich waren.

    Zunächst war ich der Meinung, daß das Debug-Frontpanel ordentlich funktioniert, später sollte ich eines besseren belehrt werden.

    Letztendlich konnte ich mit dem Aufbau aber immer noch nicht ordentlich messen.

    Also habe ich mir eine 4-Slot ECB-Bus Backplane zum Debuggen auf dem Labortisch zusammengelötet.

    Die Stromversorgung erfolgte über ein Vero Trivolt PK60 Einschubnetzteil.

    Ich konnte sporadisch einzelne Sektoren von der Floppy lesen, aber immer wieder hing das System.

    Der Floppy-Controller gab den ECB-Bus nicht wieder frei, BUSREQ_N = low.

    Irgendwann hing das System nach jedem ersten Zugriff auf den Floppy Controller, wobei der Floppy Controller das WAIT-Signal aktiviert hatte.

    Zum Glück war der Fehler statisch, Als Ursache stellte sich ein defekter 74LS08 heraus.

    Das System lief nun wieder aber immer unstabiler. Als ich das System an einem Abend eingeschaltet habe, ist es leider zu einem folgenschweren Zwischenfall gekommen.

    Die Floppy lief kurz an und blieb dann mit Dauerlicht stehen.

    Es stellte sich heraus, daß der Controller auf dem Logikboard der TM848, es handelt sich um einen 8748, keinen Mucks mehr macht.

    Nicht einmal der Oszillator schwingt an. Ich kann nur spekulieren, daß die Tatsache, daß ich Rechner und Floppy über verschiedene Netzteile versorgt habe, den Rechner über das Vero Trivolt PK60 und die 8-Zoll Floppy mit 5 Volt und 24 Volt über ein regelbares Doppelnetzteil, das Problem ausgelöst hat.

    Ich erinnere mich nicht, in welcher Reihenfolge ich die Netzteile eingeschaltet habe, ich glaube zunächst das Vero Trivolt und anschliessend das Doppelnetzteil, welches die Floppy versorgte.

    Die Masse beider Netzteile war evtl. über Laborkabel nicht ausreichend vermascht. Zudem war das Vero Trivolt über eine Steckdose am Labortisch angeschlossen, welche über einen Trenntrafo abgesichert war.

    Es ist wie es ist, die einigermaßen funktionierende Floppy ist hin und die zweite funktioniert nicht gescheit.

    So muß ich zunächst den Plan, meinen ersten CP/M Rechner im Originalzustand wieder in Betrieb zu nehmen zu den Akten legen.


    Ein paar Tage später habe ich meinen ersten Schock wieder überwunden und habe im Internet Hinweise gefunden,

    wie man eine 3,5 Zoll Floppy auf 360 RPM umbauen kann.

    Bei meinen 3,5 Zoll Laufwerken habe ich ein TEAC FD-235HF-800U mit dem Motor Controller A13440 gefunden, das ich durch Entfernen einer 0-Ohm Brücke (W61) auf 360 RPM umbauen konnte. Das TEAC FD-235HF-800U ließ sich zudem durch Umsetzen einer 0HM-Brücke einfach von Disk-Change zu Ready-Signalisierung umbauen.

    Leider tat sich überhaupt nichts, nachdem ich das Laufwerk angeschlossen hatte. Der Motor wurde nicht angeschaltet.

    Waren neben der Floppy auch einige Interface-Bausteine auf dem Floppy-Controller abgestorben?

    Ich habe bis auf den Datenseperator alle Interface-Bausteine ausgetauscht. Es tat sich trotzdem nichts.

    Dann habe ich den Motor über eine Drahtbrücke dauerhaft eingeschaltet und konnte nun eine 3,5 Zoll HD-Floppy als Single Density Floppy

    mit 77 Tracks und 26 Sektoren mit 128 Bytes formatieren und anschliessend einzelne Tracks lesen und schreiben.

    Wobei das Schreiben ganz gut funktionierte, das System beim Lesen aber immer wieder einfror (BUSREQ_N und BUSAK_N dauernd auf low).

    Das System wurde aber immer unstabiler. Manchmal lief es nach RESET nicht hoch oder starte unmotiviert neu.

    Auch der Memorytest, über das Monitorprogramm aufgerufen, fror manchmal ein.

    Ich entschloss mich, die ECB-Bus-Karten im angestammten 19-Zoll Rack weiter zu testen.


    Morgen dann mehr zu dieser Geschichte.























    .

  • Zurück in der Backplane des 19-Zoll Racks lief der Rechner immer noch nicht stabil.

    Man musste nur einen Teil der Schaltung mit der Meßspitze eines Oszilloskops berühren, um den Rechner zum Absturz zu bringen. Man konnte manchmal den Eindruck gewinnen, daß man nur ein wenig zu fest auftreten musste, um einen Absturz zu verursachen.

    Zunächst wurden alle Geräte, der Rechner selbst, der Bedienrechner mit der Terminal-Emulation und die Messgeräte an eine gemeinsame Steckdosenleiste angeschlossen, leider ohne Erfolg. Die provisorische serielle Schnittstelle wurde mit der Gehäusemasse verbunden und es wurde sicher gestellt, daß die Abschirmung bis zum Terminal-Rechner durchverbunden war, wieder keine Verbesserung.

    Auf der Backplane wurden am linken Ende ein 1000 uF Abblockkondensator und am rechten Ende ein 470 uF Abblockkondensator eingelötet, immer noch keine Änderung.

    Der aktive Busabschluß wurde geändert. Die BC327/BC337 wurden durch stärkere Darlingtons BD681 und BD682 ersetzt. Auf der Bus-Abschluss-Karte, die direkt auf die Backplane aufgelötet ist, wurde ein weiterer 47 uF Abblockkondensator aufgelötet. Leider brachte auch das keine Verbesserung.

    Im Zuge der Änderungen stellte sich heraus, daß 3K3 Pull-Up Widerstände für den Abschluß gegen die geregelte Anschlußspannung von 2,5 Volt eingesetzt wurden. Im Schaltplan waren 110 Ohm angegeben, was ich schon immer als zu niederohmig angesehen hatte.

    Einmal fiel mir auf, daß der Rechner in dem Moment abstürzte als ich das Kabel des Frontpanels bewegte. Ich habe den Stecker des Frontpanels neu aufgesteckt und als Ergebnis schien der Rechner zunächst stabiler zu laufen. Der Eindruck hielt aber nicht lange an.

    Bei weiteren Messungen stellte sich heraus, daß die NMI-Leitung auf der Backplane ständig auf Low-Pegel lag. Die Ursache musste auf dem neu gefädelten Frontpanel liegen. Bei Messungen an einem 74LS123, welcher definierte Pulse für das RESET-Signal und für das NMI-Signal erzeugt, fiel eine bizarre Signalform an den RESET-Eingängen des Bausteins auf. Es stellte sich schliesslich heraus, daß der Fädeldraht an dem zuständigen Pull-Up Widerstand nicht ordentlich durchgelötet war und keinen Kontakt hatte. Das RESET-Signal war störungsfrei, nachdem der Pull-Up ordentlich angelötet war. Das NMI Signal funktionierte immer noch nicht.

    An der Hälfte des 74LS123, welcher für die Erzeugung des NMI-Pulse zuständig ist, hatte ich die R/CEXT und den C-Eingänge vertauscht. In Kicad, mit dem ich den Schaltplan der Fädelkarte gezeichnet habe, ist der R/CEXT-Eingang bei einem Symbol am obersten Pin und bei dem zweiten Symbol am zweitobersten Pin. Beim Kopieren von Schaltungsteilen ist also Vorsicht angeraten.

    Nach der Korrektur funktioniert nun auch der NMI, aber der Rechner kann die Daten immer noch nicht zuverlässig von der Floppy lesen.

    Die Geschichte geht weiter.

  • Bei dem Rechner wurde die Peripherie über die Z80-CPU-Karte gesteuert.

    Über ein an der Frontseite der CPU angestecktes 50-poliges Flachbandkabel wurden die Schnittstellen zunächst zum Front-Panel verbunden und von dort über ein 40-poliges Flachbandkabel zur Rückwand des 19 Zoll Gehäuses verbunden.

    Der Rechner unterstützte wie das Intellec MDS zwei serielle Schnittstellen, CRT und TTY. CRT und TTY konnten über jeweils einen 15-Polige D-Dub Stecker angestöpselt werden. Gab es einen Standard für die Belegung von 15-poligen seriellen Schnittstellen?

    Über zwei 8-Bit-Schnittstellen, die von einem Intel 8255 angetrieben wurden, wurde ein Paper-Tape Punch und ein Paper-Tape Reader unterstützt.

    Wie die seriellen Schnittstellen sind auch Paper-Tape Punch und Paper-Tape Reader über 15-Polige D-Dub Stecker anschliessbar. Die Belegung dieser Stecker ist mit Sicherheit kein Standard. Ende der 70-er Jahre habe ich mir in München in der Elektronik-Meile in der Nähe des Hauptbahnhofs einen Paper-Tape Reader von Olivetti geholt, weil sich alle einen geholt haben. Der wurde nie benutzt und ist irgendwann verschwunden.

    Wir haben zu der Zeit übrigens noch einen Paper Tape Reader und einen Paper-Tape Punch in der Firma eingesetzt, um PROM-Inhalte zu archivieren und um diese später ins Programmiergerät einzulesen.

    Der Port, an welchem der Paper-Tape Reader angeschlossen werden kann, kann auch dazu benutzt werden, den Zustand einen 8-poligen DIP Schalters auf dem Front-Panel einzulesen.

    Wie beim Intellec MDS können Interrupt 7 - Interrupt 0 und RESET vom Front-Panel ausgelöst werden. Für die Z80-CPU-Karte kommt hier der NMI hinzu.

    Der Boot-Monitor steuert über ein 16-Bit Shift Register ein 4-Bit Hex Status Display plus 12 LEDs an. Weitere 4 LEDs, WAIT, BUSAK, ULD und MEXT werden von diskreten Signalen angesteuert, die über das 50-polige Flachbandkabel verbunden werden. Zwei Bits des Port C des 8255, die nicht für die Steuerung von PRT und PTP benötigt werden, steuern den linken und den rechten Dezimalpunkt des HEX-Displays an.


    Der Netz-Ein Taster steuert eine Logik an, welche Nixdorf Netzteile über das NEN-Signal ein- und ausschalten kann.

    Die linke mit KBD bezeichnete Buchse war für den Anschluss eines ASCII-Keyboards vorgesehen, wurde aber nie benutzt.


    Die mit SAS-bezeichneten 6-poligen Buchsen dienen zum Anschluss von Nixdorf SAS1 Peripherie. SAS steht für serielle Arbeitsplatz-Schnittstelle.

    Über einen gemeinsamen Draht (TN1) werden Daten gesendet und empfangen. Die SAS-Peripherie konnte über die Schnittstelle mit 24 Volt versorgt werden. Über das NEN-Signal konnte der Rechner über die SAS-Schnittstelle eingeschaltet werden.

    Ich hatte da mal eine SAS-Tastatur der Nixdorf 8890 angeschlosssen, die ich ausgeliehen hatte. Nachdem ich diese wieder zurück gegeben habe sind weitere Arbeiten an der Baustelle zum Stillstand gekommen. Die Dekodiertabellen Nixdorf - ASCII sind aber weiterhin im Monitorprogramm enthalten.

    Vielleicht werde ich irgendwann einmal eine Nixdorf SAS1 Tastatur anschliessen.

  • Das einzig funktionierende TM848 acht Zoll Laufwerk ist leider hinüber und Ersatz ist nicht in Sicht.

    Ich muss mir etwas anderes überlegen.

    In Netz habe ich gelesen, dass 3,5 Zoll Laufwerke, die von 300 RPM auf 360 RPM und aus READY- statt DISKCHANGE-Signalisierung umgebaut sind, eine 8-Zoll Diskette ersetzen können. Ein GOTEK ist geordert, lässt aber auf sich warten.

    Einen HXC100 habe ich in einem anderen Projekt eingesetzt. Auf den könnte ich notfalls zurückgreifen.

    Unter den 3,5 Zoll Laufwerken, die ich vor einiger Zeit repariert habe, findet sich ein TEAC FD-235HF-800U, bei dem der im Netz erwähnte W61 Jumper auf der Motorplatine zu finden ist.

    Ich habe dem 0 Ohm Widerstand W61, der ein Signal mit GND verbindet entfernt.

    Die Drehzahl ändert sich durch diese Maßnahme tatsächlich von 300 RPM auf 360 RPM. Die Index-Pulse kommen nun im Abstand von 166 Millisekunden statt 200 Millisekunden zuvor bei 300 RPM.

    Die Leitung, welche von der Brücke W61 auf GND gelegt wird, führt zum Motor Controller A13440 (fünfter Pin von der linken oberen Ecke).

    Wenn W61 entfernt wird steigt der Pegel an diesem Pin von 0 Volt auf ~ 1,3 Volt und als Konsequenz schaltet der Controller auf 360 RPM um.

    Ich habe den Pin probehalber mit einem 22K Widerstand gegen 5 Volt beschaltet. Der Pegel steigt dann auf 5 Volt.

    Die Floppy dreht nach wie vor mit 360 RPM.


    Die 0 - Ohm Brücken, mit denen zwischen DISKCHANGE# oder READY# an Pin 34 des Floppy-Steckers umgeschaltet werden kann, waren schnell gefunden.

    Die 0 Ohm Brücke habe ich von Position S27 (DC) auf Position S28 (RDY) umgesetzt.


    Ich lade hier mal eine bebilderte Anweisung hoch, in der die notwendigen Änderungen beschrieben werden.

  • Daß die Daten auf 3,5 Zoll Floppies schneller verschwinden als auf 5 1/4 Zoll Disketten, hätte ich nicht unbedingt erwartet.


    Vielen Dank für die Links. Da gibt es eine Unmenge von Informationen, die erst einmal verdaut werden müssen.

    Ich versuche zunächst einmal auf der 3,5 Zoll Schiene weiter zu fahren, weil die Floppies nur eine 5 Volt Stromversorgung benötigen und weil sie weniger Platz einnehmen.

    Natürlich benötige ich für die 3,5 Zoll Floppies einen Adapter vom 50-poligen Kabel auf ein 34-poliges Kabel.

    Ich habe mir den Adapter selbst zusammengelötet.

    Ich habe ihn so angelegt, daß ich auf der 34-poligen Seite Standard PC-Floppy Kabel verwenden kann.

    Drive 0 wird am gedrehten Ende des Floppy Kabels angeschlossen.

    Zum Testen kann ich alle Leitungen durch Jumper auftrennen und bei Bedarf durch Drahtbrücken mit anderen Leitungen verbinden.

    An den Jumpern kann ich die Signale zum Messen abgreifen.

    Zwei Bananenbuchsen erlauben, eine angeschlossene 3,5 Zoll Floppy ohne Rechner zu betreiben.

    Die Signale, die von der Floppy zum Motherboard führen, können in dem Fall über Jumper mit Pull-Up Widerständen gegen 5 Volt verbunden werden.

  • Der Floppy Adapter ist fertig und die Floppy wird angeschlossen. Im Monitorprogramm lese ich den Status-Port des Floppy Controllers ein und

    stelle fest, daß er sich als Double Density Controller meldet.

    Ich versuche einen Sektor von der Floppy zu lesen, aber der Controller schaltet den Motor der Floppy nicht ein.

    Die komischen Pulse, die ich an Drive Select messe, erklären sich nach dem Studium des uPD765 Floppy Controller Datenblatts.

    Der Floppy Controller fragt den Ready Status aller Laufwerke reihum ab.

    Die Verbindungen auf dem Floppy Controller bis zum Laufwerk sind OK. Eigentlich müsste der Motor eingeschaltet werden.

    Ich versuche es mit Drive Nummer 0 -3, was Double Density Disk sein sollten, nichts. Auch mit Drive Nummer 4 und 5, was den Monitor zum Umprogrammieren auf Single Density veranlassen sollte, tut sich nichts. Am Ende lege ich die Motor-ON-Leitung per Drahtbrücke auf GND und der Motor läuft dauerhaft. Die Motor-On Signale sind eine neue Baustelle, die ich später betrachten will.

    Ich habe eine im PC auf 1,44MB formatierte HD-Diskette eingelegt und versuche einen Sektor einzulesen. Das Monitorprogramm macht 16 Read-Versuche und meldet dann einem Address Error. Das war zu erwarten.

    Ich versuche die Diskette mit dem im Monitor eingebauten Format Kommando zu formatieren. Der Controller beginnt mit dem Formatieren, bleibt aber immer wieder hängen. BUSAK ist dann dauerhaft aktiv. Dann hilft nur ein RESET.

    Irgendwann läuft der Format auf Drive 0 fehlerfrei bis zum Ende durch. Ich habe jetzt eine formatierte Double Density Diskette im 3,5 Zoll Format.

    Nun versuche ich, einzelne Sektoren einzulesen.

    Solange ich nur einen oder zwei Sektoren einlese funktioniert das ganz gut und ich sehe mir das Format Bytes im Speicher an. Beim implementierten Format Kommando ist das per Default E5.

    Ich starte einen Seek Test, der ebenfalls im Monitorprogramm implementiert ist und er funktioniert problemlos. Also, solange keine Daten übertragen werden, funktioniert der Floppy Controller ganz gut.

    Ich schreibe einen Ausschnitt des Monitorprogramms auf einen oder zwei Sektoren und kann ihn zurück lesen. Die Daten sind fehlerfrei.

    Sobald ich aber über zwei Sektoren hinaus gehe hängt das System in der bekannten Weise. Mehr als 7 Sektoren kann ich fast nie lesen oder schreiben.

    Ganz selten kann ich mal einen kompletten Track schreiben. Noch seltener kann ich einen ganzen Track lesen. Schreiben klappt eindeutig besser als lesen.

    Ich bin mit meiner 3,5 Zoll Floppy also auf dem gleichen Stand wie mit der 8 Zoll Floppy.


    Vielleicht geht es ja besser mit Single Density Floppy Disks. Dummerweise habe ich das Format-Kommando nur für Double Density implementiert.

    Auch wenn ich Drive 4 oder 5 wähle wird nicht versucht, den Controller auf Single Density umzuprogrammieren.


    Ich hole einen 486 Rechner aus seiner Ecke, den ich zu Anfang des Projekts aufgebaut habe, um ISIS-II oder CP/M Images auf eine 8-Zoll Floppy zu schreiben. Der Rechner ist bereits mit einem Adaptec AHA 1422B Controller ausgerüstet, auf dem ein Floppy Controller Baustein sitzt, mit dem mit Hilfe des Imagedisk Programs von Dave Dunfield ein ISIS-II- oder CP/M Image auf eine 8 Zoll Floppy geschrieben werden kann.

    Mir ist das damals leider nicht gelungen.

    Nachdem mir Fritz einige Images auf 8 Zoll Disketten geschrieben hatte, habe ich dann das Interesse an dem Projekt verloren und den Rechner zur Seite gestellt.


    Jetzt schließe ich das modifizierte 3,5 Zoll Laufwerk an den Rechner an und hole mir ein ISIS-II Ver. 4.3 im Single Density Format aus dem Internet.

    Das Image lässt sich ohne Probleme beim ersten Versuch auf die Floppy schreiben.

    Ich bin ganz überrascht und schliesse die Floppy wieder am Ziel-Rechner an.


    Ich versuche von Drive 4, also Single Density zu lesen, leider ohne Erfolg, Drive not Ready. Warum ?

    Ich erinnere mich, daß ich den Drivemode, der festlegt, wie Drive-Select zu Motor-ON und Density gemappt werden von Mode 0 auf

    Mode 1 geändert habe. Dieses Feature unterscheidet den Lakosa Floppy Controller vom original Intel Floppy Controller.

    Ich dachte, daß ich die handschriftlichen Notizen von Lakosa verstanden hätte und dass Drive-Mode 1 besser auf meinen Rechner passt.

    Ich programmiere das Monitor Program um, zurück auf Mode 0. Der Motor der Floppy wird auch mit Mode 0 nicht eingeschaltet. Das Signal muss weiterhin mit einem Jumper auf GND gelegt werden.

    Aber jetzt kann ich den ersten Sektor der Single Density Diskette mit Drive Nummer 4 einlesen.

    Die Copyright Meldung von Intel ist im Klartext im Speicher zu lesen.

    Das fängt schon gut an, aber die Ernüchterung folgt gleich wieder. Auch bei der Single Density Diskette kann ich nur wenige Sektoren lesen.

    Ich versuche trotzdem einmal, ISIS-II zu booten.

    Der Rechner macht 16 Versuche mit Double Density, schaltet dann auf Single Density Mode um, liest einen Sektor der Floppy auf Adressse 3000h und bleibt hängen, aber anders als zuvor. Die BUSAK-LED leuchtet nicht dauerhaft.

    In Sektor 0 ist ein Bootloader, in den verzweigt wird, nachdem er geladen worden ist. Der Bootloader soll dann den Rest des Betriebssystems laden.

    Schade! Ich schaue mir den Bootloader, es sind ja nur 128 Bytes, genauer an und entdecke etwas.

    Einmal editiert, zuletzt von NIXDAS ()