24 Feb
2011
24 Feb
'11
12:14 p.m.
On 02/24/11 19:00, Al Kossow <aek at bitsavers.org> wrote:
On 2/24/11 2:58 AM, Philipp Hachtmann wrote:
Yes, but you need the clock track in order to write. So, read is
self-timed, and write is done with the help of the timing track.
And yes, the speed of the motor will affect how fast data comes in/out,
but only indirectly, since it's the clocking off the data from the tape
that matters. Tricks to increase speed would be to run an already
formatted tape faster or to format a tape at a slower speed.
Formatting a tape at a slower speed will also make it possible to fit
more data onto the tape (obviously).
> For me it sounds quite more interesting to
format a tape on a normal drive - and then use it on a drive which has been adjusted to
spin faster...:-)
>
It shouldn't matter over the range that the G888A can decode it. DECtape
uses Manchester encoding, so it is self-clocking. Head skew relative to the timing tracks becomes more
of an issue, but even that was mitigated by putting redundant tracks
on different parts of the tape and or-ing the heads together.
I'm not sure how much head skew could happen. The data from the tape is
read by just one head, with 10 tracks. So, the timing track is read at
the same point as the data.
You could possibly get some kind of skew if the signal was delayed
through the electronics.
The trick with holding your thumb on the reel became
necessary when DEC started shipping less tape on the reel than
certain PDP-8 operating systems expected.
Yes...
Johnny
24 Feb
24 Feb
3:27 p.m.
On 24 Feb 2011 at 21:14, Johnny Billquist wrote:
And yes, the speed of the motor will affect how fast
data comes
in/out, but only indirectly, since it's the clocking off the data from
the tape that matters. Tricks to increase speed would be to run an
already formatted tape faster or to format a tape at a slower speed.
I'd always assumed that the reason a relative shallow spool was used
is because the tape is reel-driven, sans capstans to assure a more-or-
less constant speed. Some sort of clocking mechanism (either with a
clock track or by modulation methods) would seem to be a necessity.
And it's also why you don't see 2400' DECtape reels...
Cheap Japanese portable tape recorders of about the same time also
used reel-drive; some even had rheostats to tweak the motor speed.
--Chuck
25 Feb
25 Feb
12:08 p.m.
I'd always assumed that the reason a relative
shallow spool was used
is because the tape is reel-driven, sans capstans to assure a more-or-
less constant speed. Some sort of clocking mechanism (either with a
clock track or by modulation methods) would seem to be a necessity.
And it's also why you don't see 2400' DECtape reels...
Cheap Japanese portable tape recorders of about the same time also
used reel-drive; some even had rheostats to tweak the motor speed.
The HP9865 (I assume), internal cassette drive of the HP9830 (and I
asusme 9821) and other machines using a simialr mechanism (such as the
Racal P72 Digideck) were spool-drive only. The Racal manual claims this is
a beneifit since it reduces tape wear. Hmmm...
Anyway, these units use something called BMS encoding (Bit-Mark Sequence,
I believe). There are 2 tacks on the tape. A '1' bit is a pulse on one of
the tracks. A '0' bit is a pulse on the other track, A byte marker is a
pusle on the 2 tracks simultaneuosly. Obviously this is self-clocking, so
tape speed doesn't matter too mach.
AFIk, HP put a marker at the start of every (9 bit) word on the tape,
Racal put one on the start and end of every word. So words on a Racal
tape have 2 markers between htme, on an HP tape only one.
Th 9 bit words is the 8 bits of the'user byte, and a flag bit. The latter
is in the middle of the worf, and is set to indciate file markes and the
like. Putting it in the middle means it's in the same position relative
to the amrkers no matter which way yhr tape is movign, so you can scan
for file markers in either direction.
-tony
5049
days inactive
5050
days old
2 comments
3 participants
participants (3)
-
ard＠p850ug1.demon.co.uk -
bqt＠softjar.se -
cclist＠sydex.com