DEC RL02 Simulator

Wie schon Eingangs erwähnt geht es mir bei diesem Projekt um die Erhaltung der Software. Die Software ist allerdings direkt abhängig von dem einwandfreien Zustand des Storage Laufwerks, in diesem Fall eine DEC RL02. Das damals ( ~1980 ) erschienene RL02 Laufwerk entpuppte sich als ALLROUND-Laufwerk und war durchgehend auf allen DEC System-Plattformen vertreten, wie PDP-8, PDP-11, VAX mit den Betriebs Systemen OS-8, RT-11, RSX-11, MUMBS, RSTS und VMS. Dies war der Hauptgrund warum ich mich für die Simulation dieses Laufwerks entschieden hatte.

Diese Laufwerke stehen nicht mehr lange funktionsfähig zur Verfügung. Die meisten Laufwerke funktionieren leider eh nicht mehr. Ersatzteile gibt es sowieso nicht mehr und so muss man mit großem Zeitaufwand aus vielleicht 3 defekten Laufwerken ein funktionierendes Laufwerk bauen. Auch an den Datenträgern nagt die Zeit, denn die Magnetschicht unterliegt auch der Alterung und die Daten werden bald nicht mehr zur Verfügung stehen. Read-Error und zu viele Bad Blocks sind die typischen Symptome.

Um das Projekt überhaupt starten zu können benötigte ich die dementsprechende Hardware, welche mir das Computer-Museum in München ( http://www.computermuseum-muenchen.de/ ) zur Verfügung stellte. Eine Micro-PDP-11 mit 11/23+ CPU + RLV-12 Controller und eine RL02, welche ich wieder so einigermaßen instand setzen konnte. Vielen Dank an Hr. DR. John G. Zabolitzky und Hr. Wolfgang Kainz-Huber.

Projektstart war September 2009. Da ich eine Wissenslücke seit 1995 von gut 15 Jahren hatte, mußte ich mich Stück für Stück auf die neue Technologie umstellen, wie C-Programmierung auf ARM-7 CPU's. Das war nicht einfach für mich. Ein Video von Fritz Weld zeigt ein RL02-Laufwerk in Aktion: RL02-in-action

Das Projekt startete. Meine Motivations Gründe für dieses Projekt ist sicherlich auch Nostalgie, die Liebe zu den Computer-Oldtimer und auch die Herausforderung, etwas zu realisieren, was es weltweit noch nicht gibt.

In eigener Sache: Da ich dieses Projekt ausschliesslich in meiner Freizeit durchführe und somit leider nicht kontinuierlich daran arbeiten kann , gibt es immer wieder Verzögerungen. Für jeden Hinweis bin ich deshalb sehr dankbar.

Der Aufbau begann im September 2009. Zuerst musste ich ein spezielles, 40 poliges Flachbandkabel anfertigen für die Verbindung zwischen RLV-12 Controller und dem RL02 Laufwerk mit einen zusätzlichen Connector für die Hardware des RL02 Simulator um sich quasi in den RL02-Bus einzuhängen. Das Design des RL02-Bus beruht auf einer Differential Bus Architektur mit +/- 5 Volt, jeweils 6 Signale für beide Richtungen . Ich fand keinen vernünftigen Ersatz für die nötigen Bus Receiver/Transmitter Chips und hatte erst mal große Mühe, die Original Chips vom Typ 75113 und 75107 aufzutreiben. Letztendlich ist mir dies dann doch gelungen und ich baute eine Schaltung in Wire-Wrap Technik auf . Ein zusätzlicher DC/DC Konverter war dazu auch noch erforderlich um die benötigen +/- 5Volt zu erhalten. Somit konnte ich erstmal die Signale auf TTL-Level für Messzwecke mit Scope und für die weitere Verarbeitung konvertieren. Der Aufbau ist im folgenden Bild ersichtlich. Oben ist der 40-polige Connector für den RL02-Bus.

A) Im Überblick ist hier die gesamte Entwicklungs-Hardware zu sehen. Oben links ist das QL200 PIC-MCU Development Board zu sehen. Es war der erste Versuch. Allerdings stellte sich sehr schnell heraus, daß eine PIC 16Bit MCU vollkommen unzureichend war für dieses Projekt. Das Programmieren in Assembler mit dem Integrated Development Environment MPLAP von Fa. MICROCHIP war für mich kein Problem und es zeigte sich sehr schnell, daß der Durchsatz und die Bandbreite mit 8 Bit nicht ausreichten. Fehlinvestition für dieses Projekt , aber es ging weiter....

... und hier sind alle 3 aktiv benützen und verkabelten Komponenten zu sehen ( Stand FEB 2010 ):

B) Im Oktober 2009 war ich dann in der Entscheidungs- Phase, welche MCU ich benützen soll Nach langem Recherchieren habe ich mich dann für das LPC-P2148 Development Board von Fa. OLIMEX entschieden. Dieses Board arbeitet mit einer MCU: 16/32 bit ARM7TDMI-S™ ( Fa. Philips ) with 512K Bytes Program Flash, 42K Bytes RAM, USB 2.0, RTC, 10 bit ADC 2.44 uS, 2x UARTs, 2x I2C, SPI, 2x 32bit TIMERS, 6x PWM, 8x CCR, 1x DAC, WDT, 5V tolerant I/O, up to 60MHz operation. Dieses Board ist Ideal für den Einstieg gewesen und bestens für die Entwicklungsphase geeignet. Im Endausbau wird es dann wohl ein Board wie z.B. das LPC-H2294 werden. Im folgenden Bild ist mein LPC-P2148 Bord zu sehen mit zusätzlichen 16 Leuchtdioden um den Datentransfer, welchen ich mit 16 Bit realisierte zu überwachen und zu testen.

C) Nun ging es eher zäh weiter. Die Software Entwicklungs-Umgebung musste aufgesetzt werden ( Siehe 1.4 ) und die Hardware des RL02 Simulator musste Stück für Stück entwickelt werden. Im ersten Schritt entwickelte ich eine Schaltung um das Command-Register des RL02-Laufwerks auszulesen, da es die Basis für alles Weitere ist. Da ich noch von der „Alten Schule“ bin, bzw. damals war, realisierte ich dies mühevoll mit Wire-Wrap Technik und Lötkolben. Die Schaltung funktionierte letztendlich und der Aufbau ist im folgenden Bild ersichtlich. Die Schaltung dazu ist hier einsehbar: Schaltung-Command-Register

D) Der bisher größte Durchbruch bei diesem Projekt: FPGA. Ich selbst als „Oldi“ verweigerte mich sehr lange diese neue Technologie einzusetzen und im Nachhinein ärgere ich mich , weil ich diesen Schritt nicht früher gemacht hatte. Ich war jetzt voll in der embedded systems Welt angekommen. Und es ging zügig weiter. Ich entschied mich für den MAXII-FPGA von Fa. ALTERA . Dieser FPGA befindet sich komfortabel vor-montiert auf einen MAXII-Micro-Kit-Board inklusive USB Blaster von Fa. Terasic Technologies Inc , bezogen von Fa. Digi-Key . Mit der mitgelieferten Quartus II 9.1 Web Edition Software von Fa. ALTERA kann ich nun in einen Bruchteil der Zeit eine Schatung entwickeln. Das Micro-Kit-Board habe ich Steck-Kompatibel zur obigen TTL-Schaltung aufgebaut und ist im folgenden Bild ersichtlich:

Environment:

Für das Programmieren der Entwicklungsumgebung aus Kapitel 1.3. benütze ich einen Laptop mit Windows XP. Die serielle Schnittstelle ist mit dem LPC-P2148 Development Board , RS232-0 verbunden, um die HEX-Dateien herunterzuladen. Über einen 4-Port USB-HUB und 2 USB/Serial-Konverter ist die Console der Micro-PDP-11 und die RS232-1 Schnittstelle des LPC-P2149 Board verbunden. Die verbleibenden 2 USB-Ports sind mit dem Micro-Kit-Board und dem QL200 PIC-MCU Development Board verbunden. Da mein Laptop schon in die Jahre gekommen ist, lasse ich die Quartus II 9.1 Web Edition Software von Fa. ALTERA für die Programmierung des FPGA auf meinen Quad-Core PC unter Windows-Vista laufen, welcher über ein Netzwerk Laufwerk mit meinen Laptop verbunden ist. Der Laptop wird somit beim Programmieren des FPGA in meinem Fall meistens nur für das Flashen des FPGA benützt.

Software:

Meine gesamte Software Umgebung für die ARM-7 Programmierung ist “Free Software“, basierend aus dem GNU Compiler Collection ( GCC ) Bereich. Meinen Laptop habe ich nach vielen Hin und Her und Ausprobieren mit folgenden Tools in folgender Reihenfolge installiert, was dann auch zum Erfolg führte. Zuerst das Dev-C++ Integrated Development Environment (IDE) installieren. Als nächstes benötigt man die Cygwin Umgebung, um mit Unix Commandos arbeiten zu können. Nun braucht man noch den arm-none-eabi-gcc C-compiler für den ARM7. In der Cygwin Umgebung ist leider kein der make Utility dabei. Ich benütze das mingw32 Utility, läuft ohne Probleme. Das Flash-Tool von Philips sollte die Version 2.2.3 beim Einsatz des LPC-P2148 Board sein ( Flash-Utility-Doku ).

Die Programmierung des MAXII-Micro-Kit-Board erfogt mit der Quartus II 9.1 Web Edition Software von ALTERA. Die Neue Version 9.1 ist ohne Probleme vom ALTERA Online-Update-Service zu beziehen. Diese Version läuft ohne Probleme auf meinen Windows-Vista 64Bit System.

Block diagram:

Aufbau der gesamten Entwicklungsumgebung basierend auf der ARM-7 MCU und MAXII FPGA

September 2010 : Neues DE1 Board mit Cyclone® II FPGA. ARM-7 wird durch NIOS MCU abgelöst.

Benutzung der SD Card:
Eine SD Card ist ein Flash-Memory Baustein mit 512 Bytes/Block. Jeder dieser Blöcke kann nur mit einer limitierten Anzahl beschrieben werden. ( Abhängig von der eingesetzten SD Card variiert dies zwischen 1000-2000 Schreib Zyklen ). Läuft nun ein altes Betriebssystem (RSX11-M) von der SD Card mit meinen Simulator, würde die SD Card nach einigen Stunden unbrauchbar sein, weil diese alten Betriebssysteme sehr I/O intensiv arbeiten.

Servo/Header struktur der RL02 Cartridge macht Probleme:
Die RL02 Cartridges wurden in der Factory Vor-Formatiert und das Servo/Header Format war DEC intern streng geheim, um sicherzustellen, dass die Kunden nur die relativ teuren Cartridges von DEC kaufen mussten. Im Servo/Header Bereich der RL02 Cartridges tauchen ab und zu 0.125uS oder 0.625uS ( 0.250uS, 0.325uS, 0.500uS is normal ) MFM Signale auf und verursachen, dass mein MFM Decoder im Servo/Header Bereich durcheinander kommt und nicht mehr synchronisiert ist. DEC hatte dies damals mit einen ROM Code quasi ausgeglichen, welcher auf dem RLV-11/12 Controller sitzt. Um diese leider undokumentierte Gegebenheit im Kapitel C) zu umgehen, überspringe ich den Servo/Header Teil und synchronisiere das MFM Timing neu in der Data preample (PR2) Phase, welche aus 47 "0" und einen marker "1" (Sync Bit) besteht. Bis die Servo/Header Struktur nicht 100% klar ist, wird die MFM Clock bei Auftreten eines noch unbekannten MFM Signal für 0.250uS ausgeschaltet. Das 100%ige Verstehen der Servo/Header Struktur ist allerdings unbedingte Voraussetzung bei der Realisierung des noch nötigen MFM ENCODER. Dies ist ein offener Punkt und ich arbeite daran. Aus jetziger Sicht wäre es viel einfacher gewesen , einen ST506 basierenden Disk Simulator zu entwickeln.

Zurücknahme
Es funktioniert doch ! Die Problematik wie damals beschrieben ( mein letzter Eintrag im Anhang ) kann umgangen werden, siehe Kapitel 1.7.

Mein letzter Versuch mit der MAXII /ARM-7 Entwicklungsumgebung: ( Sommer 2010 )
MFM Decodierung mit Clock Signal Rück-Gewinnung ( clock-recovery )
============================================================
Hintergrund:
Ich bin zwar schon in der Lage, MFM daten zu decodieren aber diese Methode funktioniert nur wenn ein Clock Signal zu Verfügung steht. Der Nachteil dieser Methode ist, dass die Sector/Track Struktur und die Kontroll-Signale, wie CRC usw. quasi manuell nachgebildet werden müssen. Diese Methode konnte auch nicht angewendet werden, weil in der MAXII Architektur keine Memory vorhanden ist, um die nötigen FIFO's einzubauen.
>> Die Idee für meinen letzten Versuchs war einen, bzw. zwei ( HEAD-0 and HEAD-1 ) Tracks komplett in die Memory der ARM-7 MCU einzulesen. Ein Track besteht aus 40 Sectoren und ein Sector besteht aus 280 Bytes, = 11200 Bytes per Sector x 2 = 22400 Bytes. Die verfügbare Memory auf meinem eingesetzten ARM-7, LPC2148 Board ist 42H Byte RAM, also genügend groß um 2 komplette Tracks tu halten. Der nächste Schritt wäre dann, alle Tracks auf einer SD-Card zu speichern und somit eine quasi vor-formatierte RL02 Cartridge zu simulieren. Dies wäre eine ideale Ausgangsbedingung für eine einfachere Entwicklung weil man die doch recht umfangreichen Sector Strukturen nicht nachbilden muss.
ABER ..... bis jetzt war ich nicht in der Lage diese Idee umzusetzen. Mit meinem jetzigen Kenntnissen war der Hauptgrund weil die bisher auf MAXII basierende Entwicklungsumgebung keinen PLL support hatte. So wie ich die Problematik mit meinem jetzigen Kenntnisstand sehe, ist ein PLL unbedingt nötig, um ein Clock-Signal zu erzeugen und somit die MFM Daten zu synchronisieren. Kann auch sein , dass ich schon zu alt bin für die FPGA -Welt ? Bis jetzt hatte ich immer alles mit Schaltplänen entwickelt, überwiegend asynchron aufgebaut, was allerdings in der FPGA Welt nichts zu suchen hat. Also , ich lerne z.Zt. „The Verilog Hardware Description Language“ und werde versuchen damit das komplette Design zu realisieren.

Die Herausforderung war nun : CLOCK RECOVERY ohne PLL

Alle Details wie Schaltpläne , logic-analyser timing und eine genaue Beschreibung ist für Download hier verfügbar: manchester-try.zip

ERGEBNIS: Bis jetzt war ich nicht in der Lage, diese Herausforderung zu lösen-
Jede Hilfe oder/und Hinweis ist sehr willkommen.