scw%ucla-locus@cepu.UUCP (01/28/84)
From: Steve Woods <cepu!scw@ucla-locus>
Well, if you really want to be diskgusted (Ha,Ha) I recall one day watching
a friend of mine running OS\8 on a PDP-12, using a TU-10 as the masstorage
device. Talk about a HACK. Talk about writing a driver in 2 128 word (12 bit)
pages. Talk about *SLOWWWWWWWWWWWWW*. But it was interesting. (Actually the
tape came from a ?system? that was a PDP-8e with only a TU-10, he was copying
some FORTRAN code from our PDP-12).
--
I am, y'r obd't s'vt
Stephen C. Woods
(VA Wadsworth Med Ctr./UCLA Dept. of Neurology)
uucp: ...{ hao, trw-unix, sdcsvax!bmcg}!cepu!scw
ARPA: cepu!scw@ucla-locus location: N 34 06'37" W 118 25'43"Little.Fleas%hi-multics@sri-unix.UUCP (01/30/84)
From: Gary Little <Little.Fleas@hi-multics> My my my, such terrible horror stories. The REAL programmer however remembers running multi pass assemblers on punched cards (disk whats a disk) and HIS mentor used 60 wpm paper tapes. Complain about DEC-tapes or floppies, remember there are slower things.
guy%ucla-locus@sri-unix.UUCP (02/01/84)
From: Richard Guy <guy@ucla-locus>
There were (still are?) storage devices/techniques slower than DECtapes.
However, I can't recall hearing of anyone trying to run a multi-user timesharing
system from cards or paper tape. (swapping??? demand paging??? random access
files???) The original issue being addressed was the truth of rumours about
people running UNIX, etc, on tape-only systems.
richard
ps Come to think of it, if one had a fancy enough card sorter/collater combined
with a reader/punch, one could mimic a DECtape, modulo a few orders of
magnitude with respect to time.ddc@druky.UUCP (Custer) (02/04/84)
This is a true story, even though some folks might think its in "The first guy hasn't got a chance!" cagegory. In the late 60's, before the advent of OS8, DEC had a DOS. This dos used DF-32 disk drives. 32k of 12 bit words! I was a grad student at University of Colorado, Boulder, at the time & was doing some work at LASP (Laboratory for Atmospheric and Space Physics, I think). They had a an original (transistor, not IC) PDP-8. This PDP-8 had 4k memory, a Teletype ASR33 jimmied up so the computer could control (turn on or off) the paper tape reader (10 cps), a 12 bit AD converter, and a 7 track mag tape (you know, the predecessor to a 9 track tape). (Back then the characters were 6 bit, the tape wrote one char plus parity). The machine was a $100,000 analog to digital converter. The mag tapes were hand carried to an IBM 4044 (later a CDC 6400) for analysis. I got tired of assembly language programming on it (paper tape at 110 baud!). Two pass assembler (read the tape twice) object on paper tape, core image executable on paper tape. YUK! To make a looooong story short, I developed a scheme for random access on the 7 track, including read after write (couldn't be done, **they** said). Then I managed to get my hands on the source for DOS (including a funny FORTRAN-II like compiler). All it needed was a disk emulator for the mag tape! In 1 plus page of 128 words! I'll never forget the time it first ran. The scientist in charge of the machine (Jeff Pierce, Where Are You?) happened to be showing the lab to a visitor. The system booted, and started searching the tape for the SAM block(s) so it could swap itself out. It was really dramatic (real sloooow too, as it did almost as many backspaces as it did forward moves). I explained to Jeff and his visitor that the OS was searching the tape for a place to swap on, and to load the command line interpreter. Jeff was awestruck. He muttered something to the effect, "Can you imagine a 12 bit computer doing that!?" Even tho it was slow, it was **MUCH** better than paper tape on an ASR33 TTY. I left shortly thereafter, but before I did I noticed that the PDP-8 got an increment of memory (for a total of 12K, I believe), a pen plotter, a disk, and lots of other goodies. Turned it into a real computer, by golly. Published the scheme in a DECUS proceeding. The chairman introduced my talk with the statement that it really worked: he knew because he didn't believe it until he tried it on his machine! It's interesting how people accept as gospel "conventional knowledge." The conventional knowledge of the time was that you couldn't read after write on an "industry standard" i.e., 7 track 1/2 inch, mag tape, that you couldn't random access info on a mag tape, that you couldn't write in the middle of a tape without destroying all the information after the write, etc. It was true too -- if you orgainized the tape in the conventional way. Of course, the inventor of DecTape knew better. All I did was adapt the algorithms of DecTape to a 1/2" 7-track mag tape. The only trick was to get the tape driver to fit into < 128 machine instructions! David Custer AT&T ISL, Denver druky!ddc (303) 538-3517
rpw3@fortune.UUCP (02/07/84)
#R:druky:-60800:fortune:26900023:000:1954
fortune!rpw3 Feb 7 04:45:00 1984
And I'll bet a nickel that the chairman of the session who
introduced Dave Custer to give that paper was John Alderman,
who never quit bragging about doing it too!
If Dave's scheme was the same one, it involved pre-formatting
the tape with short block headers alternated with longer data
blocks, with extended erase gaps after the data part:
<header1> <gap> <data1> <long gap> <header2> <gap> <data2> <long gap>...
You search for the header part (ignoring read errors but checking
block numbers of good headers in case you overshot), then immediately
turn on the write gate to write the data part. (The turnoff trash
ends up being short-gap written on top of long-gap. No problem.)
While working for John in 1971, we built a cassette tape controller
(Sykes tape) to run O/S-8 (for the PDP-8/e) on Phillips cassettes.
It ran, quite well in fact. About as fast as slow floppies.
It used similar formatting principles to the magtape scheme.
The controller was a micro-coded state machine using a hardwired
matrix of 7405 open-collector gates as a ROM! (Field blastable ROMs
didn't exist yet.) Was my first introduction to metastable logic
bugs. (Hours in front of a scope listening to the tape go "click,
hiss, whirr, click, hiss, click,...<silence>" hoping to see the
25ns glitch when the micro-PC on the controller got zapped causing
silent death.)
The trick to the controller was that the system device driver in O/S-8
has to fit in 92 (decimal) 12-bit words, thus the controller had to have
some smarts. (The boot code was 6 words, hand keyed!) One PDP-8 I/O
command ("SYBOOT") would halt the tape, wait until halted, rewind, wait
for clear leader, halt, wait 'til halted, go forward normal, wait until
non-leader, start data read. One instruction. (The other 5 were simpler.)
Rob Warnock
UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065ajs@hpfcla.UUCP (02/12/84)
Time to jump into this one...
The HP-UX/9000 Series 500 allows you to treat Linus tape drives (built
into the 7908/11/12/14 Winchester discs) as block devices. You can
initialize a short (~17Mb) or long (~65Mb) tape and then mount it!
We use this feature for system distribution. To install a new system,
you boot from the tape and run with it as your root volume. It's
sslloowww but it's effective.
Not only that, but in emergencies you could boot off such a tape and use
it to repair a trashed disc (never happens in real life, of course...)
Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado
{ihnp4 | hplabs}!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"donn@hp-dcd.UUCP (02/14/84)
I tried (under duress) using a 7 track as a disc, but it didn't work. The problem was the well known "crap in the gap" problem. SOME tape drives are accurate enough that they don't generate crap in the gap, and SOME are tolerant enough to skip over the crap, but don't count on it. DecTapes have a "clock track" that is written "once" and used to clock the bits onto the tape so that physical block length doesn't vary from write to write. The clock on 7 track tape is taken from the OR of the 7 bits so if the capstan slips a bit, so do the bits. Did you ever try taking moving one of those tapes from one drive to another; not really likely to work. Forget about ever getting a CDC 6400 (at least early '70s vintage) to read such a tape; they had a real problem with crap in the gap. Donn Terry hplabs!hp-dcd!donn
ddc@druky.UUCP (CusterDD) (02/16/84)
What donn@hp-dcd says is quite right about "crap in the gap" and associated problems with timing and skew if you use conventional methods. The solution I published was to pre-record the tape with blocks separated by hardware tape marks. Each block had a header id record and a data record, somewhat like a soft-sectored floppy has nowadays. The key was the grossness of the tape (eof) mark -- 3 **inches** of blank tape (erased) followed by a special character. Regular inter-record gaps were used only between the header record and the data record within a block. Once the block was recorded, the header was never over-written (at least not intentionally :-) ). The grossness of the tape mark allowed the drive to make all its dirties in the 3" gap after a write. Since the normal irg was only about 1" this left 2" for "crap in the gap", timing/speed errors, etc. Actually, tape stretch increased the margin for error. This scheme worked for both the top-of-the line controller and the bottom-of-the-line. Had no trouble with it at all. Except for speed, it was a reasonably good system for the time. It was **much** slower than DECtape. Much better than paper tape! Over the years I got two inquiries from interested parties via DECUS, so you can see that it wasn't wildly popular, but then those tape drives cost more than the DF-32s, **alot** more. To give you an idea of the situation, the tape controller we had occupied most of a 6 foot high rack (SSI? heck, no! Transistors! discrete components, and the like. 2 flip-flops per pc card.) The tape control was about 4 times the size of the PDP-8 CPU. The bottom-of-the-line control used what dec called the 3 cycle DMA of the PDP-8, which means it used the CPU to keep track of the word count, and addresses. Not this baby though! It used the single cycle DMA, which meant it had to have its own accumulators for word count and addresses, as well as function registers, etc. On the basis of sheer size it would seem that it had more logic in it than the CPU! In any event both controls would successfully wade thru the "crap in the gap" and find the tape mark. Sometimes the status register would indicate parity error and sometimes not. I didn't care, just reset it and go. Sure was nice to have FORTRAN II and no paper tape to edit, splice and keep the programmer busy till 4AM! Incidentally, if anyone is really interested in all the gory details, its in either the 1968 or 1969 Proceedings of the DECUS Fall Symposium, 1969 I think. Held in Las Vegas. DEC had a PDP-12 on demo there that year. Couldn't get next to it because someone had programmed it to allow two users to play space wars (against each other). Boy, was it neat! Ain't reminiscing fun! :-) If you are really, REALLY interested in all the gory details and you can't find the opus cited (which is probably quite likely since most have probably crumbled to dust by now :-) ), let me know, and for only an arm and a leg, I'll dig thru the mold in my basement & see if I can find my copy. David Custer AT&T Information Systems Labs, Denver druky!ddc (303) 538-3517