[TUHS] Determining what was on a tape back in the day

[TUHS] Determining what was on a tape back in the day

[Noel Chiappa]

    > The 0th block does seem to contain some PDP-11 binary - a bootstrap of
    > some sort. I'll look in more detail in a bit.

OK, I had a quick look, and it seems to be a modified version of mboot.s:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/mdec/mboot.s

I had a look through the rest of the likely files in 'mdec', and I didn't find
a better match. I'm too lazy busy to do a complete dis-assembly, and work out
exactly how it's different, though..


A few observations:

  000:    000407 000606 000000 000000 000000 000000 000000 000001 

An a.out header, with the 0407 'magic' here performing its original intended
function - to branch past the header.

  314:	105737 177560 002375

Some console I/O stuff - this two instruction loop waits for the input
ready bit to be set.

  326:	042700 177600 020027 000101 103405 020027 000132 101002

More character processing - the first instruction clears the high bits of R0,
and the next two sets of two instructions compare the contents with two
characters (0101 and 0132), and branch.

  444:    000207 005000 021027 000407 001004 016020 
  460:    000020 020006 103774 012746 137000 005007

This seems like the code that checks to see if the thing is an a.out file
(note the 'cmp *r0, $0407'), but the code is different from that code in
mboot.s; in that, the instruction before the 'clr r0' (at 0446 here) is a
'jsr', whereas in this it's an 'rts pc'. And the code after the 'cmp r0, sp'
and branch is different too. I love the '05007' - not very often you see
_that_ instruction!

  502:    012700 177350 012701 177342 012711 000003 105711 

Clearly the code at 'taper:' (TC11 version).

	Noel

[TUHS] Determining what was on a tape back in the day

[Will Senn]

On 11/20/17 10:01 AM, Noel Chiappa wrote:
>      > The 0th block does seem to contain some PDP-11 binary - a bootstrap of
>      > some sort. I'll look in more detail in a bit.
>
> OK, I had a quick look, and it seems to be a modified version of mboot.s:
>
>    http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/mdec/mboot.s
>
> I had a look through the rest of the likely files in 'mdec', and I didn't find
> a better match. I'm too lazy busy to do a complete dis-assembly, and work out
> exactly how it's different, though..
>
>
> A few observations:
>
>    000:    000407 000606 000000 000000 000000 000000 000000 000001
>
> An a.out header, with the 0407 'magic' here performing its original intended
> function - to branch past the header.
>
>    314:	105737 177560 002375
>
> Some console I/O stuff - this two instruction loop waits for the input
> ready bit to be set.
>
>    326:	042700 177600 020027 000101 103405 020027 000132 101002
>
> More character processing - the first instruction clears the high bits of R0,
> and the next two sets of two instructions compare the contents with two
> characters (0101 and 0132), and branch.
>
>    444:    000207 005000 021027 000407 001004 016020
>    460:    000020 020006 103774 012746 137000 005007
>
> This seems like the code that checks to see if the thing is an a.out file
> (note the 'cmp *r0, $0407'), but the code is different from that code in
> mboot.s; in that, the instruction before the 'clr r0' (at 0446 here) is a
> 'jsr', whereas in this it's an 'rts pc'. And the code after the 'cmp r0, sp'
> and branch is different too. I love the '05007' - not very often you see
> _that_ instruction!
>
>    502:    012700 177350 012701 177342 012711 000003 105711
>
> Clearly the code at 'taper:' (TC11 version).
>
> 	Noel

Thanks for the insight into how to look into this. I'm off to refreshing 
my pdp-11 assembly language skills...

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

[TUHS] Determining what was on a tape back in the day

[Ron Natalie]

> It bloody well worked as a read-only file system; I take great umbrage at
the implication that I am a liar, and I'm the sort of obstreperous bastard
who neither forgives not forgets...

Nobody was calling you a liar, and if you mistook my posts for that, I
sincerely apologize.   Understand that people can be wrong without being a
"liar" or dispute someone without making accusations of being a "liar."

[TUHS] Determining what was on a tape back in the day

[William Pechter]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

Dave Horsfall wrote:
> On Mon, 20 Nov 2017, Random832 wrote:
>
>> For whatever it's worth, the tm(4) and ht(4) manpages from V5 onward
>> say "seeks have their usual meaning", and both drivers provide a
>> 'non-raw' device which is a block device and (according to the
>> manual) only supports tapes consisting of 512-byte records - the BUGS
>> section mentions that the raw device, conversely, does *not* support
>> seeking.
>
> Thank you; I dimly recall that seeks were implemented by the driver
> keeping track of whichever block was under the head, and skipping
> forwards or backwards accordingly, with simple arithmetic. I no longer
> have access to those sources, but we at UNSW certainly modified Unix
> rather heavily, so if that capability is not in the distributed
> version then it means that we modified it; this was over 30 years ago...
>
> It bloody well worked as a read-only file system; I take great umbrage
> at the implication that I am a liar, and I'm the sort of obstreperous
> bastard who neither forgives not forgets...
>
I know that a read-only filesystem for installs is possible.  Pyramid
Technologies used a tape install filesystem called ROFS...guess what
that stands for...

We used it on both cartridge (QIC-150 iirc) and 9 track magtapes... So
there's no special type of drive needed.
It was created by dd-ing  a chrooted specially constructed file tree
(IIRC).   I constructed special ones at my
site with all the site specific info (passwords, groups, etc) on it for
emergency recovery.

It was used for their OS/x (BSD-SysV dual universe for their Risc CPU)
and DCOSx (SVR4 port to Mips R3000).

Bill

[TUHS] Determining what was on a tape back in the day

[Dave Horsfall]

On Mon, 20 Nov 2017, Random832 wrote:

> For whatever it's worth, the tm(4) and ht(4) manpages from V5 onward say 
> "seeks have their usual meaning", and both drivers provide a 'non-raw' 
> device which is a block device and (according to the manual) only 
> supports tapes consisting of 512-byte records - the BUGS section 
> mentions that the raw device, conversely, does *not* support seeking.

Thank you; I dimly recall that seeks were implemented by the driver 
keeping track of whichever block was under the head, and skipping forwards 
or backwards accordingly, with simple arithmetic. I no longer have access 
to those sources, but we at UNSW certainly modified Unix rather heavily, 
so if that capability is not in the distributed version then it means that 
we modified it; this was over 30 years ago...

It bloody well worked as a read-only file system; I take great umbrage 
at the implication that I am a liar, and I'm the sort of obstreperous 
bastard who neither forgives not forgets...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Determining what was on a tape back in the day

[Noel Chiappa]

    > From: Will Senn

    > I'm off to refreshing my pdp-11 assembly language skills...

A couple of things that might help:

- assemble mboot.s and 'od' the result, so when you see something that matches
  in the dump of the 0th block, you can look back at the assembler source, to see
  what the source looks like

- read the boot block into a PDP-11 debugger ('db' or 'cdb' on V6, 'adb' on
  V7; I _think_ 'adb' was available on V7, if not, there are some BSD's that
  have it) and use that to disassmble the code

	Noel

[TUHS] Determining what was on a tape back in the day

[Paul Winalski]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]

On 11/19/17, Clem cole <clemc at ccc.com> wrote:
> Noel is correct. DECtape (aka linctape) was a block oriented technology.
> Traditional 1/2” mag tape which had 5, 7 or 9 tracks is a stream oriented
> technology.

DECtape/LINCtape was unusual as tape technology goes.  It was
block-oriented, meaning that data were formatted as a sequence of
fixed-length blocks (256 or 512 bytes, IIRC).  It was also
block-replaceable--you could seek (fast-forward or rewind) to a
particular block and rewrite it without destroying the data following
the block.  DECtape also had a timing track and could be read at
variable speed.  I heard one story from a PDP-10 operator who had
critical data on a DECtape, but the motor on the drive broke down.  He
was able to use a pencil to wind the tape, and because of the timing
track the drive was able to read the tape successfully.

> DECtape was used liked disk in the late 60s.  It was comparably cheap and
> very reliable.  The joke was you could unroll it and run over it with a car
> and then roll it back up and it would still work.

Because of the block-oriented and block replacement feature, you could
treat a DECtape as if it were a high-capacity disk with a horribly
long seek time.

> Magtape was traditional back up scheme.  Cost per bit was low and good for
> archiving.  But you could only add to the end of a tape.  You can do funny
> things like change recording techniques between files (not recommended as it
> can confuse many tape controllers but is technically allowed and was done).

I never used 5-track 1/2" magtape, and had only a brief acquaintance
with 7-track tape.  9-track tape at 800 bits/inch used non-return to
zero inverted (NRZI) encoding, 1600 bpi using phase encoding (PE), and
6250 bpi using group coded recording (GCR).  Data were written as
variable-length blocks, with a special tape mark indicating
end-of-file.  The first block of a file was typically a file label.
PE- and GCR-encoded tapes had a special "PE burst" or "GCR burst"
record as the first block on the tape.  This allowed the tape drive to
determine automatically the encoding for the tape.

9-track magtape could have some peculiar quirks.  VMS Engineering at
DEC once received a 6250 bpi tape from a customer containing a crash
dump, but when they tried to read it, the tape had a completely
different file on it.  The customer verified that they had sent the
correct tape.  The VMS engineer mounted the tape on a different drive,
and lo and behold, the crash dump was on the tape!  It turned out that
the first tape drive was out of adjustment, missed the GCR burst, and
read the tape as 800 bpi NRZI.  The 6250 bpi crash dump had been
recorded on top of an earlier 800 bpi file, but the old file was still
readable at 800 bpi.

-Paul W.

[TUHS] Determining what was on a tape back in the day

[Random832]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

On Sun, Nov 19, 2017, at 20:18, Dave Horsfall wrote:
> On Sun, 19 Nov 2017, Ronald Natalie wrote:
>
> [ Tape as a mountable file-system ]
>
> >> So you mount it read-only...
> >
> > Still won’t work.    Seek doesn’t work right.
>
> I don't feel like arguing this, but it most certainly did for me,
> thank you very much (I'm desperately trying to be polite here); a
> modified tape driver, perhaps?  It was quite amusing watching it
> thrash back and forth, until I put it out of its misery.
>
> I think I even mentioned it once, in an issue of AUUGN; all I remember
> now was that the tape had 512-byte blocks, just like the RK-05 from
> which it was presumably DD'd (I wasn't silly enough to try a MKFS).

For whatever it's worth, the tm(4) and ht(4) manpages from V5 onward say
"seeks have their usual meaning", and both drivers provide a 'non-raw'
device which is a block device and (according to the manual) only
supports tapes consisting of 512-byte records - the BUGS section
mentions that the raw device, conversely, does *not* support seeking.

It's not clear exactly what kind of support the block device had for
unaligned read/write/seeks (the mention of "monstrous record gaps" for
small writes suggests it was not seamless), but it seems like it not
being possible to replace whole blocks explicitly is something that
would have been mentioned.

The 'raw' interface itself first appears in V5; The V4 manual does not
mention seeking, but also does not mention "record gaps". The V4 kernel
only has tm as a block device. The V3 manual says seeking does not work,
and describes semantics for reads/writes of less than 512 bytes that are
not mentioned in later versions of the manual.

Modern OSes (Linux and BSD, anyway) do not provide the block device, and
use ioctl for "seeking" (since lseek is an inappropriate interface for
block-level seeking).

On a historical note, it looks like in addition to the original PDP/VAX
drivers, Interdata 7/32 and Tahoe ports also provided "non-raw"
interfaces for those platforms' particular tape devices, whereas the
HP300 port of 4.3BSD did not.

[TUHS] Determining what was on a tape back in the day

[Noel Chiappa]

    > From: Will Senn

    > I don't see this file in the tuhs source code index

OK, here it is:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/stp.h
  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/stp1.c
  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/stp2.c
  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/stp3.c

That MIT PWB1+ tape has so many treasures on it! (We've already seen all the
early networking software.) I really must getting around to curating it, and
making the whole works available.

	Noel

[TUHS] Determining what was on a tape back in the day

[Lawrence Stewart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]


> On 2017, Nov 18, at 6:16 PM, Don Hopkins <don at DonHopkins.com> wrote:
> 
> 
> 
> I have been wondering about that for years. 
> 
> Here’s the manual! LISTREVERSE is documented on page 9-3. Maybe if I printed out the "READERS COMMENTS" form at the back of the manual, wrote my question in big upper case block letters, then ticked the "If you require a written reply, please check here” checkbox, then “Fold Here” and “Do Not Tear - Fold Here and Staple” as instructed, I could mail in the free first class pre-addressed, business reply mail, no postage stamp necessary if mailed inside the United States envelope, and they’d write me back a nice letter telling me what the fuck they were thinking. 
> 
> http://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/DEC-20-LBMAA-A-D%20BASIC%20User%27s%20Guide.pdf <http://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/DEC-20-LBMAA-A-D%20BASIC%20User's%20Guide.pdf>
> 
> -Don
> 

The thing is, the sort of people in engineering at Digital would do exactly that.  The apocryphal case is when someone asked why the base of VMS DAYTIME was November 17, 1858 and got the following back:

http://h41379.www4.hpe.com/wizard/wiz_2315.html <http://h41379.www4.hpe.com/wizard/wiz_2315.html>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171119/056ce2a2/attachment.html>

[TUHS] Determining what was on a tape back in the day

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

On Sun, 19 Nov 2017, Ronald Natalie wrote:

[ Tape as a mountable file-system ]

>> So you mount it read-only...
>
> Still won’t work.    Seek doesn’t work right.

I don't feel like arguing this, but it most certainly did for me, thank 
you very much (I'm desperately trying to be polite here); a modified tape 
driver, perhaps?  It was quite amusing watching it thrash back and forth, 
until I put it out of its misery.

I think I even mentioned it once, in an issue of AUUGN; all I remember now 
was that the tape had 512-byte blocks, just like the RK-05 from which it 
was presumably DD'd (I wasn't silly enough to try a MKFS).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Determining what was on a tape back in the day

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]


> On Nov 19, 2017, at 6:41 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Sun, 19 Nov 2017, Ronald Natalie wrote:
> 
>> You can’t mount a regular 9 track or many other types because they weren’t block replaceable.  Once you wrote the superblock the second time, you lost the rest of the filesystem.
> 
> So you mount it read-only...
> 
> 

Still won’t work.    Seek doesn’t work right.

[TUHS] Determining what was on a tape back in the day

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]

On Sun, 19 Nov 2017, Ronald Natalie wrote:

> You can’t mount a regular 9 track or many other types because they 
> weren’t block replaceable.  Once you wrote the superblock the second 
> time, you lost the rest of the filesystem.

So you mount it read-only...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Determining what was on a tape back in the day

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

You can’t mount a regular 9 track or many other types because they weren’t block replaceable.    Once you wrote the superblock the second time, you lost the rest of the filesystem.


> On Nov 19, 2017, at 5:00 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Sun, 19 Nov 2017, Ron Natalie wrote:
> 
>> You could actually mkfs a DECtape and mount it but the system would stall while rewinding to write the superblock. 
> 
> The early Sun boxes used to hang when rewinding the cartridge tape, because the controller didn't release the Multibus; the stingy Lionel Singer used to sell the 3/50 as cheap servers...
> 
> And you haven't lived until just for fun you put a file system onto a 9-track tape and ran FSCK on it.
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Determining what was on a tape back in the day

[Lyndon Nerenberg]

> The early Sun boxes used to hang when rewinding the cartridge tape, because 
> the controller didn't release the Multibus; the stingy Lionel Singer used to 
> sell the 3/50 as cheap servers...

The Convergent Tech MiniFrame had a similar bug with the QIC tape drive. 
If you sent it an interrupt during a rewind (e.g. ^C a cpio after the 
extract was done, but before the rewind/close finished), it would block 
the tape device from any further use.

That was my first expedition into non-API UNIX kernel hacking, writing a 
program that would reach into the kernel to clear the 'busy' bit on the 
tape device.

--lyndon

[TUHS] Determining what was on a tape back in the day

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Sun, 19 Nov 2017, Ron Natalie wrote:

> You could actually mkfs a DECtape and mount it but the system would 
> stall while rewinding to write the superblock. 

The early Sun boxes used to hang when rewinding the cartridge tape, 
because the controller didn't release the Multibus; the stingy Lionel 
Singer used to sell the 3/50 as cheap servers...

And you haven't lived until just for fun you put a file system onto a 
9-track tape and ran FSCK on it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Determining what was on a tape back in the day

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6682 bytes --]

You could actually mkfs a DECtape and mount it but the system would stall while rewinding to write the superblock. 

Sent from my iPhone

> On Nov 19, 2017, at 4:00 PM, William Corcoran <wlc at jctaylor.com> wrote:
> 
> My first exposure to Unix was a Motorola S2000 model 290.  This was introduced in the year I graduated high school, 1985.
> 
> This box was based upon the Motorola 68000 chip as I recall.   This system was unique in that the primary OS was called ISOS and System III UNIX would actually exist as a process under ISOS.   The bus was a precursor to VME.  The entire system consisted of several small towers strapped together by a 50 pin SCSI bus.  The first tower was the CPU, called a data processing unit (“DPU”).  The remaining small towers would include a QIC tape drive, a 50 MB disk drive, another 50 MB disk drive, and a 5 MB removable disk drive.   This entire arrangement was called a supermicrocomputer.  
> 
> The 50 MB drives were 5.25” form factor full height mechanisms.  Yet, they had a very unique property. Instead of voice coil technology, I think they used a stepper motor because the drives would make a relatively loud click sound when accessed.  During boot, say after a panic,  fsck would kick off and I will never forget the sound of these drives as they would chatter like crazy!  
> 
> Now, turning to the subject at hand, eventually system III was upgraded to system V in 1986.  Well, one of the coolest things this little beast had was a QIC tape drive that would stream quite nicely with very little under-runs during backup and restore. 
> 
> But, the QIC tape driver had a unique property:  You could treat the QIC tape cartridge as a block device.  First, there was a utility to create a limited file system on the tape.   Next,  once the tape was inserted, you could mount the tape—-just like a disk.  
>  
> Then, you could “cd” into the mount point of the tape.   You could use “/bin/cp” to copy files into the tape.   You could “/bin/ls” as well.  In fact, you could even “mkdir” into the QIC tape as well.  There was limit to the number of nested folders. 
> 
> While mounting a QIC tape into the tree of life was in interesting concept, it was totally impractical.  Tape based operations on the QIC cartridge were slow.  Worse, the tape driver couldn’t stream when treated as a block device.  This resulted in “shoe shining” the tape heads for responding to the simplest of commands like “ls.”
> 
> Finally, if any of our good members here has any Information in the Motorola S2000 model 290 supermicro, I would love to know.  I have searched for years to get my hands on this unit or its documentation.  I did locate and obtain a DPU.  But, it was in very bad shape.  
> 
> No one forgets their first UNIX box!
> 
> Truly,
> 
> Bill Corcoran
> 
> 
> On Nov 19, 2017, at 9:57 AM, Clem cole <clemc at ccc.com> wrote:
> 
>> Noel is correct. DECtape (aka linctape) was a block oriented technology.  Traditional 1/2” mag tape which had 5, 7 or 9 tracks is a stream oriented technology.   
>> 
>> DECtape was used liked disk in the late 60s.  It was comparably cheap and very reliable.  The joke was you could unroll it and run over it with a car and then roll it back up and it would still work.  
>> 
>> Magtape was traditional back up scheme.  Cost per bit was low and good for archiving.  But you could only add to the end of a tape.  You can do funny things like change recording techniques between files (not recommended as it can confuse many tape controllers but is technically allowed and was done). 
>> 
>> Because of the variable nature of things the OS needs a way to support these behaviors.  Unix makes it pretty easy by letting the user do it all in user space and passing info to the driver.  Other OSs do a lot of work when ‘mounting’ a tape.  But either way simh needs to support these type of functions.  Hence the idea of the virtual tape format that includes meta data to describe things like the size of each block written.  A ‘file mark’ can be read/written (which is special) besides data blocks    
>> 
>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
>> 
>> On Nov 19, 2017, at 8:41 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>> 
>>>> From: Will Senn
>>> 
>>>> I don't quite no how to investigate this other than to pore through the
>>>> pdp11/40 instruction manual.
>>> 
>>> One of these:
>>> 
>>> https://www.ebay.com/itm/Digital-pdp-Programming-Card-8-Pages/142565890514
>>> 
>>> is useful; it has a list of all the opcodes in numerical order; something none
>>> of the CPU manuals have, to my recollection. Usually there are a flock of
>>> these "pdp11 Programming Cards" on eBait, but I only see this one at the
>>> moment.
>>> 
>>> If you do any amount of work with PDP-11 binary, you'll soon find yourself
>>> recognizing the common instructions. E.g. MOV is 01msmr (octal), where 'm' is
>>> a mode specifier, and s and r are source and destination register
>>> numbers. (That's why PDP-11 people are big on octal; the instructions are easy
>>> to read in octal.) More here:
>>> 
>>> http://gunkies.org/wiki/PDP-11_architecture#Operands
>>> 
>>> So 0127xx is a move of an immediate operand.
>>> 
>>> 
>>>>> You don't need to mount it on DECTape drive - it's just blocks. Mount
>>>>> it as an RK05 image, or a magtape, or whatever.
>>> 
>>>> I thought disk (RK05) and tape (magtape) blocks were different...
>>> 
>>> Well, you need to differentiate between DECtape and magtape - very different
>>> beasts.
>>> 
>>> DECtape on a PDP-11 _only_ supports 256 word (i.e. 512 byte) blocks, the same
>>> as most disks. (Floppies are an exception when it comes to disks - sort
>>> of. The hardware supports 128/256 byte sectors, but the usual driver - not in
>>> V6 or V7 - invisibly makes them look like 512-byte blocks.)
>>> 
>>> Magtapes are complicated, and I don't remember all the details of how Unix
>>> handles them, but the _hardware_ is prepared to write very long 'blocks', and
>>> there are also separate 'file marks' which the hardware can write, and notice.
>>> 
>>> But a magtape written in 512-byte blocks, with no file marks, can be treated
>>> like a disk; that's what the V6 distribution tapes look like:
>>> 
>>> http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition#Installation_tape_contents
>>> 
>>> and IIRC 'tp' format magtape tapes are written the same way, hardware-wise (so
>>> they look just like DECtapes).
>>> 
>>>    Noel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171119/2e6854dc/attachment.html>

[TUHS] Determining what was on a tape back in the day

[William Corcoran]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6209 bytes --]

My first exposure to Unix was a Motorola S2000 model 290.  This was introduced in the year I graduated high school, 1985.

This box was based upon the Motorola 68000 chip as I recall.   This system was unique in that the primary OS was called ISOS and System III UNIX would actually exist as a process under ISOS.   The bus was a precursor to VME.  The entire system consisted of several small towers strapped together by a 50 pin SCSI bus.  The first tower was the CPU, called a data processing unit (“DPU”).  The remaining small towers would include a QIC tape drive, a 50 MB disk drive, another 50 MB disk drive, and a 5 MB removable disk drive.   This entire arrangement was called a supermicrocomputer.

The 50 MB drives were 5.25” form factor full height mechanisms.  Yet, they had a very unique property. Instead of voice coil technology, I think they used a stepper motor because the drives would make a relatively loud click sound when accessed.  During boot, say after a panic,  fsck would kick off and I will never forget the sound of these drives as they would chatter like crazy!

Now, turning to the subject at hand, eventually system III was upgraded to system V in 1986.  Well, one of the coolest things this little beast had was a QIC tape drive that would stream quite nicely with very little under-runs during backup and restore.

But, the QIC tape driver had a unique property:  You could treat the QIC tape cartridge as a block device.  First, there was a utility to create a limited file system on the tape.   Next,  once the tape was inserted, you could mount the tape—-just like a disk.

Then, you could “cd” into the mount point of the tape.   You could use “/bin/cp” to copy files into the tape.   You could “/bin/ls” as well.  In fact, you could even “mkdir” into the QIC tape as well.  There was limit to the number of nested folders.

While mounting a QIC tape into the tree of life was in interesting concept, it was totally impractical.  Tape based operations on the QIC cartridge were slow.  Worse, the tape driver couldn’t stream when treated as a block device.  This resulted in “shoe shining” the tape heads for responding to the simplest of commands like “ls.”

Finally, if any of our good members here has any Information in the Motorola S2000 model 290 supermicro, I would love to know.  I have searched for years to get my hands on this unit or its documentation.  I did locate and obtain a DPU.  But, it was in very bad shape.

No one forgets their first UNIX box!

Truly,

Bill Corcoran


On Nov 19, 2017, at 9:57 AM, Clem cole <clemc at ccc.com<mailto:clemc at ccc.com>> wrote:

Noel is correct. DECtape (aka linctape) was a block oriented technology.  Traditional 1/2” mag tape which had 5, 7 or 9 tracks is a stream oriented technology.

DECtape was used liked disk in the late 60s.  It was comparably cheap and very reliable.  The joke was you could unroll it and run over it with a car and then roll it back up and it would still work.

Magtape was traditional back up scheme.  Cost per bit was low and good for archiving.  But you could only add to the end of a tape.  You can do funny things like change recording techniques between files (not recommended as it can confuse many tape controllers but is technically allowed and was done).

Because of the variable nature of things the OS needs a way to support these behaviors.  Unix makes it pretty easy by letting the user do it all in user space and passing info to the driver.  Other OSs do a lot of work when ‘mounting’ a tape.  But either way simh needs to support these type of functions.  Hence the idea of the virtual tape format that includes meta data to describe things like the size of each block written.  A ‘file mark’ can be read/written (which is special) besides data blocks

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.

On Nov 19, 2017, at 8:41 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu<mailto:jnc at mercury.lcs.mit.edu>> wrote:

From: Will Senn

I don't quite no how to investigate this other than to pore through the
pdp11/40 instruction manual.

One of these:

https://www.ebay.com/itm/Digital-pdp-Programming-Card-8-Pages/142565890514

is useful; it has a list of all the opcodes in numerical order; something none
of the CPU manuals have, to my recollection. Usually there are a flock of
these "pdp11 Programming Cards" on eBait, but I only see this one at the
moment.

If you do any amount of work with PDP-11 binary, you'll soon find yourself
recognizing the common instructions. E.g. MOV is 01msmr (octal), where 'm' is
a mode specifier, and s and r are source and destination register
numbers. (That's why PDP-11 people are big on octal; the instructions are easy
to read in octal.) More here:

http://gunkies.org/wiki/PDP-11_architecture#Operands

So 0127xx is a move of an immediate operand.


You don't need to mount it on DECTape drive - it's just blocks. Mount
it as an RK05 image, or a magtape, or whatever.

I thought disk (RK05) and tape (magtape) blocks were different...

Well, you need to differentiate between DECtape and magtape - very different
beasts.

DECtape on a PDP-11 _only_ supports 256 word (i.e. 512 byte) blocks, the same
as most disks. (Floppies are an exception when it comes to disks - sort
of. The hardware supports 128/256 byte sectors, but the usual driver - not in
V6 or V7 - invisibly makes them look like 512-byte blocks.)

Magtapes are complicated, and I don't remember all the details of how Unix
handles them, but the _hardware_ is prepared to write very long 'blocks', and
there are also separate 'file marks' which the hardware can write, and notice.

But a magtape written in 512-byte blocks, with no file marks, can be treated
like a disk; that's what the V6 distribution tapes look like:

http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition#Installation_tape_contents

and IIRC 'tp' format magtape tapes are written the same way, hardware-wise (so
they look just like DECtapes).

   Noel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171119/fdecaaad/attachment-0001.html>

[TUHS] Determining what was on a tape back in the day

[Steve Simon]

It can be hard to visualise what is on a tape when you have no idea
what is on there.

Attached is a simple tool I wrote "back then", shamlessly copying an
idea by Paul Scorer at Leeds Poly (My video systems lecturer).

It is called tm (tape mark).

-Steve
-------------- next part --------------
/* tm.c - read tape marks */
#include <stdio.h>
#include <signal.h>

int halt = 0;
void intr();


int main(int argc, char *argv[])
{
	int fd;
	static char buf[BUFSIZ * 128];
	int got = 0, data = 0, mark = 0, was = -1;
	char *dev = "/dev/tape";

	if (argc > 1)
		dev = argv[1];

	if ((fd = open(dev, 0)) == -1){
		perror(dev);
		return(-1);
	}

	signal(SIGINT, intr);

	do {
		got = read(fd, buf, sizeof(buf));
		got = (halt)? -1: got;		/* check for restarted system call */
		mark = (was == 0)? mark +1: 0;
		data = (was >  0)? data +1: 0;

		if (got != was && was > 0){
			printf("%-6d X %-6d\n", data, was);
			mark = 0;
		}

		if (got != was && was == 0){
			printf("tm     X %-6d\n", mark);
			data = 0;
		}

		was = got;
	} while(got != -1);
	close(fd);

	if (halt){
		puts("Interupted");
	}
	else{
		fflush(stdout);
		perror("EOF");
	}

	return(0);
}

void intr()
{
	halt = 1;
}

[TUHS] Determining what was on a tape back in the day

[Noel Chiappa]

    > From: Arthur Krewat

    > For anyone reading old tapes, I implore you to attempt to read data past
    > the soft EOT ;)

The guy who read my tape does in fact do that; you'll notice my program has an
option for looking for data after the soft EOT.

       Noel

[TUHS] Determining what was on a tape back in the day

[Arthur Krewat]

When reading magtapes, or any tapes for that matter, I usually dd the 
"files" on the tape into separate files on disk. This doesn't preserve 
the actual blocking factor on the tape, but I used other methods to 
determine that - usually experimenting with dd and small block sizes 
until I got to the point where it no longer errors.

One of my favorite pastimes was to read until the soft EOT (usually a 
double EOF), and then do a "mt fsf". Depending on the tape drive, this 
could advance the tape beyond the soft EOT where more data might be 
saved. The idea being that a tape had been overwritten from the 
beginning, but with less data overall.

So it would look like this: |data|EOF|data|EOF|data|EOT|short 
data|EOF|data|EOF|data|EOT|blank|Hard-EOT

I used this method to rescue a TOPS-10 6.03A install monitor from a 
backup set that was past the soft EOT on one of my own personal tapes. 
I've rescued a lot of other data that way too.

For anyone reading old tapes, I implore you to attempt to read data past 
the soft EOT ;)



On 11/19/2017 12:49 PM, Noel Chiappa wrote:
>      > From: Will Senn
>
>      > I think I understand- the bytes that we have on hand are not device
>      > faithful representations, but rather are failthful representations of
>      > what is presented to the OS. That is, back in the day, a tape would be
>      > stored in various formats as would disks, but unix would show these
>      > devices as streams of bytes, and those are the streams of bytes are what
>      > have been preserved.
>
> Yes and no.
>
> To start with, one needs to differentiate three different levels; i) what's
> actually on the medium; ii) what the device controller presented to the CPU;
> and iii) what the OS (Unix in this case) presented to the users.
>
> With the exception of magtapes (which had some semantics available through
> Unix for larger records, and file marks, the details of which escape me - but
> try looking at the man page for 'dd' in V6 for a flavour of it), you're correct
> about what Unix presented to the users.
>
>
> As to what is preserved; for disks and DECtapes, I think you are broadly
> correct. For magtapes, it depends.
>
> E.g. SIMH apparently can consume files which _represent_ magtape contents (i,
> above), and which include 'in band' (i.e. part of the byte stream in the file)
> meta-data for things like file marks, etc. At least one of the people who
> reads old media for a living, when asked to read an old tape, gives you back
> one of these files with meta-data in it. Here:
>
>    http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tools/rdsmt.c
>
> is a program which reads one of those files and convert the contents to a file
> containing just the data bytes. (I had a tape with a 'dd' save of a
> file-system on it, and wanted just the file-system image, on which I deployed
> a tool I wrote to grok 4.2 filesystems.)
>
>
> Also, for disks, it should be remembered that i) and ii) were usually quite
> different, as what was actually on the disk included thing like preambles,
> headers, CRCs, etc, none of which the CPU usually could even see. (See here:
>
>    http://gunkies.org/wiki/RX0x_floppy_drive#Low-level_format
>
> for an example. Each physical drive type would have its own specific low-level
> hardware format.) So what's preserved is just an image of what the CPU saw,
> which is, for disks and DECtapes, generally the same as what was presented to
> the user - i.e. a pile of bytes.
>
>       Noel
>

[TUHS] Determining what was on a tape back in the day

[Noel Chiappa]

    > From: Will Senn

    > I think I understand- the bytes that we have on hand are not device
    > faithful representations, but rather are failthful representations of
    > what is presented to the OS. That is, back in the day, a tape would be
    > stored in various formats as would disks, but unix would show these
    > devices as streams of bytes, and those are the streams of bytes are what
    > have been preserved.

Yes and no.

To start with, one needs to differentiate three different levels; i) what's
actually on the medium; ii) what the device controller presented to the CPU;
and iii) what the OS (Unix in this case) presented to the users.

With the exception of magtapes (which had some semantics available through
Unix for larger records, and file marks, the details of which escape me - but
try looking at the man page for 'dd' in V6 for a flavour of it), you're correct
about what Unix presented to the users.


As to what is preserved; for disks and DECtapes, I think you are broadly
correct. For magtapes, it depends.

E.g. SIMH apparently can consume files which _represent_ magtape contents (i,
above), and which include 'in band' (i.e. part of the byte stream in the file)
meta-data for things like file marks, etc. At least one of the people who
reads old media for a living, when asked to read an old tape, gives you back
one of these files with meta-data in it. Here:

  http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tools/rdsmt.c

is a program which reads one of those files and convert the contents to a file
containing just the data bytes. (I had a tape with a 'dd' save of a
file-system on it, and wanted just the file-system image, on which I deployed
a tool I wrote to grok 4.2 filesystems.)


Also, for disks, it should be remembered that i) and ii) were usually quite
different, as what was actually on the disk included thing like preambles,
headers, CRCs, etc, none of which the CPU usually could even see. (See here:

  http://gunkies.org/wiki/RX0x_floppy_drive#Low-level_format

for an example. Each physical drive type would have its own specific low-level
hardware format.) So what's preserved is just an image of what the CPU saw,
which is, for disks and DECtapes, generally the same as what was presented to
the user - i.e. a pile of bytes.

     Noel

[TUHS] Determining what was on a tape back in the day

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

How do you easily determine the last few line numbers so you know where 
to start appending new lines?



On 11/18/2017 8:04 PM, Clem cole wrote:
> List start,end
> Is standard Dartmouth basic from Kemeny & Kurtz - (aka K&K) which was the equivalent of K&R in those days.  [i think I have my Dad’s copy from they early 1960’s - which is what he taught me with in 1967].
>
> And Yes DEC basic supported it
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
>> On Nov 18, 2017, at 7:42 PM, Don Hopkins <don at DonHopkins.com> wrote:
>>
>>
>>> On 19 Nov 2017, at 01:35, Steve Nickolas <usotsuki at buric.co> wrote:
>>>
>>> On Sat, 18 Nov 2017, Arthur Krewat wrote:
>>>
>>>> Tail for BASIC. On a slow printer or CRT, you could ^C and only see the last few lines. Better than printing out the entire thing from the beginning.
>>>>
>>>> Or did it have a way of listing only a certain range of line numbers?
>>> Can't speak for DEC's dialect.  Apple's dialect supported LIST start,end and Microsoft's dialects supported LIST start-end (with some supporting the comma variant as well).
>>>
>>> Never heard of a backward LIST before. o.O
>>>
>>> -uso.
>> Maybe there was a corresponding RUNREVERSE command!
>>
>> -Don
>>
>

[TUHS] Determining what was on a tape back in the day

[Will Senn]

Sent from my iPhone

On Nov 19, 2017, at 7:41 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>  https://www.ebay.com/itm/Digital-pdp-Programming-Card-8-Pages/142565890514
> 
> is useful;


Thanks, Noel,

The archive has the card:
https://archive.org/details/bitsavers_decpdp11PDul75_1582192

> 
> Well, you need to differentiate between DECtape and magtape - very different
> beasts.
> 
> DECtape on a PDP-11 _only_ supports 256 word (i.e. 512 byte) blocks, the same
> as most disks. (Floppies are an exception when it comes to disks - sort
> of. The hardware supports 128/256 byte sectors, but the usual driver - not in
> V6 or V7 - invisibly makes them look like 512-byte blocks.)

> Magtapes are complicated, and I don't remember all the details of how Unix
> handles them, but the _hardware_ is prepared to write very long 'blocks', and
> there are also separate 'file marks' which the hardware can write, and notice.
> 
> But a magtape written in 512-byte blocks, with no file marks, can be treated
> like a disk; that's what the V6 distribution tapes look like:

I think I understand- the bytes that we have on hand are not device faithful representations, but rather are failthful representations of what is presented to the OS. That is, back in the day, a tape would be stored in various formats as would disks, but unix would show these devices as streams of bytes, and those are the streams of bytes are what have been preserved. 

Some formats have header info, file lists, and such placed in predetermined locations, and some have different block sizes, file/tape marks, but no track, sector type or device specific info is retained? Does this sound reasonably accurate?

Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171119/623f856e/attachment.html>

[TUHS] Determining what was on a tape back in the day

[Clem cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3473 bytes --]

Noel is correct. DECtape (aka linctape) was a block oriented technology.  Traditional 1/2” mag tape which had 5, 7 or 9 tracks is a stream oriented technology.   

DECtape was used liked disk in the late 60s.  It was comparably cheap and very reliable.  The joke was you could unroll it and run over it with a car and then roll it back up and it would still work.  

Magtape was traditional back up scheme.  Cost per bit was low and good for archiving.  But you could only add to the end of a tape.  You can do funny things like change recording techniques between files (not recommended as it can confuse many tape controllers but is technically allowed and was done). 

Because of the variable nature of things the OS needs a way to support these behaviors.  Unix makes it pretty easy by letting the user do it all in user space and passing info to the driver.  Other OSs do a lot of work when ‘mounting’ a tape.  But either way simh needs to support these type of functions.  Hence the idea of the virtual tape format that includes meta data to describe things like the size of each block written.  A ‘file mark’ can be read/written (which is special) besides data blocks    

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

On Nov 19, 2017, at 8:41 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>> From: Will Senn
> 
>> I don't quite no how to investigate this other than to pore through the
>> pdp11/40 instruction manual.
> 
> One of these:
> 
>  https://www.ebay.com/itm/Digital-pdp-Programming-Card-8-Pages/142565890514
> 
> is useful; it has a list of all the opcodes in numerical order; something none
> of the CPU manuals have, to my recollection. Usually there are a flock of
> these "pdp11 Programming Cards" on eBait, but I only see this one at the
> moment.
> 
> If you do any amount of work with PDP-11 binary, you'll soon find yourself
> recognizing the common instructions. E.g. MOV is 01msmr (octal), where 'm' is
> a mode specifier, and s and r are source and destination register
> numbers. (That's why PDP-11 people are big on octal; the instructions are easy
> to read in octal.) More here:
> 
>  http://gunkies.org/wiki/PDP-11_architecture#Operands
> 
> So 0127xx is a move of an immediate operand.
> 
> 
>>> You don't need to mount it on DECTape drive - it's just blocks. Mount
>>> it as an RK05 image, or a magtape, or whatever.
> 
>> I thought disk (RK05) and tape (magtape) blocks were different...
> 
> Well, you need to differentiate between DECtape and magtape - very different
> beasts.
> 
> DECtape on a PDP-11 _only_ supports 256 word (i.e. 512 byte) blocks, the same
> as most disks. (Floppies are an exception when it comes to disks - sort
> of. The hardware supports 128/256 byte sectors, but the usual driver - not in
> V6 or V7 - invisibly makes them look like 512-byte blocks.)
> 
> Magtapes are complicated, and I don't remember all the details of how Unix
> handles them, but the _hardware_ is prepared to write very long 'blocks', and
> there are also separate 'file marks' which the hardware can write, and notice.
> 
> But a magtape written in 512-byte blocks, with no file marks, can be treated
> like a disk; that's what the V6 distribution tapes look like:
> 
>  http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition#Installation_tape_contents
> 
> and IIRC 'tp' format magtape tapes are written the same way, hardware-wise (so
> they look just like DECtapes).
> 
>     Noel

[TUHS] Determining what was on a tape back in the day

[Noel Chiappa]

    > From: Will Senn

    > I don't quite no how to investigate this other than to pore through the
    > pdp11/40 instruction manual.

One of these:

  https://www.ebay.com/itm/Digital-pdp-Programming-Card-8-Pages/142565890514

is useful; it has a list of all the opcodes in numerical order; something none
of the CPU manuals have, to my recollection. Usually there are a flock of
these "pdp11 Programming Cards" on eBait, but I only see this one at the
moment.

If you do any amount of work with PDP-11 binary, you'll soon find yourself
recognizing the common instructions. E.g. MOV is 01msmr (octal), where 'm' is
a mode specifier, and s and r are source and destination register
numbers. (That's why PDP-11 people are big on octal; the instructions are easy
to read in octal.) More here:

  http://gunkies.org/wiki/PDP-11_architecture#Operands

So 0127xx is a move of an immediate operand.


    >> You don't need to mount it on DECTape drive - it's just blocks. Mount
    >> it as an RK05 image, or a magtape, or whatever.

    > I thought disk (RK05) and tape (magtape) blocks were different...

Well, you need to differentiate between DECtape and magtape - very different
beasts.

DECtape on a PDP-11 _only_ supports 256 word (i.e. 512 byte) blocks, the same
as most disks. (Floppies are an exception when it comes to disks - sort
of. The hardware supports 128/256 byte sectors, but the usual driver - not in
V6 or V7 - invisibly makes them look like 512-byte blocks.)

Magtapes are complicated, and I don't remember all the details of how Unix
handles them, but the _hardware_ is prepared to write very long 'blocks', and
there are also separate 'file marks' which the hardware can write, and notice.

But a magtape written in 512-byte blocks, with no file marks, can be treated
like a disk; that's what the V6 distribution tapes look like:

  http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition#Installation_tape_contents

and IIRC 'tp' format magtape tapes are written the same way, hardware-wise (so
they look just like DECtapes).

     Noel

[TUHS] Determining what was on a tape back in the day

[Will Senn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]


On 11/18/17 4:53 PM, Clem Cole wrote:
>
>
> On Sat, Nov 18, 2017 at 4:07 PM, Will Senn <will.senn at gmail.com 
> <mailto:will.senn at gmail.com>> wrote:
>
>
>     I thought disk (RK05) and tape (magtape) blocks were different...
>
> ​For simh they are, but not once UNIX sees them.​
>
> Physically 7/9-tapes were variable formatt
> ​ed and could have multiple 'files' on them.  UNIX reveals all of this 
> to user (as do most OSs), so you need put in the simh 'virtual' tape 
> format support for the size of the 'blocks' and all of the extra 
> things that the HW supports.
>
> But after the simh 'mounts' the 'virtual tape file' on the host when 
> it reads the 'tape', simh strips the meta-data out and presents on the 
> blocks to the OS. Or on write, simh takes the raw blocks, adds the 
> simulated metadata and writes that to host file system as a 'virtual 
> tape file.'
>
> In the old days disks physically could also be different formats.    
> But the 'controller' was used to format the disk.   Each disk block 
> included metadata that the controller used.    On DEC (and most other 
> systems of the day), the disk controller had some way to set this up, 
> usually with the diagnostic system.   The OS saw the disk after 
> formatting (as we do now).   The diagnostics would have decided how 
> big a block was etc...    DEC standardized on 512 bytes per block.
>
> simh could have taken the approach like disks, and then 'virtual 
> disks' would need the meta data; but could have supported all sorts of 
> file formats (like Apollo's and Xerox's).  But the simulated disk 
> controller would then need to handle the meta data.
>
> Since, most OSs just looked at disk as 'block streams' simh only needs 
> to provide for the OS to work properly, is map a UNIX file of bytes 
> into 512 byte blocks.   This works for most OSs.  As I said, it will 
> not work for Aegis or any of the Xerox systems which put some of what 
> the OS normally did in the microcode of the disk controller.
>
>

Thanks, Clem, this is very helpful information. I have a better sense 
now of what's going on.

Will

>

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/13ded55a/attachment.html>

[TUHS] Determining what was on a tape back in the day

[Clem cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

List start,end 
Is standard Dartmouth basic from Kemeny & Kurtz - (aka K&K) which was the equivalent of K&R in those days.  [i think I have my Dad’s copy from they early 1960’s - which is what he taught me with in 1967].

And Yes DEC basic supported it 

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 18, 2017, at 7:42 PM, Don Hopkins <don at DonHopkins.com> wrote:
> 
> 
>> On 19 Nov 2017, at 01:35, Steve Nickolas <usotsuki at buric.co> wrote:
>> 
>> On Sat, 18 Nov 2017, Arthur Krewat wrote:
>> 
>>> Tail for BASIC. On a slow printer or CRT, you could ^C and only see the last few lines. Better than printing out the entire thing from the beginning.
>>> 
>>> Or did it have a way of listing only a certain range of line numbers?
>> 
>> Can't speak for DEC's dialect.  Apple's dialect supported LIST start,end and Microsoft's dialects supported LIST start-end (with some supporting the comma variant as well).
>> 
>> Never heard of a backward LIST before. o.O
>> 
>> -uso.
> 
> Maybe there was a corresponding RUNREVERSE command!
> 
> -Don
> 

[TUHS] Determining what was on a tape back in the day

[Don Hopkins]

> On 19 Nov 2017, at 01:35, Steve Nickolas <usotsuki at buric.co> wrote:
> 
> On Sat, 18 Nov 2017, Arthur Krewat wrote:
> 
>> Tail for BASIC. On a slow printer or CRT, you could ^C and only see the last few lines. Better than printing out the entire thing from the beginning.
>> 
>> Or did it have a way of listing only a certain range of line numbers?
> 
> Can't speak for DEC's dialect.  Apple's dialect supported LIST start,end and Microsoft's dialects supported LIST start-end (with some supporting the comma variant as well).
> 
> Never heard of a backward LIST before. o.O
> 
> -uso.

Maybe there was a corresponding RUNREVERSE command!

-Don

[TUHS] Determining what was on a tape back in the day

[Steve Nickolas]

On Sat, 18 Nov 2017, Arthur Krewat wrote:

> Tail for BASIC. On a slow printer or CRT, you could ^C and only see the last 
> few lines. Better than printing out the entire thing from the beginning.
>
> Or did it have a way of listing only a certain range of line numbers?

Can't speak for DEC's dialect.  Apple's dialect supported LIST start,end 
and Microsoft's dialects supported LIST start-end (with some supporting 
the comma variant as well).

Never heard of a backward LIST before. o.O

-uso.

[TUHS] Determining what was on a tape back in the day

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

Tail for BASIC. On a slow printer or CRT, you could ^C and only see the 
last few lines. Better than printing out the entire thing from the 
beginning.

Or did it have a way of listing only a certain range of line numbers?



On 11/18/2017 6:16 PM, Don Hopkins wrote:
>
>> On 18 Nov 2017, at 23:37, Dave Horsfall <dave at horsfall.org 
>> <mailto:dave at horsfall.org>> wrote:
>>
>> On Sat, 18 Nov 2017, Don Hopkins wrote:
>>
>> (LISTREVERSE}
>>
>>> Chalk one up for DEC and BASIC. What other programming languages 
>>> support that feature, huh?
>>
>> You could probably do it in APL; you could do damned well everything 
>> else after all...[*]
>
> If you LISTREVERSE’ed a Lisp program, it would look like PostScript 
> with parens!
>
>>
>>> LISTREVERSE and LISTNHREVERSE print the contents of the user's 
>>> memory area in order of descending line numbers. LISTREVERSE 
>>> precedes the output with a heading, LISTNHREVERSE eliminates the 
>>> heading.
>>
>> Why on earth would you want to?
>
> I have been wondering about that for years.
>
> Here’s the manual! LISTREVERSE is documented on page 9-3. Maybe if I 
> printed out the "READERS COMMENTS" form at the back of the manual, 
> wrote my question in big upper case block letters, then ticked the "If 
> you require a written reply, please check here” checkbox, then “Fold 
> Here” and “Do Not Tear - Fold Here and Staple” as instructed, I could 
> mail in the free first class pre-addressed, business reply mail, no 
> postage stamp necessary if mailed inside the United States envelope, 
> and they’d write me back a nice letter telling me what the fuck they 
> were thinking.
>
> http://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/DEC-20-LBMAA-A-D%20BASIC%20User%27s%20Guide.pdf
>
> -Don
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/85be19a4/attachment-0001.html>

[TUHS] Determining what was on a tape back in the day

[Don Hopkins]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]


> On 18 Nov 2017, at 23:37, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Sat, 18 Nov 2017, Don Hopkins wrote:
> 
> (LISTREVERSE}
> 
>> Chalk one up for DEC and BASIC. What other programming languages support that feature, huh? 
> 
> You could probably do it in APL; you could do damned well everything else after all...[*]

If you LISTREVERSE’ed a Lisp program, it would look like PostScript with parens! 

> 
>> LISTREVERSE and LISTNHREVERSE print the contents of the user's memory area in order of descending line numbers. LISTREVERSE precedes the output with a heading, LISTNHREVERSE eliminates the heading.
> 
> Why on earth would you want to?

I have been wondering about that for years. 

Here’s the manual! LISTREVERSE is documented on page 9-3. Maybe if I printed out the "READERS COMMENTS" form at the back of the manual, wrote my question in big upper case block letters, then ticked the "If you require a written reply, please check here” checkbox, then “Fold Here” and “Do Not Tear - Fold Here and Staple” as instructed, I could mail in the free first class pre-addressed, business reply mail, no postage stamp necessary if mailed inside the United States envelope, and they’d write me back a nice letter telling me what the fuck they were thinking. 

http://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/DEC-20-LBMAA-A-D%20BASIC%20User%27s%20Guide.pdf <http://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/DEC-20-LBMAA-A-D%20BASIC%20User's%20Guide.pdf>

-Don

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171119/8513bb04/attachment.html>

[TUHS] Determining what was on a tape back in the day

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]

On Sat, Nov 18, 2017 at 4:07 PM, Will Senn <will.senn at gmail.com> wrote:

>
>> I thought disk (RK05) and tape (magtape) blocks were different...

​For simh they are, but not once UNIX sees them.​


Physically 7/9-tapes were variable formatt
​ed and could have multiple 'files' on them.  UNIX reveals all of this to
user (as do most OSs), so you need put in the simh 'virtual' tape format
support for the size of the 'blocks' and all of the extra things that the
HW supports.

But after the simh 'mounts' the 'virtual tape file' on the host when it
reads the 'tape', simh strips the meta-data out and presents on the blocks
to the OS. Or on write, simh takes the raw blocks, adds the simulated
metadata and writes that to host file system as a 'virtual tape file.'

In the old days disks physically could also be different formats.    But
the 'controller' was used to format the disk.   Each disk block included
metadata that the controller used.    On DEC (and most other systems of the
day), the disk controller had some way to set this up, usually with the
diagnostic system.   The OS saw the disk after formatting (as we do now).
 The diagnostics would have decided how big a block was etc...    DEC
standardized on 512 bytes per block.

simh could have taken the approach like disks, and then 'virtual disks'
would need the meta data; but could have supported all sorts of file
formats (like Apollo's and Xerox's).  But the simulated disk controller
would then need to handle the meta data.

Since, most OSs just looked at disk as 'block streams' simh only needs to
provide for the OS to work properly, is map a UNIX file of bytes into 512
byte blocks.   This works for most OSs.  As I said, it will not work for
Aegis or any of the Xerox systems which put some of what the OS normally
did in the microcode of the disk controller.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/2186d530/attachment.html>

[TUHS] Determining what was on a tape back in the day

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

On Sat, Nov 18, 2017 at 4:26 PM, Will Senn <will.senn at gmail.com> wrote:

>
> I'll look around. v6 tp was able to read the tape:
> set tc en
> att tc0 unix6.dat
> c
> # chdir /usr/6
> # tp t0
> speakez/sbrk.s
> dcheck.c
> ...
>
> the directories don't get created on extract, but that's typical on v6.
>
>
​I think that's one of the things that stp will do.

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/ede37022/attachment-0001.html>

[TUHS] Determining what was on a tape back in the day

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Sat, 18 Nov 2017, Don Hopkins wrote:

(LISTREVERSE}

> Chalk one up for DEC and BASIC. What other programming languages support 
> that feature, huh? 

You could probably do it in APL; you could do damned well everything else 
after all...[*]

> LISTREVERSE and LISTNHREVERSE print the contents of the user's memory 
> area in order of descending line numbers. LISTREVERSE precedes the 
> output with a heading, LISTNHREVERSE eliminates the heading.

Why on earth would you want to?

[*]
And the novice asked the master: "Master, does EMACS have the Buddha 
nature?"  The master thought for a while, and replied: "I don't see why 
not; it bloody well has everything else in it."

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Determining what was on a tape back in the day

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On Sat, 18 Nov 2017, Ronald Natalie wrote:

> We commonly used “ar” to write DECtapes (TU58) back in the day.  If the 
> first block has a list of filenames, I’m betting that’s what it is!

Or ye olde "tp" format?  'Twas the precursor of "tar", and I dimly recall 
that it was wriiten for the Ducktapes (our old 11/40 had just about 
everything except that).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Determining what was on a tape back in the day

[Warren Toomey]

On Sat, Nov 18, 2017 at 03:32:22PM -0600, Will Senn wrote:
>I don't see this file in the tuhs source code index (there are several 
>stp.c files but they don't appear to be tape related).

A long time ago I wrote some tools to extract files from tp and variant tp
archives: http://www.tuhs.org/Archive/Tools/Tapes/tp-progs.tar.gz

One may work as-is, or with some modifications!

Cheers, Warren

[TUHS] Determining what was on a tape back in the day

[Will Senn]

On 11/18/17 1:23 PM, Noel Chiappa wrote:
>      > From: Clem Cole
>
>      > stp is from the Harvard distribution.
>
> The MIT PWB1 system I have has the source; the header says:
>
>        M. Ferentz
>        Brooklyn College of CUNY
>        September 1976
>
> If it can't be found on TUHS, I can upload it.
>
> No man page, though. :-(
>
>     Noel

I don't see this file in the tuhs source code index (there are several 
stp.c files but they don't appear to be tape related).

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

[TUHS] Determining what was on a tape back in the day

[Will Senn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

On 11/18/17 12:57 PM, Clem Cole wrote:
> A quick look, and I think it's an stp (super TP) tape -- stp is from 
> the Harvard distribution.   This would make sense, because that was 
> the standard back before tar.
> As Ron pointed out, tp (which Ken designed for DECTapes originally) 
> puts the index at the head of the tape (tar and later cpis threaded 
> the index inline).   But it means its a fixed size and there were some 
> other issues (tp may have originally been in assembler IIRC).   On 
> DECtape, tp worked pretty well/was pretty cool because you could 
> update a block, less so on 9-track which when you re-wrote block N, 
> you lost all blocks afterwards.  Also, I don't remember why now 
> [probably the limits off the directory], but it was typically in those 
> days to take all the files in a directory, turn them into a foo.a (ar 
> format) archive.  So the stp image was a bunch of files: dir1/mumble.a 
>  dir2/grumble.a dir3/bumble.a ...
> You then needed to unarchive the files within each directory.   Also, 
> remember ar(1) when through some changes in format between 4-7th 
> editions as the compiler and linker matured.  So watch out on that 
> front too...
>
> Anyway, v6 tp probably will read it, but if you poke around the TUHS 
> and bitkeeper archives for the original Harvard distribution, stp.c 
> should exist.
>
I'll look around. v6 tp was able to read the tape:
set tc en
att tc0 unix6.dat
c
# chdir /usr/6
# tp t0
speakez/sbrk.s
dcheck.c
...

the directories don't get created on extract, but that's typical on v6.

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/25c533d8/attachment.html>

[TUHS] Determining what was on a tape back in the day

[Will Senn]

On 11/18/17 12:34 PM, Noel Chiappa wrote:
> If you look here:
>
>    http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#dumpf
>
> Try downloading it and compiling it - if it doesn't work, please let me know;
> it'd be worth fixing it so it does work on Linux.
Works fine. Thanks.
> The 0th block does seem to contain some PDP-11 binary - a bootstrap of some
> sort. I'll look in more detail in a bit.
Cool. I don't quite no how to investigate this other than to pore 
through the pdp11/40 instruction manual.
>  From what I can see, it's probably a tp-format tape: the 1st block contains
> some filenames which I can see in an ASCII dump of it:
>
>    speakez/sbrk.s
> ...
Well lookit that. I see it now, too :)
>      > v7 and look at its content using tm or tp, but then I realized that I
>      > didn't have a device set up for TU56
>
> You don't need to mount it on DECTape drive - it's just blocks. Mount it as
> an RK05 image, or a magtape, or whatever.
I thought disk (RK05) and tape (magtape) blocks were different...

Thanks,
Will


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

[TUHS] Determining what was on a tape back in the day

[Don Hopkins]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

Speaking of old BASIC interpreters, does anyone know out why DECSYSTEM 20’s BASIC had a “LISTREVERSE” command? 

Yes, it actually did exactly what it sounds like! 

Chalk one up for DEC and BASIC. What other programming languages support that feature, huh? 

https://imgur.com/a/Bt40M <https://imgur.com/a/Bt40M>

DECSYSTEM 20 BASIC User's Guide: LISTREVERSE command

LISTREVERSE
LISTNHREVERSE

LISTREVERSE and LISTNHREVERSE print the contents of the user's memory area in order of descending line numbers. LISTREVERSE precedes the output with a heading, LISTNHREVERSE eliminates the heading.

LISTREVERSE

EQUIV                              10:53                                       13-NOV-75

40    END
35    PRINT "THE EQUIVALENT CURRENT IS",I, " AMPERES"
25    I=E1/R
10    INPUT R
5     INPUT E1

READY

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/014a6735/attachment.html>

[TUHS] Determining what was on a tape back in the day

[Noel Chiappa]

    > From: Clem Cole

    > stp is from the Harvard distribution.

The MIT PWB1 system I have has the source; the header says:

      M. Ferentz
      Brooklyn College of CUNY
      September 1976

If it can't be found on TUHS, I can upload it.

No man page, though. :-(

   Noel

[TUHS] Determining what was on a tape back in the day

[Clem Cole]

A quick look, and I think it's an stp (super TP) tape -- stp is from the
Harvard distribution.   This would make sense, because that was the
standard back before tar.
As Ron pointed out, tp (which Ken designed for DECTapes originally) puts
the index at the head of the tape (tar and later cpis threaded the index
inline).   But it means its a fixed size and there were some other issues
(tp may have originally been in assembler IIRC).   On DECtape, tp worked
pretty well/was pretty cool because you could update a block, less so on
9-track which when you re-wrote block N, you lost all blocks afterwards.
 Also, I don't remember why now [probably the limits off the directory],
but it was typically in those days to take all the files in a directory,
turn them into a foo.a (ar format) archive.  So the stp image was a bunch
of files:   dir1/mumble.a  dir2/grumble.a dir3/bumble.a ...
You then needed to unarchive the files within each directory.   Also,
remember ar(1) when through some changes in format between 4-7th editions
as the compiler and linker matured.  So watch out on that front too...

Anyway, v6 tp probably will read it, but if you poke around the TUHS and
bitkeeper archives for the original Harvard distribution, stp.c should
exist.

On Sat, Nov 18, 2017 at 11:39 AM, Will Senn <will.senn at gmail.com> wrote:

> So, I came across this tape:
>
> http://bitsavers.trailing-edge.com/bits/DEC/pdp11/dectape/
> TU_DECtapes/unix6.dta
>
> I was curious what was on it,  so I read the description at:
>
> http://bitsavers.trailing-edge.com/bits/DEC/pdp11/dectape/TU_DECtapes.txt
>
> UNIX1       PURDUE UNIX TAPES
> UNIX2
> UNIX4
> UNIX6
> HARBA1      HARVARD BASIC TAPE 1
> HARBA2      HARVARD BASIC TAPE 2
> MEGTEK      MEGATEK UNIX DRIVER
> RAMTEK      RAMTEK UNIX DRIVER
>
> Cool, sounds interesting, so I downloaded the unix6.dta file and fired up
> simh - after some fiddling, I figured out that I could get a boot prompt
> (is that actually from the tape?) if I:
>
> set cpu 11/40
> set en tc
> att tc0 unix6.dta
> boot tc0
> =
>
> At that point, I was stuck - the usual tmrk, htrk, and the logical
> corollary tcrk didn't do anything except return me to the boot prompt.
>
> I was thinking this was a sixth edition install tape of some sort, but if
> it is, I'm not able to figure it out. I thought I would load the tape into
> v7 and look at its content using tm or tp, but then I realized that I
> didn't have a device set up for TU56 and even if I did, I didn't know how
> to do a dir on a tape - yeah, I know, I will go read the manual(s) in
> chagrin.
>
> In the meantime, my question for y'all is similar to my other recent
> questions, and it goes like this:
>
> When you received an unmarked tape back in the day, how did you go about
> figuring out what was on it? What was your process (open the box, know by
> looking at it that it was an x rather than a y, load it into the tape
> reader and read some bytes off it and know that it was a z, use unix to
> read the tape using tm, tp, tar, dd, cpio or what, and so on)? What advice
> would you give a future archivist to help them quickly classify bit copies
> of tapes :).
>
> Thanks,
>
> Will
>
>
>
>
>
> --
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171118/f2248bad/attachment-0001.html>

[TUHS] Determining what was on a tape back in the day

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

And the other more likely option is the “tp” command.   It too (unlike the later tar), put the filenames at the beginning of the tape.

> On Nov 18, 2017, at 1:37 PM, Ronald Natalie <ron at ronnatalie.com> wrote:
> 
> We commonly used “ar” to write DECtapes (TU58) back in the day.   If the first block has a list of filenames, I’m betting that’s what it is!
> 

[TUHS] Determining what was on a tape back in the day

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 151 bytes --]

We commonly used “ar” to write DECtapes (TU58) back in the day.   If the first block has a list of filenames, I’m betting that’s what it is!

[TUHS] Determining what was on a tape back in the day

[Noel Chiappa]

     > From: Will Senn

    > So, I came across this tape:
    > ...
    > I was curious what was on it

'od' is your friend!

If you look here:

  http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#dumpf

there's a thing which is basically 'od' and 'dd' rolled in together, which
allows you to dump any block you want in a variety of formats (ASCII, 16-bit
words in octal [very useful for PDP-11 binary], etc). I wrote it under CygWin,
for Windows, but it only uses the StdIO library, and similar programs (e.g. my
usassembler) written that way work fine under Losenux.

Try downloading it and compiling it - if it doesn't work, please let me know;
it'd be worth fixing it so it does work on Linux.


    > after some fiddling, I figured out that I could get a boot prompt (is
    > that actually from the tape?)

The 0th block does seem to contain some PDP-11 binary - a bootstrap of some
sort. I'll look in more detail in a bit.

    > I was thinking this was a sixth edition install tape of some sort, but
    > if it is, I'm not able to figure it out.

From what I can see, it's probably a tp-format tape: the 1st block contains
some filenames which I can see in an ASCII dump of it:

  speakez/sbrk.s
  dcheck.c
  df.c
  intel/as80.c
  intel/optab.8080


    > v7 and look at its content using tm or tp, but then I realized that I
    > didn't have a device set up for TU56

You don't need to mount it on DECTape drive - it's just blocks. Mount it as
an RK05 image, or a magtape, or whatever.


    > When you received an unmarked tape back in the day, how did you go about
    > figuring out what was on it?

Generally there would have been some prior communication, and the person
sending it would have told you what it was (e.g. '800 bpi tar', or whatever).

    > What advice would you give a future archivist to help them quickly
    > classify bit copies of tapes :).

Like I said: "'od' is your friend!"!! :-)

     Noel

[TUHS] Determining what was on a tape back in the day

[Will Senn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]

So, I came across this tape:

http://bitsavers.trailing-edge.com/bits/DEC/pdp11/dectape/TU_DECtapes/unix6.dta

I was curious what was on it,  so I read the description at:

http://bitsavers.trailing-edge.com/bits/DEC/pdp11/dectape/TU_DECtapes.txt

UNIX1       PURDUE UNIX TAPES
UNIX2
UNIX4
UNIX6
HARBA1      HARVARD BASIC TAPE 1
HARBA2      HARVARD BASIC TAPE 2
MEGTEK      MEGATEK UNIX DRIVER
RAMTEK      RAMTEK UNIX DRIVER

Cool, sounds interesting, so I downloaded the unix6.dta file and fired 
up simh - after some fiddling, I figured out that I could get a boot 
prompt (is that actually from the tape?) if I:

set cpu 11/40
set en tc
att tc0 unix6.dta
boot tc0
=

At that point, I was stuck - the usual tmrk, htrk, and the logical 
corollary tcrk didn't do anything except return me to the boot prompt.

I was thinking this was a sixth edition install tape of some sort, but 
if it is, I'm not able to figure it out. I thought I would load the tape 
into v7 and look at its content using tm or tp, but then I realized that 
I didn't have a device set up for TU56 and even if I did, I didn't know 
how to do a dir on a tape - yeah, I know, I will go read the manual(s) 
in chagrin.

In the meantime, my question for y'all is similar to my other recent 
questions, and it goes like this:

When you received an unmarked tape back in the day, how did you go about 
figuring out what was on it? What was your process (open the box, know 
by looking at it that it was an x rather than a y, load it into the tape 
reader and read some bytes off it and know that it was a z, use unix to 
read the tape using tm, tp, tar, dd, cpio or what, and so on)? What 
advice would you give a future archivist to help them quickly classify 
bit copies of tapes :).

Thanks,

Will





-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF