<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">
      <blockquote type="cite">The DECtape format as such, with all the
        headers and so on, is the same on all tapes. A normal PDP-8
        formatted tape will have 129 (12-bit) words, however, while a
        PDP-10 (or any other 18-bitter) would have 128 18-bit words (if
        I remember right).
      </blockquote>
      Pretty much right.  129 may be slightly misleading.  The format is
      129, but the -8 used  only 128 of the 129 12-bit words/block for
      data.  <br>
      <br>
      The PDP-10 is 36-bit, not 18-bit.  A PDP-10 (actually, non-PDP-8)
      formatted DECtape would have 578 blocks of 128 36-bit words.  (256
      18-bit words at the hardware level.)   <br>
      <br>
      Blocks 0, 1, 2 are for DTBoot (hardware read-in bootstrap), and
      didn't contain user data.  <br>
      <br>
      Block 100 is the directory block.  Thus 574 blocks for user data. 
      The directory holds up to 22 files, plus a map of which file owns
      each block.  <br>
      <br>
      The user data blocks have a one word header (LH = next block of
      file; RH = first block & words used in this block) + 127 words
      of payload.  This differed from disk files, where all 128 words
      were payload, so inattentive programmers could make a number of
      mistakes.  (E.g. random access block isn't word/128; you had to
      pay attention to the buffer's word count, etc.)<br>
      <br>
      Data blocks of a file are (usually) not contiguous; this allowed
      the drive to stop and restart while reading or writing without
      having to reverse direction.  The spacing depended on what blocks
      were free when files were written, and the data mode.  (Files
      written in 'core dump' modes were assumed to be read by the
      monitor without stopping, so the gap was smaller, allowing larger
      programs to be read without reversing direction.)  <br>
      <br>
      The gory details of the format are in the Monitor Calls manual
      (TOPS-10).<br>
      <br>
      The PDP-11 used 18-bit format, but ignored the high 2 bits of each
      word (except when reading PDP-10 tapes; the hardware for that was
      tricky as the high bits had to be read with programmed IO; the low
      16 were DMAed on the TC-11.)<br>
      <br>
      The low-level formatting that established the mark track, end
      zones and block delimiters was done via a stand-alone diagnostic. 
      This differs between the two formats.  The directory block could
      be initialized under timesharing.   <br>
      <br>
      Directory structure given is for the PDP-10; other OSs used
      different formats.<br>
      <br>
      From an emulation point of view, the PDP-10's controller was the
      most interesting; the driver does dead reckoning; that is, it will
      start a drive spinning for a seek, disconnect, service other
      drives, and reconnect just before the desired block is expected to
      be over the read head.  So real-world timing matters.  The other
      controllers (and thus OSs) didn't support this.<br>
      <br>
      Oh, all numbers above are radix 10.<br>
      <br>
      The link for OS8 that I posted yesterday was via filewatcher; the
      direct link is<a
href="ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/">
ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/os8/</a>
      Sorry if this was confusing.<br>
      <br>
      Of potential interest to low-level folks is
<a class="moz-txt-link-freetext" href="http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293">http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN/3387293</a><br>
      <br>
      Hope this is useful.<br>
      <br>
      <pre class="moz-signature" cols="72">This communication may not represent my employer's views,
if any, on the matters discussed. 
</pre>
      On 18-Mar-13 16:26, Johnny Billquist wrote:<br>
    </div>
    <blockquote cite="mid:5147788C.2090901@softjar.se" type="cite">On
      2013-03-18 17:44, Bob Supnik wrote:
      <br>
      <blockquote type="cite">I was trying to get a debug setup for
        PIP10, per Ian King's mail, when I
        <br>
        discovered that none of my OS/8 images have PIP10 on them. This
        <br>
        certainly explains why the feature has never been tested before.
        I
        <br>
        suspect that ReadAll and WriteAll either are not working at all,
        or are
        <br>
        not working when the DECtape format is 18b. Another possibility
        is that
        <br>
        PDP-10 DECtape format is not the same as 18b format, at the
        nitty-gritty
        <br>
        level (format of headers and trailers).
        <br>
      </blockquote>
      <br>
      The DECtape format as such, with all the headers and so on, is the
      same on all tapes. A normal PDP-8 formatted tape will have 129
      (12-bit) words, however, while a PDP-10 (or any other 18-bitter)
      would have 128 18-bit words (if I remember right).
      <br>
      The PDP-8, when doing 12-bit formatted tapes, just packs data in a
      way that is rather different from an 18-bit machine. But at the
      tape as such, there is nothing odd about it.
      <br>
      <br>
      But I can see lots of potential for errors when emulating this
      whole thing.
      <br>
      <br>
      I couldn't give exact details on lots of bits without looking in
      manuals, but in essence a DECtape is always doing 18-bit words.
      That is done by doing 6 groups of 3 bits each.
      <br>
      A PDP-8 will pack three 12-bit words into two 18-bit words. This
      means that a DECtape block for a PDP-8 will only have 86 18-bit
      words.
      <br>
      So the blocks are shorter, but you have more of them, when the
      tape is formatted for a PDP-8.
      <br>
      <br>
      I hope (assume) that you already know all of this. If not, let me
      know, and I can try helping out some more.
      <br>
      I actually did dump a few 18-bit tapes on my PDP-8 only a few
      months ago, which is when I actually had to dig rather deep into
      all of this.
      <br>
      PIP10 was one of the things I really looked into. But since my
      tapes had actually been written on a PDP-15, I had to write my own
      code in the end, to just dump the raw data.
      <br>
      <br>
      <blockquote type="cite">If anyone has a canned OS/8 V3C image with
        PIP10, please post it
        <br>
        somewhere (like Mediafire) and let me know by email.
        <br>
      </blockquote>
      <br>
      I think someone already posted this, but I know I have that
      software, including sources (if I remember right) somewhere. Let
      me know if it can't be located anywhere else.
      <br>
      <br>
          Johnny
      <br>
      <br>
      _______________________________________________
      <br>
      Simh mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://mailman.trailing-edge.com/mailman/listinfo/simh">http://mailman.trailing-edge.com/mailman/listinfo/simh</a>
      <br>
    </blockquote>
    <br>
  </body>
</html>