[Simh] [simh at alderson.users.panix.com: Re: Announcement: back10]

Rich Alderson simh at alderson.users.panix.com
Sun Feb 19 20:55:35 EST 2017


Johnny Eriksson responded to me privately, and I answered him the same way.
Since there has been further discussion since then, I'm going to make this
public.

Since that conversation, I've thought of another objection:  No one using
a Tops-10 or TOPS-20 backup tool will be able to read tape images in the
ANSI ASCII format, since both BACKUP and DUMPER force, repeat *force*, the
drive into coredump format, for both input and output.  Rather than rewriting
all the tools created to deal with tapes, why don't we simply use the right
format to begin with?

                                                                Rich

------- Start of forwarded message -------
Date: Thu, 16 Feb 2017 15:55:55 -0500
From: Rich Alderson <simh at alderson.users.panix.com>
Subject: Re: [Simh] Announcement: back10

> Date: Thu, 16 Feb 2017 11:34:45 WET
> From: Johnny Eriksson <bygg at cafax.se>

>> Personally, I'd vote for coredump format, as it's the common denominator
>> among Tops-10 and its derivatives (SAIL's WAITS, Tymshare's TYMCOM-X, the
>> CIS monitor) and TOPS-20, with utilities to convert into the others if
>> necessary (which it rarely is).

> Are you suggesting that the backup utilities extract files in this format,
> i.e. four octets + the remaining four bits into octet five?  Instead of
> what I use now, which is five seven-bit values into five octets, plus the
> remaining bit into the high order bit of octet five?

> The latter as a default extract format has a number of features, like the
> fact that text is automatically readable, and all bits are preserved.

Actually, they are not.  Quoting from the TOPS-20 v7 Monitor Calls Reference
Manual (p2-41) and the Tops-10 v7.04 Monitor Calls Manual vol. 1 (p14-9):

    (T20)
    ANSI ASCII Mode

    This mode stores a word of data as five 7-bit bytes in five frames of
    a 9-track tape.  On a read  operation, five frames of 7-bit bytes are
    read, left-justified, into  a word.  The remaining bits  (bits 35) of
    each frame are  ORed together, and the result is placed  in bit 35 of
    the word.   On a write operation,  the leftmost 5 7-bit  bytes of the
    word are  written into five frames on  the tape.  Bit 35  of the word
    must be  zero to conform to  ANSI standards.  It is  written into the
    high-order bit of the fifth  frame, and the remaining high-order bits
    of  the  first  four  frames   are  0.   This  mode  is  useful  when
    transferring  ASCII data  from TOPS-20  to machines  that  read 8-bit
    bytes.  This  mode is available on  any 9-track drive  connected to a
    TM02 or DX20 tape controller.

    (T10)
    Code 4 (.TFM7B)  set 7-bit mode, called ANSI  ASCII (not available on
    TM10s and  TC10-Cs).  This mode stores  one 7-bit ASCII  byte in each
    frame of the  tape.  This mode is useful  for transferring ASCII data
    from DECsystem-10s  to 8-bit byte-oriented machines,  such as PDP-11s
    and System  360/370s.  Five left-justified (in core)  7-bit bytes are
    stored in five  frames on the magnetic tape.  Bit 35  must be zero to
    conform to ANSI standards.  Bit 35 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.

Note that both manuals specify that bit 35 should be zero.  The fact that this
mode accidentally works for 36-bit binaries on certain controllers does not
justify making it the standard default.  There are controllers (the TA78, for
example) which do not agree with the TM02/TM03 in things like this.

> If there is a compelling reason I can add an option to extract into core-
> dump format, but I plan to keep the default.

I would think accuracy of representation would be the most compelling argument
available, and would militate against ANSI ASCII mode as your default.

[ portion unrelated to this discussion snipped ]

------- End of forwarded message -------


More information about the Simh mailing list