<div dir="auto">We should move to COFF (cc’ed) for any further discussion. This is way off topic for simh. </div><div dir="auto"><br></div><div dir="auto">Below<br></div><div dir="auto"><br clear="all"><div dir="auto"><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Sent from a handheld expect more typos than usual</div></div></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 30, 2023 at 7:59 PM Nigel Johnson MIEEE via <a href="http://groups.io">groups.io</a> <nw.johnson=<a href="mailto:ieee.org@groups.io">ieee.org@groups.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
    
  
  <div>
    <p><font face="Eurostile LT Pro Unicode">First of all, 7-track vs
        9-yrack - when you are streaming in serpentine mode, it is
        whatever you can fit into the tape width having regard to the
        limitations of the stepper motor accuracy.</font></p></div></blockquote><div dir="auto">Agreed.  It’s the physical size of head and encoding magnetics.  Parallel you have n heads together all  reading or writing together into n analog circuits.   A rake across the ground if you will.  Serial of course its like a single pencil line with the head on a servo starting in the center of the tape and when you hit the physical eot move it up or down as appropriate.  </div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p dir="auto"><font face="Eurostile LT Pro Unicode"> It is nothing to do
        with the number of bits per data unit.  </font></p></div></blockquote><div dir="auto">I did not say that or imply it.   But variable vs. fixed blocking has implications on both mechanical requirements and ends up being reflected in how the sw handles it.  Traditional 9-track allows you to mix record sizes on each tape.  Streamer formats don’t traditionally allow that because they restrict / remove inter record gaps in the same manner 9-track supports.  This increases capacity of the tape (less waste).  </div><div dir="auto"><br></div><div dir="auto">Just for comparison at 6250 BPI a traditional 2400’ ½” tape writing fixed blocks of 10240 8-bit bytes gets about 150Mbytes.  A ¼” DC-6150 tape using QIC-150 only one forth the length and half as wide gets the same capacity and they both use the same core scheme to encode the bits.  QIC writes smaller bits and wastes less tape with IRCs.  </div><div dir="auto"><br></div><div dir="auto">That all said, Looking at the TK25 specs besides being 11 tracks it is also supports a small number different block sizes (LRECL) - unlike QIC.   Nothing like 9-track which can handle a large range of LRECLs.  What I don’t see in the TK25 is if you can mix them on a tape or if that is coded once for each tape as opposed in each record.  </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Btw while I don’t think ansi condones it, some 9-track units like the Storage Tek ones could not only write different LRECLs but could write using different encoding (densities) on the same medium.  This sad trick confused many drives when you moved the tape to a drive that could not.  I have some interesting customer stories living those issues.  But I digress …</div><div dir="auto"><br></div><div dir="auto">FWIW As I said before do have a lot of experience with what it takes to support this stuff and what you have to do decode it, the drivers for same et al.   I never considered myself a tape expert- there are many the know way more than I - but I have lived, experienced and had to support a number of these systems and have learned the hard way about how these schemes can go south when trying to recover data.  </div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p dir="auto"><font face="Eurostile LT Pro Unicode">Back in the beginning of
        my career, we had Uniservo VIC drives which were actually 7-bit
        parallel! (256, 556, and 800 bpi! NRZI</font></p></div></blockquote><div dir="auto">Yep same here. ½” was 5, 7 and 9 bits in parallel originally.  GE-635 has in the late 1960s then and a IBM shop in the early 70s.  And of course saw my favorite tapes of all - original DEC tape.  I’ve  also watched things change with serial and the use of serpentine encoding.    </div><div dir="auto"><br></div><div dir="auto">You might find it amusing — any early 1980s Masscomp machines had a special ½” drive that had a huge number serpentine tracks I’ve forgotten the exact amount. They used traditional 1/2” spools from 3M and the like but r/w was custom to the drive.    I’ve forgotten the capacity but at the time it was huge. What I remember it was much higher capacity and reliability than exabyte which at the time was the capacity leader. The USAF AWACS planes had 2 plus a spare talking to the /700 systems doing the I/O - they were suckling up everything in the air and recording it as digital signals. The tape units were Used to record all that data.  An airman spends his/whole time loading and unloading tapes.     Very cool system.<br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p dir="auto"><font face="Eurostile LT Pro Unicode"><br>
      </font></p>
    <p><font face="Eurostile LT Pro Unicode">Some things about the 92192
        drive:  it was 8" cabinet format in a 5.25 inch world so needed
        an external box.  It also had an annoying habit, given Control
        Data's proclivity for perfection, that when you put a cartridge
        in, it ran it back and forth for five minutes before coming
        ready to ensure even tension on the tape!</font></p>
    <p><font face="Eurostile LT Pro Unicode">The formatter-host adapter
        bus was not QIC36, so Emulex had to make a special controller,
        the TC05, to handle the CDC Proprietary format. The standard was
        QIC-36, although I think that Tandberg had a standard of their
        own.</font></p></div></blockquote><div dir="auto">Very likely.  When thoses all came on the scene there were a number of interfaces and encoding schemes. I was not involved in any of the politics but QIC ended up as the encoding standard and SCSI the interface</div><div dir="auto"><br></div><div dir="auto">IIRC the first QIC both Masscomp and Apollo used was QIC-36 via a SCSI converter board SCS made for both of us.  I don’t think Sun used it.  Later Archive and I think Wangtek made SCSI interface standard on the drives. </div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p dir="auto"><font face="Eurostile LT Pro Unicode"><br>
      </font></p>
    <p><font face="Eurostile LT Pro Unicode">I was wrong about the
        9-track versus 7, the TC05/sentinel combination writes 11
        tracks!  The standard 1/4' cartridge media use QIC24, which
        specifies 9 tracks. I just knew it was not 9!</font></p></div></blockquote><div dir="auto">It also means it was not a QIC standard as I don’t believe they had one between QIC-24-DC and QIC-120-DC.   Which I would think means that if this tape came from a TK25 I doubt either Steve or my drives will read it - he’ll need to find someone with a TK25 - which I have never seen personally. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p dir="auto"><font face="Eurostile LT Pro Unicode"><br>
      </font></p>
    <p dir="auto"><font face="Eurostile LT Pro Unicode">That's all I know!</font></p></div></blockquote><div dir="auto">fair enough</div><div dir="auto"><br></div><div dir="auto">Clem<span style="color:white">_._,_._,_</span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<p></p><p></p></blockquote></div></div>