Homepage

 

 

 

Mikrocontroller   PCs — Embedded Electronics

Ideen — Projekte — Fachwissen 

 

 

 

 

System .002b

 

 

 

 

 

 

 

 Home

 ReAl Computer Architecture

 Projekte

 Fachtexte

 Lehrarchiv

 Privatarchiv

 Die historische Webseite

 Impressum + Datenschutz

 Kontakt

 Neuigkeiten

 

 

 

 
 I tell this tale, which is strictly true,
 just by way of convincing you
How very little since things were made
Things have altered in the computer trade.
 

Frei nach R. Kipling

System .002b

Alle Fotos aus dem  Prospektmaterial des Herstellers. Dokumentation nicht verfügbar, private Aufzeichnungen nicht vorhanden. Zeichnungen neu erstellt. Es sind Überblicksdarstellungen aus der Erinnerung. Es kann nicht garantiert werden, daß sie genau zutreffen.

Entwicklung: ca. 1975 bis 1978.

Projektiert als Bedienkonsole für eine EDV-Anlage mit dem Ziel, die verfügbaren Bauteile zweckmäßig auszunutzen (das Sortiment war bescheiden) . Eine Art Zwischenstufe zwischen einem reinen programmierbaren Steuerwerk (was  nur als Steuerautomat arbeiten, aber nicht rechnen kann) und einem Minicomputer ähnlich PDP-8 usw. Universelle Nutzung als programmierbare Steuerung  wurde nicht von Grund auf angestrebt, aber nach Abschluß der Entwicklung vorgeschlagen. Es wäre etwas Ähnliches geworden wie  PDP-14, nur leistungsfähiger (und -- naturgemäß -- etwas sehr spät...). Was man beim PDP-14 danebenstellen müßte, um universelle Programmierbarkeit und interaktiven Dialog zu unterstützen (Terminal, PDP-8 usw.) wäre hier -- dem Funktionsvermögen nach, jedoch nicht kompatibel -- schon eingebaut gewesen...

Quellen der Anregung: ein paar Bücher über Minicomputer und Mikroprogrammsteuerung, einige wenige Servicehandbücher der IBM (Theory of Operation Manuals), also das, was so herumlag oder was wohlmeinende Vorgesetzte einen haben lesen lassen... In den Einzelheiten ist es ein vorbildloser Entwurf. Patentanmeldungen gab es nur zum Spezialinterface und zum Leistungsmeßzusatz. Alles andere war eigentlich nur eine trickreiche Kombination an sich bekannter Grundsatzlösungen mit dem Ziel, trotz der unzulänglichen Bauelementebasis überhaupt etwas fertig zu bekommen. Der Versuch, Patentansprüche zu formulieren, wurde bald wegen offensichtlicher Aussichtslosigkeit abgebrochen.

Gesamtansicht:

1 - Elektronikschank, 2 - Stromversorgungsschrank, 3 - Monitor, 4 - Nadeldrucker. Die Stromversorgung hat seinerzeit etwas groß gebaut; primärgetaktete Schaltregler gab es nicht (wegen nicht verfügbarer Bauteile). Im Grunde hat man sich schon Mühe gegeben, das Gerät ansehnlich zu gestalten. Das Brühwürfeldesign des Monitors habe ich nicht zu verantworten...

Blick auf das Bedienfeld:

1 - Tastatur, 2 - Signalauswahl für Leistungsmeßzusatz, 3 - Bedeintasten, 4 -Schlüsselschalter für Spezialinterface, 5 - Anzeigen, 6 - Notschalter (für das gesamte System), 7 - Abdeckklappe des Wartungsfeldes, 8 - Griff zum Aufklappen.  

Die Tastatur war ein Kaufteil, geliefert von der legendären Waffenfabrik Brünn (damals CSSR). Das Bedienpult war als eine Art Blechnapf ausgelegt, in den die Tastatur hineingestellt wurde.

Auf dem Bedienpult sind auch die Taster und Schalter untergebracht, die zum Ein- und Ausschalten des Systems erforderlich sind.

Tasten und Anzeigen befinden sich in getrennten Bereichen des Bedienpultes. Das vor allem deswegen, weil alles auf gedrucken Schaltungen angeordnet wurde. Keine Kabelbäume, kein Drahtverhau. Hierzu wurden die Bauteile nach Bauhöhe und Art der mechanischen Befestigung sortiert.

Das Wartungsfeld war im normalen Betrieb abgedeckt. Es war recht aufwendig und komfortabel. Mikrobefehls- und Datenanzeige, Adreß- und Dateneingabe, Adreßvergleichsstop, Schrittbetrieb usw., ähnlich den seinerzeitigen Minicomputern und kleineren EDV-Anlagen (vgl. IBM System /3 und /7, Burroughs 1700, Data General Nova usw.). Die Abdeckklappe hatte einen massiven Griff, aus V2A-Stahl gefräst. Sie hatte aber keinen Gewichtsausgleich. Also: vorsichtig zuklappen, nicht einfach fallenlassen...

Es gab auch eine vereinfachte Version als Systemkonsole der EDV-Anlage R40, die ein herkömmliches Bedienfeld hatte. Ablösung der bisherigen Bedienschreibmaschine ("Abfrageeinheit"). Nur Systembedienung, keine Wartungsbedienung. Bedienfeld vereinfacht. Festwertspeicher nur drei (oder vier?) Steckkarten.

Bedienung mit Lichtstift:

Der Lichtstift (zum Auswählen durch Antippen) war eine wahlfreie Zusatzeinrichtung. Die Nachfrage soll nur gering gewesen sein.

Die Funktionseinheiten im Überblick:

Dieses Blockschaltbild als PDF

S.002b Block Diagram as PDF

Es ist eine Trickkiste, die in kein richtigen Schema paßt, weder ein Minicomputer noch ein simples Mikroprogrammsteuerwerk. Kein Universalbus, sondern Einzelanschluß der Funktionseinheiten. Details sind ohne Dokumentation nicht mehr zu rekonstruieren (schon lange her...).

Der Prozessorkern im Blockschaltbild:

Dieses Blockschaltbild als PDF

S.002b Block Diagram as PDF

12 Bits Verarbeitungsbreite, 12-Bit-Adressierung, Mikrobefehle 15 Bits + 1 Paritätsbit.

Die Maschine wurde um den Transformator-Festwertspeicher herumgebaut:

Elementare Datenformate:

Adreßstrukturen:

Die Mikrobefehlsformate.

Der Lokalspeicher:

 

Der Bildspeicher (Frame Buffer):

Das Taktschema der Maschine hat sich aus der Pixeldarstellung auf dem Monitor ergeben:

Mikrobefehlszyklus ca. 650 ns, Überspringen / Verzweigen usw. das Doppelte. Bildspeicherzugriffe bis zu 64 µs, weil auf den Zeilenrücklauf gewartet werden mußte. Ohne die eingeschachtelte (interleaved) Zeichendarstellung hätte man die Maschine mit etwa 400 ns laufen lassen können.

Vergleich zum Z80 (2, 5 MHz) anhand typischer Programmabläufe der Unterstützung von Bildschirmfunktionen (wie IBM 3270): Geschwindigkeit 10 mal höher, Speicherbedarf 1/4. Die Maschine läßt sich aber bei weitem nicht so flott programmieren wie der Z80...

Der erste Ansatz: System .002

Anfang der 70er Jahre sollte eine EDV-Anlage mit ECL-Schaltkreisen gebaut werden (Sortiment wie Motorola 10k / 100k, nur etwas eingeschränkt). Es wurde aber ein durchaus ansehnliches Sortiment an MSI-Typen angekündigt, bis hin zu 1k-SRAMs und zur 4-Bit-ALU. Der Einfall: damit eine 4-Bit-Maschine bauen. Jede Funktionseinheit im Datenweg braucht dann jeweils nur einen Schaltkreis, also auch nur ein Taktsignal. Clock Skew gibt es praktisch nicht. Also kann man die Mühle mit der höchsten Taktfrequenz laufen lassen, die die Baureihe hergibt (100 MHz und mehr). Projekt: Mikroprogrammsteuerwerk mit 32-Bit-Mikrobefehlen und 4-Bit-Verarbeitung. Damit sollte man alle möglichen Prüfgeräte bauen können, aber auch eine Bedienkonsole mit kompletter Bildschirmbedienung, so daß das herkömmliche Bedienfeld der  EDV-Anlage  entfallen kann (seinerzeit kam die 370/158 heraus). Auch wären die paar Platinen ein Probeprojekt gewesen, um die gesamte Entwurfsautomatisierung an einem einfachen, aber nicht trivialen Beispiel durchzuexerzieren. Der Vorschag wurde eingereicht und sogar angenommen. Dokumentation nicht mehr vorhanden. Damit ist leider auch nicht mehr festzustellen, ob das Konzept wirklich aufgegangen wäre. Turing-vollständig wäre der Apparat wohl gewesen. Ein sehr kleine Maschine, die die Verarbeitungsleistung nur über die Kürze der Taktzyklen bringen kann, ist aber nur dann wirklich brauchbar, wenn sie mehrstufige (geschachtelte) Unterprogrammrufe einschließlich der Parameterübergabe und Ergebnisrückgabe effektiv erledigen kann. Fragt sich, ob das wirklich der Fall gewesen wäre...

Nochmal von vorn: System .002b

Viele Probleme erledigen sich von selbst. Dieses hat sich dadurch erledigt, daß das gesamte Vorhaben mit den ECL-Schaltkreisen irgendwann eingestellt wurde. Daraus ergab sich das Problem der Arbeitsplatzsicherung, genauer gesagt, der Sicherung einer annehmbaren Arbeitsaufgabe.  (Unter den seinerzeitigen Bedingungen war der Arbeitsplatz als solcher sicher, es war aber fraglich, was man auf demselben zu tun bekommt / tun darf. Womöglich Prüfschritte erstellen oder Stücklisten ausfüllen, natürlich unter Aufsicht... Einfach kündigen und etwas Eigenes aufziehen ging ja bekanntlich nicht.)

Was gebaut werden sollte, war eine EDV-Anlage herkömmlicher Art. Wirkprinzipen S/370, aber TTL SSI / MSI und DRAM-Arbeitsspeicher. Das MSI-Sortiment war bescheiden. Zähler 74192 / 193, Schieberegister 7495, RAM 16 * 4, Multiplexer 8 zu 1 usw., aber keine ALU und kein RAM, der als Mikroprogrammspeicher brauchbar gewesen wäre. Es verblieb nur der bereits seit längerem bewährte Transformator-Festwertspeicher (Ringkerne und Fädelprinzip, so ähnlich wie im Bordcomputer des Apollo-Mondlandemoduls...). Die Maschine sollte ein herkömmliches Bedienfeld erhalten, die Signale sollten aus dem Innern der Maschine über Multiplexer zu den Anzeigen durchgeschaltet werden (in der Dokumentation der IBM-Mainframes als Serializer bekannt und seinerzeit auch so bezeichnet).

Die Grundfrage: kann man trotzdem was Brauchbares bauen?

Vielleicht, wenn man von der totalen Universalität abgeht und die Verabeitungsbreite höher nimmt. Es gab aber nur den Transformatorspeicher. Äußerlich eine unscheinbare Angelegenheit auf Steckkarten, keineswegs so hochgestochene Technologie wie der TROS im System /360. Eine Steckkarte enthält 4 kBytes. 8 Steckkarten sind das Maximum, das sich unter vernünftigen Beschränkungen der Größe und der Kosten unterbringen läßt. Also höchstens 32 kBytes.

Es sollte Ähnliches werden wie die Konsole der 370/158, aber ohne Diskette und als vorbildloser Entwurf mit  verfügbaren Bauteilen.

Was soll eine solche Maschine leisten?

Es sind zwei Grundfunktionen:

1. Systemkonsole. Bedienung des Betriebssystems. Das Gerät muß dem System gegenüber wie ein kompatibles Bildschirmgerät mit angeschlossenem Drucker erscheinen.

2. Bedienkonsole zur Wartungsbedienung. Kein herkömmliches Bedienfeld mehr. Signalanzeige, Auslösen von Schrittbetriebsarten, von Diagnosefunktionen usw. am Bildschirm.

Daß sich die erste Funktion (Systemkonsole) im Rahmen des Verfügbaren implementieren läßt, war schnell klar. Bildschirmsysteme, die das auch konnten, gab es aber schon.

Der eigentliche Startpunkt:

Wie bekommt man die vielen Signalanzeigen mit den zugehörigen Beschriftungen unter? Jedes Signal hat eine Serializeradresse, eine Bildschirmadresse und eine Textanzeige. Hinzu kommen die Anzeigeprogramme. Das paßt doch alles nicht in 32k?

Der entscheidende Einfall:

Wenn die Maschine (EDV-Anlage, Zentraleinheit) für ein herkömmliches Bedienfeld entworfen werden soll, dann muß der Serializer ja auf reguläre Weise angeschlossen werden.  Hätte man Disketten als Datenträger, könnte man Multiplexer nach Belieben auf die Steckkarten setzen  und die Signale so anschließen, wie es sich gerade ergibt. Die Zuordnung wird Bit für Bit in gespeicherten Tabellen beschrieben. Sollen die Signale aber auf Reihen von hart verdrahtetenLeuchtanzeigen treffen (Deserialisierung), müssen sie in einer jeweils bestimmten Reihenfolge seriell übertragen werden. Folglich muß der Serializer nach festen Anschluß- und Adressierungsregeln entworfen werden. Auf diese Weise liegt der Anzeigespeicher schon zu einem großen Teil in der Verdrahtung der Maschine. Um alle Bits eines Registers in der richtigen Reihenfolge anzuzeigen, braucht man keine Bitliste. Es genügt, die Serializeradresse in bestimmter Weise weiterzuzählen. Um so etwas zu codieren, wurde eine erste Version sog. Anzeigedeskriptoren ausgearbeitet. Um die Anzeige eines 64-Bit-Registers zu codieren, genügen vergleichsweise wenige Bytes. Startadresse auf dem Bildschirm, Darstellart (hexadezimal oder binär), Text, Bitnumerierung, Startadresse Serializer, Zählweise. Es hat sich gezeigt, daß  es -- unter der Voraussetzung, daß man den Serializer so entwirft, als ob ein herkömmliches Bedienfeld anzuschließen wäre -- tatsächlich passen müßte.

 

 

 

 

 

 

Aktuelles:

14. 11. 2017

Seite erstellt.