PDP11GUI Disk Image window

The Disk Image windows lets you read and write data from different disk drive from/to file. Data is transfered over the serial console line. No operating system or any working device is needed. All non-fake PDP-11 types you can connect to are supported, this includes SimH with simulated disk drives.

At the moment these disks are supported: RL01/02, RK05, RK06/07, MSCP RD*, RM* on RH11, RX01/02.

For tapes there's only the PC05 paper tape reader/puncher.

How to use it: Base operation

1. Open a drive

“Opening a drive” means making contact to the disk drive and getting its size and geometry. This includeds a download of the disk driver into the PDP-11.

1. If removable media: insert disc pack, get the drive ready.
2. Select the controller type. The combobox lists all available PDP11GUI controller drivers.
3. Select the unit number. This number identifies one of multiple drives connected to the controller. The unit number is normally visible on the drive, often as a changeable plug.
4. Select the drive type, or press “Open disc” to determine the drive type automatically (if MSCP controller)
5. Press “Open disc”. Driver is loaded, and geometry information about disk drive is shown
   You can see how PDP11GUI uses the MACRO-11 Source window, the MACRO -11 Listing window and the Terminal window to translate and load the driver.

After opening, you can read or write. If you have changed the UnitNr, you must re-select the disk type, and must re-open the disk again.

2a. Reading an image from disk to buffer

1. Be sure the file image buffer is cleared. You can read data into an already filled image buffer, but this will make sense only under certain conditions.
2. Set “current blocknr” to 0
3. Press the “Read all from blocknr to end” button. PDP11GUI will read data in chunks of one track size. This may last several hours! You may press “Stop”, which will irritated PDP11GUI a bit ... ignore any strangeness.
4. If everything is OK, save the image buffer to disk

You can also load a partly filled image file, read more data into it from the disk, and save it again. So big disks can be read in several sessions.

You may also read single blocks from disk. Or you can perform a disk scan by pressing “Check all” or “Check single block”. A disk scan is like a “read”, but no data is transferred. So its a fast way to check the disk media’s health.

2b. Writing an image from buffer to disk

1. Load an image file into the buffer. It must have a size less than the disks size.
2. Set “current blocknr” to 0
3. Press the “Write all” button. Operation is similar to “Read all”

3a. Communication selftest

You can test wether PDP11GUI can communicate with the driver over the serial console port . Just press the “Test” button.

A block of data is transmitted to the current driver, is inverted at the PDP-11 and send back to PDP11GUI. This tests also checksums und RLE compression, depending on the test pattern you selected.

3b. Function selftest

To verify the overall operation, start SimH with a simulated disk drive and an attached image file. Example: to work with an RL02 drive loaded with XXDP diagnostics, you would enter in SimH:

set rl0 rl02
att rl0 xxdp25.rl02

Then you connect PDP11GUI to that SimH instance over telnet, and read data from the simulated RL02 into an image file. If you save the image file, it should be an identical copy of the mounted disk image ... here “xxdp25.rl02”.

You can reverse that test and write a disk image to simulated disk under SimH.

But this test works only for single blocks at the moment ... see “telnet bug”.

Image file format

Every DEC disk or tape is logically represented as a linear list of “blocks”. The block size differs between 128 byte and 1024 bytes. Reading and writing is based on block numbers.

The file format is that of SimH: a file image is just a stream of blocks.

How it works: the disk driver

For every controller type PDP11GUI uses a different Disk Driver. A disk driver is a MACRO-11 program with fixed entry points. This program is first loaded onto the target PDP-11 machine. Assembling and loading is done exactly the same way as user programs were loaded.

Every driver supports these three functions:

1. read a block of data from a certain disk address.
2. write a block of data
3. perform communication selftest.

The base operation for one driver call is

1. PDP11GUI commands the console to start execution at the driver’s entry point
2. The driver polls for a block of data, PDP11GUI sends those data over the serial line.
   Data contains a count, values for CPU registers R0..R5, and the actual data buffer.
   One data buffer may be up to 32 kBytes in size. In case of “Read” the data buffer is empty.
3. After end of transmission, the driver gets controlerl and disk addresses from t he R0 ... R5 values and starts operation. In case of an error R0 ... R5 are filled with error information.
4. The driver transmits back a block of data, format is the same as in step 2. In case of “Write” no data buffer is transmitted back.
5. PDP11GUI decodes register values and data buffer.

Concepts

Disk, Image buffer, Driver

The Disk Image window is driven by a complex state machine. User buttons are enabled or disabled depending on the states. State information is also displayed in three information lines:

1. Disk: information about access to physical disk
2. File: information about the PC image file and the image buffer
3. Driver: information about PDP11GUI’s driver activity.

User controls must be operated in a up-to-down fashion: You work your way from the window’s top to the bottom. User guidance is through enabled/disabled window controls.

Data is read or written from an internal image buffer. This image buffer can be celared, laoded from a memory file or written to a file.

Error handling

While reading or writing, all errors are logged in the “bad block” window. If  “Stop on error” is checked, the current operation (read, write, check) aborts, the current error is displayed.
Errors consist of four 16-bit error register values ans an “error location”. To interpret the errors, examine the current driver source, begin by searching for the “error location” (I know, you will hate me for this! :-)

In case of an disk error, PDP11GUI will first repeat the current multi-block transfer, but on a block-by-block base. This is needed to get the exact block position. For every error, the read/write is repeated 16 times. Even if the error can be cleared by multiple triies, an entry into the bad block table is made.

Bad block list

Together with each imnage file PDP11GUIs managesd a “bad block list” for that image, it is aved in the “bad block file”.Every error while reading or writing is saved in the “bad block” table. Bad blocks are never deleted, but new bad blocks are always added to the bad block list. You can easily edit a or delete a bad block list file manually.

So bad spots an every media gets registered and never forgotten.

If the image buffer is written to disk as , the current bad block table is saved as “.bad”. If an image file is laoded and there is a file “.bad”, it is also loaded from disk. So bad block information is kept very tight with the disk images.

DECs bad sector format

DEC has a standard format for recording bad sector information on a disk. See “DEC standard 144”, or the “bad144 (8)” utility on BSD. To transfer information from PDP11GUIs bad block lists, you must enter the bad blocks manually into DEC’s bad sector tools (typical a XXDP diagnostic for that disk).

Caution: Since bad sector information is part of the disk image, you can usually not transfer full images between one disk and another.

Other methods of accessing a PDP-11 disk devices

Exchanging disk images is the preferred way to transfer data between a PC and a PDP-11. Everybody who deals with the “PDP-11 and modern PC” matter has developed procedures to bridge the gap between the ‘11 and the modern world. Some other methods include:

• VTserver, a virtual tape drive (see below)
• Operating systems which can run a Kermit version (serial data transmission tool).
• Operating systems, which can transfer data over network adapters (fastest, but limited to modern PDP-11 and a working Ethernet adapter is needed).
• Data transfer by physical disk. SCSI disks can be accessed by PDP-11 controllers and modern PCs. So on the PDP-11, dump a disk image to a SCSI drive, attach the SCSI drive to PC and dump data back. UNIBUS SCSI controllers are very expensive (hundreds of $). SCSI controllers emulate later DEC controllers (MSCP, SMD), so the PDP-11 operating system must support this DEC drive type.
• Small amount of text data can be exchanged with a modern terminal emulator.
  Those terminal emulator can send text from a PC disk file by “typing” it into the PDP-11, where an text editor must receive and save the “typed” data.
  Data can be send from PDP-11 to PC by “listing” them under the DEC operating system to the terminal. Then it can be fetched from the terminal emulator’s display window with normal Copy&Paste.
  This works for all machines and all operating systems, not just necessarily PDP-11.

VTServer

VTserver is a sophisticated approach exchanging data between a PDP-11 and PC. VTserver emulates a virtual tape drive. The content of the tape media is mapped to a set of disk files on the host PC. For PDP-11 a boot loader is given, so the PDP-11 can load the first file from the “tape” and execute it. Typically this is a universal stand-alone copy program, which can transfer data between certain DEC disks and the virtual  tape itself, so disk images can be read or written to virtual tape. And since virtual tape is mapped to PC disk files, the images are transferred to the host PC.

VTserver’s strengths are:

• support for almost all disk drives (it uses the BSD UNIX driver libraries).
• PC disk files are accessible from Unixes with driver for VTserver.
• Great concept, widely used. First choice!

I tried indeed to access my disk drives with VTserver first. For me it did not work right, so I’ve written a disk interface for PDP11GUI. Weaknesses were:

• For transmission, VTserver apparently uses all 8-bit character codes (0 to 255). This fails, if only a 7-bit connection exists, or some protocol characters have special meaning in the transmission path
  This is the case for the 11/44 console: Character “Control-P” is used to break into the console processor, so VTserver’s transmission will fail.
  The same is true for SimH: there “Control-E” is the escape character. (But there are reports VTserver works on SimH).
• In my test runs I found bugs in VTserver, which caused transmission to abort after 10 megabytes or so.
• VTserver is made for fully functioning equipment. It gives no extended diagnostics for disk failures or bad sectors. (It uses the functionality of UNIX disk drivers).
  As a restorator I needed a tool that could handle drive malfunctions.

PDP11GUI’s strengths are:

• It is an open diagnostic tool. Disk drivers are written in MACRO-11 and can be changed to perform additional diagnostics and return detailed error information.
• It uses no control characters, but only 64 printable chars for transmission (similar encoding as Base64). So it can be used over every transmission line.
• It has build in RLE compression, so empty disk blocks can be copied very fast. Though Base64 encoding makes transmission slower, overall transmission speed is typical better than VTserver.
• Serial transmission is checksum protected.
• Transfer of an disk image can be broken up into several sessions, so it’s very fault tolerant.
• Errors can be understood by checking out error locations in driver source.
• The system of driver downloading and executing is not limited to PDP-11, later PDP-8 versions maybe possible.

The Telnet bug

In my test I found the telnet connection to crash after long transmission. This is a bug in the telnet components I linked into PDP11GUI. The read/write of whole disk images seems only possible over serial connection at the moment. Read/write of single blocks, or smaller parts of disk still are possible.