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
Fr die, die es interessiert: hier ist meine Geschichte. Bei allen anderen entschuldige ich mich fr 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 Gedchtnis 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 erwhnt 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 erzhlt 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 Gebude mitten in Auckland, um ihn uns anzusehen. Alles was wir bei dem sehr sprlichen Licht erkennen konnten, waren mehrere groe Schrnke, fast begraben unter Gewrzscken und wei der Himmel was noch allem. Nachdem wir uns einen Weg dorthin gebahnt hatten, besttigte sich, dass es sich um eine IBM handelte und die Schrnke seitlich die Typennummern 2030 und 2841 trugen. Es standen auch mehrere kleinere Gehuse 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 erffnen, aber die Gre des Rechners sprengte den Rahmen, auch wenn der Preis stimmte. Immerhin, er war gratis, wir bentigten nur einen Platz zum Aufstellen, und die Firma wrde 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.) fr einen Freund (Steven Murray), der ein kleines Bro (etwa 3x3 Meter) im Zentrum Aucklands hatte. Daneben war ein grerer 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 Stck nach oben gelangen.
Ich entschied mich dafr, die Haupteinheiten zu mir nach Hause bringen zu lassen, wo sie den grten Teil einer Seite unserer Garage in Anspruch nahmen, whrend die kleineren Teile wie die Laufwerke gleich in das Bro wanderten. Da war eine Menge riesiger blauer Handbcher, ungefhr 50 Plattenstapel und diverses anderes Zeug. Nach einer Weile wurde die Identitt des Systems erkennbar, als das Typenschild auftauchte: "IBM System/360". Nach langen Recherchen in der Bcherei kriegte ich heraus, dass das, was wir hatten, ein "Model 30" war, daher die Nummer 2030. Was eine kleine Enttuschung darstellte, weil ich mir ein Model 91 oder so etwas erhofft hatte.
Meine Freizeit wurde durch die Beschftigung mit der Maschine und den Handbchern komplett verbraucht. Es war offensichtlich, dass die beiden Haupteinheiten zerlegt werden mssten, um sie in das Bro zu bekommen. Die Gestelle knnten ber die Treppe nach oben gebracht werden, aber wenn wir sie heben wollten, msste ihr ganzer Inhalt getrennt transportiert werden. Unglcklicherweise 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 Handbchern 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, tatschlich - mehr darber spter) und ein Relaisbrett.
Vorne links unten waren die zwei Kernspeichereinheiten. Jede hatte 32kByte, und 64kB war die maximale Kapazitt 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 60 bit in Lngsrichtung der Karte, und die Karten wurden durch Blge, die der vorhin erwhnte Kompressor fllte, gegen die Platinen gedrckt. 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 Anschlsse an der Rckseite ermglichte. Ein zweiter Rahmen gleicher Gre war vorgesehen, wurde aber, wie ich erfuhr, nur gebraucht, wenn man die optionale Fliekommaeinrichtung, die auch zustzlichen CCROS bentigte, oder einen zweiten Selektorkanal eingebaut hatte.
Als ich das alles durchgesehen hatte, kannte ich mich ziemlich gut darin aus. Obwohl die IBM 360 natrlich eine 32-Bit-Maschine ist, ist die Model 30 intern ein 8-Bit-System, sodass alle Berechnungen vier mal ausgefhrt werden mssen. Der Adressbus war 16 Bit breit, daher auch die Beschrnkung des Kernspeichers auf 64k.
Sie hatte je einen Multiplex-Kanal und einen Selektor-Kanal. Der Selektor-Kanal war komplett in Hardware realisiert, whrend der Multiplex-Kanal in Microcode implementiert war und nur wenig eigene Hardware bentigte. Es war auch noch etwas Zusatzspeicher (auerhalb der 64k Hauptadressraum) vorhanden, welcher die Registerinhalte der 360 (bis auf den Programmzhler, den die Hardware bernahm) und den Unterkanalstatus des Multiplex-Kanals fr bis zu 32 gleichzeitig ablaufende bertragungen aufnahm.
Der CPU-Takt war etwa 1,3 MHz. In einem Taktzyklus (750nS) konnte der Kernspeicher einen Lesevorgang ausfhren, und im nchsten Takt wurden die Daten zurckgeschrieben, wenn sie nicht verndert 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 Gert in mehrere groe Stcke zerlegt: Die Stromversorgung (nach dem Entfernen einer sehr toten Ratte), die CCROS-Einheit, die Kernspeichermodule, den Logikrahmen und die Frontplatte. Ich musste nur wenige Drhte abtrennen, machte aber gute Aufzeichnungen fr den Wiederzusammenbau. brig blieb nach dem Entfernen der Gehuseplatten 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 fr jedes der vier Laufwerke ein Interface. Die Laufwerke waren vom Typ 2311, konnten jeweils ca. 7 MB (eine riesige Datenmenge fr damals) aufnehmen, und ich hatte gengend Plattenstapel. Die 2841 wurde genauso demontiert, obwohl sie eigentlich kein groes Problem darstellte.
Ich machte mir kleine Papierschablonen von den Gerten und schob sie auf einem Plan des Bros herum, um mich zu versichern, dass ich alle Tren ffen konnte und die Kabel zwischen den Gerten trotzdem ausreichten. Ein befreundeter Elektriker, Doug Hook, verlegte Drehstrom von der Verteilung bis in das Bro.
Der ganze Transport wurde an Wochenenden erledigt, zu allen anderen Zeiten wre es durch den Verkehr und die anderen Mieter zu schwierig geworden. Das CPU-Gestell und der Logikrahmen schleppten wir die Treppe hoch, ohne das Gelnder allzusehr zu beschdigen, 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 ausfhrlich genug und nichts war beschdigt worden. Whrend dieses Vorgangs verstand ich immer besser die FEMM-Handbcher. Sie enthielten alle Schaltplne einschlielich der Steckerbelegungen, und obwohl ich mit den Bauelementen nicht vertraut war, waren sie mir ntzlich, 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 groe Karte montiert, und diese wiederum steckten auf etwa 20 x 30 cm groen Platinen, von denen der Logikrahmen insgesamt etwa 30 aufwies.
Als alles wieder, so gut es mir mglich war, zusammengesetzt war, kam der groe Tag des Einschaltens. Ich kann mich nicht besonders gut daran erinnern, da es nicht wirklich bedeutend war - im Rckblick kann ich mich glcklich schtzen, 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 bettigte ich den Einschalter. Eine Serie lauter Relaisklicks, das Gerusch vom Hochlaufen vieler Lfter und des Kompressors, dann ein weiteres Klicken und alles ging ruckartig aus.
Ich wurde mir nie ganz darber 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 Gerte verband - es knnte sein, dass ich es vorbergehend durch das Versetzen des Abschlusswiderstandes von der 2841 in die 2030 behoben habe), und das Subern aller Relaiskontakte lste das Problem.
Das Starten des Systems brachte einen andauernden Lrm mit sich. Der Kompressor schaltete sich nach ungefhr 20 Sekunden ab, um alle paar Minuten, wenn sich die Blge entleert hatten, wieder anzulaufen, aber es mssen -zig Lfter im Rechner gewesen sein, die alle surrten und riesige Mengen heier Luft herausbliesen. Ich musste die Deckenplatten entfernen und das Fenster ffnen, wenn er lnger 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-Prfung stoppte. Dahinter verbarg sich ein verzwickter Fehler. Der Microcode ist auf speziellen Lochkarten untergebracht, die mit leitfhigen Silberstreifen beschichtet sind. Beim Bearbeiten mittels eines Stanzers werden Teile der Silberflchen entfernt, und die briggebliebenen bilden eine Hlfte eines kleinen Kondensators. Die andere Hlfte stellen Leiterbahnen auf den Platinen dar, daher auch die Bezeichnung CCROS. Im Laufe der Zeit waren Teile des Silbers korrodiert, was zu bitweisen Ausfllen fhrte. Zum Glck hatte jedes Microcodewort mehrere Parittsbits, 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 reprsentiert wurde und es einen Einzelschritt-Microcode-Modus gab. Ein kompletter Satz Handbcher enthielt den Microcode (CLDs) in einer graphischen Darstellung, die ich bald verstehen lernte. Davor war ich noch nie mit Microcode in Berhrung gekommen. Das Microcodesystem war ziemlich trickreich und die meisten Befehle schienen in der krzesten berhaupt machbaren Zeit ausgefhrt zu werden, auch wenn schon eine einfach Addition Register zu Register ungefhr 33 Taktzyklen (25 Mikrosekunden) brauchte.
Nebenbei gesagt, das Prinzip des Verzweigens innerhalb des Microcodes war ebenfalls hchst 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 eigenstndige Funktionscodes bestimmt, wodurch jeder Befehl bis zu vier mgliche Nachfolger bekam. Die Funktionscodes enthielten "immer 0" und "immer 1", wo keine Verzweigung notwendig war. Da die vier mglichen Zieladressen am Zyklusende bereits eingelesen waren, entstand keine Verzgerung durch die Verzweigung.*
Die Maschine hatte Unmengen von Kontrolllampen - einen Block fr den Microcode, einen fr den Selektorkanal, und dazu noch die standardmigen 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 mglich, da ich mich noch nie mit all den Umstndlichkeiten der Maschinensprache der 360 oder der Kanalbefehlswort-Programmierung auseinandergesetzt hatte. All diese Bcher ber "Erlernen der Assemblersprache der IBM 360" hatten eine neue, beraus groe Bedeutung gewonnen, obwohl sich meine Arbeit zumindest anfangs hauptschlich auf die Programmausdrucke in den Diagnosehandbchern und die Tatsache, dass die Maschinensprachen von 360 und 1802 eng miteinander verwandt waren, sttzte.
Ich schrieb ein paar einfache Programme und gab sie ber die Bedienelemente auf der Frontplatte ein: Vier Schalter 16 Positionen fr die Adresse, zwei fr die Daten, und "Lese-" und "Schreib-"knopf. Fast alles lief wie vorgesehen, aber ein paar seltsame Vorgnge konnte ich schlielich auf wenige fehlerhafte SLT-Bauteile zurckfhren.
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). Schlielich stellte sich ein Eingang eines Gatters mit drei oder vier Eingngen als fehlerhaft heraus und ich berlegte mir, dass eine einzige strategisch geschickt auf der Rckseite 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 Plastikbndern zu erfassen. Entsprechend der Position gestanzter Lcher 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 Kpfe unabhngig positionieren, aber nur eines konnte jeweils Daten bertragen. Die 2841 hatte keine Puffermglichkeit - Die Daten mussten durch den Kanal und in die CPU, sobald sie vom Laufwerk kamen, mit der Geschwindigkeit von 145kB/Sec.
Die Kpfe der 2311-Laufwerke werden hydraulisch positioniert und bewegen sich fr ihre Gre 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 Hydraulikflssigkeit war ausgelaufen, aber ich entleerte eines der Laufwerke vollstndig, sodass ich genug zum Auffllen der anderen drei erhielt.
Ich suchte mir einen Plattenstapel, der unwichtig aussah, setzte ihn ein, und schaltete an. Ich sah nervs 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 Gerusch zuerst ganz nach innen, dann wieder nach auen 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 Datentrger heraus und setzte ihn in das Laufwerk mit der Adresse 190 ein. Als er hochgelaufen war, drckte 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-Handbcher hatte und nicht genau wusste, was ich eingeben sollte, aber schlielich hatte ich mein eigenes, lauffhiges DOS-System.
Das war ziemlich verblffend, weil ich bis dahin nur mit CP/M und TRSDOS als Betriebssystem gearbeitet hatte, und dieses DOS einen vllig 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 durchzufhren.
Zum Glck 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 zurckgab! Ich sah die Plattenstapel, die ich hatte, nach interessanten Programmen durch. Soweit ich feststellen konnte, war die Maschine fr typische Aufgaben der Rechnungsstellung eingesetzt worden. Ich fand keine interessanten Daten, ich suchte auch nicht besonders grndlich 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 Handbcher ber die 360, DOS und COBOL zu bestellen. Die mssen sich gewundert haben, warum sich berhaupt noch jemand dafr interessierte, aber es ist ihnen hoch anzurechnen, dass sie schnell ankamen und sehr gnstig waren. Ich war etwas vorsichtig mit Ausknften gewesen, da mir die Herkunft der Maschine etwas zweifelhaft schien.
Ungefhr im Dezember 1882 hatte ich eine Glcksstrhne, als ich eine Anzeige fr eine IBM 2203 RJE- (Remote Job Entry, etwa: Auftragsferneingabe-)Einheit entdeckte. Eine Regierungsstelle wollte sie meistbietend loswerden. Ich bot $151 dafr und bekam sie. Ich glaube, ich war der einzige Bieter - ich htte mglicherweise $150 sparen knnen. Der Chef des anbietenden Amtes war ziemlich "erfreut" - er hatte sich wohl $10000 oder so dafr erhofft.
Die Einheit bestand aus einem Lochkartenleser und einem Zeilendrucker. Da ich keine Lochkartenstanze hatte, weder handbetrieben noch automatisch, war der Leser nicht besonders ntzlich, wohl aber der Drucker. Unglcklicherweise 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 Gert im Bro stand, den mitgelieferten Stapel Testkarten ausdrucken, und auch hier fehlte es nicht an Handbchern.
Der Drucker war ein Kettendrucker, die Typen bewegten sich an einer Reihe von Druckhmmern vorbei, die anschlugen, wenn das richtige Zeichen vor ihnen stand. Mit allen Grobuchstaben und Zahlen, ungefhr 44 Zeichen insgesamt, druckte er 300 Zeilen pro Minute, was ein ganz guter Wert war. Er machte einen furchtbaren Krach, wenn die Hmmer fr jede Zeile gespannt und dann mit einem kreischenden Gerusch losgelassen wurden.
Egal, zurck zum Anschlieen der Einheit an den Rechner. Ich entschied, dass ich fr die Erledigung grerer Aufgaben einen anderen Weg der Datenein- und -ausgabe als den Bedienungsblattschreiber brauchte. Es gab keine andere Mglichkeit, als selbst die passende Peripherie fr den Multiplexkanal zu entwickeln. Ich kann es nicht mehr glauben, aber mithilfe der Bedienungsanleitungen, Schaltplne und Microcode-Programme war ich in der Lage, die Funktionsweise des Kanals nachzuvollziehen.
Ich entschied mich dafr, 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 ntigen externen Schaltkreise. Da ich keine Kanalkabel brig hatte (und ein Kanalverbinder grer gewesen wre als der gesamte Mikroprozessorschaltkreis), verband ich einen zustzlichen Anschluss mittels Fdeltechnik mit den entsprechenden Punkten innerhalb der CPU und fhrte ein Stck Flachkabel (inklusive Versorgungsleitungen) heraus zu meinem kleinen Gert.
Der Kanalinterface-Schaltkreis war ziemlich kompliziert, da die 6802 nicht schnell genug fr die Gerteadressierung durch die 360 reagieren konnte und somit Zwischenspeicher und Komparatoren ntig wurden. Glcklicherweise gab es keine Probleme mehr, sobald die bertragung lief. Alle Transfers wurden byteweise durchgefhrt, ohne Pufferung oder Burstbetrieb.
Der 6802 ergab zusammen mit vier seriellen Treibern 6850 8 unabhngige Unterkanle, bezeichnet mit 8 bis F, um sich in die vorgegebenen Peripheriezuweisungen einzufgen. Der 6802 verkraftete gleichzeitigen Betrieb aller 8 Verbindungen. Ich kann mich nicht erinnern, wie man die Baudrate fr die einzelnen Kanle einstellte, ich glaube, dafr gab es Drehschalter. Die RS-232 Handshakeleitungen wurden als Statusanzeiger benutzt, wenn ein Programm die Bereitschaft eines Gertes 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 Gert, die die CPU zum Anhalten beim Kanaltest zwangen, ohne dass ein Grund erkennbar gewesen wre. Es passierte so selten, dass ich es nie nachverfolgen konnte, aber es war etwas entnervend.
Darberhinaus konnte ich nun den COBOL Compiler aufrufen, ein Programm ber das System 80 zufhren 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 funktionsfhig 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 vorzufhren, aber schlielich zahlte ich meine Miete nicht mehr und lie den Strom abklemmen. Das Gebude hat inzwischen mehreren Eigentmern gehrt. Eines Tages brach dann jemand die Tr des Bros auf und stahl das Bcherregal, das meine Handbcher enthielt. Seitdem war ich nicht mehr dort.
Meine Erfahrungen mit dem System haben sich als ntzlich erwiesen. Ich habe groe 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 Wilkinson
Auckland, Neuseeland
18. Mai 1993
Lawrence Wilkinson
"Es heit, 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
*/P.S.: Wenige Tage nach Fertigstellung dieser bersetzung stellte Mr. Wilkinson anhand alter Unterlagen fest, dass sich bei seiner ursprnglichen Beschreibung des Microcode-Systems einige Fehler eingeschlichen hatten. Der Microcode-Speicher war nicht interleaved und es fand auch kein Vorauseilendes Lesen der mglichen Folgebefehle statt.
