[Simh] DECtape emulation

Rich Alderson simh at alderson.users.panix.com
Fri Feb 10 15:55:51 EST 2006


Currently, DECtape is emulated on the 18-, 16-, and 12-bit systems from DEC by
representing standard-blocked tapes as streams of 16-bit words (for 12- or 16-
bit systems) or 32-bit words (for 18-bit systems).  This works fine for those
standard images available to date on the net, but I have recently encountered
non-standard DECtapes which could not be represented this way.

I would like to suggest that DECtapes be emulated as streams of 8-bit bytes
representing the 10-bit frames on the tapes themselves.  The two edge tracks
are timing marks, and are emulated simply by the byte-timed file structure;
the rest of the frame is made up of redundant pairs of bits consisting of one
mark track and three data tracks.  The simplest model would simply be 4 bits
per byte xxxx123M; more elaborate (and most closely matching the actual medium)
would be dual entry M123123M; and greatest hack value would take into account
the fact that DECtape can be read and written in either direction, and would
represent one nibble as the complement obverse[1] of the other.

DECtape uses 6-bit mark codes, encoded longitudinally on the tape.  (Given the
small capacity of DECtapes, this level of overhead seems acceptable to me.)  A
tape was generally formatted so that there was roughly 10ft (300cm) of leader
and trailer, a brief turn-around zone at each end between data blocks and the
leader/trailer area, and formatted blocks.[2]  On the PDP-1 and PDP-4, there
are 4 overhead words at each end of a block; on the other DECtape systems,
there is an additional word at each end.  The mark codes on a block are

     25 26 32 10 10 10 10 70 70 70 70 ... 70 70 70 70 73 73 73 73 45 51 25

where the 25s are not used by the PDP-1 and PDP-4.  The data portion is marked
by two 10s to start, two 73s to end, and 70s between as needed.  26 marks the
block number, 51 its complement obverse; the other six words are used in
different ways by different systems.

A minor benefit of such an emulation would be to allow the PDP-11 emulator to
handle "non-standard" tapes correctly, with the 17th and 18th bits presented in
the status register of the DECtape controller.  See the TC11 writeup in the
1976 Peripherals Handbook, available at bitsavers.org.

Another result of using this representation of DECtape is that LINCtape could
also be emulated, with its 4-bit mark codes and opposite-polarity recording,
if anyone were interested.

Does this kind of emulation appeal to anyone else?

                                                                Rich Alderson


[1] "Complement obverse" is the phrase DEC used to describe the bit-level
    result of writing bits in one direction and then reading them in the
    opposite direction, that 1's and 0's invert.  Expressed as octal digits:

		   0 <-> 7    1 <-> 6    2 <-> 5    3 <-> 4

    This fact was used in the design of the mark codes recorded in the mark
    track, some of which are their own complement obverses.

[2] The PDP-10 formatting algorithm suggests 7000 leader codes (42000 frames),
    200 turn-around codes at each end, and trailer codes till the tape comes
    off the reel; we can probably be satisfied with one leader (55), one
    turn-around (25), data blocks as necessary, one turn-around (25), and one
    trailer (22).



More information about the Simh mailing list