DEC RL02 Simulator

As I have already mentioned briefly the challenge in this project is to achieve the vintage software and preserve it on new technology. However the Software is directly dependent on the condition of the disk drive, in my case a DEC RL02 disk drive. The RL02 drive uses removable disk packs to provide 10MB of storage; twice as much as its predecessor, the RL01. After the announcement ~1980 the RL02 turned out very fast to be DEC's all-round disk drive. Although other DEC disk drives like the DEC MSCP-protocol based disk drives ( e.g. RA80 ) would be easier to simulate I nevertheless decided in favor to simulate the RL02 disk drive. My decision was based on three reasons: First: The RL02 drive was available on most of all DEC systems like PDP-8, PDP-11 and VAX systems. Second: The RL02 drive was device-driver supported running on all DEC operating systems, like OS-8, RT-11, RSX-11, MUMBS, RSTS und VMS. Third: My personal challenge and a good chance to jump into the embedded systems world.

Aim of this project: Being able to use the RL02 Simulator on all DEC vintage computer platforms.

To be able to start such a project, we need an up and running environment including a RL02 disk drive and a DEC computer system with disk controller and attached RL02 drive. These RL02 disk drives are already very rare. Unfortunately, most RL02 disk drives don't work any more. Spare parts don't exist anyway. I had it left nothing else to build an operating disk drive from 2 to 3 faulty disk drives left. For me the most difficult part was to adjust the mechanical part via Oscilloscope based on the maintenance instruction following the alignment procedure . I am glad that I was successful and the most important prerequisite for this project was available now. Another problem still is related to the disk packs. A disk pack consists of 2 data surfaces and were pre-formatted by factory and can not be reformatted. After about 25 years, the format information on the surfaces has been already decreased in most cases which may result in Read-Error or in Too-Many-Bad-Blocks.

To be able to start the project at all, I needed the appropriate hardware. The Computer-Museum in München ( http://www.computermuseum-muenchen.de/ ) put these Hardware for me more friendly wisely at disposal. The hardware consists of a Micro-PDP-11 with 11/23+ CPU + RLV-12 Controller and a RL02 disk drive. Many thanks to DR. John G. Zabolitzky and Mr. Wolfgang Kainz-Huber.

Project start was Septembers 2009. Since I had a knowledge gap since 1995 of more than 15 years, I had to switch me over to the new technology bit by bit like C programming on ARM 7 CPU. This wasn't simply for me. A video from Fritz Weld shows a RL02 disk drive in action: RL02-in-action

The project started. Nostalgia is surely also my motivation reason for this project. The main reasons are the love of the vintage computers and also to realize the challenge, something worldwide there is not yet.

At least: Because I only can work exclusively in my spare time on this project , the major problem results in having not enough time to work on it continuously. Every notes/concerns are welcome !

The construction started in September 2009. First, a possibility had to be found to measure the differential RL02-bus signals and convert it to TTL level for further processing . For this purpose I designed a special, 40-pole ribbon cable for the connection between RLV-12 controller and the RL02 disk drive. Therefore I was able to watch the RL02 bus signals. The RL02 bus architecture is based on +5V/-5V differential signals, 6 signals each for the two directions. I didn't find any substitute for the necessary bus Receiver/Transmitter chips and had much trouble to get the original chips of the type 75113 and 7510. In the end after many searches I was successful anyway and the chips could be obtained via the dealer sh-Halbleiter in Germany. The board is designed in Wire-Wrap technology like in the following picture, based on the circuit diagram from the RLV-12-engineering-drawings . To get the required DC power, +5V/-5V, an additional DC/DC-Converter was installed. To be able to watch and check the transmitter read signals from the drive to the controller, I installed 3 additional 7510 receiver chips. The 40-Pin Connector of the RL02 bus is visible in the upper part of this picture.

A) In the summary the complete development hardware can be seen here. The QL200 PIC MCU Development board is above on the left visibly. It was the first attempt and it turned out very fast, though, that a PIC 16 bit MCU was completely insufficient for this project. Programming based on assembler language with the Integrated Development environment MPLAP of MICROCHIP wasn't a problem for me and it turned out very fast that the throughput and the frequency range didn't suffice with 8 bits. Bad investment for this project at this point in time, but it went on ...

... and here are all 3 actively connected components visible ( FEB 2010):

B) I was in the decision phase in October 2009, which MCU is suited best for this project. After investigating for a long time I have decided in favor of the LPC-P2148 Development board of OLIMEX. This board works with a 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. This board was ideally suitable for the getting in and very well for the developmental stage. This board isn't the final version, though and will then replaced by another like such as LPC-H2294 . This will become necessary because a SD card only can handle a restricted number of write cycles. The final version will hold the RL02 data in RAM and the SD-Card will be used just for the load and store operations. In the following picture my LPC-P2148 board can be seen with additional 16 LED's to be able to watch the 16 bit based data transfer visually.

C) It went on rather toughly now. The setup of the software development environment had to be implemented (see 1.4) and the hardware of the RL02 Simulator had to be developed step by step. The base for this project is to be able to read the RL02 drive command register. In the first step I therefore developed a circuit diagram to read the command register of the RL02 disk drive. Since I was still an engineer of the old style I built the design based on TTL-Chips and Wire-Wrap technology. It wasn't simple for me but I managed to complete this board and I was able now to read the RL02 Drive-Command-Register. The circuit diagram to this is open here: Drive-Command-Register

D) The greatest breakthrough at this project was: FPGA ( Field Programmable Gate Array ). Myself, also already an “OLDIE“ refused this new technology to employ me very long and I am annoyed afterward because I hadn't made this step earlier. I had arrived in the embedded systems world and it was going on speedily now. I decided in favor of the MAXII-FPGA of ALTERA. To make the start in the FPGA-world as simple as possible I bought the Development board , MAXII-Micro-Kit-Board , at Digi-Key, manufactured by Terasic-Technologies-Inc . This board is ready for use, includes the MAXII FPGA and also a USB Blaster for downloading the compiled circuit diagrams. With the enclosed Quartus II web edition software of ALTERA, I was able to develop a circuit diagram into a fraction of time. The Micro-Kit-Board has been built up pin-compatible to the above TTL-design like in the following picture obvious.

My Environment:
For programming the development environment from chapter 1.3. I use a laptop computer with serial interface running Windows XP on it. The serial interface (COM1) is connected to RS232-0 of the LPC-P2148 Development Board and is used to download the HEX images. An additional 4-port USB HUB is also necessary One port is connected via USB/serial converter to the console of the Micro-PDP-11. Another port is connected via USB/serial converter to RS232-1 of the LPC-P2148 Development Board. The remaining 2 USB ports are connected to the MAXII-Micro-Kit-Board and the QL200 PIC MCU Development board. Since my laptop computer has come already in the years ( but serial interface is available ) , I use my Quad-Core PC to run the Quartus II 9.1 web edition software to reduce the compile time. My laptop is connected via network-drive to my Quad-Core PC and is used only for flashing the FPGA in this case.

Software:

My complete software environment for programming the ARM-7 MCU is “Free software“ based, on the GNU compiler Collection (GCC) area. After some tests I installed my laptop computer successfully with the following software in the correct order. Installing first the Dev-C++ Integrated Development environment (IDE). As next one needs the Cygwin environment installed to be able to work with Unix Commandos under Windows. We still need the arm-none-eabi-gcc C-compiler now to program the ARM-7 MCU. Unfortunately, no make-utility is in the Cygwin package included . I use the mingw32 utility, which runs without any problems.. The Flash-Tool from Philips should be version 2.2.3 to support for LPC-P2148 board (Flash-Utility-Doku ).

The Quartus II 9.1 Web Edition Software from ALTERA is necessary to program the MAXII-Micro-Kit-Board . The new version 9.1 has to be obtained without problems of the ALTERA online update service. This version runs without any problems on my Windows-Vista 64Bit system.

Block diagram:

Design of the entire development environment, based on ARM 7 MCU and MAXII FPGA.

September 2010: New DE1 Board based on Cyclone® II FPGA. ARM 7 is replaced by NIOS MCU.

Usage of the SD card
A SD card is a flash memory device with 512 Bytes/block. Also, each 512 block of data on a SD card can be written a limited number of times ( depending on the SD card used, this number varies between 1000 and 2000 times ). Running an old operating system ( RSX11-M ) from the SD card via my Simulator would destroy every SD card after some hours because this old operating systems are very I/O intensive.

Servo/Header structure of the RL02 Cartridge makes problems.
The RL02 cartridges were factory formated and the Servo/Header format was strictly company confidential to force purchasing the expensive, original DEC cartridges only. In the Servo/Header section of the RL02 disk cartridge format appears sometimes a 0.125uS or 0.625uS MFM signal ( 0.250uS, 0.325uS, 0.500uS is normal ) which will confuse my MFM decoders, described in chapter B) and C) Original, the Servo/Header decoding was realized with a ROM on the RLV-11 controller. To eliminate this undocumented feature in the design chapter C) , the Servo/header part will be skipped and a re-sync with byte alignment in the Data preample (PR2) phase which contains 47 "0" following by a marker "1" (Sync Bit) is my way to bypass it at this point in time. Unless the structure of the Servo/Header information ist not 100% clear, the MFM clock will be disabled for 250uS. Understanding the Servo/Header structure will become very important by designing the MFM Encoder and is an ongoing issue for me. From the present view it would have been much simpler to develop a disk simulator based on the ST506 interface .

Retraction
It works anyway! The difficulties as described at that time ( my last post, see appendix ) can be solved elsewhere, see chapter 1.7.

My last attempt based on the MAXII and ARM-7 environment: (summertime 2010 )
Trying to decode RL02-MFM data with clock-recovery
=========================================
Background:
I am already able to decode and encode MFM data but my current used method only works, because the strobe-clock signal is available. The disadvantage of this methode: I have to rebuilt manually all the timing-track/header infos including CRC during the MFM-encoding cycle. This method also could not be implemented in the MAXII environment because no memory is available building the necessary FIFO's.
The idea was to read one or two ( HEAD-0 and HEAD-1 ) complete tracks into the memory of the ARM-7 MCU. One track contains 40 sectors and one sector cointains 280 Bytes, = 11200 Bytes per track x 2 = 22400 Byte ( HEAD-0 and HEAD-1. The available Memory on my used ARM-7, LPC2148 is 42K Bytes RAM and this would be enough to hold 2 tracks in the ARM-7 memory. Next step would be to save all tracks on a SD-Card which results in a RL02-like formated SD-Card. This would be an ideal starting point for a much simpler implementation because we have not to take care about Header+CRC sector structures.
But......I was not able to realize this idea until now. The main cause was because no PLL support is provided for the MAXII FPGA but with my present state of knowledge a PLL is definitely necessary to generate a clock signal for synchronizing the MFM data. Also possible that I am already too old for the new FPGA-world ? Until now I was using circuit diagrams which is not effective and I just started to learn the Verilog Hardware Description Language.

The challenge was: CLOCK RECOVERY without PLL

All details with circuit diagrams , logic-analyser timings and a detailed description is available for download here : manchester-try.zip

RESULT : I was not able to solve this challenge with the current used environment.
Any input/hints to this issue always welcome !