Beiträge von NIXDAS

Ich suche Unterlagen zum Einplatinen-Rechner Siemens SICOMP SMP16 CPU-045.

Im Netz habe ich nur wenig gefunden. Es scheint die Nummer 6AR1300-0FD30-0AA0 zugeordnet zu sein.

Es handelt sich um einen 80486 Einplatinen Computer mit on-Board DRAM, IDE Schnittstelle, Floppy Schnittstelle

2 X COM-Schnittstelle, Tastatur-Schnittstelle. Die 26-polige Wannenleiste könnte zu einer LPT-Schnittstelle gehören.

Welche VIDEO-Karte würde man zusammen mit dieser CPU verwenden?

Die Karte stammt aus eine Rohde&Schwarz Gerät.

Um welches Gerät könnte es sich handeln?

Ich habe beim Z80 Datenbit 0 begonnen, einige Signale auf dem FDC zu kontrollieren.

Schon bei der ersten Messung gefällt mir etwas nicht.

Im nachfolgenden Bild ist der Fehlerfall gezeigt.

Der Z80 transferiert eine Reihe vom Bytes vom FDC-Speicher in den Speicher des Z80 am ECB-Bus.

Irgendwann endet der Transfer vorzeitig. Das WR_N Signal des Z80 auf dem FDC bleibt ständig auf low.

Der Z80 auf dem FDC macht zwei M1 Zyklen, um den LDIR-Befehl aus dem EPROM zu holen.

Nach jedem Opcode Fetch erfolgt ein Refresh Zyklus.

Beim ersten Refresh Zyklus ereicht DO einen Signalpegel vom ca 4 Volt.

Beim zweiten Refresh Zyklus erreicht D0 nur einen Signalpegel 1,5 Volt.

Meine erste Vermutung war, daß während des zweiten Refresh Zyklus ein anderen Teilnehmer auf den Datenbus geschaltet wird.

Im unteren Teil des Bildes wird ein gezoomter Ausschnitt der Signale am oberen Rand des Bildes gezeigt.

Als ich die Floppy Controller Karte gekauft war Lakosa gerade dabei die Karte aufzubohren.

Es gibt zwei Disketten Bänke, Bank 0 und Bank 1. Jede Bank hat ein eigenes Status Register.

Die zweite Bank kam später hinzu und Lakosa hat das Status Register der zweiten Bank huckepack über

das Status Register (74LS374) der ersten Bank gelötet.

Beide 74LS374 sind bei VCC, GND, Inputs und bei den Outputs miteinander verbunden.

Die Clock Inputs und Output-Enable Inputs beider Bausteine werden getrennt angesteuert.

Der Clock Input und Output-Enable Input des oberen Bausteins ist über Fädeldrähte verbunden.

Genauso sind die Steuersignale der Motoren über Fädeldrähte nachträglich verdrahtet.

Ich denke Lakosa hat das PCB später bereinigt oder hatte vor, das PCB später zu bereinigen.

Ich habe noch eine Prototypenversion.

Bei der Durchsicht der Schaltung habe ich zwei offene Eingänge, IC6 Pin 17 und Pin 2, entdeckt.

Offene Eingänge können dazu führen, daß die Ausgänge unkontrolliert schalten.

Noch schlimmer ist, daß die Ausgänge oszillieren können.

Deshalb sollten offene Eingänge immer auf einen definierten Pegel gelegt werden.

Das geschieht entweder durch eine Drahtbrücke nach GND oder über einen Pull-Up-Widerstand

gegen VCC. Eine direkte Verbindung von Eingängen nach VCC ist nicht zu empfehlen.

Die Eingänge vom CMOS Bauelementen sind mit ESD-Schutzdioden beschaltet.

Spannungsspitzen auf der Versorgungsspannung können die Eingänge in den Latch up bringen,

wobei die ESD-Schutzdioden permanent durchgeschaltet sind.

Dieser Zustand lässt sich erst beenden indem die Spannungsversorgung abgeschaltet wird.

Eingänge werden durch den Latch Up Effekt auf ein bestimmtes Potential, high oder low, geklemmt.

Sie können beschädigt werden und im schlimmsten Fall zerstört werden.

Bei der Lakosa FDC-Karte wurde keine Verbesserung durch diese Maßnahme erzielt.

Die Rückseite der Floppy Controller-Karte hat inzwischen einige zusätzliche keramische 100 nF Abblockkondensatoren bekommen.

GND- und VCC-Leitungen wurden weiter vermascht.

An zwei Stellen, wo zwei 100 nF Abblockkondensatoren unmittelbar nebeneinander platziert waren, wurde jeweils einer durch einen 10 uF Elko ersetzt.

Nahe dem Z80 wurde ein 3,3 uF Tantal-Elko durch einen 100 uF Elko ersetzt.

Auf dem folgenden Bild beachte man die dünne Leiterbahn, die vom Masseanschluss des Elkos in Richtung des ECB-Bus Steckers führt.

Das ist die Masseleitung des Elkos und des 100 nF Abblock-Kondensators.

Die Induktivität einer dünnen Leitung wie dieser macht den 100 nF Abblock-Kondensator zumindest teilweise unwirksam.

Abblock-Kondensatoren müssen immer zu kurz wie mögich und so dick wie möglich an das abzublockenden Bauteil und an GND und VCC angeschlossen werden.

Ich habe inzwischen einen neuen Testaufbau mit einer 4-fach ECB-Backplane gebastelt, die von einem Vero Trivolt PK60 Netzteil versorgt wird.

Der Floppy Controller steckt ganz rechts.

Die darauf bestückten IC sind nur problemlos durch eine Oszilloskop Meßspitze zu erreichen, ohne die Karte für jede Meß-Adaption

aus dem Gehäuse ausbauen zu müssen.

Danke schon einmal!

Lange hat es leider nicht gehalten das Vero Trivolt PK 110, nur einen Tag.

Heute beim ersten Einschalten lässt es ein lautes Zirpen hören.

Die LED für V2 (+ 12 Volt) leuchtet nicht mehr.

Daran ändert sich nichts, nachdem ich die Ausgänge von der Schaltung getrennt habe.

Am Stecker ist ein satter Kurzschluss zwischen + 12 Volt und GND zu messen, also auseinanderbauen.

Drei Elkos an der + 12 Volt Versorgung ausgelötet, natürlich ist es der letzte, der einen Kurzschluss aufweist.

Leider gibt es kein Happy End. Auch der Übertrager hat einen satten Kurzschluss.

Die Ausgangsspannung kann man durch Potis im Bereich plus 12 Volt - plus 15 Volt und von minus 12 Volt - minus 15 Volt einstellen.

Die Potis sind von außen zugänglich.

Zitat von Holger

ist das Dokument hier das richtige?

https://docs.rs-online.com/8ca5/0900766b80681bc5.pdf

Sorry, ich sehe grade beim erneuten durchlesen, dass du 110 suchst, nicht 60. Könnte es dieses sein?

forum.classic-computing.de/index.php?attachment/59195/

Super, das zweite Dokument passt zum PK110!

Das Vero Trivolt PK 110 ist ein Standard Netzteil für 19 Zoll Gehäuse mit 3 HE.

Es liefert 5 Volt/10A, + 12 Volt/2A und - 12 Volt/2A.

Ich habe zwei dieser Netzgeräte als Beifang bei einer Ebay Auktion ergattert.

Zunächst möchte ich das Vero Trivolt PK 110 als temporäres Ersatz-Netzteil für meinen alten

Rechner verwenden, der aus Europakarten aufgebaut ist und Anfang/Mitte der 80-er Jahre ISIS-II und CP/M booten konnte.

Ich arbeite schon seit längerem daran, den Rechner wieder zum Leben zu erwecken.

Aktuell ist er aber immer noch zu unstabil, um damit wieder zuverlässig arbeiten zu können.

Inzwischen habe ich per Bildersuche die Steckerbelegung gefunden.

4: + 5 Volt

6: + 5 Volt Sense

8: GND Sense

10: GND

12: + 12 Volt

14: Ext. ON/OFF

16: GND für +/- 12 Volt

18: Power Fail Status

20: - 12 Volt

22:

24:

26: Netz, N

28:

30: Netz, L

32: Netz, SL

Ich suche die Steckerbelegung des Einschub-Netzteils Vero Trivolt PK 110.

Die Belegung des Vero Trivolt PK 60 passt nicht.

Auf jeden Fall liegt der 220 Volt Anschluss auf anderen Pins als beim PK 60.

Der Hinweis auf das Netzteil ein weiterer guter Ansatz.

Alles fing damit an, daß ich meinen alten Rechner eines Tages von seinem Platz ganz oben auf dem Schrank im Keller herunter geholt habe.

Ich habe den Rechner ohne weitere Überprüfung eingeschaltet. Damals waren die Boot-Floppies bereits einer Aufräum-Aktion zum Opfer gefallen.

Das ungewöhnlich serielle Anschlußkabel 15-polig auf 9-polig existierte noch.

Der Rechner startete noch, die POST-Codes in der Hex-Anzeige zählten hoch, aber außer ein paar Monitor-Kommandos auszuprobieren konnte ich ohne Boot Floppies nichts tun.

Schon kurze Zeit später löste sich ein Kondensator im Netzteil in eine riesige Rauchwolke auf. An der Rückseite des Gehäuses sind die Schmauchspuren

heute noch zu sehen. Das Problem konnte noch schnell gelöst werden. Einen passenden Kondensator hatte ich noch liegen.

Leider hielt die Freude nicht lange an. Schon nach einigen weiteren Stunden stelle das Netzteil seinen Dienst sang und klanglos ein.

Die Sicherung ist OK. Ohne Schaltplan kann ich nichts ausrichten. Trotz des Alters, ich schätze, daß es aus den 70-er Jahren stammt.

handelt es sich um ein Schaltnetzteil. Das schöne an dem Netzteil war, daß es neben den 5 Volt und einer negativen Spannung die 24 Volt

für die Floppy-Laufwerke erzeugt hat. Die anderen Spannungen, + 12 Volt, -12 Volt, -5 Volt habe ich durch Längsregler erzeugt.

Ich habe das Netzteil provisorisch durch ein Netzteil mit ATX-Anschluss (Delta DPS-160KB-2) aus einem kleinen PC-Server ersetzt.

Natürlich sind alle Verbindungen jetzt ein Stück länger geworden und der ATX-Stecker ist auch zusätzlich hinzu gekommen.

Ich wollte Gehäuse des alten Netzteils irgendwann ausräumen und ein oder zwei kleine Schaltnetzteile von der Stange dort einbauen.

Das alte Netzteil mit seinen Kühlrippen ist einfach viel dekoratives als das Provisorium.

Leider finde ich es im Moment nicht wieder.

Wie misst man Ripple am besten?

Ich habe es mir im ersten Ansatz einfach gemacht, eine Probe auf der Backplane angeklemmt und AC-gekoppelt gemessen.

Auf diese Weise messe ich etwa 150mV Ripple auf der Backplane.

Ich hänge ein Bild des provisorischen Netzteils an.

Die Festplatte dient als Grundlast.

Das Teil mit den Kühlrippen ist ein 12 Volt auf 24 Volt Wandler.

Der Lüfter des Netzteils trägt nichts zur Kühlung des Rechners bei.

Ich wollte das Gehäuse nicht durch einen Ausschnitt für den Lüfter verändern.

Die Stromaufnahme der elektronischen Schaltkreise ist nicht konstant, sondern kann sich rapide ändern abhängig davon, was sie gerade tun.

Die Stromversorgung der Bausteine kann nicht immer optimal verdrahtet werden, schon gar nicht bei einer zweilagigen Platine,

bei der die Stromversorgung sich den Platz mit den Signalleitungen teilen muss.

Es gibt also Spannungsabfälle, die sich abhängig von den Schaltvorgängen ändern. Das führt zu Ripple auf den Versorgungsspannungen.

Besonders groß kann die Stromänderung sein, wenn viele Ausgänge ihren Zustand gleichzeitig ändern.

Diese Stromänderungen müssen von Abblockkondensatoren aufgefangen werden, die sich ganz nah an den Stromversorgungspins der

Bausteine befinden sollten. Die Stromänderungen können rapide erfolgen. Um diese rapiden Stromänderungen aufzufangen müssen kleine

(keramische) Abblockkondensatoren 10 nF, 100 nF direkt an den Pins der Bausteine platziert werden. Größere, langsame Elkos liefern dann die Energie für

mehrere der kleinen schnellen Kondensatoren nach. Die Anschlüsse der Abblockkondensatoren zu GND und VCC müssen so kurz wie möglich sein und die Leiterbahnen sollten so breit wie möglich sein, um die Anbindung der Abblockkondensatoren so niederohmig wie möglich zu machen.

Zitat von Toast_r

Zitat von NIXDAS

Es ist ein 2732 mit maximaler Zugriffszeit von 450 nsec.

...

Ich ... brenne das 462532 trotzdem.

2732 und 2532 haben ein unterschiedliches Pinout, die sind nicht austauschbar!

Danke für den Hinweis. Da habe ich nicht aufgepasst!

Ich bin mit meiner Berichterstattung über das Projekt etwas in Verzug.

Vor einigen Tagen war ich dann soweit, daß ich ehr ein analoges Problem vermutet habe.

Ich habe zunächst einmal ein 100 nF Abblockkondensator zwischen GND und VCC des Z80 auf dem FDC geschaltet.

Beim Z80 liegen die Pins fast direkt gegenüber in der Mitte des Baustein.

Zu meiner Überaschung verschlimmerte sich das Problem durch diese Maßnahme.

Das deutet darauf hin, daß sich der Abblockkondensator nicht gegen ein vernünftiges GND-potential abstützen kann.

Ich habe dann eine differentielle Probe P6247 zwischen dem GND-Pins des ECB-Bus und dem GND-Pin des Z80 angeschlossen.

Hier konnte ich ca. 600 mV Spitze-Spitze, ich weiss nicht wie ich es nennen soll, Ripple, Ground Bounce, gemessen.

Dieser Schmutz wurde durch den zusätzlichen Abblockkondensator vermutlich auf den VCC-Anschluss des Z80 gekoppelt

und hat die Probleme noch verschärft.

Ich habe mir daraufhin die GND-Verdrahtung der FDC-Karte angesehen.

Die Karte ist 2-lagig aufgebaut. GND und VCC werden zusammen mit den Signalen auf Vorderseite und Rückseite geführt.

Die GND-Leitung des Z80 führt über eine schmale Verbingung zunächst vom ECB-Bus weg zur Front wird wird dann an GND angebunden

Auch andere GND Verbindungen sind als schmale Stege ausgeführt.

Im ersten Schritt lege ich eine GND-Verbindung vom GND-Pin des 756 Floppy Controllers zum GND-Pin des Z80 und binde

auch alle dazwischen liegenden Bausteine an diese GND-Leitung an.

Daneben binde ich auch den VCC-Pin des Z80 über eine Litze an eine Durchkontaktierung, die zu einer VCC-Schiene führt,

die gut an den ECB-Bus Stecker angebunden ist.

Durch diese Maßnehmen reduzieren sich die Störungen am GND-Pin des Z80 von ca. 600 mV auf ca 300 mV.

Das Problem wird wesentlich entschärft.

Ich kann ISIS-II von Diskette booten und auch ein DIR-Kommando ausführen.

Später traue ich mich sogar, eine Datei zu kopieren.

Allerdings ist das System immer noch nicht ganz OK.

Manchmal bleibt es beim Booten noch hängen. Manchmal stürzt es ab und läuft im günstigen Fall auf einen Interrupt Vector,

der noch vom Monitor besetzt ist. Manchmal kommt der Command Prompt nach einem DIR-Kommando nicht zurück.

Die Fehlersuche muss weiter gehen.

Mein Adapterprint vom 50 poligen Floppy-Kabel auf ein 34-poliges Standard PC-Floppy Kabel nervt.

Bei den Messungen ist er dauernd im Weg und ich muss außerdem befürchten, daß er Kurzschlüsse verursacht.

Ich bastele mir ein Adapterkabel vom 50-poligen Floppy-Anschluß auf den 34-poligen PC-kompatiblen Anschluß

und verwende dafür ein Standard PC-Floppy-Kabel.

Glücklicherweise sind viele Pins gleich belegt.

An einigen Stellen muss ich Drähte trennen und anders verbinden.

Hier ist ein Screenshot in dem ich mit 4 Markern den Zeitpunkt markiert habe, wo das Refresh-Signal des Z80 auf dem FDC eigentlich auf den ECB-Bus durchgeschaltet werden müsste. Leider passiert das nicht.

Ich befürchte, die ECB-Bus Treiber werden nur für die Dauer der Speicherzugriffe auf den ECB-Bus geschaltet.

Hier ein weiterer Screenshot, der zeigt, daß die Opcodes des LDIR Befehls (ED B0) für jeden Transfer neu aus dem EPROM ausgelesen werden.

Meine Vermutung an dieser Stelle: Die Opcodes des LDIR Befehls werden im Fehlerfall vom Z80 nicht richtig verstanden.

Ich sehe mir das Firmware EPROM an, Es ist ein 2732 mit maximaler Zugriffszeit von 450 nsec. Ist das vielleicht zu langsam?

In meiner EPROM-Schachtel finde ich nur Hitachi HM482732. Die kann mein TL866 EPROM Brenner nicht schiessen.

Ich finde ein Hitachi 462532, das ich mit einem Galep 4 brennen kann. Das hat aber ebenfalls eine maximale Zugriffszeit von 450 nsec.

Ich hole einen Notebook mit Windows 2000 hervor und brenne das 462532 trotzdem.

Beruhigend ist, daß der GALEP 4 die gleiche Checksum anzeigt, wie auf dem Firmware EPROM aufgepinselt.

Da sind in der Vergangenheit glücklicherweise keine Bits gekippt.

Der Test ist ernüchternd. Mit dem neuem EPROM funktioniert der FDC überhaupt nicht.

Ich bastele mir einen 2764 zu 2732 Adapter und schiesse die Firmware in ein 2764 EPROM mit 250 nsec Zugriffszeit.

Damit funktioniert der FDC, aber der Fehler bei der Datenübertragung ist unverändert da.

Ich bin auf einer falschen Spur. Später messe ich Setup- und Hold-Zeit der EPROM Daten mit dem 450 nsec 2732.

Setup- und Hold-Zeiten sind ausreichend.

Das ist nicht das Problem.

Während der Datenübertragung vom Speicher des FDC in den Speicher des Zielrechners, der dann abrupt endet,

macht der Z80 auf dem FDC zwei Opcode Fetches, einen Memory-Read-Zyklus und einen Memory Write Zyklus.

Der Z80 auf dem FDC führt hier einen LDIR-Befehls aus, Opcode = ED B0. Der Opcode wird nach jedem Transfer neu aus dem EPROM geholt.

Nach jedem Opcode Fetch führt der Z80 auf dem FDC einen Refresh Zyklus aus.

Komisch, der Refresh Zyklus landet nicht auf dem ECB-Bus. Liegt da ein Design Fehler vor?

Im Moment ist das nicht wichtig. Ich verwende nur SRAM.

Hier ein Screnshot des Logic State Analyzer, der einen groben Überblick zu den Fehler gibt.

Zusätzlich zu den ECB-Bus Signalen sind der Datenbus und einige Control Signale des Z80 auf den FDC angeklemmt.

Die Signale sind an einem vorangestellten "F" zu erkennen.

Zu beachten ist, daß der Datenbus auf dem FDC und auf der CPU jeweils durch einen invertierenden Treiber (74LS640) getrieben werden.

Aus einem Datum E4 am FDC-internen Datenbus wird ein 1B auf den ECB-Bus.

Der FDC holt sich den ECB-Bus über BUSREQ_N und transferiert einige Bytes in den Speicher des Zielrechners.

Dann kommt die Übertragung zum HALT. Der Schreibzyklus, in diesem Falle auf Adressse 801B des Zielrechners wird nicht beendet.

Ihr seid auf der richtigen Spur mit den Abblockkondensatoren und den Störungen auf der Versorgungsspannung.

Um das zu erkennen, habe ich aber noch ein paar Runden gedreht. Ich hoffe, dass ich die Story am Abend weiter erzählen kann.

Dass der Clock des Z80 vom ECB-Bus abgenommen wird, hat mich auch erstaunt. Ich habe den Clock irgendwann nachgemessen

und war erstaunt, daß das Ergebnis recht gut ausfiel.

Ich habe dann trotzdem eine kleine Schaltung aufgebaut mit 16 MHz Quarz-Oszillator, 4-fach-Teiler und nachgeschaltetem Treiber.

Das hat damals zwar für einen ganz sauberen Clock gesorgt, aber der Fehler hat sich dadurch nicht verändert.

Im Zuge der Verdrahtung der Schaltung habe ich festgestellt, daß die Entwickler schon damals Probleme mit dem Clock gehabt haben müssen.

Per Fädeldraht ist eine Änderung eingebaut worden, durch die der Clock vom ECB-Bus zunächst einmal über ein freies AND Gate gepuffert wird, bevor er der Schaltung zugeführt wird.

Der 330 Ohm Pullup am Clock auf der FDC-Karte soll den high Pegel noch ein wenig anheben. An anderer Stelle habe ich gelesen, daß der Z80 besondere Anforderungen an den Clock hat. In anderen Schaltungen. z. B. bei Janich und Klass, habe ich gesehen, daß der Clock über zwei Transistoren getrieben wird.

Auf der CPU-Karte wird der Clock über einen 74LS14 getrieben.

Die Schreib-Zugriffe bleiben bei unterschiedlichen Adressen hängen. Die Situation ist aber immer die gleiche.

Daten werden per LDIR vom Speicher des FDC in den Speicher des ECB-Rechners geschrieben.

BUSREQ_N wird auf dem FDC über einen I/O-Port erzeugt.

Im Listing weiter vorn ist zu sehen, wie BUSREQ_N vor dem LDIR-Befehl aktiviert wird und danach wieder deaktiviert wird.

Die Schaltung des FDC auf auf oldcomputers ist der richtige. Funkenzupfer hat sich die Mühe gemacht, die beiden Hälften des Schaltplans zusammenzuführen, siehe weiter vorn in diesem Thread.

Die PROMs und ihre Pull-Up-Widerstände muss ich mir ansehen.

Vielen Dank für die vielen Anregungen!

Im Fehlerfall bleibt der Rechner einfach stehen, stürzt nicht etwa unkontrolliert ab.

Statisch habe ich gemessen, daß der Flopppy Controller BUSREQ aktiviert hat und nicht wieder deaktiviert.

Der Z80 auf dem Floppy Controller scheint zum absoluten Stillstand gekommen zu sein, obwohl die Inputs des Z80 auf den FDC wie WAIT_N, BUSREQ_N, RESET_N inaktiv sind. NMI_N, INT_N und HALT_N sind ebenfalls inaktiv.

Ich schiebe die ECB-Bus Tracer-Karte ein und triggere den Logik-State Analyzer auf ein Timeout, BUSAK_B aktiv für einige Millisekunden.

Ok, das funktioniert nicht gleich, Der Floppy Controller aktiviert BUSREQ_N bei jedem Floppy Zugriff zwei Mal. Zunächst aktiviert er BUSREQ_N zu Anfang und liest den IOPB über den ECB-Bus aus dem Speicher des Rechners. Dann vergeht viel Zeit, bevor der FDC das BUSREQ_N-Signal ein weiteres Mal aktiviert und die Daten von der Floppy in den Speicher des Rechners überträgt.

Ich lasse den Logikanalyzer auf die zweite fallende Flanke des BUSAK_N Signals warten und triggere dann auf eine Timeout-Bedingung des ECB-Bus Write Signals. Einige Male kann ich auf den Fehler triggern indem ich den Triggerpunkt ganz weit nach hinten schiebe.

Im Fehlerfall bricht die Übertragung einfach ab bei einem Schreibzugriff des FDC auf den Speicher des Rechners. BUSAK_N , MREQ_N und WR_N sind dauerhaft aktiv. Keines der Signale, die den Z80, der die Übertragung auf dem FDC steuert, anhalten könnte, ist aktiv.

Ich muss noch einige Signale des Z80 auf dem FDC anklemmen. Zunächst klemme ich nur wenige Signale an, RD_N, WR_N, M1_N, MREQ_N, IOREQN.

Der Rechner scheint in einer ganz kurzen Schleife zu laufen. Ich sehe nur zwei M1-Zyklen, gefolgt von Memory Read und Memory Write Zyklen.

Was kann den Rechner hier stoppen?

Ich habe noch 16 Kanäle frei. Im nächsten Schritt klemme ich A15:A0 des Z80 auf dem Floppy Controller an.

Ich möchte wissen, wo im Programm der FDC-Rechner im Fehlerfall kreist.

Zu dem Floppy Controller habe ich beim Kauf ein Listing der Firmware bekommen. Schon vor einiger Zeit musste ich feststellen, daß das Listing nicht zum Programm passt. Das Binary ist glatt doppelt so groß wie das laut Listing zu erwarten wäre. Da bin ich nachträglich noch ein wenig angefressen.

Ich hatte schon vor einiger Zeit einen Disassembler auf das Binary losgelassen. Das Binary ist Disassembler-freundlich. Tabellen befinden sich am Ende des Codes. es sind so gut wie keine Texte embedded.

Der Z80 auf dem FDC hängt hier in der LDIR Instruction, die einfach stehen bleibt.

M059F LD DE,(M8009) ;

EXX ; Strich-Register zur Adressierung I/O

LD BC,(M8002) ; M8002 = Speicherstelle CPUPOR

SET 1,B ; Set Busrequest active

RES 0,B ; BIT 0 ????

OUT (C),B ;

EXX ; Normale Register

LDIR ; LDIR +++++

EXX ; Strich-Register zur Adressierung I/O

RES 1,B ; Clear Busrequest

RES 0,B ; BIT 0 ????

OUT (C),B ;

EXX ; Normale Register

RET ;

OK, die kopierten Tabstops kommen nicht an. Das muss ich korrigieren, sonst ist es nicht lesbar.

Ich will nicht nur die Z80-Signale am ECB-Bus aufzeichnen. Auf dem Floppy Controller befindet sich ein weiterer Z80, den ich idealerweise

gleichzeitig anklemmen würde. Im Moment benutze ich 48 Kanäle für den ECB-Bus. Die 16 noch freien Kanäle benutze ich zur Überwachung

des Z80 auf dem FDC-Controller. Ich schliesse abwechselnd entweder den 16-Bit Adressbus des Z80 auf dem FDC-Controller oder den 8-Bit Datenbus

und die wichtigsten Control-Signale an.

In meinem TLA-714 ist ein Modul TLA-7N2 eingebaut mit 2 GHZ Timing, 100 MHz State und 256 K Speichertiefe.

In mein Gerät kann ich maximal einen weiteren Einschub einbauen.

Einer deiner TLA7N4 Option 6S (1M Depth, 200MHz State) wäre da sehr passend.

Ich könnte den TLA-7N2 natürlich auch durch einen TLA7N4 ersetzen.

Für die 8-Bit Welt, in der ich mich zur Zeit bewege, wären 138 zusätzlichen Kanäle mehr als genug.

Ich weiß jetzt nicht, ob man Module mit verschiedenen Ausstattungen bzgl. Timing und Speichertiefe zusammenschalten kann.

Ich habe für den Analyzer mit den Anschlusskabeln 330 € bezahlt.

An einem weiteren Einschub für den TLA-714 bin ich interessiert.

Mein TLA-714 läuft mit Firmware 4.x. Deshalb kann ich einige neuere Einschübe nicht verwenden.

Ich hänge eine Datei mit den Einschüben an, die für den TLA-714 passen.

Beim ECB-Adapter habe ich einige Signale aufgelegt, die man nicht unbedingt benötigt, wie MEMD ( Memory Disable), 2PHI, IEI und IEO.

Ich hänge zwei Dateien mit der Belegung des ECB-Bus Adapters an.

In die 18-poligen Sockel können Widerstandsarrays, mit Pull-Up Widerständen eingesetzt werden.

Daneben lade ich einen Screenshot des TLA-Setups hoch. Zu beachten ist, daß an PODs A2 und A3 Datenbus und Control Signale des Z80 auf dem Floppy Controller angeschlossen sind. Sie gehören nicht zum ECB-Bus Adapter.

Interessant, dieser Link auf das Programm, mit dem man ISIS-Dateien auslesen kann.

Aber neue Erkenntnisse, wie die Daten auf meinen Disketten organisiert sind und wie sich das im Vergleich zu Original Intel Disketten verhält,

habe ich nicht gewonnen. Im Kommentar des Programms wird gesagt, daß alle Intel Double Density Disketten doppelseitig sind.

Das würde ich anzweifeln.

Das Double Density Format der vom Lakosa FDC geschriebenen 8 Zoll Double Density Disketten ist evtl. nicht kompatibel zu dem der

Intel Double Density Disketten. Ich vermute, daß ich immer Single Density Disketten verwendet habe, um Daten mit dem Intellec MDS in der Firma auszutauschen.

Nun weiter mit den Messungen, mit denen ich versucht habe, den Fehler einzugrenzen.

Hier kam es mir zugute, daß ich vor Weihnachten nach Ulm gefahren bin, wo ich einen Tektronix TLA-714 Logik State Analyzer erwerben konnte.

Auf dem TLA-714 läuft die gleiche Firmware wie auf den TLA720 und TLA721, mit denen ich noch vor einigen Jahren gearbeitet habe.

So konnte ich gleich loslegen, ohne mich in die Bedienung einarbeiten zu müssen.

Also auf nach Ulm. Für die Hin- und Rückfahrt habe ich ziemlich genau 1000 km zurückgelegt und ziemlich genau 100 Liter Diesel verbrannt.

Das war es mir aber wert. Auf dem Versandwege kann ziemlich viel schief gehen.

Vom Weihnachtsmarkt in Ulm habe ich leider nur einen Ausschnitt gesehen. Die Anfahrt und die Suche nach einem Parkplatz haben zu lange gedauert.

Es reicht noch für einen alkoholfreien Punsch und für eine Weisse. Das ist eine stinknormale Bratwurst.

Ich hätte vielleicht doch eine Roode nehmen sollen.

Um 18:00 ist die Übergabe bei der Verkäuferin. Das Gerät funktioniert. Der Kauf geht schnell über die Bühne.

Sehr gut ist, dass alle Kabel beim Gerät sind. Sogar die Einzel-Litzen für 6 Pods sind dabei. Die Grabber für die Einzel-Litzen fehlen, aber das kennt man ja.

Übernachtung auf dem Womo Stellplatz in Lauingen ca. 30 km nördlich von ULM und Rückfahrt am nächsten Tag.

Im Gerät ist ein Einschub TLA 7N2 eingebaut, der 64 (68) Kanäle unterstützt. Um den ECB-Bus aufzuzeichnen benötige ich 48 Kanäle.

Die verbleibenden 16 Kanäle reichen leider nicht, um die Signale des Z80 auf dem FDC Board aufzuzeichnen.

Die 48 Kanäle kann man unmöglich einzeln am ECB-Bus anschließen. Ich habe mir ein Adapterboard gebastelt, das ich in einen

ECB-Bus Slot einstecken kann und auf das die PODS direkt aufgesteckt werden können.

ich arbeite neben der Geschichte mit den Diskettenformaten seit einigen Tagen daran,

zu messen, warum der Rechner bei einem Zugriff auf das Diskettenlaufwerk hängt.

Viele Schritte waren notwendig.

Heute habe ich den ersten kleinen Erfolg zu vermelden.

Ich konnte ISIS-II Ver. 4.3 von einer im Single Density Format beschriebenen Diskette booten.

Ich konnte sogar ein DIR Kommando ausführen und die auf der Diskette gespeicherten Dateien wurden angezeigt.

Beim zweiten Aufruf des DIR Kommandos kam allerdings der Command Prompt nicht wieder.

Bei einem zweiten Boot-Versuch verzweigte der Rechner nach einem Interrupt in das Monitorprogramm.

Der Rechner läuft noch nicht stabil genug.

Ich habe dann auf dem 80486 Rechner noch einmal eine Double Density Diskette mit Imagedisk generiert.

Dazu habe ich eine Samsung SFD-321B benutzt, die ich auf 360 RPM umgebaut habe, benutzt.

Ich hatte zuvor bereits eine .IMG Datei mit BIN2IMD nach IMD gewandelt mit den Parametern:

77 Tracks, 26 Sektoren, 256 Byte/Sector

(IS243DD.IMG)

Ich konnte Track 00, Sektor 1 auslesen und habe gleich versucht ISIS-II von der Double Density Diskette zu booten.

Hurra, ISIS-II Ver. 4.3 bootet von der Double Density Diskette.

Daß ich mit der auf 360 RPM umgebauten Floppy erfolgreich sein würde, ist mir einleuchtend.

Ich will Imagedisk und dem Zielrechner schließlich eine 8 Zoll Diskette vorgaukeln, die mit 360 RPM dreht.

Warum ich allerdings das Format mit 77 Tracks zu 26 Sektoren mit 256 Bytes verwenden muß, ist für mich nicht einsichtig.

Warum läuft der Rechner jetzt besser als zuvor?

Ich sage nur "Signal-Integrity".

An den nächsten Abenden werde ich unter diesem Thread aus dem Keller berichten,

welche Schritte ich versucht habe, um näher an den Fehler ran zu kommen.

Es bleibt noch einiges zu tun, stabil läuft der Rechner immer noch nicht, ein wenig besser als zuvor aber schon.

Ich lade die die beiden Images, die ich erfolgreich booten konnte hier hoch.

Hier ein Teraterm-Abzug des erfolgreichen Boot-Versuchs

@inp 7e

40

@dread 0 0 1 1 8000

INSERT DISK, TYPE CR !

IOPB : 80 04 01 00 01 8000

IOPB : 80 04 01 00 01 8000

OK !

@disp 8000 80ff

00 .8000 C3 7D 30 4D 2A 0C ED EB CD 8F EB 2A 0C ED 3E 00 .}0M*#.....*#.>#

00 .8010 41 C3 21 F8 C5 E1 4E 06 15 CD 44 F8 16 04 23 4E A.!...N##.D.###N

00 .8020 06 16 CD 44 F8 15 C2 1E 30 C9 28 43 29 20 31 39 ##.D.#.#0.(C) 19

00 .8030 37 35 2C 31 39 37 36 2C 31 39 37 37 2C 31 39 37 75,1976,1977,197

00 .8040 38 2C 31 39 37 39 2C 31 39 38 30 2C 31 39 38 31 8,1979,1980,1981

00 .8050 2C 31 39 38 32 20 49 4E 54 45 4C 20 43 4F 52 50 ,1982 INTEL CORP

00 .8060 00 10 20 30 01 02 20 40 00 30 00 30 01 02 01 02 ## 0## @#0#0####

00 .8070 40 00 50 10 01 01 02 02 00 00 31 F3 3A 31 F3 3A @#P#######1.:1.:

00 .8080 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU

00 .8090 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU

00 .80A0 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU

00 .80B0 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU

00 .80C0 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU

00 .80D0 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU

00 .80E0 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU

00 .80F0 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU

@

@isis

INSERT ISIS-FLOPPY, TYPE CR !

DOUBLE DENSITY !

IOPB : 80 04 1A 00 01 3000

ISIS-II, V4.3

-dir i

DIRECTORY OF :F0:970003.08

NAME .EXT BLKS LENGTH ATTR NAME .EXT BLKS LENGTH ATTR

ISIS .DIR 26 3200 IF ISIS .MAP 5 512 IF

ISIS .T0 24 2944 IF ISIS .LAB 54 6784 IF

ISIS .BIN 94 11756 SIF ISIS .CLI 25 2984 SIF

ISIS .OV0 11 1279 SIF ATTRIB 41 5002 WSI

COPY 70 8582 WSI DELETE 40 4917 WSI

DIR 55 6908 WSI EDIT 59 7333 WSI

FIXMAP 51 6396 WSI FORMAT 63 7849 WSI

HDCOPY 49 6087 WSI HEXOBJ 35 4226 WSI

IDISK 63 7931 WSI LIB 82 10227 WSI

LINK 105 13074 WSI LINK .OVL 37 4578 WSI

LOCATE 120 15021 WSI OBJHEX 28 3430 WSI

RENAME 21 2439 WSI SUBMIT 40 4914 WSI

VERS 17 1930 WSI SYSTEM.LIB 26 3128 WS

PLM80 .LIB 45 5615 W FPAL .LIB 74 9125 W

1360

1360/4004 BLOCKS USED

Heute habe ich das Double Density ISIS-II Image ausprobiert.

Leider kann ich die Diskette mit dem Z80-Rechner nicht lesen.

Der Floppy Disk Controller meldet einen Address Error, sobald ich Track 00, Sector 1 einlesen will.

Auf dem Zielrechner habe ich eine 3,5 Zoll Diskette formatiert, 77 Tracks, 52 Sektoren a 128 Bytes, Format Byte = E3.

Diese Diskette habe ich dann auf dem 80486 PC mit Imagedisk eingelesen.

Dazu habe ich ein auf 360 RPM modifiziertes Samsung SFD 321B Laufwerk benutzt.

Imagedisk archiviert die Diskette mit der Organisation 77 Tracks, 26 Sektoren zu 256 Byte.

Ich lade die IMD-Datei mal hoch.

Vielleicht hilft dir die Datei, zu verstehen, wie das DD-Format auf meinem Zielrechner aufgebaut ist.

Die Datei ist sehr kurz.

Das liegt vermutlich daran, dass die Daten komprimiert sind und die Daten immer gleich sind.

Ich habe ebenfalls ein Samsung SFD-321B Floppy Laufwerk auf 360 RPM umgebaut

aufbauend auf dem oben genannten Link und bin auf Unstimmigkeiten gestoßen.

Ich habe meinen Umbau in der angehängten Datei dokumentiert.