Wie schnell sind Voyagers Bordcomputer?
Heute vor genau 45 Jahren startete Voyager 1. Wir der regelmäßige Blogleser weiß arbeite ich seit drei Monaten an einem Buch über die Sonden. Ich hatte mir vorgenommen zu dem Startdatum fertig zu werden, was ehrgeizig war. Das habe ich auch geschafft – es muss nur noch korrekturgelesen werden. Ich bin das ganze Buch mindestens einmal durchgegangen und die Korrekturleser sind bei etwa der Hälfte angekommen. Ich habe aber auch das Unternehmen unterschätzt. Anfangs dachte ich das ich so bei 400 Seiten lande, dann wurden es 500 und derzeit sind es 588 Seiten. Davon sind aber rund 250 über die Vorgeschichte und Grundlagen (Swing-By, Vorherige Erforschung der Gasriesen, Pioneer und TOPS Sonden) und Nachfolger (Galileo bis Juno).
Derzeit kürze ich eher etwas. Es fallen mir zahlreiche Wiederholungen auf und ich habe zwei größere Teile entdeckt die hier in den Blog passen, aber nicht so sehr ins Buch. Den ersten davon gibt es heute. Der zweite ist Teil der Geschichte um die Golden Record. Über sie gibt es nun auch den Buchtext in der Website, da ich als an den Sonden interessierter dieses Kapitel bisher stiefmütterlich behandelt habe. Ebenso habe ich aus dem gleichen Grund das Kapitel über die TOPS Sonden ausgekoppelt. Als dritten neuen Aufsatz findet ihr (ohne Text) alle von Mastertape der Golden Record ausgelesenen Bilder.
Das Thema des heutigen Artikels ist so etwas was wohl mich, aber kaum jemand sonst interessiert. Es geht um die Geschwindigkeit der Bordcomputer eingeordnet in die damalige Zeit. Hier zuerst mal der Text aus dem Buch:
Als Voyager startete, waren Computer noch nicht in die Haushalte eingezogen. Der erste „PC“, der Altair 8800, erschient 1975. Bei ihm musste man Bytes über Kippschalter eingeben. Im selben Jahr, in dem Voyager startete, erschienen die ersten Computer mit Tastatur und Fernsehanschluss, die man einfach einschalten und programmieren konnte. Das waren der Commodore PET, das TRS-Modell I und der Apple II. Entsprechend gab es damals von der NASA keine Information, wie schnell Voyagers Bordrechner waren. Da sie nicht aus Mikroprozessoren bestanden, ist ein Vergleich schwer. Von allen drei Rechnern gibt es aber eine Angabe über die Zykluszeit:
Prozessor |
Zykluszeit |
Takt (bei Voyager geschätzt) |
Befehle/s |
Architektur |
---|---|---|---|---|
CCS |
88 Mikrosekunden |
0,2 bis 0,25 MHz |
11.000 |
18 Bit MSI |
FDS |
12 Mikrosekunden |
0,4 bis 0,73 MHz |
80.000 |
16 Bit MSI |
AACS |
28 bzw. 32,2 Mikrosekunden |
0,2 MHz |
35.000 |
18 Bit MSI |
6502 |
1 Mikrosekunde |
1 MHz |
250.000 |
8 Bit LSI |
8080 / Z80 |
1,6 Mikrosekunden |
2,5 MHz |
367.000 |
8 Bit LSI |
RCA 1802 |
5 Mikrosekunden |
1,6 MHz |
160.000 |
8 Bit LSI |
AMD 2900 |
1,25 Mikrosekunden |
4 MHz |
143.000 |
16 Bit LSI |
Die Zykluszeit ist die Zeit, welche die CPU für eine einfache Operation benötigt. Komplexe Operationen erfordern mehrere Zyklen. Bei der Z80 beträgt die Ausführungszeit bei einfachen Operationen vier Takte (einen Zyklus). Bei komplexen Operationen können es bis zu 23 Takte (sieben Zyklen) sein. Im Mittel sind es 6,8 Takte pro Instruktion.
Für die Zykluszeit des CCS gibt es zwei Angaben. Einmal 1,37 Mikrosekunden und einmal 88 bis 90 Mikrosekunden. Die letztere war angesichts dessen, dass das CCS aus dem Viking Bordcomputer (der ebenfalls 88 Mikrosekunden Zykluszeit hat) entwickelt wurde, wahrscheinlicher. Ich vermute, man hat hier zwei Dinge verwechselt: die Zykluszeit mit dem Takt und das FDS mit dem CCS. Für das FDS wäre ein Takt von 0,73 MHz (1 / 1,37 µs) plausibel, eine Instruktion würde dann 8 oder 9 Takte erfordern, davon alleine 4 für den Speicherzugriff.
Für das FDS gibt es eine Angabe über die durchgeführten Befehle: 80.000/s. Im Vergleich dazu lag ein 8080/Z80 Prozessor, mit den beim Start von Voyager üblichen 2,5 MHz Takt, bei 360.000 Befehlen/s. Ein 6502 mit 1 MHz Takt lag bei 250.000 Befehlen/s. Das berücksichtigt aber nicht, das die Voyager-Computer 16 oder 18 Bit Rechner waren und welchen Befehlsvorrat sie hatten. Die 16/18 Bit bieten einen Vorteil gegenüber den damals etablierten 8-Bit-Architekturen. Die Befehle aller drei Computersysteme waren einfach und auf ihre Aufgabe zugeschnitten. Heute würde man sie als Mikrocontroller bezeichnen, also als Prozessoren, die direkt mit der Hardware agieren. Ich denke, dass selbst das FDS einem damals aktuellen 8 Bit Mikroprozessor unterlegen war. Das verwundert nicht, schließlich wurden sie schon Jahre vorher entwickelt.
Den Mikroprozessor RCA 1802 und den Bit-Slice-Prozesor AMD 2900 habe ich hinzugenommen, weil diese Prozessoren in Galileo eingesetzt wurden. Der RCA 1802 ist ein 8 Bit Mikroprozessor wie der Z80 und 6502, aber in CMOS Technologie. Der AMD 2900 ist ein Bit-Slice Prozessor. Er verarbeitet nur vier Bits, kann aber kombiniert werden. Vier AMD 2900 wurden genutzt, um einen 16-Bit-Prozessor für Galileos AACS zu schaffen. In Galileo war die Geschwindigkeit durch den langsamen Speicher begrenzt. Mit adäquatem Speicher wäre der Rechner über 1 MIPS schnell gewesen. Galileo war die erste Raumsonde, die Mikroprozessoren einsetzte. Da bei Galileo auch die meisten Experimente einen eigenen Mikroprozessor und RAM/ROM hatten, gab es insgesamt 19 Mikroprozessoren, 320 KByte RAM und 41 KByte ROM.
Der Vergleich ist allerdings unfair, da Voyager nur die Technologie einsetzen konnte, die bei Projektbeginn existierte. Alle Mikroprozessoren erschienen später. Der einzige Mikroprozessor, der damals existierte, war der Intel 4004. Das war ein 4-Bit-Prozessor, der maximal 60.000 Befehle/s abarbeitete – doch das waren 4-Bit-Befehle. Für die Verarbeitung von 16 oder 18 Bit, wie beim FDS und CCS/AACS, muss ein 4 Bit Prozessor vier bis fünf Zugriffe durchführen. Das reduziert die Geschwindigkeit auf ein Viertel bis ein Fünftel. Zudem haben die Computer von Voyager mehr Register, die Speicherzugriffe ersparen und die Befehle sind mächtiger. Außerdem war der Adressbereich des 4004 von 640 Byte RAM und 4 KByte ROM zu klein, um ihn einsetzen zu können.
Computer |
Bitbreite |
Speicher |
In KByte |
Befehle/s |
Stromverbrauch |
Gewicht |
---|---|---|---|---|---|---|
CCS |
18 Bit |
4 KWorte |
9 KByte |
Max. 11.000 |
24,7 Watt |
15,2 kg |
AACS |
18 Bit |
4 KWorte |
9 KByte |
Max. 35.000 |
54 Watt |
49,5 kg |
FDS |
16 Bit |
8 KWorte |
16 KByte |
Max. 80.000 |
9,9 Watt |
19,3 kg |
Beim Stromverbrauch und dem Gewicht ist zu berücksichtigen, das an die Computer Hardware angeschlossen war, die zum System zählte. Beim AACS z. B. die Sensoren, Schrittmotoren und die Gyroskope. Alle Rechner zusammen haben einen Speicher von 68 KByte, aufteilbar in RAM und ROM.
Soweit der Text aus dem Buch. Nun eine Ergänzung. Ich habe nachgedacht und man kann die Geschwindigkeit auch direkt angeben und zwar anhand einer aufgabe. Das FDS war ausgelegt die Kameras ausgelesen. Seine Geschwindigkeit bestimmte die Datenrate, so war die maximale Datenrate zum Bandrekorder dieselbe wie die maximale zur Erde, was dafür spricht, dass dies die Grenze des FDS ist, denn es gab vorher schon schnellere Bandrekorder bei Viking und auch Galileo konnte schneller auf den Rekorde speichern als zur Erde übertragen. Was musste das FDS beim Auslesen der Kameras machen? Nach meinen Recherchen ist es so, das es die Elektronik anstoßen musste eine Zeile auszulesen. Die legte dazu über DMA in einem bestimmten Speicherbereich die digitalisieren Pixel ab. Das FDS musste diese getaktet auslesen, also eine kleine Schleife von einer definierten Dauer durchlaufen. Dann musste es die Daten selbst sichern. Dafür gibt es (wie übrigens auch für das Einlesen) zwei Optionen – als I/O Zugriff wird ein Wert an einen Port zum Sendesystem geschrieben oder es landet erneut in einem Datenblock, der dann komplett an das Sendesystem übergeben wird., Nach Beschreibung der Kompression für das Uranusencounter gehe ich davon aus, das die zweite Lösung gewählt wird. Das FDS scheint über memory-mapped I/O zu arbeiten. Dann kann man aber den Code für diese Schleife formulieren. Ich habe dies hier zweimal gemacht. Einmal in Pseudo-Assembler für alle Leser und einmal in der Maschinensprache des Z80, wobei ich spezielle Z80 (Nicht-8080) Befehle die die Aufgabe noch beschleunigen vermieden habe. Wer 8080 Code aber mal geschrieben hat, weiß warum ich die kryptischen 8080 Mneorics vermeide.
Pseudocode |
Z80 Assemblercode |
Takte |
---|---|---|
Lade Reg1 mit Adresse des digitalisierten Pixels |
Ld de,Pixeladr |
10 |
Lade Reg2 mit Adresse des Speicherblocks einer Zeile |
Ld hl,Block |
10 |
Lade Reg3 mit Zähler einer Zeile (800) |
Ld bc,800 |
10 |
Schleifenbeginn: |
Schleife: |
|
Lade Reg4 mit aktuellen Pixelwert aus Adresse bei Reg1 |
Ld a,(de) |
7 |
Speichere Inhalt von Reg1 bei aktueller Blockadresse ab |
Ld (hl),a |
7 |
Erhöhe Blockadresse um 1 |
Inc hl |
6 |
Erniedrige Zähler um 1 |
Dec bc |
6 |
Springe wenn nicht Null zum Schleifenbeginn |
Jp nz,Schleife |
10 |
Speicherblockadresse |
Block: defs 800 |
|
Pixeladresse |
Pixeladresse equ 1000h |
|
Schleifendauer |
36 Takte |
Diese Routine war für alle FDS Modi die gleiche, da das Verlangsamen des Auslesens dadurch bewerkstelligt wurde, dass die Pause nach dem Strahlrücklauf von 4,3 ms (ohne Verzögerung) auf 604,3 ms (Modus 10:1) ausgedehnt wurde. Das FDS beherrschte es aber auch, nur Teile einer Zeile auszulesen, das macht die Schleife etwas komplexer:
Pseudocode |
Z80 Assemblercode |
Takte |
---|---|---|
Lade Reg1 mit Adresse des digitalisierten Pixels |
Ld de,Pixeladr+Offset |
10 |
Lade Reg2 mit Adresse des Speicherblocks einer Zeile |
Ld hl,Block |
10 |
Lade Reg3 mit Zähler einer Zeile (800) |
Ld bc,800 |
10 |
Schleifenbeginn: |
Schleife: |
|
Lade Reg4 mit aktuellen Pixelwert aus Adresse bei Reg1 |
Ld a,(de) |
7 |
Speichere Inhalt von Reg1 bei aktueller Blockadresse ab |
Ld (hl),a |
7 |
Erhöhe Blockadresse um 1 |
Inc hl |
6 |
Erniedrige Zähler um 1 |
Dec bc |
6 |
Vergleiche Highbyte Zähler |
Ld a,highbyte |
4 |
Cp b |
4 |
|
Springe wenn nicht identisch zum Schleifenanfang |
Jp nz,Schleife |
10 |
Vergleiche Highbyte Zähler |
Ld a,lowbyte |
4 |
Cp c |
4 |
|
Springe wenn nicht Null zum Schleifenbeginn |
Jp nz,Schleife |
10 |
Speicherblockadresse |
Block: defs 800 |
|
Pixeladresse |
Pixeladresse equ 1000h |
|
Offset |
Equ 96 |
|
Highbyte |
Equ 2 |
|
Lowbyte |
Equ 191 |
|
Schleifendauer |
62 Takte |
Man sieht hier schon das der Z80 als 8 Bit Computer etwas benachteiligt ist, er muss den Vergleich der ja wegen des Maximalwest von 799 über 256 liegt, in zwei Schritten einmal mit dem höherwertigen Byte und einmal mit dem niederwertigen Byte durchführen. Das FDS als 16 Bit Rechner kann das in einem Schritt. Es durchläuft aus demselben Grund die Schleife auch nur 400-mal da jedes Lesen und Schrieben gleich 16 Bit also zwei Pixel liest und schreibt.
Das Einschränken der Pixelzahl pro Zeile war ein schon beim Start vordefinierter Mode, während das Weglassen von Zeilen erst bei Uranus und Neptun hinzukam. Das verwundert mich, weil wenn man ganze Zeilen weglässt das nur eine Prüfung außerhalb der Schleife (also in der Zeit die man dann für den Stahlrücklauf hat und damit in einem unkritischen Bereich) nötig macht bei dem Weglassen von Spalten es dagegen die Schleife verlängert. Das man die Bilder spaltenweise ausgelesen hat (dann würde es auch passen) kann ich aber wegen unvollständiger Bilder in denen immer der untere Teil fehlt, ausschließen.
Nun zur Geschwindigkeitsabschätzung. Eine Z80 gab es damals mit einem maximalen Takt von 2,5 MHz, die hätte pro Sekunde 69.000 bzw. 40.000 Durchgänge (mit Prüfung) ermöglicht was 322 bzw. 555 kbit/s entspricht oder die drei bis fünffache Geschwindigkeit des FDS.
Es spricht für mich viel dafür, dass das FDS ähnlich arbeitet, denn es hatte etwa 70 µs für ein Pixel, 140 µs für ein 16-Bit-Wort. Die Zykluszeit wird mit 12 Mikrosekunden angegeben, wobei Befehle mehrere Zyklen benötigen können (bei der Z80 beträgt sie 4, im obigen Beispiel brauchen Befehle bis zu drei Zyklen). Bei einem 16 Bit Rechner sind es maximal 8 Befehle in einer Zeile, davon drei mit Speicherzugriff die mindestens einen zweiten Zyklus brauchen. Das FDS kann maximal 11 bis 12 Instruktionen in dieser Zeit durchführen, was dann bei 8 Befehlen + 3 Extrazyklen für Speicherzugriffe recht gut passt.
Ein 8080 wäre also drei bis fünfmal schneller als das FDS. Würde man die LDI/LDIR Instruktion der Z80 einsetzen so würde die Ausführungszeit von 36 auf 21 Takte bzw. 62 auf 52 Takte sinken, entsprechend wäre eine Z80 dann vier bis zehnmal schneller als das FDS.
Aber man muss eben daran denken: das FDS wurde entworfen, da gab es die 8080 noch gar nicht. Wie lange das her ist erkennt man an den Speicherchips. Nach meinen Recherchen fassten die 256 Bits pro IC, der gesamte Speicher benötigte so 512 IC. Ein typischer Heimcomputer mit einer der obigen CPUs hatte dagegen 8 oder 16 Chips. Bei gleicher Chipanzahl hätte ein C64 z.B. 4 MByte Speicher. Das lag am Alter, aber auch daran, dass CMOS IC nur ein Viertel von NMOS Chips der gleichen Ära speicherten.
Zuletzt noch etwas aktuelles, zum meinem neuen Buzz-Thema „Verseichten“. Das hat nun auch die NASA erfasst. Voyager 1 übertrug sein Mai „Nonsense Daten“ des AACS, eines der Computersysteme an Bord. Das wurde nun behoben. Die Aussage der NASA ist nicht besonders ausführlich: „The AACS had started sending the telemetry data through an onboard computer known to have stopped working years ago, and the computer corrupted the information.“
Nun arbeiten meiner Recherche nach alle Rechner von Voyager 1, ich fand bei einer neuen Recherche auch nichts anderes. Es macht auch kein Sinn, wie soll ein nicht mehr arbeitender (also abgeschalteter) Computer die Information verändern? Sie würde dann wohl eher nicht ankommen. Aber einer der beiden oberen Speicher des FDS von Voyager 1 ist seit den achtziger Jahren defekt. Es spricht also dafür, dass man die Daten wohl über diesen Speicher geleitet hat. Warum schreibt man das nicht? Das sind zwei Sätze mehr. Überfordert das schon den heutigen Leser? Oder ist die Person schon überfordert, die den Text geschrieben hat? Ich glaube ja eher an letzteres.
Man hat die Ursache der Anomalie noch nicht gefunden, sondern nur die Auswirkung.
„Die Ingenieure wissen noch nicht, warum das AACS damit begonnen hat, Telemetriedaten an den falschen Computer zu leiten, aber es hat wahrscheinlich einen fehlerhaften Befehl erhalten, der von einem anderen Bordcomputer generiert wurde. Wenn dies der Fall ist, würde dies darauf hindeuten, dass an anderer Stelle im Raumschiff ein Problem vorliegt. “ mit goggle übesetzt.
Falsche Befehle vom CCS an das AACS gab es schon öfters. Aus meinem Buch:
„Am 13.12.1979 verlor die Bodenstation nach einer Kurskorrektur von Voyager 1 in 970 Millionen km Entfernung den Kontakt. Während einer Kurskorrektur gab es einen kombinierten Fehler von einem fehlerhaften Moduswechsel-Kommando mit gleichzeitig ausgelösten Fehler durch Prüfinformationen. …
… Die Ursache des Kommunikationsproblems zwischen CCS und AACS wurde untersucht. Bis dahin hatte das CCS über 38 Millionen Befehle an das AACS ohne Probleme übermittelt. Es zeigte sich, dass die beiden CCS, die parallel arbeiteten und immer dieselbe Ausgabe haben sollten, leicht differierten, eventuell löste dies den Fehler aus.“
Man merkt das Computer eine Leidenschaft von Dir sind Bernd. 🙂 Ich finde deine Artikel zu den Computerthemen interessant, leider versteh ich sie meist net..da fehlt mir einfach das Grundwissen zu. Lesen tu ich sie dennoch gern