Back to Diane's HomePage
Kontakt Datenschutz

Diane's DEC Alpha & VAX Page


English version


von

Diane Neisius aka ~medusa

Last update: 15. Dezember 2012



Inhalt

DEC Alpha 21164

MicroVAX II

Links



Anti-Spam codierte Mailadresse :
medusa ät diane minüs neisius döt de




DEC Alpha 21164



Manchmal entstehen Projekte durch Zufall. Für meine Chipsammlung hatte ich schon eine Weile nach einem Alpha-Chip gesucht und dann mehr oder weniger zufällig einen in der Elektrobucht günstig erwischt. Irgendwie war ich aber neugierig, ob dieser große Klotz aus Keramik und Gold auch noch funktioniert und habe mehr oder weniger ziellos nach einer geeigneten Platine dafür gestöbert. Und dann, auch ziemlich günstig, gefunden. Sogar mit 1GB RAM drauf und einer weiteren 21164 CPU mit 533 MHz. Es war sogar noch eine Multifunktionskarte (PCI64) dabei, die über 2 SCSI-Anschlüsse, zwei Ethernet-Ports und einen Grafikadapter verfügt. Letztere brauche ich eigentlich nicht (falls die jemand haben möchte, einfach mailen, bevorzugt im Tausch gegen andere DEC-Hardware für die VAX oder PDP-11). Alles funktionierte bestens, auch die zuerst ergatterte CPU ist trotz leichter Übertaktung bei 466 MHz noch voll funktionsfähig.
Bild 1 - Dieser Chip löste mein Alpha Projekt aus. Obwohl als "Schrott" gekauft, ist er noch voll funktionsfähig.

Fragt sich, was man mit einem nackten AlphaPC 164LX Motherboard anfängt. Ich natürlich, wenn es denn irgend geht, erstmal Debian Linux draufpacken. Über die Installation von Debian auf Alphas gibt es im Web sehr gute Anleitungen, deshalb will ich das hier nicht nochmal alles aufschreiben, sondern nur auf die Probleme und ihre Lösung eingehen.
Ich habe über den ersten seriellen Port (das ist der obere DB9- Stecker) einen Terminalemulator auf meinem Desktop-PC drangehängt. Mit einem handelsüblichen ATX-Netzteil für PCs startete mein Alpha-Motherboard in den SRM.
Bild 2 - Das AlphaPC 164LX Board von oben gesehen. Charakteristisch für diese Platinen ist die "Kachelung" mit den L3-Cache Chips links oben. Zwei CF-Festplattenadapter stecken auf den IDE-Anschlüssen statt den Festplatten, ihre Kontroll-LEDS beleuchten die halbe Platine. In dem PCI32-Slot wird eine Netzwerkkarte mit dem schon etwas betagten RealTek 8139 Chip von der Alpha erkannt (von oben schwer zu sehen).

Bild 3a/b - Nebst dem PC-Netzteil braucht man als Minimum noch einen Taster, um das Alpha-Board einzuschalten (links neben dem 20-poligen ATX-Stecker sichtbar). Ich habe noch die Power-LED, einen Reset-Taster und die HD-LED bestückt. Alle Taster/LEDs sind auf Stücke einer Sockelleiste gelötet und werden auf die Platine aufgesteckt.

Für einen Bootversuch habe ich aus meinem Desktop das DVD-Laufwerk ausgebaut und an den zweiten IDE-Bus gehängt. Die Debian-Installer DVD für Alpha bootet davon auch ganz schön mit dem SRM-Kommando "boot dqb0 -flags 1".
Für den ersten IDE-Bus habe ich als Ersatz für eine Festplatte einen CF-Adapter mit einer 8GB-Karte für die Linux-Installation besorgt. Gewissermaßen statt einer SSD, ist das billiger als die meisten Festplatten, die man heute so kaufen kann.
Das lief auch erstmal alles ganz gut, Debian installiert sich auf der Speicherkarte ohne Probleme. Der Installer-Bildschirm sieht im reinen Textmodus über Seriellschnittstelle witzig aus, es ist aber sonst alles wie gewohnt. Nur der Reboot klappt nicht, auch dann nicht, wenn die Platte/CF-Karte im BSD-Format partitioniert wird. Ich habe alle möglichen Tips aus dem Web ausprobiert und dreimal auf unterschiedliche Art installiert, nichts hat funktioniert.

Booten von der Installer-DVD klappte nach wie vor, und von dort aus im Rescue-Modus eine Shell öffnen und das Filesystem auf der Karte mounten und per chroot auch richtig benutzen klappte wiederum beim ersten Versuch. Das Linux Rootfilesystem war also in Ordnung, nur wollte der zickige SRM nicht davon booten. Allerdings tat er das doch problemlos von ISO-Filesystemen... hmmm...
Also habe ich die /boot Partition von der CF-Karte kopiert (mit einem Kartenadapter am PC ist das sehr viel einfacher als eine ganze Festplatte umzubauen), habe davon mit einem normalen Brennerprogramm ein *.iso Image erstellt und das dann mit dem Tool isomarkboot bootfähig für eine Alpha gemacht. (Der aboot Loader muß dafür im Wurzelverzeichnis liegen, was er bei einer vom Installer erzeugten Partition meistens schon tut. Er heißt für die 164LX-Platine bootlx.)
In der Shell gibt man dann ein "isomarkboot mybootiso.iso bootlx" (oder wie das *.iso nun genau heißt). Man kann vor dem Erstellen des *.iso Images in der Datei etc/aboot.conf noch einige Anpassungen vornehmen, falls nötig. (Wer wie ich nur die seriellen Konsolenschnittstellen unter Linux benutzen möchte, sollte dem Kernel das über den entsprechenden Kernelparameter "console=ttyS0" mitteilen.)
Das bootfähige Image habe ich dann einfach mit dd auf eine zweite CF-Karte kopiert. Es tut dafür die kleinste, billigste und langsamste CF-Karte, die man finden kann, denn das Image ist nur ungefähr 100MB groß, der Rest des Speichers bleibt also unbenutzt. Alternativ kann man das Image natürlich auch auf eine CD brennen und von der booten. Hab ich auch ausprobiert, allerdings wollte mein Desktop-PC dann auch sein DVD-Laufwerk wiederhaben. ;)
Bild 4 - Der AlphaPC 164LX unter Debian Linux. Links hinten ist das Seriellkabel zu sehen, ein Fenster mit dem Minicom-Terminalemulator ist auf dem Flatscreen meines PCs zu sehen. Schnittstelle ist per Default auf 9600Baud, 8Bit, keine Parität, 1Stopbit gesetzt. Bei einem 15 Jahre alten AlphaPC paßt das stylische schwarzgrüne Terminal im Stil der alten VT102s, das ich sonst für die PDP-11 benutze, auch noch ganz gut...

Tja, und dann zu den Anwendungen... natürlich mußte ich die Performance des Maschinchens mit Linpack testen. Erstaunlicherweise entspricht die Performance der 15 Jahre alten Alpha durchaus noch der neuerer Maschinen, wie etwa dem iPad 1 oder der Wii.
Bei 1GB Speicher paßt mit Linpack sogar eine 10000x10000 Matrix noch, allerdings rechnet die 21164 CPU an der LU-Zerlegung auch etwa 1.5 Stunden...

Was mir noch fehlt ist ein Gehäuse. Ein kleines 2HE flaches im Design der AlphaStation 500 könnte mir gefallen.




MicroVAX II

Mit einer PDP-11 und einer Alpha fehlte mir nun eigentlich nur noch eine VAX in meiner Sammlung... auch hier hatte ich eigentlich zuerst nur an eine CPU (vielleicht eine schicke KA820) für meine Sammlung gedacht. Natürlich mit dem Hintergedanken, daß es schön wäre, wenn die auch noch funktioniert. Was ohne zusätzlichen Aufwand eigentlich nur in der Qbus-Packplane meiner '11 möglich ist... womit ich dann jedoch auf eine von den MicroVAXen festgelegt war.
Ich habe schließlich sehr günstig eine KA630 CPU ergattert, also die ursprüngliche Microvax II mit dem 78032 Chip drauf, historisch der ersten VAX, deren Kern in einen Chip paßte. Meine ist eine "A2" Revision, äußerlich gleich der A1. Auch schön für eine Sammlung. Zudem hat diese CPU fast genau die gleiche Leistung wie die berühmte VAX 11/780, was auch Anlaß zu einigen Wortspielereien mit dem Namen der uVAX II geben kann (s.u.).

Die KA630 CPU ist mit Konsolen-Schnittstelle, ROM, 1MB RAM und der entsprechenden Firmware ausgestattet, um auch ganz alleine laufen zu können. Die Konsolenfirmware erinnert in ihrem Design durchaus an das, was einen bei DEC Alpha's im SRM an der Konsole erwartet, allerdings nur in rudimentärem Zustand (man versteht dann aber, wo's herkommt).
Das M7606-Modul (also die KA630-CPU) ist Quad-Height, paßt also erstmal nicht in eine Dual-Backplane, wie ich sie besitze. Ein genaueres Studium zeigt allerdings, daß auf den "C" und "D" Kontaktflächen nur Adreßbuskontakte liegen. Stromversorgung ist redundant auch auf "A" und "B" vorhanden. Die Kontrollanschlüsse der Qbus-VAXen sind die gleichen wie bei Qbus-PDPs (insbesondere DC_OK, siehe meine PDP-11 Seite). Es ist also möglich, eine KA630 CPU nur mit einer Dual-Packplane auf den Kontaktflächen AB zu betreiben, allerdings nur allein. Meine Backplane ist zudem auch nur eine Q18, was aber ohne weitere eingesteckte Module auch keine Rolle spielt.

Bild 5 - Das ist wahrscheinlich die abgedrehteste VAX, die es im Web zu sehen gibt. Meine H9281 Dual Backplane (von der PDP-11/03) ist hier aus dem Card Cage ausgebaut, da die Quad-Height KA630 sonst überhaupt nicht paßt. Die nackte Backplane kann allerdings nicht auf ihrer Unterseite liegen, da sonst die Wirewrap- Kontaktpins verbiegen und Kurzschlüsse verursachen. Deshalb liegt hier die uVAX II CPU mit der auf die Kontaktflächen A und B aufgesteckten Backplane auf der Seite. An der Backplane ist die kleine Kontrollplatine von der PDP-11 zu sehen, das PC-Netzteil liegt hinter der Platine.
Wichtig ist: die uVAX muß aktiv gekühlt werden. Ohne Kühlung sind die Kühlflächen der beiden Chips 78032 und 78132 nach wenigen Minuten zu heiß, um sie noch anfassen zu können. Das ist nicht gut, denn für alle Halbleiter gilt: je kühler, desto länger leben sie. (Eine Weisheit, die die Besitzer übertakteter Grafikkarten an modernen PCs bestätigen können.) Für die Kühlung sorgt hier ein hängender PC-Gehäuselüfter, der die beiden pilzförmigen Kühlkörper anbläst.
Hinter der Platine ist der PC-Bildschirm mit dem Terminal-Emulator im passenden Schwarz-Grün zu sehen.

Auch die serielle Konsolenschnittstelle kann mit Zubehör von der PDP-11 versehen werden. Sie hat die gleiche Belegung wie die vier Stecker an der DLV11-J Seriellkarte für die '11. Deshalb hatte ich natürlich schon passende Kabel... auch dazu der Verweis auf meine PDP-11 Seite.
Alle anderen Steckanschlüsse können zunächst unbelegt bleiben. Die Konfiguration eintspricht dann logischen Nullen an den Eingängen des Steckers J2, was bedeutet:

Auf diese Weise läßt sich die uVAX schon mal starten. Der Prompt der Konsole ist übrigens schon genau der, der auch noch bei der Alpha Verwendung findet, ein ">>>".
Direkt nach dem Booten ist die CPU in der Konsole im Interruptmodus mit der höchsten Priorität, d.h., alle Interrupts sind abgeschaltet, und der Interrupt Stack Pointer (ISP) wird auf R14 gemappt. Er wird auch automatisch auf einen Wert von 0x200 initialisiert.
Weiterhin ist das virtuelle Memory-Mapping abgeschaltet, alle Speicheradressen entsprechen also den physikalische Adressen.

Bild 6 - Ein Blick auf den L-förmigen Spezialjumper, den ich mir für J2 aus einem Stück gedrehter Sockelleiste gebastelt habe. Er zieht den "HLT ENB" Pin und die Konfigurationspins 0 und 2 für die serielle Schnittstelle auf Masse (was in der invertierten Eingabelogik bedeutet, daß die entsprechenden Bits 1 werden). Die CPU bootet damit bis zur Konsole und sucht nicht mehr vergeblich nach Platten oder Netzwerk, und die Baudrate der Seriellschnittstelle ist auf die standardmäßigen 9600 Baud gesetzt. Zu diesen Angaben vgl. das Handbuch der KA630 CPU.
Links neben J2 mein Seriellkabel von der DLV11-J Schnittstelle, rechts die Status-LEDs der uVAX. Grün zeigt DC_OK an, die vier roten LEDS sind die Bits des Konsolenstatus. Im Halt-Mode ist die Ausgabe "8", also binär "1000" oder "An-Aus-Aus-Aus".

An der Konsole kann man nun mit sehr viel mehr Komfort als bei der PDP-11 die internen Register der uVAX oder Speicherstellen abfragen oder ändern. "e" steht für "examine" und gibt die Inhalte von Werten aus, "d" wie "deposit" schreibt Werte ein. Mit "s" kann man ein eingegebenes kleines Programm im Speicher starten. In Anlehnung an das Mini-Programm, das die Speichergröße in der PDP-11 ermittelt, habe ich genau so etwas auch für die VAX geschrieben:

P  00001000  D4 50          <--- R0 = 0
P  00001002  90 80 51       <--- Lade R1 von der Adresse in R0, erhöhe R0
P  00001005  11 FB          <--- ...und springe wieder zum letzten Befehl
Das P zeigt die Konsole bei einem "e" Kommando an, es bedeutet, daß der Wert an der physikalischen Speicheradresse liegt (G bedeutet "general purpose register" und I "internal register").
Startet man dieses kleine Programm mit dem Befehl "s 1000", dann wird die Schleife etwa eine Sekunde lang ausgeführt, ehe sie mit einer "DBL" Fehlermeldung abbricht (die CPU ist noch im höchsten Interruptmodus und hat trotzdem noch eine Unterbrechung durch einen Speicherfehler bekommen). Mit "e /g 0" kann man nun das Register r0 auslesen, in dem der Wert der Speichergröße steht. In meinem Fall nur mit dem 1MB Onboard-RAM ist das der Hex-Wert 00100000.

Wird fortgesetzt!

Appendix - VAX 11/630

Eine VAX 11/630 gab es von DEC genausowenig wie eine MicroVAX 11/630. Es gab aber eine VAX in einem Gehäuse namens 630 QZ oder 630 QY, bei der auf der Titelseite des Manuals die Zeile "MicroVAX II 630 QB/QY" stand. Der verwendete Schrifttyp verwendete nur eine senkrechte Linie für das große "I", was auch in anderen Fällen nur schwer von einem "l" oder einer "1" unterscheidbar ist.
Allerdings ist die Vermutung, daß das 11/630 heißen soll, im übertragenen Sinn auch nicht ganz abwegig. In einer uVAX II steckt eine KA630 CPU, während in der berühmten VAX 11/780 in der Tat eine KA780 CPU zu finden ist. Der (falsche) Schluß ist also auf den ersten Blick nicht unsinnig.
Ich muß sagen, ein Gehäusedesign inspiriert von der 11/780, nur mit einem gefakten 11/630 Typenschild ist ein interessanter Gedanke für meine uVax II... :)





Links


Debian homepage -- Alles was der Fan von reinem GNU/Linux braucht :)

Bitsavers -- Eine Fundgrube an Dokumentation von alten Computern

HP Alpha Archive -- Dokumentation für Alpha Hardware bei HP



*

Referenzen

Alpha:
[1] Alpha 21164 Microprocessor Hardware Reference Manual, DEC, Maynard, Massachusetts 1996

[2] Alpha 21164 Microprocessor Data Sheet, Maynard, DEC, Massachusetts 1996

[3] AlphaPC 164LX Motherboard Technical Reference Manual, Compaq Computer Corporation 1999

[4] AlphaPC 164LX Motherboard Tru64 UNIX User's Manual, Compaq Computer Corporation 1999

[5] Alpha Architecture Reference Manual 4th Edition, Compaq Computer Corporation 2002

MicroVAX:
[6] KA630-AA CPU Module User's Guide, DEC 1986

[7] VAX-11 Architecture Reference Manual, Revision 6.1, DEC 1981

[8] MicroVAX II 630QY, 630QZ Operation, DEC, Maynard, Massachusetts 1986






Created: 15. Dezember 2012
© 2012 Diane Neisius