> From: "Stan Sieler" <sieler(a)allegro.com>
> To: "Douglas H. Quebbeman" <dquebbeman(a)acm.org>,
> "ClassicCmp List" <classiccmp(a)classiccmp.org>
> Date: Thu, 2 May 2002 12:06:37 -0700
> Subject: Re: Tape dumping programs for Unix/Linux...
> Cc: fmc(a)reanimators.org
> In-Reply-To: <000701c1f1e2$a795cd80$e401a8c0(a)tegjeff.com>
> Content-Transfer-Encoding: 7BIT
>
> Re:
>
> > The emulator community is vigorously using a tape image container
> > format known as TAP for precisely this purpose.
> >
> > Each record from tape is written to file prefixed *and* suffixed
> > by a four-byte record length in little-endian format. A zero-
> > length record is represented by a 4-byte value of zero; although
> > intuition might call for 8-bytes (a prefix & suffix with nothing
> > in between), this is not the case. The convention appears to come
> > directly from FORTRAN 77's handling of unformatted sequential files.
> >
> > And EOF is represented by two consecutive zero-length records.
>
> Darn...sounds like a subset of what I use. I'd be interested
> in knowing more about TAP (with an eye towards adopting use of it),
> and would suggest some possibly missing features might be:
Is there any more information on "TAP" other than the program that I
find with Bob Supnik's simh stuff, namely "mtdump" that produces
a "TAP" image given a list of files? It would be nice if someone else
had already written the program that reads a real physical magtape and
produces a "TAP" image.
carl
>The problem is that the popular U.S. vendors expend entirely too much of
>their
>resources on packaging, thinking, perahaps correctly, that it will help
>sales,
>but they forget, oir perhaps not, that the individualized packaging will make
>their systems difficult to upgrade over time, thereby making the long-term
>usefulness of considerably less value. Apple has taken this to the extreme,
>as only a vendor knowing he has a market segment to himself could do.
Most of the system manufacturers WANT to make it hard to upgrade the
system. They don't want you swapping parts to renew the life of your
machine... they want you to just buy a whole new machine every few years.
These upgrade impared designes are deliberate.
-chris
<http://www.mythtech.net>
>While the logical replacement has never been a problem, the rounded front
>that
>fits the case is a virtually impossible thing to replace by the time the
>drive
>needs replacment. They seem to require a rounded drawer front with no bezel
>of the drive. Whereas the bezel can be removed easily enough, finding a
>drive
>with that rounded front that fits, precisely, the slot in the plastic
>front-face of the box is a problem. The part number is seemingly never
>available more than 90 days after the computer is no longer an off-the-shelf
>item.
The last HP I had to do a CD swap on, I gave up finding a replacement
"HP" drive, and just found the same model Mitsumi drive, then swapped the
front bezel off the drawer. Of course, finding an 8x multi-year old
Mutsumi CD drive was a challenge in itself (I tried other Mitsumi's, but
on newer ones, and on every other CD drive I found, the drawer position
and or mounting clips had changed, so there was no way to align it or put
the old bezel on it).
One more reason I build my own PCs these days.
-chris
<http://www.mythtech.net>
> From: Raymond Moyers <rmoyers(a)nop.org>
> To: classiccmp(a)classiccmp.org
> Subject: Re: Tape dumping, bad blocks.
> Date: Fri, 3 May 2002 01:01:59 -0500
> In-Reply-To: <200205030508.BAA32513(a)conman.org>
>
>
> Funny, on the 9 track tape you dont confront this issue.
> 9 track tape is 8 bits + parity right ? so here a bad bit dont
> cause you to lose the ability to get the next byte and know
> that its a valid byte, a physical superiority it has over the
> serial streamers ?.
>
> Or am i assuming too much again.
I think you are assuming that there will never be a dropout over the
complete width of the tape. i.e. there will always be at least one
"1" bit passing the read head. Data clocking is essentially done
on the inclusive OR of all channels, so if they all drop out, you
have lost your place.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenstein(a)ucsd.edu
Sorry for being a bit off-topic....
I ran out of ports a few weeks ago so i am looking to buy a 4-5 port 10mbit
or so ethernet hub or switch. Contact me off-list.
Thanks,
Torquil MacCorkle III
Lexington, Virginia
So I finally got this TSZ07 that I've been wanting for a while so I can
archive a mountain of magtape I have (including System III sources for
the 11/780, on up to distro tapes of the 1990s). I can use dd to slurp
stuff off of tape, but it's tedious. What tools are people using for
tape archiving under Linux or Solaris? AIX seems to come with "tcopy"
that essentially pulls everything off the tape until logical or physical
EOT. I'm looking for something similar - point it at the drive and
siphon it on down.
At present, because of cable reach, I am talking to the tape drive
through an Adaptec AHA1460 PCMCIA SCSI interface on a Dell Latitude LM
running RedHat 5.2. I can address the drive fine and dump files with
dd and cat. I'm looking for a bulk data slurper, source or RH RPM. I'm
willing to throw this beast on the SPARCstation 5, but I'd rather not
put it in that corner just yet. At the moment, the drive is several
dozen times larger than the computer controlling it.
-ethan
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
To Wit
(about dd blocking handling)
The original need for dd came with the 1/2" tapes used to
exchange data with other systems and boot and install Unix
on the PDP/11.
Those days are gone, but the 9-track format lives.
To access the venerable 9-track, 1/2" tape, dd is superior.
With modern SCSI tape devices, blocking and unblocking are no
longer a necessity, as the hardware reads and writes 512-byte data blocks.
( what i was familiar with )
However, the 9-track 1/2" tape format allows for variable length blocking
and can be impossible to read with the cp command.
The dd command allows for the exact specification of input and output block
sizes, [[and can even read variable length block sizes, by specifying an
input buffer size larger than any of the blocks on the tape.]]
(Stan was right on target here eh ?)
Short blocks are read, and dd happily copies those to the output file
without complaint, simply reporting on the number of complete and short
blocks encountered.
Murphy's Law was postulated long before digital computers,
but it seems it was specifically targeted for them.
When you need to read a floppy or tape, it is the only copy in the
universe and you have a deadline past due, that is when you will
have a bad spot on the magnetic media, and your data will be unreadable.
To the rescue comes dd, which can read all the good data around the bad
spot and continue after the error is encountered. Sometimes this is all that
is needed to recover the important data.
Example dd bs=265b conv=noerror if=/dev/st0 of=/tmp/bad.tape.image
Yup .. using cat to do the same thing, it gets the err signal and
drops, but dd can be told to ignore it
So in this case its clearly superior, and the *only* tool for 9 track tapes,
( due to the block handling )
So i stand before you better educated. thx to those that filled in the
missing bits
Raymond
> Date: Thu, 2 May 2002 02:01:33 -0700 (PDT)
> From: Ethan Dicks <erd_6502(a)yahoo.com>
> Subject: Tape dumping programs for Unix/Linux...
> To: classiccmp(a)classiccmp.org
> Sender: owner-classiccmp(a)classiccmp.org
> Reply-To: classiccmp(a)classiccmp.org
>
>
> So I finally got this TSZ07 that I've been wanting for a while so I can
> archive a mountain of magtape I have (including System III sources for
> the 11/780, on up to distro tapes of the 1990s). I can use dd to slurp
> stuff off of tape, but it's tedious. What tools are people using for
> tape archiving under Linux or Solaris? AIX seems to come with "tcopy"
> that essentially pulls everything off the tape until logical or physical
> EOT. I'm looking for something similar - point it at the drive and
> siphon it on down.
Look for a program named "copytape". It copies tapes including the
block structure, file marks, etc. Unlike dd(1) which only really
works if all blocks are the same size and there is only one file
on the tape. It can copy tape-drive to tape-drive or tape-drive to
disk file, and puts markers in the disk file to indicate the
structure of the data on the tape.
Copytape is a "classic" piece of software, its source file begins as follows:
/*
* COPYTAPE.C
*
* This program duplicates magnetic tapes, preserving the
* blocking structure and placement of tape marks.
*
* This program was updated at
*
* U.S. Army Artificial Intelligence Center
* HQDA (Attn: DACS-DMA)
* Pentagon
* Washington, DC 20310-0200
*
* Phone: (202) 694-6900
*
**************************************************
*
* THIS PROGRAM IS IN THE PUBLIC DOMAIN
*
**************************************************
*
* July 1986 David S. Hayes
* Made data file format human-readable.
It should be available at numerous FTP sites.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenstein(a)ucsd.edu
> From: Raymond Moyers <rmoyers(a)nop.org>
> To: classiccmp(a)classiccmp.org
> Subject: Re: Tape dumping programs for Unix/Linux..
> Date: Thu, 2 May 2002 20:15:37 -0500
> In-Reply-To: <3CD16EDB.31791.1013160B@localhost>
>
> On Thursday 02 May 2002 18:52, you wrote:
>
> > Someone had copied a tape whose records were 16 KB long using software
> > that expected the records to be 8192 bytes longs ... and only asked
> > for 8192 bytes in each read() request.
>
> Now i really do find this interesting
>
> Lets scope out some examples to illustrate my focus.
>
> On a floppy or a hard disk as examples you have
> pad data inbetween its records these are usually
> all FF's constant stream on 1's in other words
> then an address mark like FE followed by the header data
> Head Sector Cylinder ,, then some more FF's then a start
> of data mark the block of data then the CRC .. then all
> else is ignored ,, be it artifacts from a prev write ( hub speed jitter )
> or whatever .. the controller is looking for its string of a minimum
> number of 1's then the FE and so it repeats all round the disk.
>
> During lowlevel formatting you are basically building an image
> of this track .. complete with the between sector filler of FFs
> amd dumping a whole track at once with the write track command.
>
> These devices are random access, but when you pull the image
> off the device using it as a streamer, you are not getting
> the filler bytes the address marks or the crc's your getting
> only the content of the sectors (soft physical records)
> back to back a raw spool off a unix device with a typical
> device driver gives you the data without the controler
> interested bits off the media.
>
> I would assume that any decent unix driver up to the minimal
> expectations of behavior should act the same, including
> that for a proper interface to a 9 track tape.
>
> If the record length is varible, then is not the record length
> in the block headder ? and should not the driver read
> that from the headder then xxx bits of data ?
No. You haven't been around tape drives long enough. The tapes
are not preformatted with block headers. They are written sequentially.
In general, a tape drive can only record forward and add data beyond
whatever has already been written.
> it would seem that any tape used as a random access
> block device, that ever had a record re written would
> have garbage (from a prev update of that record)
> in the block,
> just like on a floppy where this happens all the time,
> (jitter again) and the controller simply ignores looking
> for its resetting minimal number of FF's and the next
> address mark
Only some very special tapes with extra tracks for tape mark
information can be reliably used as random-access block devices.
The classic example is DECtape, 3/4 inch wide on 3 inch reels.
Pre-formatted into blocks of 129 12-bit words or other interesting
combinations.
> ( im ignoring the hard sector media with a hole for
> every sector, but it would still apply in this scope
> albeit a bit differently)
>
> Now .. excuse me, but ive been around this stuff
> for a long time, and i think ive got a really firm grasp
> of the minimal amount of things needed in place for
> any data-to-media, data-from-media scheme to work.
>
> So, do i have this right ?
No.
> That if i spooled off a 9 track tape, and assuming no
> non-recoverable media errors, that i would *not*
> get all of the data from all the records and without
> trailing garbage and the controler interested bits left out ?
Your tape-reading program might truncate all block lengths to
the length that it was "expecting". Or just quit after the
first file instead of reading all the files on the tape.
> Knowing the proper expected behavior of any unix
> driver i could name ... i find this rather ....
> well unexpected.
Nobody has said that Unix has well-designed tape drivers.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenstein(a)ucsd.edu
From: Cameron Kaiser <spectre(a)stockholm.ptloma.edu>
>> If a formula for determining classic computer cool factor gets finalized,
>> I'd like to create a calculator script on the VCF website so that people
>> can enter their parameters and have their score automatically computed.
>>
>> We need a unit or label for this number.
>
>The neuron.
Feh! Too common, everyone has a few many don't use them.
First it should be dimensionless, those are weird enough. If not then
like DB (DeciBell) which will give it a log or exponential character though
I'd be interested in seeing other oddly shaped numbers.
A possible name? Calcula with a range of values from microcalcula
(watch calc or smaller) to Kilo or maybe megacalcula(Sage! or other beast).
Allison
