Mein Micro‑Expander Model 1
(Die Seite ist noch im Aufbau und wird gerne erweitert.)
(English translation by Google)
2020-04-18
Das Micropolis Doppellaufwerk und der Floppy-Controller
Im Januar habe ich diese schönen Stücke bekommen. Der Micropolis S-100
FloppyController wird vom Micro-Expander Monitor unterstützt. Naja,
unterstützt, d.h. es gibt einen Sprungbefehl zum Boot-ROM des
FloppyControllers.
Nach der Analyse der Boot-PROMs kam wieder die Frage des Betriebssytems
auf. Klar sollte es CP/M sein. Also wieder suchen.
Die Firma Vector Graphic hatte den Micropolis Floppycontroller in den
eigenen Computern verbaut und vertrieben. Und Vector Graphic hatte auch
ein CP/M System, ein weiteres gab es von Lifeboat. Ausreichend Auswahl
gibt es auf Mikes Webseite deramp.com.
Ich hatte mir 4 Diskettenimages angeschaut. 3 davon haben das gleiche
System, deshalb habe ich mich für ein Image von Mike entschieden. I.a.
sind hier alle wichtigen Programme schon vorhanden.
Jetzt hatte ich wieder mein Problem: Wie kommt das Image auf Diskette
oder wie kann der Computer booten?
Es blieb wieder nur der Weg über meinen selbstgestrickten
Floppy-Emulator. Der musste erstmal an die Disketten (16 Sektoren statt
bisher 10) und das komische Micropolis Format mit 275 Bytes/Sektor (256 Bytes
Nutzdaten, Rest ist Synchronisation, Track- und Sektornummer, Checksum und
ein paar Dummy-Daten) angepasst werden.
Um das BIOS ändern zu können, habe ich erstmal ein kleines Programm
geschrieben, was mir die reinen Nutzdaten in ein separates Image
schreibt. Bei der Analyse des Bootloaders war schnell der verwendete Skew
von 3 auf der
Diskette erkennbar. Kein Problem, macht das Programm mit. Jetzt hatte ich
schon mal die Systemtracks extrahiert. Bei der Ansicht der Datentracks war
aber das Directory sehr zerpflückt. Im Original-Image habe ich dann den
Skew von 5 gefunden. 2 unterschiedliche Skew, sehr ungewöhnlich. Im BIOS
war dies aber nachvollziehbar. Ok, Software nochmal anpassen.
(Fortsetzung folgt)
2020-01-25
Der Memory-Test
Eigentlich wollte ich mich mit dem neuen Micropolis Floppy-Controller
beschäftigen. Aber der Micro-Expander startete mal wieder nicht.
Nach ein bischen nachmessen und nachlöeten gings wieder, aber bei kurzen
Eingaben ins Memory kam i.a. nur Blödsinn zurück. Jetzt muss ein
Memorytest her!
Allerdings ist der Monitor voll, also die unnötigen Cassetten-Routinen
können raus. Aber erstmal ein assemblierbares Source haben. Mit Disassembler
und vorhandenem Monitor-Source war die Aufgabe beherschbar.
Die ersten Memorytests mit einfachen Pattern mit 0x55 und 0xAA brachten
schon sehr seltsame Ergebnisse. Kaum ein Testdurchlauf bestätigte das
Ergebnis des Vorläufers. Alles nur Huddel! Also wieder Messen!
Und schon die 3. Adressleitung kam nicht am S-100 Bus an. Mal wieder eine
dieser alten, kaputten Durchkontaktierungen. An der gleichen Leitung hatte
ich schon mal repariert.
Danach liefen die Tests alle gut. Allerdings ist "gut" bei 0x55 und 0xAA
nicht wirklich aussagekräftig.
Deshalb wollte ich jetzt den
RAMBUG in den Monitor einbauen. Das hat dann
ein wenig länger gedauert. Auch die Test dauern etwas länger, aber jetzt
habe ich ein gutes Gefühl: Alle Tests positiv! Zum Test habe ich mal ein
ICs rausgezogen, hier das Ergebnis:
Jetzt konnte ich mich über den Micropolis Floppycontroller
hermachen.
2018-03-10
Es ist viel passiert, und es hat lange gedauert.
Nachdem das CP/M bootet, habe ich gedacht, klappt auch das Schreiben auf
Disketten. Aber dem war gar nicht so.
Alle Versuche, die emulierte NorthStar-Diskette auf eine richtige
Diskette zu kopieren, funktionieren nicht anständig. Manchmal läßt sich
das Directory der Diskette noch lesen, beim nächsten Mal geht's schief.
Alles ist instabil, aber ich sehe nicht warum.
Ich entscheide mich noch die Lifeboat CP/M zu probieren. Also wieder
Image analysieren, Binärfile diassemblieren, usw. Zu meiner Überraschung
ist das Lifeboat Image deutlich einfacher aufgebaut. Aber das sagt über
die Funktion auch nichts aus.
Und wie es kommen musste, Lifeboat bootet ohne nennenswerte Änderungen
(Erfahrung zahlt sich aus! :-) ). Aber Tests beim Schreiben gehen genauso
gut (sagt der Optimist) oder schlecht (sagt der Pessimist) aus.
Ich habe von Christian die Original-Laufwerke geholt, die damals bei
dem Controller dabei waren. Aber auch mit denen funxt es nicht.
Mir fällt auf, das die Laufwerke gar nicht mehr die Track0 Position
anfahren. Das erklärt einige Fehler. Auf den NorthStar-Disketten ist keine
Kennung auf welchen Track der Lesekopf ist. Die Software kann nur mit
dem Track0-Signal und zählen der Step-Impuse die richtige Spur anwählen.
Aber anscheinend geht hierbei etwas schief.
Das ist der richtige Zeitpunkt den geplanten Floppy-Tester
aufzubauen.
Der Floppy-Tester
Die Idee zu einem Floppy-Tester gab es schon länger. Der Floppy-Emulator
ist aus dem Projekt entstanden. Ich habe die Schaltung so erweitert, das
ich jede Leitung auf dem Shugart-Bus einlesen und ansteuern kann. So kann ich
alles testen, und der Floppy-Emulator bleibt auch möglich.
Dann hab ich Schaltung und Software entwickelt, um die Floppy zu
aktivieren, das Sektor/Index-Signal auswertet und die Signale für das
Tracking erzeugt. Mit dem letzten habe ich erstmal die Floppy-Laufwerke
getestet, was mit dem Track0 los ist.
Step-Impulse für Anfänger
Ich habe das Direction- und das Step-Signal nach Datenbuch eingestellt und
wie erhofft und zu erwarten war, rennt der Schreib-/Lesekopf nach aussen
und nach innen und wieder raus. Genau die Anzahl der Tracks, die ich
einstelle. Auch die Step-Frequenz kann ich einstellen und teste diese auch
an den unterschiedlichen Laufwerken. Hier ist alles ok, also muss der
Fehler woanders liegen.
Stepping unter CP/M
Also mal sehen wie das CP/M steppt. LA wieder raus, ja, ein Oszilloskop
reicht zum messen des Step-Signals. Aber ich will auch wissen wo in der
Software das Stepping erzeugt wird um dann das Delay für die Steprate
finden. Mit dem LA kann ich sehen welcher Befehl das Step setzt. Ok, die
Steps kommen ca. alle 5ms, das ist ganz klar viel zu schnell für die
alten 40-Track Laufwerke.
Die Step-Delay Routine ist zügig gefunden. Es wird ein Wert aus einer
Speicherstelle gelesen und entsprechend oft eine Verzögerung durchlaufen.
Aber wo kommt dieser Wert her? Auch das Schreiben auf die Speicherstelle
ist mit dem LA schnell gefunden. Nach ein bischen Softwareanalyse ist
klar, die Funktion misst die Zeit für einen Sektor und legt dies als Delay
fest. Warum aber das Steprate-Delay nur einem Viertel der Sektorzeit
entspricht, ist mir vollkommen unklar.
Wie dem auch sei, irgendwie muss ich das Steprate-Delay hochdrehen.
Eine Idee war, statt der Sektorzeit die Indexzeit, also eine gesamte
Diskettenumdrehung, zu nehmen. Zum Glück sind mir zwischendurch ein paar
PDFs über das Liveboat CP/M aufgefallen. Und da stosse ich auf das
Konfigurationsbyte CONFG, in dem für 4 Laufwerke ein Double-Side Flag und
ein Fast-Step Flag gesetzt werden kann. Beides war für Laufwerke A und B
gesetzt. Auch eine genauere Okularinspektion der Delay-Routine bestätigt
das Fast-Step Flag. Also, Versuch macht klug!
CONFG Byte geändert, Assembler gestartet, Binärdatei ins Image kopiert,
Floppy-Emulator programmiert, CP/M neu gestartet, Steprate gemessen und
... es sind ca. 40ms Delay. Was so ein Bit ausmacht, wenn man es
kennt.
Reboot tut gut!
Ein neuer Versuch für die richtigen Floppy-Laufwerke
Ich habe also wieder ein 40-Track Laufwerk angeschlossen und mit dem
Copy-Programm die Emulator-Diskette 1:1 auf eine richtige Diskette kopiert.
Dann den Emulator abgebaut, das DriveSelect des Floppy-Laufwerks
umgestellt und ...
GEBOOTET !
CP/M bootet endlich von einer Floppy-Disk.
Das NorthStar CP/M hat beim Stepping das gleiche Problem. Also auch
hier mal schauen. Interessanterweise finden sich in dem NorthStar CP/M
fast die gleichen Routinen wie im Lifeboat CP/M, sogar das CONFG ist bei
NorthStar gleich. Ist die Frage, wer hier von wem abgeschaut hat.
2017-12-25
CP/M 2.2 bootet
Nach viel lesen, einigen Überlegungen und vielen Änderungen hat der
Expander ein CP/M 2.2 gebootet.
Erweiterung des Floppy-Emulators
Bisher hatte der Floppy-Emulator alle Tracks gleich emuliert. Für
eine anständige Diskette reicht das leider nicht. Also habe ich den
Emulator erstmal erweitert. Da die Floppy-Imagedaten nicht ins FPGA passen,
muss das SPI-Flash diese aufnmehmen. Ein Trackwechsel dauert bei einem
Floppy-Laufwerk relativ lange (um die 20ms und mehr), hier ist genug Zeit
die Daten aus dem SPI-Flash zu lesen und im FPGA zu speichern.
CP/M, woher nehmen?
Zeitweise hatte ich mich schon damit abgefunden das BIOS (den
hardware-abhängigen Teil) selber schreiben zu müssen. Da ich zum Glück ein
fauler Kerl bin (Lieber 5 Minuten nachdenken, als 15 Minuten
programmieren.), ist mir aufgefallen, das der NorthStar Horizon mit
dem gleichen Floppy-Controller ein funktionierendes BIOS haben muss. Also
sind doch alle BIOS-Funktionen für die Disketten vorhanden. Die
BIOS-Funktionen für die Console Ein- und Ausgaben sind deutlich einfacher
zu entwickeln als die für Disketten.
Also habe ich ein CP/M Disketten Image von
Dave Dunfield für den NorthStar genommen, die CP/M
Spuren extrahiert und analysiert. Dazu gehörte das Verstehen des
Bootloaders (der eine Sektor, der der ganzen Rest lädt und startet), wo
ist das BIOS und das Verstehen der wichtigsten Funktionen, wo kann oder
muss ich was ändern, erkennen, das noch ein Monitor-Programm geladen wird,
und einiges mehr.
Natürlich klappte der erste Boot-Versuch nicht. Mit dem Logic Analyzer
konnte ich die Hängenbleiber finden. Dann habe ich den disassemblierten
Sourcecode geändert, übersetzt und von Hand ins Diskettenimage
kopiert. Nach ein paar Versuchen bekam ich dann die erste Bootmeldung,
etwas später den Prompt. Leider klappte die Zeicheneingabe noch nicht. Der
Expander-Monitor macht die Tastaturverarbeitung im Interrupt. Nachdem ich
für die BIOS-Funktionen CONIN und CONST die Interrupt freigegeben habe,
erschienen auch die Tastatureingaben auf dem Bildschirm.
GESCHAFFT !!
2017-11-24
Ein sinnvoller Bootcode
Für den morgigen Kölner Retrotreff habe ich einen Bootcode geschrieben,
der wenigstens kurz eine Meldung ausgibt und dann den Monitor wieder
anspringt. So kann man wenigstens was sehen, auch ohne LA.
2017-11-12
Der Floppy-Controller
Wie schon gesagt, braucht der North Star Micro Disk Controller
hardsektorierte Disketten. Da ich diese nicht habe, wollte ich mir einen
Adapter bauen, der die Sektorimpulse aus dem Indeximpuls erzeugt. Deshalb
habe ich ein Indeximpulsperiodenmessgerät gebaut, um ein Gefühl für die
Schwankungen zu bekommen. Diese sind messbar, aber nicht dramatisch.
Danach habe ich mit Diskimage-Software beschäftigt, um Daten auf
Disketten schreiben zu können, von denen ich dann wieder booten kann. Aber
nach einigen Versuchen, Überlegungen und Gesprächen und Mails mit
Gleichgesinnten ist mir klar geworden, daß das nicht klappt. Die bekannten
Diskimage-Programme können nur mit softsektorierten Disketten umgehen.
Also, wie kann ich mit dem Floppy-Controller booten ohne Disketten? Da
ich auch nicht weiß, ob der Floppy-Controller funktioniert, ist eine
Datenquelle sinnvoll, die immer gleiche Daten sendet, um Messungen am
Floppy-Controller oder Softwaredebugging durchführen zu können. Aus diesen
Gründen habe ich mir einen Floppy-Emulator gebaut.
Der Floppy-Emulator
Das hört sich kompliziert an. Wenn man nur von der Floppy liest, also
die Floppy nur Daten liefert, ist das aber gar nicht.
Wenn DeviceSelect (DS) und MotorEnable (MotEnb) aktiv sind, "dreht" sich
die Floppy und erzeugt die Sektor- und Indeximpulse. Ist der
Schreib-/Lesekopf auf der äußersten Spur, wird Track0 (Trk0) aktiviert.
Über Direction (Direc) und Step überwache ich die Spurauswahl.
Bei den Lesedaten (ReadD) wird es etwas umfangreicher, aber bei den
hardsektorisierten Disketten übersichtlich. Nach der Floppy-Controller
Dokumentation wird nach jedem Sektorimpuls und einer kurzen Pause
32 Null-Bytes, 2 Sync-Bytes, 512 Daten-Bytes und das
Checksum-Byte geschrieben (bei Double-Density). Genauso gibt der
Floppy-Emulator die Daten aus. Als erstes Datenbyte wird die Sektornummer
genommen, das 11. ist 0x76 (HALT-Befehl), der Rest wird mit 0xA5 gefüllt.
Jetzt kommt noch das North Star Format: Die ersten 2048 Bytes der Floppy
(also 4 Sektoren DD oder 8 Sektoren SD) sind
Inhaltsverzeichnis, danach kommen Daten bzw. ein Bootcode. Warum der
Bootcode bei 0x0A (also das 11. Byte, s.o.) angesprungen wird, weiß ich
nicht.
Expander mit Floppy-Emulator
Wieder zum Floppy-Controller
Jetzt sollte das Laden des Bootcodes doch klappen. Aber so schnell
geht's doch wieder nicht.
Wie weit der Start-Code des Controller kommt, kann ich mit dem LA
kontrollieren. Und das sieht ganz gut aus, das einzige, das Body-Flag (was
auch immer das ist) wird nicht gesetzt. Also geht's doch wieder in die
Hardware.
Nach einigem suchen im Schaltplan und messen wird mir die Schaltung
nicht wirklich verständlich. Da der Controller anscheinend auch als Bausatz
erhältlich war, gibt es im Manual ein Board Checkout, 3 Seiten Anleitung
was man an welcher Stelle messen soll. Schaden kann es nicht, also fange
ich mal an. Und nach 2 Seiten messen fehlt mir ein Takt, BINGO. Es ist
keine Unterbrechung, der 74'123 gibt genau das vermeitliche Taktsignal so
aus. Das IC gehört zu einem VCO (steht so im Schaltplan) und wird u.a. von
einem Operationsverstärker angestuert. Und genau der macht nicht, ja wie,
kann er auch nicht, die Versorgungsspannung fehlt. Also den Floppy-Controller
wieder ausgebaut und der Fehler war ja sehr offensichlicht, beim Rückbau
habe ich eine Leiterbahnunterbrechung übersehen.
Wieder den StartCode gestartet und, schwups, war der Z80 im HALT-State,
genau was der Bootcode mit dem 0x76 Byte erreichen wollte. Damit war
vieles erreicht, der Floppy-Controller funktioniert, der StartCode läuft
und der BootCode wird ausgeführt. Jetzt muss ich nur noch was anständiges
zum Booten finden...
2017-11-06
Die zickige S-100 Backplane, Teil 2
Natürlich waren die Startprobleme durch die schönen Kabel nicht
beseitigt, wäre auch zu schön gewesen. Also den Logic Analyzer wieder
angeklemmt und, etwas überraschend, hatten wir das gleiche Problem wie
beim ersten mal. Und, schnell nachgemessen, hat
das Inverter-IC U2 wieder keinen GND. Hmmm, eigentlich war das Problem
doch erledigt. Die Backplane wieder ausgebaut und nochmal die beteiligten
Leiterbahnen nach Unterbrechnungen abgesucht und gemessen. Ich habe nichts
auffälliges gefunden, aber auf der Bestückungsseite kann ich durch den
fehlenden Röntgenblich nicht unter die IC-Sockel schauen. Ist es wieder
eine Durchkontaktierung oder nur die Lötstelle? Nicht lange diskutieren,
der Sockel muss runter.
So richtig schön sieht das nicht aus. Aber der GND Pin (rechts unten)
hat Kontakt nach GND und auch die Durchkontaktierung ist ok. Allerdings
die Leiterbahn an Pin 12 ist etwas angefressen, hat aber Durchgang, aber
zur Sicherheit hab ich etwas Lözinn auf die Leiterbahn gezogen. Ok, Sockel
wieder einlöten und probieren.
Und zu meiner großen Freude hat der Expander sofort gestartet und auch
alles rütteln an der Backplane und drücken und schieben an den ICs hat zu
keinem Absturz geführt. Da ich die Lötstelle schon 2 mal nachgelötet
hatte, möchte ich mal wissen was die damals für ein Zeug verlötet haben.
Aber egal, es funktioniert, und hoffentlich möglichst lange.
Jetzt können wir uns wieder beruhigt dem Floppy-Controller
zuwenden.
2017-11-04
Die zickige S-100 Backplane
Mir war schon mehrmals aufgefallen, das die Mechanik nicht so gut
passt. Um das Mainboard in alle Buchsen zu bekommen, musste man immer
irgendwo schieben und drücken, Schraubenlöcher passen nicht so ganz, etc.
Bei genauerer Kontrolle habe ich gesehen, das die Backplane zwischen
Mainboard und IO-Platine (hinten mit Netzteil und Steckern nach aussen)
eingeklemmt ist. Auch drückt der Stecker der Spannungsversorgung die
Backplane in eine Zwangslage. Deshalb habe ich entschlossen, den festen
Stecker durch einen flexiblen zu ersetzten.
Ich habe noch einen P8/P9 Stecker, den ich aus einem alten PC Mainboard
ausgelötet habe, und die Kabel dazu. Ich denke das Stecker passt gut, ist
ja für hohe Ströme gemacht. Also den alten erstmal raus. Beim Entlöten
bleiben die Pins manchmal an kleinsten Lötzinnresten kleben, die sich mit ein
bischen wackeln mit einem leichten Knacks lösen. Hier gab es keinen
Knacks, die Pins klebten aber ein wenig. Und als ich den Stecker raus
hatte, wunderte mich das Gefrimmels an 2 Pins.
Da das Gefrimmels komplett um den Pin geht, kann ich mir nur vorstellen,
das dies die Durchkontaktierung im Bohrloch sein kann. Normalerweise
kriegt man die aber nicht so einfach raus, sondern nur, wenn überhaupt,
mit ziemlich Gewalt, bei modernen Platinen. Da diese Platine aber schon
ein paar "Besonderheiten" gezeigt hat, ist dies jetzt das wahre
Gesicht.
Jetzt erinnere ich mich, das bei Messungen 2 der Pins nie Kontakt
hatten. Ich hatte das immer auf äusserliche Korrosion an den Lötstellen
geschoben. Aber die Pins hatten gar kein Kontakt zur GND-Leitung! Die
GND-Leitung ist nur auf der Bestückungsseite verbunden, auf der Lötseite
sind nur einzelne Lötpads. Und die Durchkontaktierung dazwischen war
früher schon kaputt und hängt jetzt an den Pins.
Es geht um die Pins 6 und 7 vom Platinenrand gezählt.
Ich überlege, ob es noch mehr solcher Durchkontaktierungen auf der
Platine gibt. Wenn ja, Prost Mahlzeit!
Der Rest des Umbaus erfolgte dann ohne weitere Probleme. Da die
Verbindung zwischen Mainboard und IO-Platine auch nicht genau passte, habe
ich auch diesen festen Stecker und Buchse gegen Stiftleisten und
Flachbandkabel ausgetauscht.
vorher - nachher
Auch wenn es nicht original ist, ist jetzt die mechanische Spannung aus
den Platinen raus. Damit habe ich wenigstens in Zukunft meine Ruhe.
Hoffentlich!
2017-11-01
Erste Versuche mit einem Floppy-Controller
Von Christian habe ich einen North Star Micro Disk Controller zur
Verfügung gestellt bekommen. Den musste ich erstmal zurückbauen.
Um zu entdecken, wie der Controller funktioniert, hab ich ihn an ein
Floppy-Laufwerk angeschlossen und den Code im PROM gestartet.
Das hat leider nicht so gut geklappt, erstens braucht der Controller
hardsektorierte Disketten und zweitens zickt die S-100 Backplane wieder
rum. Es benötigte oft mehrere Versuche den Rechner zu starten, immer mit
wackeln und rütteln an der Backplane. Also erstmal wieder hier weiter
forschen.
2017-10-16
Endlich wieder messen
Mit einem halbwegs fundierten Schaltplan kann mich jetzt auf die richtige
Fehlersuche machen. Also erstmal wieder den LA angeklemmt und, ja klar,
nach dem 2. Opcode läuft der Z80 wieder ins Nirwana. Aber das war nicht
anders zu erwarten.
Im Vergleich zwischen ohne und mit Backplane ist das Signal am Pin P3-21
mit der Backplane dauerhaft auf Low. Also erstmal die Backplane
untersuchen und am besten auch einen Schaltplan zeichnen. Wieder das
gleiches Spiel: Bauteile in Schaltplan zeichenen und wieder piepsen.
Auf der Backplane wird das Signal sINTA erzeugt, das aus einem Buffer
kommt. Und der Buffer sollte über das Signal SDSBn, gestützt von einem
PullUp, und einem Inverter dauerhaft aktiv sein. Das SDSBn ist ein Signal
vom S-100 Bus, es kommt aber an einem Slotstecker nicht an. Ich verfolge
die Leitung und am ersten Slot kommt es an, am 2. nicht! Was ist das? An
Slot 4 und 3 ist das Signal verbunden, an Slot 2 auch, nur Slot 1 mag
nicht. In der Not löte ich den Pin an Slot 1 nach, ... und jetzt ist die
Verbindung da. So kann die Backplane zu einer schönen Baustelle
werden.
Zurück zum Buffer, der wird anscheinend nicht aktiv, also messen.
Und tatsächlich ist der Buffer nicht aktiv. Jetzt wird jedes Gatter
einzeln gemessen, also an den Inverter. Und zu meiner grossen Verwunderung
ist der Inverter am Eingang und am Ausgang auf high. So geht das
nicht! Da ich kein Ersatz habe, schau ich erstmal genauer. Und tatsächlich
hat der GND Pin kein Verbindung. Wie vorher auch schon, ein wenig
nachlöten und ... Taräääää, der Inverter invertiert, der Buffer buffert
und der Z80 dreht wieder seine Ehrenrunden in der Software. Wenigstens der
Übeltäter ist gefunden.
Da die RTC auch schaltplantechnisch vermessen ist, sollte dies jetzt auch
kein Problem mehr sein. Es wird auf die RTC geschrieben und gelesen, aber
es liegt noch ein Reset an dem Zähler an. Bis jetzt liegt das Board mit
der Backplane auf dem Tisch, also ohne Reset-Taster. Ich brücke die Pins,
die eigentlich am Öffner des Tasters sind. Und schwups, RTC-Reset weg und
alles ist gut.
An dem IC auf der Backplane ist noch ein Wackler drauf, aber zum ersten
mal ein Bildschirm ohne Buchstabensalat. Handbuch raus und wenigstens mal
ein Hexdump ausgeben. So sieht das aus.
Reset, da war doch was? Hier mal die ganze Reset-Schaltung.
Die Signale mit S100_ gehen an den S-100 Bus, teilweise auch intern.
Da gibt es erstmal den PowerUpReset, der die CPU und den Bus resetet. Der
Reset-Taster löst keinen Reset aus, sondern einen NMI (was im Monitor
aber zum gleichen Code führt). Wird also der Taster betätigt, wird über
U39b das S100_SlaveCLRn aktiviert (active low), dies setzt alle
Slaves/Peripheriebausteine zurück. Gleichzeitig setzt der
Schliesser S100_NMIn auf low und löst den NMI aus (S100_NMIn geht auch an
die CPU). Beides erfolgt auf dem Bus und intern.
Hinzu kommt, das auch die Karten auf dem S-100 Bus die Leitungen
aktivieren dürfen. Deshalb geht der S100_SlaveCLRn erst auf den Bus und
dann wieder intern.
Nur die Funktion der Schleife mit U39a, U58b und U19a ist mir nicht ganz
klar. Ich kann mir nur vorstellen, das dadurch die Leitungen am
Taster nicht prellen.
So, das war die Geschichte, die den Expander wieder ans laufen
brachte.
Aber es geht bestimmt weiter, es bleibt noch einiges zu tun.
2017-10-16
Der Schaltplan
Ich habe erstmal meine Notizen in den PC eingegeben. Dabei ist mir schon
aufgefallen, das es schwierig wird die Übersicht zu behalten, das man
nicht ein Bauteil 2 mal zeichnet. Deshalb habe ich erstmal alle ICs auf
Schaltplanseiten eingefügt und benannt. Bei den 111 ICs sind 3 große
Seiten entstanden. So kann ich mit Cut&Paste jedes der 239 Gatter
nur einmal verwenden.
Jetzt ging's ans Piepsen. An einigen Stellen geht's recht schnell,
vor allem wenn 8
Datenleitungen ziemlich parallel verlaufen. Auch sind die Funktionsgruppen
räumlich gut aufgeteilt. Aber die vielen „kleinen”
Steuerleitungen sind nicht ganz ohne. Durch die Bankinglogik gibt es
einige Möglichkeiten und dies braucht auch viele Gatter, die verbunden
sein wollen.
Insgesamt eine sehr mühselige
Arbeit, man weiss auch nie genau ob eine Leitung vielleicht an mehrere
Punkte geht. Sind 2 Eingänge verbunden, muss es ja eigentlich noch einen
Ausgang geben. Es könnte aber auch nur ein statisches Signal mit einem
Pull-Up sein. Hier muss man die Schaltung dann jeweils im Detail
betrachten.
Bei der ganzen Rumpiepserei haben die Nachbarn wahrscheinlich gedacht,
ich mache einen Morsekurs. :-)
Ich pieps gerade an dem neu eingesetzten 74LS00 rum und trau meinen Ohren
nicht! Dessen Ausgänge sind mit den Ausgängen des daneben liegende
U11, auch ein 74LS00, verbunden. Das gehört gar nicht! Nochmal
kontrolliert und die Eingänge mal verfolgt. Alle 4 NAND-Gatter des U11
bekommen Signale von der S-100 Backplane. Mir wird klar, das U10 und U11
eine Alternativbestückung ist. In der technischen Beschreibung ist ein
ME-50 Bus beschrieben, anscheinend eine vereinfachte Version des
S-100. Und U10 / U11 hat wahrscheinlich mit dieser Alternative
zu tun.
Also U10 wieder raus und später den eigentlichen Fehler weiter suchen.
Nach 4 Tagen gepiepse hatte ich keine Lust mehr. Der Schaltplan ist zwar
noch nicht fertig, aber große Teile, vor allem der Dekoder und die
Bankinglogik, sind erkennbar.
2017-10-14
Erster Erfolg, aber ...
Durch den ersten Erfolg habe ich der Stelle weiter gemacht.
Der Kurzschluss am IC-Ausgang kommt vom Reset-Taster, schon seltsam. Dann
ist der Reset-Taster auch noch ein Wechlser, nicht wie üblich ein
Schließer, wieder seltsam. Der Öffner-Kontakt geht an ein IC-Eingang, der
Schließer-Kontakt an dessen Ausgang, häää. Was soll das?
Aber Bilder sagen mehr als 1000 Worte.
Die Ausgänge sind OpenCollector (OC), durch den Taster geht also nichts
kaputt.
Aber an dieser Stelle war mir diese Schaltung vollkommen unverständlich.
Da ich
die Vorgeschichte des Expander nicht kenne, hatte ich die Befürchtung, das
hier etwas verbastelt oder ein defektes Bauteil falsch ersetzt wurde. Also
habe ich den Reset-Taster erstmal ausser Betrieb genommen.
Die Hauptplatine wieder eingebaut und ... hmmm, wieder werden beim 2.
Opcode falsche „Schrottdaten” gelesen. Das war's also nicht.
Noch ein Versuch ohne die S-100 Backplane und das sieht wieder besser aus.
Da auf der Backplane nur wenige ICs sind, hielt ich die für
unproblematisch. Da störte mich der unbestückte Sockel U10 weit mehr, und
hier sind auch Leitungen von der Backplane angeschlossen.
Aber welches IC fehlt hier? Wenn es sich um Logikgatter handelt, können es
bei einem 14-pol. IC 6 Inverter oder 4 AND/OR Gatter
sein. Die Inverter
kann man durch die
herausgefundene Beschaltung ausschliessen, bleiben AND/OR/NAND/NOR übrig.
Da 2 Gatter die
Eingänge verbunden haben, macht ein AND oder OR keinen Sinn, also bleiben
NAND oder NOR übrig. Da ich nur NANDs (also 74LS00) da hatte, habe
ich das mal
probiert, und ... haha! Immerhin arbeitet der Z80 wieder den Code im EPROM
ab.
Es sieht schon vieles gut aus. Allerdings bleibt die Software in einer
Schleife hängen. Zum Glück ist der Sourcecode verfügbar.
Es wird auf einen »RTC« Port geschrieben und gelesen. Da auf
dem Mainboard kein Akku oder Batterie verbaut ist (Zum Glück!) gehe ich
nicht von einer Real-Time-Clock aus, sondern eher von einer
Hardware, die mit einem schnellen Takt (Alles ist relativ!) zählt und
einen Interrupt auslöst, also einem „Real-Time-Counter”.
Ich habe dann mit dem Oszilloskop nach den Schreib- und Lesesignalen
gesucht, die auf den »RTC« zugreift, aber ich habe nichts
gefunden, aber auch gar nichts!
Das war's! Das ganze Design ist vollkommen undurchsichtig und ich finde
die RTC nicht! Jetzt mach ich erstmal einen Schaltplan! Ich will jetzt
erstmal ein wenig Klarheit. Nur wenn ich die Schaltung kenne, wenigstens
teilweise, kann ich anständig messen. Also, was sein muss, muss sein.
2017-10-13
Die erste Messung
Da nach den ersten Tests und Versuchen kein einfacher Fehler erkennbar war
(Jonas hatte mich ja schon vorgewarnt), habe ich direkt den Logic Analyzer
angeschlossen.
Direkt die erste Messung zeigt ein massives Problem.
Der Z80 startet bei
Adresse 0000h, hier wird der Sprungbefehl nach 0F006h (JP 0F006h,
Datenbytes C3 06 F0, hellblau eingefärbt) richtig gelesen und
ausgeführt (Adresse 0F006h, dunkelblau eingefärbt).
Hier liest der Z80 aber nur den „toten” Datenbus mit 0FFh
(RST 38h) und macht bei Adrese 0038h weiter. Hier befindet sich nur
uninitialisiertes RAM, also „Datenmüll”.
Das hier nach nichts mehr anständiges passiert, ist klar.
Deshalb habe ich das EPROM auch verkabelt. Aber das hat genau das gemacht was
es sollte. Also sind die Daten bis zur CPU verloren gegangen.
Am EPROM Ausgang kommt ein Buffer (74LS367), ok, aber danach nicht die CPU.
Also weiter suchen, es kommt noch ein Buffer. Und danach noch einer. Also 3
Schaltstellen vom EPROM zur CPU, nicht schlecht. Der Designer muss eine
Fabrik für 74LS367 gehabt haben, auf der Platine sind 20 Stück
verbaut. Bei einer weiteren Messung wurden beim 2. Opcode der 2. und 3.
Buffer nicht aktiviert, also konnte das EPROM gar nichts dafuer.
Beim Piepsen fiel mit ein Ausgang auf, der fest auf GND lag. Das gehört so
nicht. Von oben war nichts zu sehen, also erstmal die Platine
ausbauen.
Wenn die Revision C noch so viele Drähte braucht, möchte ich die Vorgänger
mal sehen.
Das ausgebaute Board hatte den Kurzschluss dann nicht mehr, also nochmal
probieren. Und siehe da, es geht viel weiter.
2017-10-11
So habe ich den Expander bekommen
Auf dem Rückweg von der CC2017 habe ich bei Jonas den Expander
abgeholt.
Bis auf ein paar fehlende Tastenkappen sieht der Expander sehr gut aus.
Aber er läuft nicht an. Also mal sehen.
Dabei sind noch das The EXPANDER Installation Guide and Technical
Description, der Source des
Monitorprogramms und das Hardware Reference Manual des 64kB RAM Board.
Technische Daten:
Z80 Prozessor, 3.5 MHz
4kB ROM, 2kB RAM
Parallele und Serielle Schnittstelle
S-100 64kB RAM Board
3 freie S-100-Erweiterungsplätze
Mitglied im
