MT Tape Simulator - KS10FPGA/KS10FPGA Wiki

TM03/TU77 (MT) Tape Simulator

The TM03/TU77 is a Massbus tape drive system, consisting of a TM03 Tape Controller/Formatter and one or more TU77 Tape Transports. A real TM03/TU77 system reads and writes tape data in the industry standard 1600 BPI Phase Encoded (PE) or 800 BPI Non-Return-to-Zero Inverted (NRZI) mode. None of the tape controllers or transports supported by the KS10 supported 6250 BPI Group Code Recording (GCR) density.

In this implementation, the tape system is similar to a client/server system where the FPGA-based tape controller (client) requests access to tape data (read and write) via a register interface. The Console Processor (server) reads and writes standard SIMH ".tap" files, translates the data between a stream of bytes on the tape and 36-bit PDP-10 words (with some metadata on the side), and makes the data available to the FPGA-based tape controller. In this case, metadata refers to tape objects like beginning-of-tape (BOT), end-of-tape (EOT), Tape Marks (TMs).

The SIMH ".tap" format doesn't really create a distinction between PE or NRZI tape formats. The tape controller implementation extends this abstraction in a way such that tapes are always appear to be read and written in the proper format.

Once the files are stored using the Console Processor's Linux filesystem, the ".tap" files can be stored anywhere on my network.

This SIMH Tape Format is documented at http://simh.trailing-edge.com/docs/simh_magtape.pdf. The translation between bytes on the tape and 36-bit (or 32-bit) PDP-10 data is documented in the TM03 Magnetic Tape Formatter Users Guide (EK-0TM03-UG-003).

Although the DSTUA and DSTUB magtape diagnostics support the TM02 Tape Controller/Formatter and other tape transports besides the TU77, only the TM03 and the TU77 are supported currently.

I should probably mention that I have a pair of Kennedy 9400s that have the same "Pertec" interface as the TU77 - if I wanted the full experience watching of spinning tapes. Mercifully I don't have enough FPGA pins available on the DE-10 Nano to implement the Pertec interface without some kind of an IO expander because a Pertec interface requires a LOT of pins - standard Pertec interface has two 50-pin connectors. It might be more interesting to think about designing a generic USB-to-Pertec adapter and just plugging that into KS10 FPGA system. It also could be used for other things.

At 170 pounds each, this is not near the top of my list of things to think about.

Device Registers Summary

Each of the individual tape drives maintains some of its own state. In this context, that device state includes everything that would normally be associated with the physical tape drive. That device state includes the following registers:

Register Set

MT Control and Status #1 Register (MTCS1)

Some of the bits in the MTCS1 Register are implemented in the RH11 Controller and some bits are implemented in the MT Device.

MT Frame Count Register (MTFC)

The Frame Count Register counts tape events.

When writing to tapes, the Frame Count register is loaded with the two's complement of the number of frames to be written. When the Frame Count register overflows to zero, the write operation terminates.

When reading or performing a write-check operation, the Frame Count need not be specified and is automatically reset to zero for those operation. When the read or write-check operation is complete, the Frame Count register contains the number of frames read from tape.

This register is located on the M8909 Board and is on Sheet MBI 8 of the schematic.

MT Drive Status Register (MTDS)

This register reports the status of the tape drive.

This register is located on the M8933 Board and is on the schematic Sheet TCCM7.

MT Error Register (MTER)

This register contains the error status of the addressed drive.

This register is located on the M8909 Board and is on the schematic Sheet MBI 10 and Sheet MBI 11.

MT Attention Summary Register (MTAS)

The Attention Summary Pseudo Register allows the program to examine or modify the status of all tape drives in a single operation.

MT Character Check Register (MTCC)

The check character register is a nine-bit, read-only register that permits the programmer to check the validity of a data transfer.

In NRZI mode, this register contains the CRCC for the operation.

In PE mode, at the end of a PE read operation, this register contains a "dead track" indication.

This register is located on the M8905 Board and is on the schematic Sheet MR4.

MT Maintenance Register (MTMR)

The maintenance register is implemented as much as is required to pass diagnostic tests.

This register is located on the M8905 Board and is on the schematic Sheet MR5.

MT Drive Type Register (MTDT)

This register indicates the type of tape drive that is connected to the controller.

This register is located on the M8933 Board and is on the schematic Sheet TCCM7.

The information in the table below was extracted from the DSTUA diagnostic.

MT Serial Number Register (MTSN)

The MTSN register reports the Serial Number of the tape drive. The Serial Number is hardwired to the tape drive number. The values implemented in the FPGA are the same values that SIMH uses.

This register is located on the M8908 Board (single sheet).

MT Tape Control Register (MTTC)

This register is located on the M8905 Board and is on the schematic Sheet MR6.

Functions

The TM02/TM03/TU77 can execute the following commands:

MT Data Interface Register (MTDIR)

The MTDIR is a KS10 FPGA register that allows the MT hardware to interact with the console processor.

In the KS10 FPGA, the MT implementation is almost a client/server arrangement where the console processor performs all of the tape formatting and performs all of the file IO. The tape controller is implemented in the FPGA and makes file read/write requests of the console processor. The tape controller is the master. The console processor is slave.

Tape formatting includes all of the conversion between bytes-in-a-file and 36-bit words.

A general design rule, the bits in the MTDIR are either read-only or write-only. Some bits are listed as read/write but are really still exclusively read-only or write-only depending on the function being performed (or mode). This design eliminates the need for read/modify/write cycles and all the coherency issues that creates.

Timing Parameters

The following timing parameters are extracted from the DSTUA diagnostic and apply to the TM03 attached to a TU77 only. Where possible, the design behind the timing parameters is documented.

Console Processor Software

The console processor performs tape file IO operations for the FPGA-based Tape Controller in a manner that is compatible with the SIMH ".tap" file format.

Beginning of Tape (BOT)

The tape is defined to be at BOT when the file pointer is at the beginning of file; or more technically the value returned by ftell() is zero.

End of Tape (EOT)

The magtape has two notions of EOT: the logical EOT and the physical EOT.

The logical EOT is a sequence two tape marks and is purely a PDP-10 operating system abstraction. As such, the logical EOT is not relevant to this FPGA hardware design.

The physical EOT on a classic magtape drive is a length reflecting tape near the end of the tape that is sensed by the tape transport drive. In this system where the magtape is simulated using a file, the physical EOT is indicated on read forward operations at the end-of-file (EOF). When writes are performed, the end-of-file (and therefore physical EOT) can change without indication except when the file size becomes greater than 46,080,000 bytes (for tapes formatted at 1600 BPI) or 23,040,000 bytes (for tapes formatted at 800 BPI). When this file size is exceeded, the physical EOT is indicated on both read and writes.

Note: The file sizes above assume 2400 foot tapes, 12 inches per foot, and densities of either 1600 bytes per inch or 800 bytes per inch.

Write operations include Erase, Write Tape Mark, and Write Forward. Read forward operations include Space Forward, Write Check Forward, and Read Forward.

When the ".tap" file is opened, the file is validated for correctness. This ensures that there is a logical EOT before the physical EOT - and therefore EOT is known.

Tape Formatting

The console processor performs all of the formatting normally associated with the Bit Fiddler section of the TM03 formatter. The following PDP-10 tape formats are supported by the TM02 and TM03.

For now (and maybe forever...), only the TM03 functionality is implmented in the KS10 FPGA.

PDP-10 Core Dump Format

On a 9-track tape transport, the PDP-10 core dump format stores one 36-bit word of data in five 8-bit frames (8 bit of data plus one bit of parity).

On writes, the 4 low-order bits of the last frame are set to zero. On reads, the 4 low-order bits of the last frame are ignored.

PDP-10 Seven Track Format

On a 7-track tape transport, the PDP-10 core dump format stores one 36-bit word of data in six frames where each frame stores a 6 bits of data (plus one bit of parity). This format only supported when the tape control unit is attached to a 7-track tape transport.

This format is only supported by the TM02 tape control unit. The KS10 FPGA only implements 9 track tape transports and only implements the TM03 tape control unit and therefore this format is not implemented.

PDP-10 ASCII Format

This format was used for ANSI compliant ASCII interchange between the PDP-10 and 8-bit byte-oriented machines.

This format stores one 7-bit ASCII "byte" in each frame of the tape.

Bit 35 must be zero to conform to ANSI standards. Bit 35 (in a non-standard compliant use) is written into the high-order bit of the last frame of each word. The other high-order bits are set to zero on write operations. When the tape is read, all five high-order bits are ORed, and the result is stored in bit 35.

This format is only supported by the TM02 tape control unit. The KS10 FPGA only implements the TM03 and therefore this format is not implemented.

PDP-10 Compatible Format

This format is also sometimes called "compatibility", "compat", "normal", or "eight-bit" format depending on the reference.

This format is compatible with any machine that reads and writes 8-bit bytes and I beleve generally replaced the PDP-10 ASCII mode format described above. The format transfers 32-bit words.

When a read operation is performed, four 8-bit frames are read into each 36-bit word (left justified) with the remaining four low-order bits of the word set to zero. When a write operation is performed, the 32 high-order bits of the 36-bit word are written into four 8-bit frames (plus parity). The four low-order bits are ignored.

RH11/TM03/TU45 Status

Diagnostic Transcripts

This section summarizes the results of executing the relevant diagnostic programs.

DSTUA Basic Device Diagnostic Results

DSTUB Reliability Diagnostic Results

RH11/TM03/TU45 (MT) Status Summary

The MT system is a work in progress.

The diagnostic status is summarized below: