Xref: utzoo comp.bugs.2bsd:91 comp.periphs:1153 comp.sys.dec:753 comp.org.decus:282
Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!cmcl2!husc6!bloom-beacon!oberon!sm.unisys.com!ucla-cs!casey
From: casey@CS.UCLA.EDU
Newsgroups: comp.bugs.2bsd,comp.periphs,comp.sys.dec,comp.org.decus
Subject: Do all third party TMs interpret tmcs==0 as 1600BPI?
Keywords: TM-11/TE-10, third party TM emulators, compatibility
Message-ID: <15391@shemp.CS.UCLA.EDU>
Date: 21 Aug 88 02:22:28 GMT
Sender: news@CS.UCLA.EDU
Reply-To: casey@CS.UCLA.EDU (Casey Leedom)
Organization: UCLA
Lines: 22


  Ok all you PDP-11 gurus, get out your peripheral data books: DEC
produced a tape subsystem called a TM-11/TE-10, typically referred to by
UNIXers as a TM.  The DEC TM was only capable of 800BPI and under.

  Several third party manufactures have produced TM emulators capable of
1600BPI and even 6250BPI (AVIV only?).  2.9BSD, 4.3BSD, and several other
UNIX versions support these TM emulators.  Under 2.9 and 4.3, 060000 is
stuffed into tmcs for 800BPI (which puts a standard DEC TM into 800BPI
9-track mode), and a 0 is used for 1600BPI.  (4.3 uses a 020000 for
6250BPI for the AVIV.)

  I'm trying to get the 2.10BSD stand alone boot fixed up with better
support for 1600BPI - our only distribution density.  Will I get in
trouble if I have the stand alone primary boot stuff a zero into tmcs?
This would cause a DEC TM to go into 7-track ???BPI, but then a DEC TM
wouldn't be able to read in the primary bootstrap in any case ...

  As I understand it, most TM emulators ignore the 060000 bits in tmcs
entirely and use a physical switch on the drive to select density.

Casey