Lawrence Wilkinson's IBM 360/30 Saga

Newsgroups: alt.folklore.computers
Subject: IBM 360/30 Saga (lang)
Date: Thu, 29 Jun 95 18:50:26 GMT
Lines: 417

Für die, die es interessiert: hier ist meine Geschichte. Bei allen anderen entschuldige ich mich für die Belastung von alt.folklore.computers. Nachdem ich sie eben wieder las, kann ich nicht glauben, dass ich all das jemals schaffte. LJW 29-Jun-95

Die folgenden Ereignisse habe ich, so gut sie mir im Gedächtnis waren, beschrieben. Bei vielen Details bin ich ein wenig unsicher, da das meiste hiervon schon vor über zehn Jahren passierte. Ich entschuldige mich im Voraus bei jedem, der aushalf und nicht erwähnt wird. LJW 16-May-93.

Diese Geschichte beginnt irgendwann Mitte des Jahres 1982, als ich im zweiten Jahr einer Elektroingenieur-Ausbildung stand und Verbindung mit dem New Zealand Microcomputer Club hatte. Damals hatte ich immer noch ein 8080-basiertes S100-System mit 8k RAM und KC Standard Kassettenlaufwerk, aber ich hatte auch schon einige Arbeiten mit TRS80-kompatiblen Systemen, Sorcerers und ähnlichem gemacht.

Jemand aus dem NZMC hatte von der Existenz eines Computers in einem Lagerhaus einer Spedition erzählt bekommen, den man dort loswerden wollte. Ohne einen Schimmer davon zu haben, was uns erwartete, machte ich mich mit mehreren anderen Clubmitgliedern (Selwyn Arrow und Trevor Sheffield, denke ich) eines Abends auf zu dem Gebäude mitten in Auckland, um ihn uns anzusehen. Alles was wir bei dem sehr spärlichen Licht erkennen konnten, waren mehrere große Schränke, fast begraben unter Gewürzsäcken und weiß der Himmel was noch allem. Nachdem wir uns einen Weg dorthin gebahnt hatten, bestätigte sich, dass es sich um eine IBM handelte und die Schränke seitlich die Typennummern 2030 und 2841 trugen. Es standen auch mehrere kleinere Gehäuse herum, die ziemlich offensichtlich Plattenlaufwerke waren.

Nachdem wir alle noch nie etwas mit IBM-Produkten zu tun gehabt hatten, wusste niemand, um was es sich handelte, aber ich war mir einer Sache sicher: Wenn die es nicht haben wollten, ich wollte es! Der Club hatte vor, eine Mailbox zu eröffnen, aber die Größe des Rechners sprengte den Rahmen, auch wenn der Preis stimmte. Immerhin, er war gratis, wir benötigten nur einen Platz zum Aufstellen, und die Firma würde ihn gratis transportieren. Ein Übereinkommen zwischen mir und dem Club wurde aufgesetzt. (Auch der OSI Club, vertreten durch Brian Wilson, war beteiligt.)

Damals machte ich etwas Programmierarbeit (auf 1802, 6800 etc.) für einen Freund (Steven Murray), der ein kleines Büro (etwa 3x3 Meter) im Zentrum Aucklands hatte. Daneben war ein größerer leerstehender Raum. Die Miete war etwa $120 im Monat. Ich weiß nicht mehr, wie ich mir das damals leisten konnte, aber ich schlug zu. Der Haken dabei war: er befand sich im dritten Stock, und nur eine Wendeltreppe und ein winziger Aufzug boten Zugang, also konnte der Rechner nicht am Stück nach oben gelangen.

Ich entschied mich dafür, die Haupteinheiten zu mir nach Hause bringen zu lassen, wo sie den größten Teil einer Seite unserer Garage in Anspruch nahmen, während die kleineren Teile wie die Laufwerke gleich in das Büro wanderten. Da war eine Menge riesiger blauer Handbücher, ungefähr 50 Plattenstapel und diverses anderes Zeug. Nach einer Weile wurde die Identität des Systems erkennbar, als das Typenschild auftauchte: "IBM System/360". Nach langen Recherchen in der Bücherei kriegte ich heraus, dass das, was wir hatten, ein "Model 30" war, daher die Nummer 2030. Was eine kleine Enttäuschung darstellte, weil ich mir ein Model 91 oder so etwas erhofft hatte.

Meine Freizeit wurde durch die Beschäftigung mit der Maschine und den Handbüchern komplett verbraucht. Es war offensichtlich, dass die beiden Haupteinheiten zerlegt werden müssten, um sie in das Bäro zu bekommen. Die Gestelle könnten über die Treppe nach oben gebracht werden, aber wenn wir sie heben wollten, müsste ihr ganzer Inhalt getrennt transportiert werden. Unglücklicherweise hatten die IBM-Entwickler eine solche Zerlegung nicht vorgesehen, also waren nicht einfach nur Steckverbindungen zu trennen und alles auseinanderzuschrauben.

Nun ein paar Worte über den Aufbau des Systems. Als ich mich mit den Handbüchern eingelesen hatte, konnte ich die einzelnen Baugruppen unterscheiden. Die CPU selbst war etwa 1.50m hoch, 1m breit und 2m lang. Von vorne gesehen links befand sich die Stromversorgung, die etwa drei Viertel der Tiefe der Maschine in Anspruch nahm. Sie bestand aus einer riesigen Drehstrom-Transformator- und Filterbaugruppe und einem Schaltnetzteil. Dahinter verbarg sich ein Kompressor (ja, tatsächlich - mehr darüber später) und ein Relaisbrett.

Vorne links unten waren die zwei Kernspeichereinheiten. Jede hatte 32kByte, und 64kB war die maximale Kapazität des Systems. Über dem Kernspeicher war Mikrobefehlscode-Speicher in Form von CCROS (Card-Capacitor Read Only Storage, etwa: Karten-Kondensator Nur-Lese-Speicher), in dem Microcode auf gelochten Karten, die zwischen Leiterplatten lagen, gespeichert war. Jede Karte enthielt 12 Worte je 60 bit in Längsrichtung der Karte, und die Karten wurden durch Bälge, die der vorhin erwähnte Kompressor füllte, gegen die Platinen gedrückt. Die Maschine enthielt etwa 4k Worte oder 340 Karten Microcode.

Fast die ganze rechte Seite der Maschine beanspruchte der Logikteil, untergebracht auf einem Schwenkrahmen, der den Zugriff auf die Anschlüsse an der Rückseite ermöglichte. Ein zweiter Rahmen gleicher Größe war vorgesehen, wurde aber, wie ich erfuhr, nur gebraucht, wenn man die optionale Fließkommaeinrichtung, die auch zusätzlichen CCROS benötigte, oder einen zweiten Selektorkanal eingebaut hatte.

Als ich das alles durchgesehen hatte, kannte ich mich ziemlich gut darin aus. Obwohl die IBM 360 natürlich eine 32-Bit-Maschine ist, ist die Model 30 intern ein 8-Bit-System, so dass alle Berechnungen vier mal ausgeführt werden müssen. Der Adressbus war 16 Bit breit, daher auch die Beschränkung des Kernspeichers auf 64k.

Sie hatte je einen Multiplex-Kanal und einen Selektor-Kanal. Der Selektor-Kanal war komplett in Hardware realisiert, während der Multiplex-Kanal in Microcode implementiert war und nur wenig eigene Hardware benötigte. Es war auch noch etwas Zusatzspeicher (außerhalb der 64k Hauptadressraum) vorhanden, welcher die Registerinhalte der 360 (bis auf den Programmzähler, den die Hardware übernahm) und den Unterkanalstatus des Multiplex-Kanals für bis zu 32 gleichzeitig ablaufende Übertragungen aufnahm.

Der CPU-Takt war etwa 1,3 MHz. In einem Taktzyklus (750 nS) konnte der Kernspeicher einen Lesevorgang ausführen, und im nächsten Takt wurden die Daten zurückgeschrieben, wenn sie nicht verändert werden sollten, da Kernspeicherdaten ja beim Lesen verlorengehen. Da auch die Register im Kernspeicher lagen, fand dort die gleiche Prozedur statt.

Nach langen Beratungen wurde das Gerät in mehrere große Stücke zerlegt: Die Stromversorgung (nach dem Entfernen einer sehr toten Ratte), die CCROS-Einheit, die Kernspeichermodule, den Logikrahmen und die Frontplatte. Ich musste nur wenige Drähte abtrennen, machte aber gute Aufzeichnungen für den Wiederzusammenbau. Übrig blieb nach dem Entfernen der Gehäuseplatten ein leerer Rahmen, der aber immer noch kein bisschen zu leicht war. Die 2841 stellte sich als DASD Laufwerkscontroller heraus. Er war fast ebenso kompliziert wie der Rechner selbst, hatte seinen eigenen Microcode und für jedes der vier Laufwerke ein Interface. Die Laufwerke waren vom Typ 2311, konnten jeweils ca. 7 MB (eine riesige Datenmenge für damals) aufnehmen, und ich hatte genügend Plattenstapel.

Die 2841 wurde genauso demontiert, obwohl sie eigentlich kein großes Problem darstellte. Ich machte mir kleine Papierschablonen von den Geräten und schob sie auf einem Plan des Büros herum, um mich zu versichern, dass ich alle Türen öffen konnte und die Kabel zwischen den Gerten trotzdem ausreichten. Ein befreundeter Elektriker, Doug Hook, verlegte Drehstrom von der Verteilung bis in das Büro.

Der ganze Transport wurde an Wochenenden erledigt, zu allen anderen Zeiten wäre es durch den Verkehr und die anderen Mieter zu schwierig geworden. Das CPU-Gestell und der Logikrahmen schleppten wir die Treppe hoch, ohne das Geländer allzusehr zu beschädigen, wohingegen alles andere in den Aufzug passte (obwohl es manchmal etwas anstrengend war).

Als dann endlich alles an Ort und Stelle war, erfolgte der Wiederaufbau. Das ging ganz gut, meine Notizen waren ausführlich genug und nichts war beschädigt worden. Während dieses Vorgangs verstand ich immer besser die FEMM-Handbücher. Sie enthielten alle Schaltpläne einschließlich der Steckerbelegungen, und obwohl ich mit den Bauelementen nicht vertraut war, waren sie mir nützlich, um Verbindungen nachzuverfolgen. Eine etwas schwierigere Baugruppe war der Bedienungsblattschreiber 1051/1052, eine IBM-Selectric-ähnliche Schreibmaschine, die direkt mit den Schaltkreisen der CPU verdrahtet war und vor der Einlagerung abgetrennt worden war.

Die Logik war IBM's "SLT" (Solid Logic Technology), ähnlich DTL und basierend auf quadratischen Bausteinen mit 12,7 mm Seitenlnge, die jeweils meist nur ein Gatter enthielten. Vier bis acht Bausteine waren auf eine etwa 5 x 7,5 cm große Karte montiert, und diese wiederum steckten auf etwa 20 x 30 cm großen Platinen, von denen der Logikrahmen insgesamt etwa 30 aufwies.

Als alles wieder, so gut es mir möglich war, zusammengesetzt war, kam der große Tag des Einschaltens. Ich kann mich nicht besonders gut daran erinnern, da es nicht wirklich bedeutend war - im Rückblick kann ich mich glücklich schätzen, dass nichts hochging oder Feuer fing.

Wir schalteten die Hauptstromleitung zur CPU ein. Es gab ein leises Klicken von einem Relais irgendwo und das hohe Fiepen des Schaltnetzteiles - es lief offenbar immer, auch wenn der Computer als solcher ausgeschaltet war. Mit ausgestrecktem Arm betätigte ich den Einschalter. Eine Serie lauter Relaisklicks, das Geräusch vom Hochlaufen vieler Lüfter und des Kompressors, dann ein weiteres Klicken und alles ging ruckartig aus.

Ich wurde mir nie ganz darüber klar, was passiert war, aber ich glaube, ich kriegte heraus, dass mit dem Not-Ausschaltsystem etwas nicht stimmte (im Kanalkabel verlief eine Leitung, die die Not-Aus-Schalter aller Geräte verband - es könnte sein, dass ich es vorübergehend durch das Versetzen des Abschlusswiderstandes von der 2841 in die 2030 behoben habe), und das Säubern aller Relaiskontakte löste das Problem.

Das Starten des Systems brachte einen andauernden Lärm mit sich. Der Kompressor schaltete sich nach ungefähr 20 Sekunden ab, um alle paar Minuten, wenn sich die Bälge entleert hatten, wieder anzulaufen, aber es müssen -zig Lüfter im Rechner gewesen sein, die alle surrten und riesige Mengen heißer Luft herausbliesen. Ich musste die Deckenplatten entfernen und das Fenster öffnen, wenn er länger als zehn Minuten laufen sollte.

Ich stellte bald fest, dass nicht alles in Ordnung war und die Maschine bald nach dem Einschalten bei einer Microcode-Prüfung stoppte. Dahinter verbarg sich ein verzwickter Fehler. Der Microcode ist auf speziellen Lochkarten untergebracht, die mit leitfähigen Silberstreifen beschichtet sind. Beim Bearbeiten mittels eines Stanzers werden Teile der Silberflächen entfernt, und die übriggebliebenen bilden eine Hälfte eines kleinen Kondensators. Die andere Hälfte stellen Leiterbahnen auf den Platinen dar, daher auch die Bezeichnung CCROS. Im Laufe der Zeit waren Teile des Silbers korrodiert, was zu bitweisen Ausfällen fhrte. Zum Glück hatte jedes Microcodewort mehrere Paritätsbits, sodass diese Fehler erkannt und abgefangen wurden. Ich ging, kaufte mir eine Flasche Leitsilber und reparierte die Bahnen. Das schaffte Abhilfe.

Die Diagnose erleichterte mir die Tatsache, dass jedes Microcode-Bit durch eine Lampe auf der Frontplatte repräsentiert wurde und es einen Einzelschritt-Microcode-Modus gab. Ein kompletter Satz Handbücher enthielt den Microcode (CLDs) in einer graphischen Darstellung, die ich bald verstehen lernte. Davor war ich noch nie mit Microcode in Berührung gekommen. Das Microcodesystem war ziemlich trickreich und die meisten Befehle schienen in der kürzesten überhaupt machbaren Zeit ausgeführt zu werden, auch wenn schon eine einfach Addition Register zu Register ungefähr 33 Taktzyklen (25 Mikrosekunden) brauchte.

Nebenbei gesagt, das Prinzip des Verzweigens innerhalb des Microcodes war ebenfalls höchst durchdacht. Die 4k Microcode waren in Seiten zu 256 Worten aufgeteilt und vierfach interleaved. Ein Microcode-Wort gab nur die oberen 6 bit der Adresse des nachfolgenden Befehls (innerhalb der selben Seite) an, die unteren 2 bits wurden durch zwei eigenständige Funktionscodes bestimmt, wodurch jeder Befehl bis zu vier mögliche Nachfolger bekam. Die Funktionscodes enthielten "immer 0" und "immer 1", wo keine Verzweigung notwendig war. Da die vier möglichen Zieladressen am Zyklusende bereits eingelesen waren, entstand keine Verzögerung durch die Verzweigung.*

Die Maschine hatte Unmengen von Kontrolllampen - einen Block für den Microcode, einen für den Selektorkanal, und dazu noch die standardmäßigen Adress-, Daten- und Statusanzeigen. Eine ganze Reihe dieser Lampen waren durchgebrannt, also wurden die übrigen jeweils dorthin gesteckt, wo ich sie gerade brauchte - ich kam nie dazu, mir neue zu kaufen.

Ich hatte nun also ein System, das hochlief und an blieb, obwohl ich noch nichts damit anfangen konnte. Über die Laufwerke hatte ich mir bis dahin noch keine Gedanken gemacht. Nun musste ich anfangen zu erkunden, was mit einer 360 eigentlich anzufangen war. Ich musste soviel Material auftreiben wie möglich, da ich mich noch nie mit all den Umständlichkeiten der Maschinensprache der 360 oder der Kanalbefehlswort-Programmierung auseinandergesetzt hatte. All diese Bücher über "Erlernen der Assemblersprache der IBM 360" hatten eine neue, überaus große Bedeutung gewonnen, obwohl sich meine Arbeit zumindest anfangs hauptsächlich auf die Programmausdrucke in den Diagnosehandbüchern und die Tatsache, dass die Maschinensprachen von 360 und 1802 eng miteinander verwandt waren, stützte.

Ich schrieb ein paar einfache Programme und gab sie über die Bedienelemente auf der Frontplatte ein: Vier Schalter 16 Positionen für die Adresse, zwei für die Daten, und "Lese-" und "Schreib“-knopf. Fast alles lief wie vorgesehen, aber ein paar seltsame Vorgänge konnte ich schließlich auf wenige fehlerhafte SLT-Bauteile zurckführen.

In einem Fall fand ich den Fehler in einem bestimmten SLT-Gatter und überprfte durch Tauschen der Platine mit einer identischen anderswo im Rechner (im Handbuch war eine Liste gleichartiger Baugruppen vorhanden). Schließlich stellte sich ein Eingang eines Gatters mit drei oder vier Eingängen als fehlerhaft heraus und ich überlegte mir, dass eine einzige strategisch geschickt auf der Rückseite der Platine plazierte Diode es wieder zur Funktion bringen sollte. Es klappte!

In einem anderen Fall steckte ich die fehlerhafte Platine in einen Steckplatz, der den fehlerhaften Teil ungenutzt ließ. Abgesehen davon und von den CCROS-Fehlern hatte die Maschine zehn Jahre Lagerzeit bemerkenswert gut überstanden.

Nachdem die CPU nun wieder in Ordnung war, wendete ich meine Aufmerksamkeit den Plattenspeichern zu. Es nervte mich mittlerweile, Programme von Hand einzugeben, obwohl sie dauerhaft im Speicher blieben (ich hatte diverse Programme innerhalb der 64k verteilt).

Soweit ich mich erinnern kann, lief die 2841 von Anfang an. Sie enthielt keinen CCROS-Microcode, sondern TROS (Transformer Read Only Memory, etwa: Übertrager-Nur Lese Speicher), entfernt damit verwandt, und benutzte kleine Übertrager, um Kupferstreifen auf Plastikbändern zu erfassen. Entsprechend der Position gestanzter Löcher lief der Streifen entweder durch einen Ferritkern oder daran vorbei. Ich glaube, das war etwas schneller als CCROS, aber konnte nicht so einfach modifiziert werden.

Jedes Laufwerk war mittels zweier Kabel mit der 2841 verbunden, einem Datenkabel pro Laufwerk, das direkt zum Controller lief, und einem Steuerkabel, das durch die Laufwerke durchgeschleift war, ähnlich der ST506 Festplattenverkabelung. Jedes Laufwerk konnte seine Köpfe unabhängig positionieren, aber nur eines konnte jeweils Daten übertragen. Die 2841 hatte keine Puffermöglichkeit - Die Daten mussten durch den Kanal und in die CPU, sobald sie vom Laufwerk kamen, mit der Geschwindigkeit von 145kB/Sec.

Die Köpfe der 2311-Laufwerke werden hydraulisch positioniert und bewegen sich für ihre Größe mit erstaunlicher Geschwindigkeit. In Anbetracht des Gewichts des Kopfkammes ist es kein Wunder, dass das ganze Laufwerk bei schnell aufeinanderfolgenden Zugriffen ins Wackeln geraten konnte. Ein guter Teil der Hydraulikflüssigkeit war ausgelaufen, aber ich entleerte eines der Laufwerke vollständig, sodass ich genug zum Auffüllen der anderen drei erhielt.

Ich suchte mir einen Plattenstapel, der unwichtig aussah, setzte ihn ein, und schaltete an. Ich sah nervös zu, wie er auf Touren kam. Als er seine Solldrehzahl erreicht hatte, bewegten sich die Kpfe langsam zum Rand, wurden zur Oberflche hin abgesenkt und mit lautem Geräusch zuerst ganz nach innen, dann wieder nach außen positioniert. Es stellte sich heraus, dass dies der normale Ablauf war, aber damals erschrak ich gewaltig, und bis heute weiß ich nicht, warum dies so stattfindet. Vielleicht um etwaige drohende Kopfaufsetzer gleich beim Start und nicht erst im Betrieb stattfinden zu lassen.

Mittlerweile wusste ich, dass nach dem Einstellen der Adresse "190" mittels der Schalter auf der Frontplatte und dem Drcken der IPL-Taste das Betriebssystem geladen werden sollte. Ich suchte den mit "SYSVOL" beschrifteten Datenträger heraus und setzte ihn in das Laufwerk mit der Adresse 190 ein. Als er hochgelaufen war, drückte ich IPL. Der Bedienungsblattschreiber erwachte zum Leben und ratterte ein Prompt, das zur Eingabe des heutigen Datums aufforderte, aufs Papier. Ich glaube, ich brauchte damals eine Weile, um damit zurechtzukommen, da ich ja keine DOS-Handbücher hatte und nicht genau wusste, was ich eingeben sollte, aber schließlich hatte ich mein eigenes, lauffähiges DOS-System.

Das war ziemlich verblüffend, weil ich bis dahin nur mit CP/M und TRSDOS als Betriebssystem gearbeitet hatte, und dieses DOS einen völlig anderen Wortschatz hatte. Allerdings konnte ich nur mit dem Bedienungsblattschreiber wenig mit dem System anfangen. Es musste einmal ein Zeilendrucker und ein Lochkartenleser dabei gewesen sein, da das System ganz darauf ausgerichtet war, über Lochkarten eingegebene JCL- (Job control language, etwa: Auftragssteuersprache-) Befehle durchzuführen.

Zum Glück lieh mir ein Freund ein kleines DOS-Handbuch, das alle Befehle enthielt und sich als unentbehrlich herausstellte. John Machin, entschuldige bitte, dass ich es nie zurückgab! Ich sah die Plattenstapel, die ich hatte, nach interessanten Programmen durch. Soweit ich feststellen konnte, war die Maschine für typische Aufgaben der Rechnungsstellung eingesetzt worden. Ich fand keine interessanten Daten, ich suchte auch nicht besonders gründlich danach. Ich war mehr an Programmen interessiert und probierte jedes einzelne aus, ebenso wie ich versuchte, mithilfe der Bibliothekshilfsprogramme COBOL-Quellcode daraus zu gewinnen.

Ich schaffte es, von IBM einige Handbücher über die 360, DOS und COBOL zu bestellen. Die müssen sich gewundert haben, warum sich überhaupt noch jemand dafür interessierte, aber es ist ihnen hoch anzurechnen, dass sie schnell ankamen und sehr günstig waren. Ich war etwas vorsichtig mit Auskünften gewesen, da mir die Herkunft der Maschine etwas zweifelhaft schien.

Ungefähr im Dezember 1882 hatte ich eine Glückssträhne, als ich eine Anzeige für eine IBM 2203 RJE- (Remote Job Entry, etwa: Auftragsferneingabe-)Einheit entdeckte. Eine Regierungsstelle wollte sie meistbietend loswerden. Ich bot $151 dafür und bekam sie. Ich glaube, ich war der einzige Bieter - ich hätte möglicherweise $150 sparen können. Der Chef des anbietenden Amtes war ziemlich "erfreut" - er hatte sich wohl $10000 oder so dafür erhofft.

Die Einheit bestand aus einem Lochkartenleser und einem Zeilendrucker. Da ich keine Lochkartenstanze hatte, weder handbetrieben noch automatisch, war der Leser nicht besonders nützlich, wohl aber der Drucker. Unglücklicherweise war das System zum Anschluss an einen Mainframe über ein Modem gedacht, also brauchte ich eine serielle Verbindung, die der /360 irgendwie fehlte. Allerdings konnte ich, als das Gerät im Büro stand, den mitgelieferten Stapel Testkarten ausdrucken, und auch hier fehlte es nicht an Handbüchern.

Der Drucker war ein Kettendrucker, die Typen bewegten sich an einer Reihe von Druckhämmern vorbei, die anschlugen, wenn das richtige Zeichen vor ihnen stand. Mit allen Großbuchstaben und Zahlen, ungefähr 44 Zeichen insgesamt, druckte er 300 Zeilen pro Minute, was ein ganz guter Wert war. Er machte einen furchtbaren Krach, wenn die Hämmer für jede Zeile gespannt und dann mit einem kreischenden Geräusch losgelassen wurden.

Egal, zurück zum Anschließen der Einheit an den Rechner. Ich entschied, dass ich für die Erledigung größerer Aufgaben einen anderen Weg der Datenein- und -ausgabe als den Bedienungsblattschreiber brauchte. Es gab keine andere Möglichkeit, als selbst die passende Peripherie für den Multiplexkanal zu entwickeln. Ich kann es nicht mehr glauben, aber mithilfe der Bedienungsanleitungen, Schaltpläne und Microcode-Programme war ich in der Lage, die Funktionsweise des Kanals nachzuvollziehen.

Ich entschied mich dafür, eine auf der 6802 basierende Einheit zu bauen, da ich mich mit der Programmierung der 6800-Serie auskannte, und überlegte mir die minimal zur Verbindung mit der 360 nötigen externen Schaltkreise. Da ich keine Kanalkabel übrig hatte (und ein Kanalverbinder größer gewesen wäre als der gesamte Mikroprozessorschaltkreis), verband ich einen zusätzlichen Anschluss mittels Fädeltechnik mit den entsprechenden Punkten innerhalb der CPU und führte ein Stück Flachkabel (inklusive Versorgungsleitungen) heraus zu meinem kleinen Gerät.

Der Kanalinterface-Schaltkreis war ziemlich kompliziert, da die 6802 nicht schnell genug für die Geräteadressierung durch die 360 reagieren konnte und somit Zwischenspeicher und Komparatoren nötig wurden. Glücklicherweise gab es keine Probleme mehr, sobald die Übertragung lief. Alle Transfers wurden byteweise durchgeführt, ohne Pufferung oder Burstbetrieb.

Der 6802 ergab zusammen mit vier seriellen Treibern 6850 8 unabhängige Unterkanäle, bezeichnet mit 8 bis F, um sich in die vorgegebenen Peripheriezuweisungen einzufügen. Der 6802 verkraftete gleichzeitigen Betrieb aller 8 Verbindungen. Ich kann mich nicht erinnern, wie man die Baudrate für die einzelnen Kanäle einstellte, ich glaube, dafür gab es Drehschalter. Die RS-232 Handshakeleitungen wurden als Statusanzeiger benutzt, wenn ein Programm die Bereitschaft eines Gerätes abfragte. Eine Vollduplex-RS232-Verbindung lief zur RJE 2203, eine weitere zu einem "System 80" (TRS-80-Nachbau), das mir als Eingabeterminal diente.

Ich hatte in paar seltsame Probleme mit meinem Gerät, die die CPU zum Anhalten beim Kanaltest zwangen, ohne dass ein Grund erkennbar gewesen wäre. Es passierte so selten, dass ich es nie nachverfolgen konnte, aber es war etwas entnervend.

Darüberhinaus konnte ich nun den COBOL Compiler aufrufen, ein Programm über das System 80 zuführen und auf dem Zeilendrucker ausdrucken lassen. Ich schrieb ein paar einfache Programme in COBOL, Zahlenratespiele und so weiter, aber ich war nicht mit ganzem Herzen dabei. Der Spaß war gewesen, das System wieder funktionsfähig zu machen - als es nun wieder lief, wusste ich nichts damit anzufangen.

Danach langweilte es mich nur noch. Manchmal heizte ich es noch an, um es vorzuführen, aber schließlich zahlte ich meine Miete nicht mehr und ließ den Strom abklemmen. Das Gebäude hat inzwischen mehreren Eigentümern gehört. Eines Tages brach dann jemand die Tür des Büros auf und stahl das Bücherregal, das meine Handbücher enthielt. Seitdem war ich nicht mehr dort.

Meine Erfahrungen mit dem System haben sich als nützlich erwiesen. Ich habe große Achtung von IBM Hardware und die Anstrengung, die die Entwicklung eines solch komplexen Systems verlangt. Ich bin froh, dass es keine 360/91 war, mit der kleinen /30 hatte ich wohl doch einiges einfacher gehabt.

Lawrence Wilkinsonb
Auckland, Neuseeland
18. Mai 1993

Lawrence Wilkinson
"Es heißt, dass man von seinen Fehlern lerne.
Stimmt das, dann muss ich ein absolutes Genie sein!" - Tony Rudd

Translated by: Arno Kletzander
Proof-read by: Dr. John G. Zabolitzky
Raw Translation: 26./27.12.2000
Last revision: 15.04.2003
Bring back Umlaute - Kurt Wemmie: 01.04.2016

*/P.S.: Wenige Tage nach Fertigstellung dieser Übersetzung stellte Mr. Wilkinson anhand alter Unterlagen fest, dass sich bei seiner urspürnglichen Beschreibung des Microcode-Systems einige Fehler eingeschlichen hatten. Der Microcode-Speicher war nicht interleaved und es fand auch kein Vorauseilendes Lesen der möglichen Folgebefehle statt.