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.

  • 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

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • 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.

  • 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

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • 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.

  • 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

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • 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?

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • 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. !

  • 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.

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)