Last drum based computer?
Todd Enders A262 857-3018
I just got to wondering... When was the last computer produced that relied
on drum memory for the majority of it's storage? Also, anybody know what
the smallest drum based machine was (Litton ????, or ????) Thanks!
GUNNAR HORRIGMO
I think my memory has grown a bad block, or I have a parity error or
something.. I seem to remember quite clearly from last year studies that
drums are disks, not memory..
[sigh]
well well...
MAIL-mail: gun...@sofus.dhhalden.no SNAIL-mail: Gunnar Horrigmo
gun...@fenris.dhhalden.no Oskleiva 17
N-1772 Norway
----------------------------------------------------------------------
Disclaimer: The above posting may seem like insignificant rubbish at
first glance, but if you read between the lines, you will be
surprised to discover the annals of Burt Bacharach, world peace,
Oxford Advanced Readers Dictionary, quantum physics made easy, and an
easy-to-use step-by-step walkthrough on how to make a time travelling
device that actually works.
Adam Justin Thornton
>I think my memory has grown a bad block, or I have a parity error or
>something.. I seem to remember quite clearly from last year studies that
>drums are disks, not memory..
Hmph. Newbie. Mel would beg to differ.
Adam
--
ad...@rice.edu | These? Rice's opinions? Yeah, right. | "Might there have
been fewer crimes in the name of Jesus, and more mercy in the name of Judas
Iscariot?"--Thomas Pynchon | "This is not an assault."--FBI to David Koresh,
as they broke holes in the wall and began firing in teargas. | 64,928 | Fnord
Mark Hittinger
> I just got to wondering... When was the last computer produced that relied
>on drum memory for the majority of it's storage? Also, anybody know what
>the smallest drum based machine was (Litton ????, or ????) Thanks!
The last machine I can remember working with that had a real live drum was
an HP-2000C' 32k timeshared basic box. It used the drum for swapping in
an out of some high speed ram memory, the rest of the 32k was core.
It was a fairly hot box for its day. This was in the early 1970's say
around '72.
---------
Whats back with the wrong-ups?
Mr J L Saunders
%something.. I seem to remember quite clearly from last year studies that
%drums are disks, not memory..
Wrong! Drums are memory, and were used before memory was made in silicon.
J.
--
Jason L Saunders [ RouE ]
email: ma...@csv.warwick.ac.uk
snail: Warwick Business School, University of Warwick, Coventry CV4 7AL, UK
"At least you know a sicko's committed"
Dan Prener
> In article <ENDERS.93A...@warp6.cs.misu.NoDak.edu> end...@warp6.cs.misu.NoDak.edu (Todd Enders A262 857-3018) writes:
> > I just got to wondering... When was the last computer produced that relied
> >on drum memory for the majority of it's storage? Also, anybody know what
> >the smallest drum based machine was (Litton ????, or ????) Thanks!
> I think my memory has grown a bad block, or I have a parity error or
> something.. I seem to remember quite clearly from last year studies that
> drums are disks, not memory..
The IBM 650 used a drum for its memory.
--
Dan Prener (pre...@watson.ibm.com)
Hugh JE Davies
I worked on ITT3200 machines in 1975/6 that used drums as their sole
backing store. Booted from paper tape after you'd keyed in a bootstrap
on the front panel. Ah, nostalgia isn't what it used to be, is it?
Ob-f.l.: The first time I ever tried to boot one of these machines
myself (bearing in mind that I was a trainee programmer just graduated
with a haircut and a shiny new degree. In Biochemistry) I had considerable
trouble. Firstly, I hadn't yet memorised the bootstrap, so I had to
painfully key it in from a sheet of paper. I inserted the paper tape in
the reader, hit RUN on the front panel, and the machine promptly spat
the tape backwards out of the reader, which then sat there spinning its
little rubber wheels. So I halted it, keyed in the bootstrap again,
reloaded the tape, hit RUN, and the damn thing did exactly the same again.
After repeating the fruitless exercise 3 more times, I swallowed my pride
enough to ask. The damn bootstrap ran the tape *backwards* until it
reached a delete character, then forwards looking for the code. I hadn't
put the tape far enough into the reader, and it didn't find any deletes
before it spat the tape out.
---
Regards,
Hugh.
------------------------------------------------------------------
Huge...@rx.xerox.com Rank Xerox Technical Centre, WGC, UK.
I don't speak for Xerox, nor they for me.
"If there is anyone here who I have not insulted, I beg his
pardon." Johannes Brahms (1833-97).
Tom F Karlsson
> Wrong! Drums are memory, and were used before memory was made in silicon.
True !. RAMs, disks, floppies, tapes and papercards are all memory. They
just differs a bit when it comes to access time and how the fysically looks...
(sometimes abstractions is a good thing :-)
/Tom
--
| Tom Karlsson email: to...@meryl.csd.uu.se phone: +46 18 260097 |
| student of computer science @ Uppsala University, Sweden. |
| member of Update. |
| "Intelligence is to do stupid things in a smart way" |
Magnus Olsson
>In article <1r56ll...@clover.csv.warwick.ac.uk> ma...@csv.warwick.ac.uk (Mr J L Saunders) writes:
>
>> Wrong! Drums are memory, and were used before memory was made in silicon.
>
>True !. RAMs, disks, floppies, tapes and papercards are all memory. They
>just differs a bit when it comes to access time and how the fysically looks...
>(sometimes abstractions is a good thing :-)
On that level, it's of course trivially true. However, I think we're
having some linguistic confusion on top of the technological confusion
here:
In Swedish, one usually talks about "primary memory" (what's called
"core" in the Unix world, even though it's normally CMOS DRAM
nowadays), as opposed to "secondary memory" (disks, tape, CD-ROM, you
name it).
In English, however, "memory" is usually used only about the primary
kind, while the secondary "memory" is called "storage". So normally, a
floppy wouldn't be "memory", but "storage".
The posts that started this thread said basically
"Which was the last computer to use drum memory" and
"A drum is not memory" (i.e. it's storage)
To put things straight once and for all:
Yes, Virginia, there *were* computers that used a magnetic drum for
primary memory. (I'm too young ever to have seen one in real life,
alas). For example, the first computer here in Lund, SMIL, originally
had a 2048 word * 40 bits drum memory as its sole RAM. The secondary
storage was in the form of punched tape. The drum was later replaced
by a 4096-word ferrite core memory (which was so big that it didn't
fit through the door, but they had to make a large hole in the wall to
get it in).
Magnus Olsson | \e+ /_
Department of Theoretical Physics | \ Z / q
University of Lund, Sweden | >----<
mag...@thep.lu.se, the...@selund.bitnet | / \===== g
PGP key available via finger or on request | /e- \q
Doug Ayen
>In article <ENDERS.93A...@warp6.cs.misu.NoDak.edu> end...@warp6.cs.misu.NoDak.edu (Todd Enders A262 857-3018) writes:
>> I just got to wondering... When was the last computer produced that relied
>>on drum memory for the majority of it's storage? Also, anybody know what
>>the smallest drum based machine was (Litton ????, or ????) Thanks!
>>
>>Todd end...@warp6.cs.misu.nodak.edu
>>
>I think my memory has grown a bad block, or I have a parity error or
>something.. I seem to remember quite clearly from last year studies that
>drums are disks, not memory..
Actually, as I remember it, *REAL* old-time computing did use drums for
memory. As in the IBM 650--it would write memory on a small, rapidly
rotating drum, and then read off the data when it needed it to compute
something. This resulted in such things as hand-hacking the program
structure so that it used the drum memory to its highest efficiencty--such
that when one operation finished, and the computer needed the next op.,
the programmer could arrange things such that the stored operation would
be right under the read head at that moment--instead of it having to wait
for the drum to come around one more time.
Remember, at one point people thought that "core" was way too expensive
for most people, and that it would never catch on....
________________________
ay...@panix.com Work: 212 973-6759
Being mad keeps me from going insane. Home: 914 225-1725
Bob S.- Contractor
Todd end...@warp6.cs.misu.nodak.edu
The last computer to use a drum for main memory was the Univac SS-80.
SS is for solid state. There was also a SS-90, which processed the
Univac 90-column cards. The IBM 650 was the first computer to use a
drum for main memory. Programming the SS-80 was tricky. You had to
space the program instructions so that you would not lose a drum
revolution between steps. It was called interleaving. Finally,
someone produced an assembler to do this automatically. The SS-80
computers replaced a lot of 650s, then the IBM 1401 and
Honeywell 200 replaced most of the drum machines.
Drums were (are?) also used as storage like disks. Even the early drums
used in the SAGE computers in the 50s were faster (10 ms access)
than todays disk drives. They had a head for every track, took up a lot
of space and were expensive. Any more drum veterans out there?
Sabu
Steve Froeschke
And I used to operate a GTE IS-1000 that used a drum. Then they finally
upgraded the drum to SSD. Ah, those were the days. (This was circa
1982). They switched to SSD around 1990 or so.
Steve
John Lamp
> I just got to wondering... When was the last computer produced that relied
>on drum memory for the majority of it's storage? Also, anybody know what
>the smallest drum based machine was (Litton ????, or ????) Thanks!
God, I know people near here _still_ using Quantel's with drums!
Cheers
John
--
_--_|\ John Lamp, originating in Hobart, Tasmania
/ \ Phone: 002 23 1366 - Fax: 002 34 5685
\_.--._/ email: jw_...@postoffice.utas.edu.au
v <-----------------------------------------------------
Joe Vigneau
computer with drum storage/memory.)
How large was one of these drums?
--
/ _ __ / jvig...@cs.ulowell.edu
<_/ <_> <-' / WPI - Class of '97 - Computer Science
Dan Prener
> (Being a member of the "next generation", I have never seen a
> computer with drum storage/memory.)
> How large was one of these drums?
I don't know whether you mean the physical size or the storage capacity, but
the ones I remember had storage capacities such as 2000 words of 10 decimal
digits each, or 4096 words of 32 bits each. The physical sizes were something
like 12" long and 8" in diameter, but this part of my recollections is much
fuzzier, and more likely to be wrong.
--
Dan Prener (pre...@watson.ibm.com)
Sam Drake
fast-disks, but ... when was the last time you saw a drum being used as
a fast disk? The last one I saw was retired in 1985; several drums were
being used as 1st level paging devices on a mainframe at that date. And
gee, each one was 2 meters tall, weighed over a ton, and provided a whole
8 MEGAbytes of storage! (sigh)
Keith Willis
DP> > I think my memory has grown a bad block, or I have a parity error or
DP> > something.. I seem to remember quite clearly from last year studies that
DP> > drums are disks, not memory..
DP> The IBM 650 used a drum for its memory.
Hmmm... must be talking at cross porpoises here ;-)
One of the earlier places I worked used a Xerox Sigma 8
machine which used a mag drum as permanent storage, in the
manner of a disk.
---
. PQ 2.15 194 . . If Thy Brother Offends Thee, Pluck Out His Eye! .
Juergen Nickelsen
> I think my memory has grown a bad block, or I have a parity error or
> something.. I seem to remember quite clearly from last year studies that
> drums are disks, not memory..
I remember vaguely reading about the austrian "Mailuefterl", which
used drum storage not only for memory, but also as CPU registers, in
the early 50s.
--
Juergen Nickelsen
Reinhard Kirchner
> In article <gunnarh.62...@dhhalden.no> gun...@dhhalden.no (GUNNAR HORRIGMO) writes:
>
>> In article <ENDERS.93A...@warp6.cs.misu.NoDak.edu> end...@warp6.cs.misu.NoDak.edu (Todd Enders A262 857-3018) writes:
>
>> > I just got to wondering... When was the last computer produced that relied
>> >on drum memory for the majority of it's storage? Also, anybody know what
>> >the smallest drum based machine was (Litton ????, or ????) Thanks!
>
In 1970 the University of Karlsruhe got a Univac 1108, which had drums
of 256kW and 1MW for swap space ( 1W = 36 bit ), and the socalled
Fastrand drums for mass storage. These where lying, appr. 2 m long., with
moving heads. I don't know the capacity anymore... Two of these where housed
in one man high cabinet. Each head moved accross 64 tracks.
Reinhard Kirchner
Univ. of Kaiserslautern, Germany
kirc...@informatik.uni-kl.de
Reinhard Kirchner
> Actually, as I remember it, *REAL* old-time computing did use drums for
> memory. As in the IBM 650--it would write memory on a small, rapidly
> rotating drum, and then read off the data when it needed it to compute
> something. This resulted in such things as hand-hacking the program
> structure so that it used the drum memory to its highest efficiencty--such
> that when one operation finished, and the computer needed the next op.,
> the programmer could arrange things such that the stored operation would
> be right under the read head at that moment--instead of it having to wait
> for the drum to come around one more time.
This was the case in Zuse Z22 and Z23 also, there where 8k words of 38 or 40
bit on the drum, registers where in a 32 or 256 word core. I still keep
music playing programs, which did generate tones by tricky jumping around
the drum. Each access generated a pulse in the console speaker...
Reinhard Kirchner
Garrett Wollman
>In 1970 the University of Karlsruhe got a Univac 1108, which had drums
>of 256kW and 1MW for swap space ( 1W = 36 bit )
So that's why the swap device on my system is called /dev/drum!
Except, it's not that old! Here's what my manual page under 386BSD
says (note the HISTORY section):
DRUM(4) 386BSD Programmer's Manual DRUM(4)
NAME
drum - paging device
DESCRIPTION
This file refers to the paging device in use by the system. This may ac-
tually be a subdevice of one of the disk drivers, but in a system with
paging interleaved across multiple disk drives it provides an indirect
driver for the multiple drives.
FILES
/dev/drum
HISTORY
The drum special file appeared in 3.0BSD.
BUGS
Reads from the drum are not allowed across the interleaving boundaries.
Since these only occur every .5Mbytes or so, and since the system never
allocates blocks across the boundary, this is usually not a problem.
4th Berkeley Distribution March 28, 1991 2
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wol...@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman | It is a bond more powerful than absence. We like people
UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant
Donald Jardine
pre...@watson.ibm.com (Dan Prener) writes:
`:
>
>> How large was one of these drums?
>
>I don't know whether you mean the physical size or the storage capacity, but
>the ones I remember had storage capacities such as 2000 words of 10 decimal
>digits each, or 4096 words of 32 bits each. The physical sizes were something
>like 12" long and 8" in diameter, but this part of my recollections is much
>fuzzier, and more likely to be wrong.
>--
biquinary notation (total of 6 bits to represent digits 0-9), and
was of the size noted by Dan Prener. I worked on a 650 in 1956, and remember
many hours of console debugging :-).
Tom Van Vleck
> The IBM 650 drum was indeed 200o words of 10 decimal digits each, using a
> biquinary notation (total of 6 bits to represent digits 0-9), and
> was of the size noted by Dan Prener. I worked on a 650 in 1956, and remember
> many hours of console debugging :-).
My summer job in 1962 was at Univeral Oil Products in Des Plaines IL.
We had an IBM 7070, which was a "solid state 650." It used transistors
instead of tubes and core instead of drum. The 7070 had 10,000 words,
each ten decimal digits plus a sign (positive, negative, or alpha).
Each digit was in biquinary, represented by 5 cores coded 2 on, 3 off.
The machine stopped dead if a 2-out-of-5 check failed.
Other unusual features: 3 accumulators, 99 index registers; the
registers were memory mapped, as was the PC. Index registers had both
a count and limit field. It filled a big room.
We ran a lot of 650 simulator jobs; reassembling them to use the "awesome"
power of the 7070 would speed them up by a factor of 10 or so. We had no
disk on the machine, only tape: a wizard programmer at UOP wrote a package
that simulated a disk by shuttling data between tapes, writing in the
middle of (200 BPI) tape protected by generous guard bands. It worked
fine until the humidity got too high, & then would say
UNRECOVERABLE SON OF RAMAC ERROR - RERUN JOB
Paul Ciszek
>In article <gunnarh.62...@dhhalden.no> gun...@dhhalden.no (GUNNAR HORRIGMO) writes:
>%something.. I seem to remember quite clearly from last year studies that
>%drums are disks, not memory..
>Wrong! Drums are memory, and were used before memory was made in silicon.
And back then, memory was MEMORY-- It didn't go away when you turned the
power off.
David Breneman
:
: Wrong! Drums are memory, and were used before memory was made in silicon.
:
Anybody know the last machine to use mercury-tube memory?
--
David Breneman
System Administrator, Software Engineering Services
Digital Systems International, Inc.
Email: da...@jaws.dgtl.com Voice: 206 881-7544 X-2289 Fax: 206 556-8033
Charles Lasner
>In article <gunnarh.62...@dhhalden.no> gun...@dhhalden.no (GUNNAR HORRIGMO) writes:
>
>>I think my memory has grown a bad block, or I have a parity error or
>>something.. I seem to remember quite clearly from last year studies that
>>drums are disks, not memory..
>
>Hmph. Newbie. Mel would beg to differ.
>
>Adam
To make matters more confusing, some spinning media have brakes. Some drums
have disk brakes and some disks have drum brakes.
To help the guy out, and because Mel isn't available:
Early computers used all sorts of technology to implement main memory. Some
popular computers used what we would today call a drum or disk rotating memory
as the main memory. Thus, a program not only had to be written at all, it
also had to have its code addresses dealt with, because the next instruction
after the latest one will not be read until it passes under the read head
of the rotating memory. Each instruction indicated where the next instruction
was. In effect, a NOP was a jump instruction, etc.
The Mel story in part has to do with a programmer who bothered to hand-optimize
the ordering of the instructions in his program to gain a faster-than otherwise
available running speed as compared to the results of an existent utility which
was known to produce mediocre results as compared to the hand placement of
instructions, etc. Note that the optimization is totally model-dependent as
well.
cj "I use core myself" l
Robert Bernecky
>In article <ENDERS.93A...@warp6.cs.misu.NoDak.edu> end...@warp6.cs.misu.NoDak.edu (Todd Enders A262 857-3018) writes:
>
>> I just got to wondering... When was the last computer produced that relied
>>on drum memory for the majority of it's storage? Also, anybody know what
>>the smallest drum based machine was (Litton ????, or ????) Thanks!
>
>
>
I used a Burroughs 205 at Linde Air in Townawanda, New York, back in
1965-67. It used drum for mainstore. It, too, used instruction scheduling
to arrange instructions around the drum so that there was no delay
(well, less delay...) waiting for the next instruction to roll around
on the guitar, err drum, after the first one executed. So, you see,
instruction scheduling is NOT a new thing.
The main thing I did with the 205 was work with Paul Mundt on a
B205 simulator for the shiny new IBM 360/40 (256K of mainstore! WOW!).
Once we got the simulator working, and had a spooling system running
to read the programs off cards rather than paper tape, it ran several times
faster than the B205. The main advantage was overlapped I/O, but
distillation column design and molecular sieve designs went faster, too,
I believe.
Bob
Robert Bernecky r...@yrloc.ipsa.reuter.com bern...@itrchq.itrc.on.ca
Snake Island Research Inc (416) 368-6944 FAX: (416) 360-4694
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9
Canada
Neville Holmes
>Actually, as I remember it, *REAL* old-time computing did use drums for
>memory. As in the IBM 650--it would write memory on a small, rapidly
>rotating drum, and then read off the data when it needed it to compute
>something. This resulted in such things as hand-hacking the program
>structure so that it used the drum memory to its highest efficiencty--such
>that when one operation finished, and the computer needed the next op.,
>the programmer could arrange things such that the stored operation would
>be right under the read head at that moment--instead of it having to wait
>for the drum to come around one more time.
Assembly Program, where the optimum referred to placement of the instructions
around the drum. It did it well - no hand-hacking needed. Perhaps it would
make it plainer to explain that every machine instruction had the address of
the next instruction in it because different instructions had different
execution times. So you didn't have to put next instruction addresses
into SOAP code, because SOAP would find where on a track to put the next
instruction so that it could be read for execution as soon as the previous
instruction finished.
BTW, the first FORTRAN I used was 650 FORTRANSIT, so called because the
FORTRAN code was translated to IT (International Translator ??? from
Carnegie U??). The IT phase put out SOAP.
In respect of the subject, I think the IBM305 outlasted the 650 by just
a little, at least in Australia. Also, it was a smaller drum. The 305
was famous in its time for its use of a large (8' high from my memory)
disk drive of the kind with one seek arm only, but it used a drum for main
storage. It was interesting otherwise for two reasons. *Firstly*, the
program was shared between the drum and a plugged panel. The instructions
themselves were kept on the drum, but they were sequenced by the plugged
panel, where for example the sign of a result of any instruction gave a pulse
out of different holes in the panel depending on the value of the sign -
positive, negative, or zero. The pulse would be used to select the next
instruction. *Secondly*, it had multiprogramming features. Two tracks of the
drum could be used to hold two enquiry programs driving two typewriter
terminals. A terminal could be used to interrupt the main program, run
its corresponding enquiry program (typically to get a data from the disk)
type out the answer, and restore the main program.
--
-------------------------------------------------------------------------------
Neville Holmes AARNET: Neville...@appcomp.utas.edu.au
Dept of Applied Computing & Maths Phone : +61 03 243 393 or (003) 243 393
University of Tasmania - Launceston Fax : +61 03 243 368 or (003) 243 368
Tony Wingo
S.- Contractor) wrote:
>
> Drums were (are?) also used as storage like disks. Even the early drums
> used in the SAGE computers in the 50s were faster (10 ms access)
> than todays disk drives. They had a head for every track, took up a lot
> of space and were expensive. Any more drum veterans out there?
> Sabu
>
They also took forever to come on line. Apparently, the drum had to reach
thermal equilibrium before the heads would fly. As I recall, the drums on
the CDC3600 up at UMASS had a fixed timer built into them. This meant the
every time the system was restarted you had to wait 40 minutes before the
drums were available for swapping.
-tony
Diversion (Jeff Rogers)
>>something. This resulted in such things as hand-hacking the program
>around the drum. It did it well - no hand-hacking needed. Perhaps it would
What would Mel say?
'If you use the assembeler, you never know where it's going to put things,
so you need to use seperate constants.'
(For the uninformed, see Appendix A(?) of the Jargon File for the story of
Mel, a Real Programmer)
Diversion
--
"I can see 'em | "Want me to create a diversion?"
I can see 'em | Diversion
Someone wake me when it's over" | rog...@rpi.edu
John Newman
writes:
>From: nic...@cs.tu-berlin.de (Juergen Nickelsen)
>Subject: Re: Last drum based computer?
>> I think my memory has grown a bad block, or I have a parity error or
>> something.. I seem to remember quite clearly from last year studies that
>> drums are disks, not memory..
>
>I remember vaguely reading about the austrian "Mailuefterl", which
>used drum storage not only for memory, but also as CPU registers, in
>the early 50s.
>
Our Bendix G15* (1958) has a drum used as main memory and registers.
A total of 63423 bits arranged in 2187 x 29-bit words on 24 tracks.
Its average access time is similar to modern hard disks at 14.5ms,
but it's a little short on capacity. Real storage was paper tape.
* The G15 was last used here in 1970. It now sits quietly in our museum
gathering dust.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\ John Newman J.Ne...@icarus.curtin.edu.au /
/ Computing Centre, "There is less to this \
\ Curtin University, than meets the eye." /
/ Perth, Western Australia - Tallulah Bankhead \
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Mark C. Lawrence
rob...@sabu.EBay.Sun.COM (Bob S.- Contractor) writes:
>
>Drums were (are?) also used as storage like disks. Even the early drums
>used in the SAGE computers in the 50s were faster (10 ms access)
>than todays disk drives. They had a head for every track, took up a lot
>of space and were expensive. Any more drum veterans out there?
Sure...On our 360/67, we had 2301 drums for paging devices. These had, as
I recall, 200 tracks with about 20kB/track. I seem to have misplaced
my manual for this thing :-)
We used them on a 370/158 too, later replaced with 2305 fixed head disks.
Eventually even these were replaced by "regular" disks (3350 or 3380).
Mark C. Lawrence
Systems Programmer Internet: M.Law...@Forsythe.Stanford.edu
Stanford Data Center Bitnet: M.Lawrence@STANFORD
Stanford, CA 94305-4136 Tel: (415) 723-4976
Charles Lasner
>In article <C5y7...@panix.com>, ay...@panix.com (Doug Ayen) writes:
>>Actually, as I remember it, *REAL* old-time computing did use drums for
>>memory. As in the IBM 650--it would write memory on a small, rapidly
>>rotating drum, and then read off the data when it needed it to compute
>>something. This resulted in such things as hand-hacking the program
>>structure so that it used the drum memory to its highest efficiencty--such
>>that when one operation finished, and the computer needed the next op.,
>>the programmer could arrange things such that the stored operation would
>>be right under the read head at that moment--instead of it having to wait
>>for the drum to come around one more time.
>Hand-hacking ??? The 650 I used to use came with SOAP - Symbolic Optimum
>Assembly Program, where the optimum referred to placement of the instructions
>around the drum. It did it well - no hand-hacking needed. Perhaps it would
>make it plainer to explain that every machine instruction had the address of
>the next instruction in it because different instructions had different
>execution times. So you didn't have to put next instruction addresses
>into SOAP code, because SOAP would find where on a track to put the next
>instruction so that it could be read for execution as soon as the previous
>instruction finished.
All true, but the hand-hacking was for other machines not so fortunate to
have a functional equivalent of SOAP (but needing it). The Mel story involves
a specific machine where the utility allegedly exists, but is known to be
essentially non-functional. Thus, the hand-hacking beats all available
utilities, etc.
Additionally, hand-hacking includes self-referential programs (meaning using
the code as a source of constants, as well as self-modification, etc.). SOAP
doesn't address any of these other issues, but hand-hackers did many things
at once, etc.
cjl
Bernie Cosell
} They also took forever to come on line. Apparently, the drum had to reach
} thermal equilibrium before the heads would fly.
Not thermal equilibrium, in general, but air-flow equilibrium. In fact,
you have the hint, yourself: the term used was for heads to _fly_. Heads
were not suspended above the drum, but actually pushed _toward_ the drum.
If the drum were not rotating, they would simply land on the drum surface
[clunk!]. When the drum is rotating at full speed, it drags a layer
of air around it and the heads would 'float' on that layer. But since there is
nothing actually *holding* the heads in place, it is critical that the
air flow be _very_ stable, hence the heads would not be released until
the drum had had a chance to come up to speed and stabilize there.
/Bernie\
--
Bernie Cosell cos...@world.std.com
Fantasy Farm Fibers, Pearisburg, VA (703) 921-2358
Vadim Antonov
>Heads
>were not suspended above the drum, but actually pushed _toward_ the drum.
Well, it depends. The flying heads were invented long after magnetic
drums and i actually saw drums with heads rigidly fixed and fine-tuned
with screws. *Those* were awfully sensitive to temperature, one of the
models required 3 days (!) of wariming to get "on regime". BESM-6's
durms took only several hours :-)
Actually air cushion heads aren't much sensitive to temperature or
humidity but rater intolerant to dust (and don't generally require
warming). They were introduced because it was the only sensible way
to make head surface closer to the magnetic platter (and therefore
the weaker signals can be used and magnetic field dissipation can
be reduced to achieve higher recording density). All the modern
Winchesters based on that old idea with the only difference that
devices are hermetically sealed to prevent dusting of the heads.
May be drums are undeservedly forgotten -- they were great for paging
since they have much lesser latency and much higher throughoutput
than disks (much lower capacity too, though). The RAIDs and striped
disks solve the throughoutput problem but can't do anything about
the latency (vendors claim that caches reduce it but any sane person
knows that the hardware disk cache would be much better used if it
were simply called "RAM").
--vadim
Mark Delany
>In 1970 the University of Karlsruhe got a Univac 1108, which had drums
>of 256kW and 1MW for swap space ( 1W = 36 bit ), and the socalled
>Fastrand drums for mass storage. These where lying, appr. 2 m long., with
>moving heads. I don't know the capacity anymore... Two of these where housed
>in one man high cabinet. Each head moved accross 64 tracks.
^^^^^^^^^^^^
Nope. The heads didn't move. Every track had a head.
The two drums that Univac use to sell were the FH-432's and FH-1782.
These were Fix Head devices that, in there day had one hell of an
access time. The 432 was 4.32ms and the 1782 was (you guessed it)
17.82ms.
We used them in preference to *normal* disks because of this for
specialized applications. The only problem was that they held
virtually zilch data. The 432 (I think) held 256Kwords and the 1782
may have help 1Mwords or thereabouts (the manual is buried deep in the
garage somewhere).
These drums and Univac disks in general were formatted with 112 X 36bit
word blocks.
This raise one of the more interesting mysteries associated with
Univac. Why does El Fastrando's constant equal 112?
--
Mark Delany ma...@bushwire.apana.org.au
Mark Delany
>In article <C628w...@ulowell.ulowell.edu> jvig...@cs.ulowell.edu (Joe Vigneau) writes:
>> (Being a member of the "next generation", I have never seen a
>> computer with drum storage/memory.)
>> How large was one of these drums?
>digits each, or 4096 words of 32 bits each. The physical sizes were something
>like 12" long and 8" in diameter, but this part of my recollections is much
>fuzzier, and more likely to be wrong.
Hmm. The ones I leant against were a tad bigger than that. Shall we
say roughly equivalent to a Honda Accord on it's side?
--
Mark Delany ma...@bushwire.apana.org.au
Edward Rice
MC> (Bob S.- Contractor) writes:
MC>
> used in the SAGE computers in the 50s were faster (10 ms access) than
> todays disk drives. They had a head for every track, took up a lot of
> space and were expensive. Any more drum veterans out there?
Drums didn't /have/ to have a head for every track. There were a few units
that had moving heads (movement parallel to the axis of rotation, obviously).
There were also 1-head disk drives with multiple platters, requiring heads to
be completely brought away from the disks, moved to the right platter, and
re-flown.
Neither of these made much of a contribution to the future of computer
science, IMHO.
Edward Rice
BC> } They also took forever to come on line. Apparently, the drum had to
BC> reach } thermal equilibrium before the heads would fly.
BC>
BC> Not thermal equilibrium, in general, but air-flow equilibrium. In
BC> fact, you have the hint, yourself: the term used was for heads to
BC> _fly_. Heads were not suspended above the drum, but actually pushed
BC> _toward_ the drum. If the drum were not rotating, they would simply
BC> land on the drum surface [clunk!]. When the drum is rotating at full
BC> speed, it drags a layer of air around it and the heads would 'float'
BC> on that layer. But since there is nothing actually *holding* the
BC> heads in place, it is critical that the air flow be _very_ stable,
BC> hence the heads would not be released until the drum had had a chance
BC> to come up to speed and stabilize there.
They required at /least/ airflow equilibrium. That wasn't sufficient, though.
I know that CDC required that the system spin long enough for the air
filtration on the unit to get working seriously -- spinning an 803 or 804
/down/ took about five minutes. Then it took fifteen or more minutes to bring
the unit back online -- you had to get rotational speed and stability, then
airflow and filtration had to be acceptable (and I'm sure Seymour had a timer
in there to ensure that 99% of any smoke particles were removed before that
was considered accomplished), and then finally the heads could un-park. We
lost filtration fans occasionally, and losing two of them (or just one?) was
cause for serious alarm.
In those days, heads flew /really/ low. I think that the airflow on the CDC
units was designed to force the head away from the surface, so that low
rotational velocity (and airflow) would cause a crash. Later, they used units
that had stable positions well /above/ the surface, and the airflow was used
to force the heads to fly "downwards" (towards the platter, regardless of
whether that was up or down wrt the earth), so that a problem with the airflow
resulted in heads springing away from the platter. Big improvement!
Dan Prener
[ ... ]
> >> (Being a member of the "next generation", I have never seen a
> >> computer with drum storage/memory.)
> >> How large was one of these drums?
> >digits each, or 4096 words of 32 bits each. The physical sizes were something
> >like 12" long and 8" in diameter, but this part of my recollections is much
> >fuzzier, and more likely to be wrong.
> Hmm. The ones I leant against were a tad bigger than that. Shall we
> say roughly equivalent to a Honda Accord on it's side?
Are you talking about drums used as main memory? That is what the original
question was about; and that is what I was answering. I have certainly seen
larger drums used as secondary storage, but not as main memory.
--
Dan Prener (pre...@watson.ibm.com)
John Schuncke
>In <1993Apr26....@uklirb.informatik.uni-kl.de> kirc...@uklira.informatik.uni-kl.de (Reinhard Kirchner) writes:
>>In 1970 the University of Karlsruhe got a Univac 1108, which had drums
>>of 256kW and 1MW for swap space ( 1W = 36 bit ), and the socalled
>>Fastrand drums for mass storage.
Cool. When I came on-station at U. S. Air Force Global Weather Central here
at Offutt AFB, Nebraska, the site had just upgraded away from 1108's to
1100/82's. Ditto for peripherals: they had just ditched both the 432s
and 1782s.
In the communications switching software I maintained, there were bazillions
of references to 432s holding rapid-access scratch storage and the 1782s
for history and journaling files. There was even one major subroutine
in the message accounting subsystem called "1782". Guess where its files
resided?
>The only problem was that they held
>virtually zilch data. The 432 (I think) held 256Kwords and the 1782
>may have help 1Mwords or thereabouts (the manual is buried deep in the
>garage somewhere).
Amen. The journaling software wrote the contents of the 1782-based history
files to tape every three hours. Such teensy mass storage. So many tapes
for those poor operators. And such crummy tape drives, too.
>These drums and Univac disks in general were formatted with 112 X 36bit
>word blocks.
>This raise one of the more interesting mysteries associated with
>Univac. Why does El Fastrando's constant equal 112?
Oh, the "prep factor." 112 words is 4 28-word sectors. Apparently, that was
the Univac EXEC-8 default for Fastrand devices for "sector" buffering in
core (or was it the controller?). The cardinal rule was: "Always read and
write in prep-factor increments--so you don't waste hardware accesses."
Still largely true, though in the ten intervening years Global Weather Central
has migrated to Unisys 2200/632s with 9720 fixed-disk systems. The prep
factor is still (usually) 112 words.
This raises yet another couple of interesting mysteries associated with
Univac (or Unisys as they are called now). Why 28-word sectors? Or 36-bit
words?
No, don't answer that. #8^)
>--
>Mark Delany ma...@bushwire.apana.org.au
--
+----------------------------------------------------+----------------------+
| John L. Schuncke, Jr. schu...@cwis.unomaha.edu | You're takin' this |
| The road to Hell is paved with good intentions.. | WAY too seriously. |
| AND I'M DRIVING THE STEAM ROLLER!!!! +----------------------+
Jim Finnis
dr...@drake.almaden.ibm.com (Sam Drake) burbled:
>I know the discussion is about drums-as-main-memory, not about drums-as-
>fast-disks, but ... when was the last time you saw a drum being used as
>a fast disk? The last one I saw was retired in 1985; several drums were
>being used as 1st level paging devices on a mainframe at that date. And
>gee, each one was 2 meters tall, weighed over a ton, and provided a whole
>8 MEGAbytes of storage! (sigh)
One thing about drums worth reading is the seminal "Story of Mel - A
Real programmer" from the Jargon File, a.k.a. the New Hacker's
Dictionary. It describes how a "real programmer" used various
characteristics of the drum memory (yep, main store) to optimise the
hell out of his program until it was completely unintelligible... Fun
reading, but it makes you cringe... boy, do we have it easy these days.
--
-----------------------------------------------------------------------------
Jim Finnis, | Unit 6A, Science Park, Aberystwyth, Dyfed, SY23 3AH
Clef Digital Systems |
cl...@aber.ac.uk | Tel.: 0970 626601 Overseas: +44 970 626601
Henry S. Thompson
computing life at an NSF summer school in computers and maths at UPenn
in 1966, using three donated (!) LGP-30 (Librascope General Precision)
machines. They had a Flexowriter for I/O, a little CRT with three
square-wave traces which showed the accumulator, index register and
program counter, and 4096 16-bit words of drum memory. That's it.
The drum had 64 tracks of 64 words each, with successive
(address-wise) words being 7 words apart (drum-wise), so that if you
got your operand in the right place, you wouldn't miss a revolution
between successive instructions. The accumulator and extension
registers were written alternately on the 65th track, I think. 4-bit
opcode, 12-bit address, with a hex encoding that ran 0-9,f,g,j,k,q,w --
I don't remember why.
Any other LGP-30 or NSF summer school veterans out there? The
teaching assistants were, I think, Larry Rafsky and Eric Tappert.
ht
--
Henry Thompson, Human Communication Research Centre, University of Edinburgh
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 31 650-4440
Fax: (44) 31 650-4587 ARPA: h...@cogsci.ed.ac.uk JANET: h...@uk.ac.ed.cogsci
UUCP: ...!uunet!mcsun!uknet!cogsci!ht
Dan Prener
> Sorry, I come late to the thread and the beginning is lost. I started
> computing life at an NSF summer school in computers and maths at UPenn
> in 1966, using three donated (!) LGP-30 (Librascope General Precision)
> machines. They had a Flexowriter for I/O, a little CRT with three
> square-wave traces which showed the accumulator, index register and
> program counter, and 4096 16-bit words of drum memory. That's it.
> The drum had 64 tracks of 64 words each, with successive
> (address-wise) words being 7 words apart (drum-wise), so that if you
> got your operand in the right place, you wouldn't miss a revolution
> between successive instructions. The accumulator and extension
> registers were written alternately on the 65th track, I think. 4-bit
> opcode, 12-bit address, with a hex encoding that ran 0-9,f,g,j,k,q,w --
> I don't remember why.
The strange hex encoding was because many letters of the alphabet were
in use for other purposes. If you used the 4-bit/char encoding, rather
than the 6-bit one, then things were arranged so that the letter "a"
was the opcode for "add", "s" for "subtract", etc.
> Any other LGP-30 or NSF summer school veterans out there? The
> teaching assistants were, I think, Larry Rafsky and Eric Tappert.
I taught in that program at Penn in the summers of '63, '64, and '65, but
not (I think) in '66.
--
Dan Prener (pre...@watson.ibm.com)
DoN. Nichols
>In article <0VmRs*l...@world.std.com> cos...@world.std.com writes:
[ ... ]
>May be drums are undeservedly forgotten -- they were great for paging
>since they have much lesser latency and much higher throughoutput
>than disks (much lower capacity too, though).
I noticed something interesting while flipping through a manual for
the Fujitsu Eagle drives (the manual went with the LMI system that was
turned in several months ago. -- Property disposal won't take the associated
manuals when something is turned in. )-:
Anyway, the manual clamed that *some* of the Eagles were
manufactured with the top surface of the top platter set up as a
head-per-track drive for just that purpose - a paging device.
I haven't yet determined whether the Eagle that I have (which came
out of another LMI sysem, from a hamfest) has that feature or not. I have
determined, however, that it makes far too much noise to be considered for
home use. :-)
> The RAIDs and striped
>disks solve the throughoutput problem but can't do anything about
>the latency (vendors claim that caches reduce it but any sane person
This one did, but I don't know whether anyone ever designed one into
a system.
--
Email: <dnic...@d-and-d.com> | ...!uunet!ceilidh!dnichols
<dnic...@ceilidh.beartrack.com>
Donald Nichols (DoN.) | Voice (Days): (703) 704-2280 (Eves): (703) 938-4564
--- Black Holes are where God is dividing by zero ---
Tim Kirby
:
: [ ... ]
:
: >May be drums are undeservedly forgotten -- they were great for paging
: >since they have much lesser latency and much higher throughoutput
: >than disks (much lower capacity too, though).
Well, I haven't seen any mention of them, to I'll put in a posting "In Memoriam"
(?) for the ICL 1900 series - the one I remember in particular was installed
at British Aerospace Kingston (RIP) in 1978 and ran until around 1983 or so.
It had 384k (24 bit words, 6 bit characters) 'core' of which 256k was plated
wire memory and the rest was semiconductor; that system had a 512kW drum used
mainly for paging but, as I recall, we also had some of the operating system
(George 4) resident thereupon. I don't remember the drum manufacturer, but it
ran in a welded steel case that could not have been much bigger than 2 feet
square and about 3 feet high (the rotational axis was vertical). I also recall
that it ran in some inert gas atmosphere. Start up time was fairly quick, I
think...
It's all very hazy now, though...
A wonderful machine, the '6s. Three big bays with big doors that hid bank after
bank of flashing lights. The ideal PR machine, it was just what visitors to the
computer centre expected to see...
Tim
--
Tim Kirby --------- Cray Research Inc., Eagan, MN, USA ----------- t...@cray.com
Disclaimer: I disclaim, therefore I am. Be warned ...
-------------------------------------------------------------------------------
When all else fails, Immortality may always be assured by spectacular error(JKG)
Charles Lasner
>
>Well, I haven't seen any mention of them, to I'll put in a posting "In Memoriam"
>(?) for the ICL 1900 series - the one I remember in particular was installed
>at British Aerospace Kingston (RIP) in 1978 and ran until around 1983 or so.
>It had 384k (24 bit words, 6 bit characters) 'core' of which 256k was plated
>wire memory and the rest was semiconductor; that system had a 512kW drum used
>mainly for paging but, as I recall, we also had some of the operating system
>(George 4) resident thereupon. I don't remember the drum manufacturer, but it
>ran in a welded steel case that could not have been much bigger than 2 feet
>square and about 3 feet high (the rotational axis was vertical). I also recall
>that it ran in some inert gas atmosphere. Start up time was fairly quick, I
>think...
Sounds like a Vermont Research drum. They had a significent British division
while the main company actually (still) is in Vermont, USA.
cjl
Dave Hough,55095
>
> MC> In article <1r9p3f$j...@male.EBay.Sun.COM>, rob...@sabu.EBay.Sun.COM
> MC> (Bob S.- Contractor) writes:
> > They had a head for every track, took up a lot of
> > space and were expensive. Any more drum veterans out there?
>
> Drums didn't /have/ to have a head for every track. There were a few units
> that had moving heads (movement parallel to the axis of rotation, obviously).
My experience with drum versus disk leads me to the following definitions:
1. Drum = one head per track per surface and the heads never move.
2. Disk = one or more heads per surface, and the heads must move to
cover all tracks.
Anyone out there have a more formal definition?
/dave
p.s. Anyone out there ever seen a disk with fewer heads than surfaces that still
managed to read all the surfaces on the drive?
Valdis Kletnieks
>p.s. Anyone out there ever seen a disk with fewer heads than surfaces that still
> managed to read all the surfaces on the drive?
>
Well, in our machine room right now, we have an optical disk jukebox
that has 176 surfaces and only 4 read mechanisms. It's not a new
idea, I'm pretty sure that the one-head-per-surface scheme arose
only after the cost of read/write heads dropped down to where
it was feasible to not make do with just one and a stepper motor
moving it surface-surface....
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
P.S. Those who were there can feel free to correct me - I myself
only date back to the S/360 era. ;)
Don Stokes
> My experience with drum versus disk leads me to the following definitions:
> 1. Drum = one head per track per surface and the heads never move.
> 2. Disk = one or more heads per surface, and the heads must move to
> cover all tracks.
> Anyone out there have a more formal definition?
The dictionary definitions of "drum" and "disk" are a pretty good start.
"Drum" vs "disk" has absolutely zilch to do with the number or movement
of heads, and everything to do with the shape of the object in question.
Drum: | Disk:
.-------+-------. head
| |<head | v
| | --------+--------
| | |
`-------+-------'
|
Drums had the advantage that each track is physically the same length,
which made them that much easier to build in the early days. But drums
also take up a lot more space and contain a lot more metal for a given
surface area, making disks far more attractive.
Head-per track disk drives have been made, as have moving head drums.
--
Don Stokes, ZL2TNM (DS555) d...@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre d...@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand +64-4-495-5052
Charles Lasner
>> that had moving heads (movement parallel to the axis of rotation, obviously).
>
>My experience with drum versus disk leads me to the following definitions:
> 1. Drum = one head per track per surface and the heads never move.
> 2. Disk = one or more heads per surface, and the heads must move to
> cover all tracks.
>Anyone out there have a more formal definition?
NG. Fixed head disks exist as well. So, you have at least 4 variations:
1) Moving head disks
2) Fixed head disks
3) Moving head drums
4) Fixed head drums
I don't think you'll find a single head that traverses more than one drum,
but apparently there are designs where there are less heads than surfaces,
so the head comes out and then flies on a different surface as needed.
cjl
Vadim Antonov
>tecdah1@sdc (Dave Hough,55095) writes:
>Drums had the advantage that each track is physically the same length,
>which made them that much easier to build in the early days.
The real advantage of disks is that they pack information in three
dimensions and therefore can have much larger capacity.
[What about 4D information storage? :-) ]
>But drums
>also take up a lot more space and contain a lot more metal for a given
>surface area, making disks far more attractive.
The metal wasn't an issue in the early days :-) [ever tried to
move a 400kg IBM dual washing machine through a window?]
However, the flat metal platters are much more resistant to centrifugal (sp?)
forces than cast drums allowing for higher revolution frequency and
increasing the throughoutput (which usually gets eaten away by mindless
one-head-at-a-time electronics later).
>Head-per track disk drives have been made, as have moving head drums.
Never saw a moving head drum. The fixed-head disks weren't much
useful since they kept even less information than drums (and the
different linear velocity and length of tracks effectively kept
the density low [and elaborate variable-sectors-per-track geometries
required some additional hardware which was even costlier than mechanics
at the time].
Finally, the block of fixed heads in usually thick and there is no
much space-density advantage over drums.
--vadim
Jim Haynes
A good reference for this is "IBMs Early Computers" by Emerson Pugh, et al.
Of course it only talks about IBMs work in the field.
Drums came first because they are easier to make - you can machine drums
on a lathe to have a very good surface. Whereas with disks it's hard to
make a disk that is very flat; so it was necessary to develop flying
head technology to cope with them. Some very fast drums were made,
including sealing them in a helium atmosphere to reduce the air drag.
--
hay...@cats.ucsc.edu
hay...@cats.bitnet
"Ya can talk all ya wanna, but it's dif'rent than it was!"
"No it aint! But ya gotta know the territory!"
Meredith Willson: "The Music Man"
Guy Dawson
In article <88...@fury.BOEING.COM>, tecdah1@sdc (Dave Hough,55095) writes:
> In article AA0...@Clone.his.com, edwar...@his.com (Edward Rice) writes:
> >
> > MC> In article <1r9p3f$j...@male.EBay.Sun.COM>, rob...@sabu.EBay.Sun.COM
> > MC> (Bob S.- Contractor) writes:
> > > They had a head for every track, took up a lot of
> > > space and were expensive. Any more drum veterans out there?
> >
> > Drums didn't /have/ to have a head for every track. There were a few units
> > that had moving heads (movement parallel to the axis of rotation, obviously).
>
> My experience with drum versus disk leads me to the following definitions:
> 1. Drum = one head per track per surface and the heads never move.
> 2. Disk = one or more heads per surface, and the heads must move to
> cover all tracks.
> Anyone out there have a more formal definition?
It's more basic than that -
drum - data stored in tracks on the outer surface of a drum.
Imagine a 45 gallon oil drum spining at x rpm on its long axis
disk - data stored in concentric tracks on the surface of a disk
>
> /dave
>
> p.s. Anyone out there ever seen a disk with fewer heads than surfaces that still
> managed to read all the surfaces on the drive?
>
Guy
--
-- -----------------------------------------------------------------------------
Guy Dawson - Hoskyns Group Plc.
gu...@hoskyns.co.uk Tel Hoskyns UK - 71 251 2128
gu...@austin.ibm.com Tel IBM Austin USA - 512 838 3377
Pete Lancashire
>In article AA0...@Clone.his.com, edwar...@his.com (Edward Rice) writes:
>>
>> MC> In article <1r9p3f$j...@male.EBay.Sun.COM>, rob...@sabu.EBay.Sun.COM
>> MC> (Bob S.- Contractor) writes:
>> > They had a head for every track, took up a lot of
>> > space and were expensive. Any more drum veterans out there?
>>
>> Drums didn't /have/ to have a head for every track. There were a few units
>> that had moving heads (movement parallel to the axis of rotation, obviously).
>My experience with drum versus disk leads me to the following definitions:
> 1. Drum = one head per track per surface and the heads never move.
> 2. Disk = one or more heads per surface, and the heads must move to
> cover all tracks.
>Anyone out there have a more formal definition?
Drum: shaped like a drum. Most were HPT (head per tract).
Disk: Shaped like a disk. Today almost all are moving head. But in the
early days HPT disks where not that uncommon. Again mostly for
paging.
Has anyone seen the Burroughs (I will never call them Unisys, yuk),
SU's ? I can't remember the diameter but I would guess about 3 feet.
Well they where a HPT disk, and you should see what happend when a major
(destructive) head failure took place.
>/dave
>p.s. Anyone out there ever seen a disk with fewer heads than surfaces that still
> managed to read all the surfaces on the drive?
No, that's a new one.
Guy Dawson
In article <785...@zl2tnm.gen.nz>, d...@zl2tnm.gen.nz (Don Stokes) writes:
> tecdah1@sdc (Dave Hough,55095) writes:
> > My experience with drum versus disk leads me to the following definitions:
> > 1. Drum = one head per track per surface and the heads never move.
> > 2. Disk = one or more heads per surface, and the heads must move to
> > cover all tracks.
> > Anyone out there have a more formal definition?
>
> The dictionary definitions of "drum" and "disk" are a pretty good start.
> "Drum" vs "disk" has absolutely zilch to do with the number or movement
> of heads, and everything to do with the shape of the object in question.
>
> Drum: | Disk:
> .-------+-------. head
> | |<head | v
> | | --------+--------
> | | |
> `-------+-------'
> |
Watching the above drum spinning would be interesting!
This is what a drum was like
heads
vvvvvvvvvvvvvvvvv
+-------------------+
| |
--+ +-- axis of rotation
| |
+-------------------+
>
> Drums had the advantage that each track is physically the same length,
> which made them that much easier to build in the early days. But drums
> also take up a lot more space and contain a lot more metal for a given
> surface area, making disks far more attractive.
>
> Head-per track disk drives have been made, as have moving head drums.
>
> --
> Don Stokes, ZL2TNM (DS555) d...@zl2tnm.gen.nz (home)
> Network Manager, Computing Services Centre d...@vuw.ac.nz (work)
> Victoria University of Wellington, New Zealand +64-4-495-5052
Guy
Pete Lancashire
>In article <785...@zl2tnm.gen.nz> d...@zl2tnm.gen.nz (Don Stokes) writes:
>>tecdah1@sdc (Dave Hough,55095) writes:
>>Drums had the advantage that each track is physically the same length,
>>which made them that much easier to build in the early days.
I agree, one early argument was that you could not utilize the linear
density of a disk, remember logic was expensive. But...
>The real advantage of disks is that they pack information in three
>dimensions and therefore can have much larger capacity.
>[What about 4D information storage? :-) ]
>>But drums
>>also take up a lot more space and contain a lot more metal for a given
>>surface area, making disks far more attractive.
... yep, even floor space was part of the decision, And the
manufacturing cost of drums was VERY high. Surface finish was
getting to be a problem with drums. A disk's flat surface can be
finished easier then a drum.
>The metal wasn't an issue in the early days :-) [ever tried to
>move a 400kg IBM dual washing machine through a window?]
The mas of the 'unit' was not a problem, but the mass of the drum was.
>However, the flat metal platters are much more resistant to centrifugal (sp?)
>forces than cast drums allowing for higher revolution frequency and
>increasing the throughoutput (which usually gets eaten away by mindless
>one-head-at-a-time electronics later).
Also temp. coef. is easier to control on a disk. When a disk expands it
does not get closer to the head(s).
>>Head-per track disk drives have been made, as have moving head drums.
>Never saw a moving head drum. The fixed-head disks weren't much
>useful since they kept even less information than drums (and the
>different linear velocity and length of tracks effectively kept
>the density low [and elaborate variable-sectors-per-track geometries
>required some additional hardware which was even costlier than mechanics
>at the time].
>Finally, the block of fixed heads in usually thick and there is no
>much space-density advantage over drums.
Burroughts solved the head density problem by putting the heads in a
spiral. What killed the HPT disks were various other technologies. One
being the cost of core comming down.
-pete
Pete Lancashire
>A good reference for this is "IBMs Early Computers" by Emerson Pugh, et al.
>Of course it only talks about IBMs work in the field.
>Drums came first because they are easier to make - you can machine drums
>on a lathe to have a very good surface. Whereas with disks it's hard to
>make a disk that is very flat; so it was necessary to develop flying
>head technology to cope with them. Some very fast drums were made,
>including sealing them in a helium atmosphere to reduce the air drag.
Pumping out the air was another attempt, But I don't think it ever
made it out of the lab.
-pete
-----------------------------------------
--- Pete Lancashire pe...@sequent.com ---
---------- Sr. Systems Engineer ---------
---- Sequent Computer Systems, Inc. ----
--- Kid in spirit. Big Brother to be! ---
-----------------------------------------
Sarr J. Blumson
|> call them Unisys, yuk),
|> SU's ? I can't remember the diameter but I
|> would guess about 3 feet.
|>
whopping 2.5 mw (36 bit words,
of course) per drive. We ran a time sharing
service business with nothing else
for the better part of a year; I wrote a device
driver hack so the os (which
wasn't called TOPS-10 yet) could support 2
controllers so we could have 8 of them
on a machine.
|> >p.s. Anyone out there ever seen a disk with
|> fewer heads than surfaces that still
|> > managed to read all the surfaces on the
|> drive?
|>
Never actually seen one, but I have seen pictures of the IBM 305 RAMAC.
--
--------
Sarr Blumson sa...@citi.umich.edu
voice: +1 313 764 0253 home: +1 313 665 9591
CITI/IFS, University of Michigan, 519 W William, Ann Arbor, MI 48103-4943
Tim Kirby
: > tecdah1@sdc (Dave Hough,55095) writes:
: > Drum: |
: > .-------+-------.
: > | |<head
: > | |
: > `-------+-------'
: > |
: Watching the above drum spinning would be interesting! This is what a drum
: was like
: heads
: vvvvvvvvvvvvvvvvv
: +-------------------+
: | |
: --+ +-- axis of rotation
: | |
: +-------------------+
The drum I described on the ICL system was most definitely oriented thus:
|
.----+-----.
| |<head
| |<head
| |<head
| |<head
| |<head
| |<head
`----+-----'
|
^
Axis of Rotation
Thinking back I seem to recall one of the engineers telling me that the drum
was very slightly conical (smaller at the top) and actually raised up to meet
the fixed heads when it spun. I have no way of verifying that now, though...
Tom Van Vleck
machine used a drum as primary storage like the 650, but had a Bryant
drum with 32768 32-bit words of memory. Several tracks on the drum
had two sets of heads, a write head followed by a read head, set up
to recirculate a single word: these were our fast accumulators.
The Bryant salesman told us a story, may be urban legend, about an
experimental drum, running at very high RPM in a vacuum box.
Someone opened the door and the implosion drove the heads into the
drum surface, causing the drum to hop out of its bearings and
act like a 1-ton gyroscope, wandering the lab smashing equipment.
Tom Van Vleck
> Burroughts solved the head density problem by putting the heads in a
> spiral. What killed the HPT disks were various other technologies. One
> being the cost of core comming down.
The GE-645, the original Multics machine, came with a "firehose drum."
This was a big box, 7 feet high and about 14 x 3 feet in footprint.
Inside was a Singer Librafile fixed-head disk; rumor had it that these
were used on guided missile subs. We still called it a drum though.
Pete is right about core: this middle level of the Multics memory speed
hierarchy was replaced by a "bulk core unit" in the Honeywell 6180.
DoN. Nichols
>In article <785...@zl2tnm.gen.nz> d...@zl2tnm.gen.nz (Don Stokes) writes:
[ ... ]
>>Head-per track disk drives have been made, as have moving head drums.
>
>Never saw a moving head drum. The fixed-head disks weren't much
>useful since they kept even less information than drums (and the
>different linear velocity and length of tracks effectively kept
>the density low [and elaborate variable-sectors-per-track geometries
>required some additional hardware which was even costlier than mechanics
>at the time].
>
>Finally, the block of fixed heads in usually thick and there is no
>much space-density advantage over drums.
Except in the case of the Fujitsu Eagle (M2351) which had, in some
models according to the manual, both the usual stack of moving heads combing
the platter stack, but also a set of head-per-track heads above the top
surface only, so the extra bulk of the heads didn't exact a penalty in
platter-to-platter spaciing.
According to the manual, the intention was for the moving-head
portion to be used for normal file structures, and the head-per-track to be
dedicated to swapping/paging. A neat idea, though it did make it more
difficult to add more swap space to cover an additional influx of memory.
Dave Hough,55095
> In article <88...@fury.BOEING.COM> tecdah1@sdc writes:
> >p.s. Anyone out there ever seen a disk with fewer heads than surfaces that still
> > managed to read all the surfaces on the drive?
>
> Well, in our machine room right now, we have an optical disk jukebox
> that has 176 surfaces and only 4 read mechanisms.
I wasn't thinking about removable media when I made the orginal post. :) Let's
ignore removable media, including jukeboxes, silos and data cells (shudder) and
see if there is a disk out there that did something like this.
> It's not a new
> idea, I'm pretty sure that the one-head-per-surface scheme arose
> only after the cost of read/write heads dropped down to where
> it was feasible to not make do with just one and a stepper motor
> moving it surface-surface....
I am under the impression that drums (1 head per track) came first, because they
avoided accuracy problems with positioners of the day. Then came the slower
disk with a single head per surface that moved from track-to-track via the stepper.
Jim Haynes
In article <tom_van_vleck...@tom-vanvleck.taligent.com> tom_va...@taligent.com (Tom Van Vleck) writes:
>The GE-645, the original Multics machine, came with a "firehose drum."
>This was a big box, 7 feet high and about 14 x 3 feet in footprint.
>Inside was a Singer Librafile fixed-head disk; rumor had it that these
>were used on guided missile subs. We still called it a drum though.
G.E. also bought some of the HPT disks from Burroughs and sold them
with the 635s; I don't know if any were used on 645s.
These Burroughs HPT disks were more for file storage than for typical
drum applications. The Burroughs B5500 could have one or two drums;
I was told that they were pretty horrid pieces of hardware and everybody
got rid of them. Later when the model number was inflated to B5700
it was possible to attach B6700 core memories to the ports on the 5500
that were originally used for the drums. G.E. had a Univac drum that
was sold with the 635s - the only one I ever saw didn't work very well.
Their disk offering was built by in-house but was closely related to the
IBM and Data Products disk machines - a huge cabinet with the disks
in a horizontal plane and a moving head for each surface. These were
originally marketed with the 200- and 400-line machines, where they
performed reasonably well. The 635s beat them to pieces; hence the
switch to the Burroughs disks. I don't know if Burroughs was motivated
to use HPT disks because of the increased speed or because it let them
avoid bothering with developing moving-head technology and then having
to maintain it in the field.
Anders Thulin
>Has anyone seen the Burroughs (I will never call them Unisys, yuk),
>SU's ? I can't remember the diameter but I would guess about 3 feet.
That sounds a bit like the old Bryant disk units - I'd place their
disk at around 4 feet diameter. There was a persistent rumour that
crashed disks made nice coffee tables.
At least one of them found its way to Sweden - intended for some
DataSAAB installation. I think it had 5+5 disk platters and separate
clock disk. Packing density can't have been very high - it totalled
5Mb, I think.
This unit wasn't a head-per-track as far as I know - the heads looked
moveable to me. I may be wrong - we never started it; another of those
rumours said that when the engineers at DataSAAB started it, there
were brownouts all over the labs.
--
Anders Thulin a...@linkoping.trab.se 013-23 55 32
Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden
John Morris
>(?) for the ICL 1900 series - the one I remember in particular was installed
>at British Aerospace Kingston (RIP) in 1978 and ran until around 1983 or so.
Nostalgia time for me too! I was brought up on the old ICL 1900 series
machines: a 1905S at Lancaster University was the first computer I ever
got to really know and love - first assembler, first hack into the operating
system, and so on. It ran the George 3 operating system. In the cabinets
were real transistors - none of this new-fangled integrated circuit stuff.
An oddity with George was that ones interactive sessions (on electromechanical
flexowriters - a ten hour session left you with ringing ears...) could be
"partially" or "fully" started. For editing and submitting batch jobs you
in effect used shared code in the OS kernel (yes, the editor was in there
too, as I recall - but it's been a while...). If you actually ran a program
on-line (not always possible: Sometimes there was not enough memory) then
you saw the message "job is now fully started". The first time I saw it
I could only wonder what I had been doing for the previous four hours :-)
I think a still have the assembler manual (called "PLAN") around somewhere.
The 24 bit words were treated as either four 6 bit characters or as three
8 bit bytes or as a whole word, depending on the opcode. Many ops had a two
bit field selecting one out of three bytes _or_ the whole word. Neat.
There is a long story about the naming of the operating system "George", but
my favourite tale describes a history fellow wandering into
the computing center one day, having heard about SPSS and wanting to do
some statistics. His request was along the lines of "I need to know
about this system on your computer - I think it's called Richard the
Second or George the Third or something."
Oh happy days...
John.
--
John Morris != Spider Systems jmo...@spider.co.uk GM4ANB@GB7EDN.#77.GBR.EU
Steve McKinty - SunConnect ICNC
> In article <1993May4.0...@hemlock.cray.com> t...@palm34.cray.com (Tim
> machines: a 1905S at Lancaster University was the first computer I ever
> got to really know and love - first assembler, first hack into the operating
> system, and so on. It ran the George 3 operating system. In the cabinets
> were real transistors - none of this new-fangled integrated circuit stuff.
Yes, plated wire memory too. Much more advanced than 'core'... It was
amazing what you could do in 25K on a 1904A if you had to.
>
> If you actually ran a program
> on-line (not always possible: Sometimes there was not enough memory) then
> you saw the message "job is now fully started". The first time I saw it
> I could only wonder what I had been doing for the previous four hours :-)
I always wondered what that meant, thanks for the explanation.
>
> I think a still have the assembler manual (called "PLAN") around somewhere.
I have a PLAn handy-reference card here in my desk.
> Oh happy days...
true. George IV was ahead of its time in many ways. Pity ICL wasn't.
Steve
--
Steve McKinty
Sun Microsystems ICNC
38240 Meylan, France
email: smck...@france.sun.com BIX: smckinty
Joe Morris
>My experience with drum versus disk leads me to the following definitions:
> 1. Drum = one head per track per surface and the heads never move.
> 2. Disk = one or more heads per surface, and the heads must move to
> cover all tracks.
>Anyone out there have a more formal definition?
The IBM 3350 disks (1970s vintage) had an optional feature which placed
fixed-position heads over a small number of cylinders to provide very
fast access to the data there. I never knew anyone who bought it, although
I'm sure that there were some customers.
Also, the IBM 2305 FHSD (Fixed Head Storage Device) was a head-per-track
disk drive. Very expensive even when it was a new product, and (like
all contempory computer equipment) ridiculously overpriced by today's
standards.
>p.s. Anyone out there ever seen a disk with fewer heads than surfaces that still
> managed to read all the surfaces on the drive?
Sure: the IBM 305 RAMAC. It had a single head arm which *must* have been
designed by someone who was familiar with the pre-WWII Wurlitzer juke
boxes. When the unit was commanded to move to a different surface the
head was swung clear of the disks, then dragged up or down a column,
and re-inserted into the disk stack. The closest thing in today's
environment to this type of motion is probably the monster multi-terabyte
optical juke boxes. The STC tape silo doesn't even come close.
Joe Morris / MITRE
Joe Morris
>The drum I described on the ICL system was most definitely oriented thus:
> |
> .----+-----.
> | |<head
> | |<head
> | |<head
> | |<head
> | |<head
> | |<head
> `----+-----'
> |
> ^
> Axis of Rotation
>Thinking back I seem to recall one of the engineers telling me that the drum
>was very slightly conical (smaller at the top) and actually raised up to meet
>the fixed heads when it spun. I have no way of verifying that now, though...
The IBM 2301 disk was designed this way; the reason was that since the heads
rode on an air bearing, they could never be permitted to touch the drum
surface. With a conical drum which was raised into position by air pressure,
you have a fail-safe design because in the event of a power failure the
drum will drop away from the heads.
Another advantage of the 2301 design (unrelated to the shape of the drum)
was that it was small (maybe 30" square case? I can't remember) and
the drum itself and the heads were in a glass-enclosed section at the
top. The whole thing looked like a display case at a museum and was
a good "gee-whiz" item on most computer center tours.
Joe Morris / MITRE
Douglas W. Jones,201H MLH,3193350740,3193382879
office of the University of Illinois Computer Science Department. That
drum predates flying head technology, and if I remember correctly, it has
64 fixed heads. The thing is built to heavy machinery standards in a cast
iron housing. I've given it a spin with my fingers, and the bearings are
very good!
Each head was mounted on a micrometer mechanism that took up about a square
inch of real-estate (so you could get a wrench on the adjusting nut). The
total working surface of the drum was about a foot long, so the heads were
laid out in a slightly skewed 8 by 8 square that was wrapped around a good
part of the top half of the cast iron housing. Machining those head mounts
must have been fun!
On a far more modern note, my 1968 Digital Logic Handbook lists both fixed
head disks and drums as being available. By that year, DEC was selling
the DF32 fixed head disk, a disk that had a capacity of 32K 13 bit words
(12 bit plus parity). 4 such disks could be hung on one controller. The
advertised access time of the DF32 was 16.67 milliseconds.
The DF32 was new in 1968 -- it's not listed in DEC's earlier Logic Handbooks,
but the 1966-67 handbook and the 1967 handbook both list drum memory
systems as being available. (The 1965 handbook, a looseleaf binder, didn't
include a section on computers and peripherals, so I can't tell what was
offered back then.) The drum memory DEC sold came in increments of 32768
words, up to 262144 words. They dont say what word size they're talking
about, but the description predates the debut of the PDP-10, so 12 or 18
bits is a reasonable guess.
Doug Jones
jo...@cs.uiowa.edu
Robert Bonomi
> In article <88...@fury.BOEING.COM> tecdah1@sdc writes:
> >p.s. Anyone out there ever seen a disk with fewer heads than surfaces that still
> > managed to read all the surfaces on the drive?
Yes, there -really- were such animals, the head assembly was on an 'elevator'
mechanism - the head arm would retract, and then the assembly would 'step' vert.
to the correct platter, and the arm would seek to the proper cylinder. Now for
the 'fun part' -- there were 'smarts' :) in the drive logic to minimize vert.
step time [there were 2 step commands, 1) step up/down one step, 2) -fast seek-
to end of track -- 'fast seek' implemented as 'go till the limit switch trips']
-- the logic decided if it was 'quicker' to step/step to the desired platter,
vs. fast-seek to end and step-backwards to target platter. One day the 'upper'
limit switch failed, and the assembly did a 'fast-seek' right off the top of
the spindle it rode on; came down on the top platter -- fireworks as expected.
(talk about a 'head crash'). The entire unit was deemed 'unsalvagable' -- no
hope of getting a 'clean' environment in the disk compartment.
Robert Bonomi
Paul Ducklin
>Nostalgia time for me too! I was brought up on the old ICL 1900 series
>machines: a 1905S at Lancaster University was the first computer I ever
>got to really know and love - first assembler, first hack into the operating
>system, and so on. It ran the George 3 operating system. In the cabinets
>were real transistors - none of this new-fangled integrated circuit stuff.
Yep. My first ever computer was an ICL1901A. We had 16Kwords and 2 hard
disc units. All input except job control was on manually-punched cards.
Once, three of us typed in a whole deck of cards for an address list
and my mind got so warped [and my fingers so fast] at typing the word
which appeared in the list most often ["JOHANNESBURG"] that for weeks
aferwards, if I was punching code fast and a "J" came up, I'd lock
into the groove. I'd get lines in FORTRAN like J=JOHANNESBURG+1.
Can't tell you how excited I was when I saw my first electronic card
punch -- "hey, these things type the contents at the top of the card".
I can't remember much about this beast [I was a kid at school -- the
computer was donated, whence the manual card punches, as the electro
ones broke too often, they said, and cost too much for mere freebies],
but it was cool. To this day, I occasionally have dreams that I'm stuck
in the computer room with the machine switched off -- NOW WHAT? I'm
not certain, but I think I might just remember how to IPL the beast.
And I can remember where we stashed the key to the cupboard where the
executive was stored -- what a bugger when the reader chewed one of the
cards in the executive deck: we only ever had one copy on cards, and
a general listing [was that XEKB? or XFAE?] of the deck.
After a few years, the lamp in the card reader blew. Rather than buy another,
the machine was scrapped [for GBP35!] and an Apple ][ replaced it, though
that was after my time.
One of the bus lines [or some such -- I have always assumed it was one
of the address lines, for some reason] was wired up to a small speaker
in the bottom right corner of the teletype. Weird crackling noises
emerged when the CPU was busy -- whence, I suppose, the speaker. In code
with heavily nested loops, you could "hear" the outer loop progressing
as various sound sequences repeated. This was actually a great debugging
tool -- you could hear your initialisation; listen for the calculations;
count the number of iterations before a crash. We even had some binaries
we got from one of the field engineers which played tunes by executing
specific instruction sequences.
Weird. We all thought we were pretty sane at the time.
Paul
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\ Paul Ducklin du...@nuustak.csir.co.za /
/ CSIR Computer Virus Lab + Box 395 + Pretoria + 0001 S Africa \
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Paul Pierce
I haven't seen anyone post about a recent machine with drum _main_
memory. The latest one I know of is the Litton 1231. Its a serial binary
machine with a 40-bit word. I keep forgetting to bring the manual in,
and I can't remember how big the drum is. I think the biggest one was
20,000 characters.
The central processor is like one pedestal of a double pedestal desk,
about the size of a dorm-room refrigerator (or a VAX 750). A full-width
control box with switches and lights is on top at the back. The drum is
in the middle on the bottom inside. Its about the size of a coffee can
and mounted with the axis of rotation vertical. Its all encased in a
metal cylinder with vertical rows of connectors on the outside for
the heads. The processor logic is implemented in 7400-series TTL,
which dates it no earlier than the
late 60's. The peripherals are a special hard-copy terminal, and a
mechanical paper tape reader and punch. There was also an Anelex line
printer.
It has a very silly operating system that lives in a write-protected
area of the drum. The operating system is a program loader, interpreter,
and debugger for a very weak decimal machine. Its intended for
accounting applications. Its very hard to imagine that anyone ever paid
real money for this system.
I saw its immediate predecessor, which was physically a little smaller
and used a Teletype model 33 for I/O. Its logic was discrete transistors.
Some of the manuals come in Royal-McBee binders, which makes me think
that the machine is a descendent of their machines which I believe
includes the LGP-30 mentioned earlier in this thread.
I've also seen a Monroe Monrobot XI, which is a very similar machine
dating back to the early 60's. Its in an L-shaped desk, with the drum on
one end inside. When you take the cover off, the drum just hangs out
there in the open. It was about 6 inches around, mounted with the axis
of rotation horizontal pointing out the end of the short section of the
L. The heads were mounted in fixed positions with an easily visible gap
between the head and the surface of the drum. The circuitry was very
messy looking discrete transistors, possibly the worst layout and
construction I've ever seen in a computer. The mechanical paper tape
reader and punch were in pull-out drawers in the long section of the L.
The operator sat inside the L, and there was a little box with switches
and lights on top at the corner.
Does anyone know if or how the Librascope, Royal-McBee, Monroe, and
Litton lines are related?
--
Paul Pierce p...@ssd.intel.com
Intel
Don Stokes
Orientation wasn't something that I thought terribly relevant to the
argument of "what is a drum". After all, I've seen a lot of disks mounted
on their sides, (IBM were rather fond of doing that with (phisically!) big
drives, and a large proportion of small systems mount either way) and the
disk in the Mac SE on my desk at work is strapped at an odd angle to part
of the CRT mounting...
Edward Rice
> Well, in our machine room right now, we have an optical disk jukebox
> that has 176 surfaces and only 4 read mechanisms.
>
DH> I wasn't thinking about removable media when I made the orginal post.
DH> :) Let's ignore removable media, including jukeboxes, silos and data
DH> cells (shudder) and see if there is a disk out there that did
DH> something like this.
DH>
> It's not a new idea, I'm pretty sure that the
> one-head-per-surface scheme arose only after the cost of read/write
> heads dropped down to where it was feasible to not make do with just one
> and a stepper motor moving it surface-surface....
Dave, several of us /have/ commented on the existence of disks (EARLY disks,
admittedly) with fewer head assemblies than platters, which required the head
assembly to move to the correct platter before reading. The IBM RAMAC has
been mentioned specifically.
Peter Ingham
> Drum: shaped like a drum. Most were HPT (head per tract).
> Disk: Shaped like a disk. Today almost all are moving head. But in the
> early days HPT disks where not that uncommon. Again mostly for
> paging.
> Has anyone seen the Burroughs (I will never call them Unisys, yuk),
> SU's ? I can't remember the diameter but I would guess about 3 feet.
The last of the 3' diameter stuff would have been the 1C HPT drive, 5MB per
module, 8 surfaces, 3' diameter, 30ms avg acces (all latency!!).
There was a more recent HPT drive (5N) that ran at >6000 rpm, 5 ms access
(without caching or any 'tricks'). We found that by using regular moving head
disks of the time and restricting disk use to only a few tracks (ie: mark
95% of the tracks as bad) we could achieve access times in the region of 9-10 ms
for less cost.
> Well they where a HPT disk, and you should see what happend when a major
> (destructive) head failure took place.
The other interesting thing was the time taken to spin up & down (about 5 mins to
spin down, over half an hour from power-on to head loading) these things had
MASS.
--
Cheers
Peter S. Ingham pi...@ping.actrix.gen.nz
Lower Hutt, New Zealand 3:771/220.5
M Stobbs
>One of the bus lines [or some such -- I have always assumed it was one
>of the address lines, for some reason] was wired up to a small speaker
>in the bottom right corner of the teletype. Weird crackling noises
>emerged when the CPU was busy -- whence, I suppose, the speaker. In code
>with heavily nested loops, you could "hear" the outer loop progressing
>as various sound sequences repeated. This was actually a great debugging
>tool -- you could hear your initialisation; listen for the calculations;
>count the number of iterations before a crash. We even had some binaries
>we got from one of the field engineers which played tunes by executing
>specific instruction sequences.
>Weird. We all thought we were pretty sane at the time.
I heard that when the ICL 1900 was launched, some s/w engineers wrote code
to play the tune of SWAN LAKE. A ballet dancer was wheeled in when the tune
started.
I startedworking as an operator on an ICT 1500. A room full of equipment with
valves and mountains of power supplies. It took a number of minutes to warm up.
It consisted of a card reader, printer, and 6 tape decks. If a tape got a read
error, you could give commands at the console to rewind the tape one block
and then read in the damaged block into memory. You then did a binary
conversion of the data and fixed the problem areas. I remember looking up
addresses in the telephone book to correct data on customer files.
By the way these machines were still in operation in Zimbabwe (ICL Bureau)
until about 1979.
Regards
--
Mark Stobbs University of Fort Hare South Africa
ccs...@train.ufh.ac.za
ma...@bushwire.apana.org.au
>The Bryant salesman told us a story, may be urban legend, about an
>experimental drum, running at very high RPM in a vacuum box.
>Someone opened the door and the implosion drove the heads into the
>drum surface, causing the drum to hop out of its bearings and
>act like a 1-ton gyroscope, wandering the lab smashing equipment.
I heard a similar anecdote about the Univac drums. The USAF wanted to
put the computers on a plane (a prototype Orion ?) and had two
concerns: the gyroscopic affects of a drum on the plane and the
potential damage that wind-pocket jolts would cause the drum.
To test the latter, the engineers fixed a drum to the ceiling of the
lab (with a set of chains or some such), slowly pulled it back about a
meter or two, spun it up, then released it so that it would fall into
a specially constructed collision wall. Thus:
================================[]
[] [] []
/ / []
/ / []
/ / []
/ / []
/ / []
/ / [ ] []
(+---------------+) [ ] []
( ) [ ] []
( ) [ ] []
(+---------------+) [ ] []
[ ] []
================================[]
The important perspective is the aerial view prior to the release:
================================== External wall
----- Collision wall
+++++
| |
| | Drum
| |
| |
+++++
And this is what it looked like after the test:
=
= = =
= +++++ =
==================| |=========== External Wall
----- | |
| | Drum
| |
+++++
Oops. Guess they forgot about the gyroscopic affect on the drum :-)
--
Mark Delany ma...@bushwire.apana.org.au
Dale R. Worley
Each digit was in biquinary, represented by 5 cores coded 2 on, 3 off.
The machine stopped dead if a 2-out-of-5 check failed.
Error -- Decimal digits can be represented in 5 bits with a 2-of-5
code, or with 7 (!) bits with biquinary: 1 of two bits to give 0 or 5,
and 1 of 5 bits to give 0, 1, 2, 3, or 4. You can see why biquinary
didn't catch on.
Dale
Dale Worley Dept. of Math., MIT d...@math.mit.edu
--
What else does a chump want? Mystery! He wants to think the world is
a romantic place when it damn well ain't. -- Robert A. Heinlein
Malcolm Beattie
>In article <1993May4.0...@hemlock.cray.com> t...@palm34.cray.com (Tim Kirby) writes:
>>Well, I haven't seen any mention of them, to I'll put in a posting "In Memoriam"
>>(?) for the ICL 1900 series - the one I remember in particular was installed
>>at British Aerospace Kingston (RIP) in 1978 and ran until around 1983 or so.
>
>Nostalgia time for me too! I was brought up on the old ICL 1900 series
>machines: a 1905S at Lancaster University was the first computer I ever
>got to really know and love - first assembler, first hack into the operating
>system, and so on. It ran the George 3 operating system. In the cabinets
>were real transistors - none of this new-fangled integrated circuit stuff.
>
>An oddity with George was that ones interactive sessions (on electromechanical
>flexowriters - a ten hour session left you with ringing ears...) could be
>"partially" or "fully" started. For editing and submitting batch jobs you
>in effect used shared code in the OS kernel (yes, the editor was in there
>too, as I recall - but it's been a while...). If you actually ran a program
>on-line (not always possible: Sometimes there was not enough memory) then
>you saw the message "job is now fully started". The first time I saw it
>I could only wonder what I had been doing for the previous four hours :-)
Hurray! A year or two ago, I posted some reminiscences about
the ICL 1902T that I was brought up on and it triggered some
email from a contemporary (hello Steve) but no posted responses.
Since then, I've dug out some of the documentation that I had and
that's brought back more memories, most hazy though. The operating
system was George 3 with Maximop for interactive use with an
ASR33 as console. I have by my side a photocopy snaffled from
Sussex University of the PASCAL 1900 manual dated Sept 28 1978
which mentions a core restriction of 40K for a queued-MOP job
(64K for a scheduled job...wow :-). I don't remember using
Pascal however; I do remember using Algol.
I have also a manual `Using the GEORGE editor' which has a magtape
on the front with Liverpool, Lancaster, Salford, Keele circling it
and a date of Oct 1978. This includes the marvellous error message
YOU'VE RUN OFF THE END OF YOUR FILE
I have notes I made in 1983 about using the COBOL compiler
(that was the first time I had used COBOL.)
The steering file incantations went something like
*IDENTITY NAME
*COMPILE
*COBOL
*OBJECT
*CONSOLIDATE
****
PROGRAM-ID. NAME63
etc.
and the program id needed the 2 digit priority or it failed with
a cryptic error. Try working that out without the proper manuals.
It almost makes you miss JCL...
>
>Oh happy days...
Indeed.
--
Malcolm Beattie <mbea...@black.ox.ac.uk> | I'm not a kernel hacker
Oxford University Computing Services | I'm a kernel hacker's mate
13 Banbury Road, Oxford, OX2 6NN (U.K.) | And I'm only hacking kernels
Tel: +44 865 273232 Fax: +44 865 273275 | 'Cos the kernel hacker's late
John B. Campbell
In article <C6Mnz...@SSD.intel.com> p...@ssd.intel.com (Paul Pierce) writes:
> [....]
> I haven't seen anyone post about a recent machine with drum _main_
> memory. The latest one I know of is the Litton 1231. Its a serial binary
> machine with a 40-bit word. I keep forgetting to bring the manual in,
> and I can't remember how big the drum is. I think the biggest one was
> 20,000 characters.
[... more details of the Litton 1231 ]
> Some of the manuals come in Royal-McBee binders, which makes me think
> that the machine is a descendent of their machines which I believe
> includes the LGP-30 mentioned earlier in this thread.
>
> I've also seen a Monroe Monrobot XI, which is a very similar machine
> dating back to the early 60's. Its in an L-shaped desk, with the drum on
[....more details about the Monrobot]
> Does anyone know if or how the Librascope, Royal-McBee, Monroe, and
> Litton lines are related?
--
> Paul Pierce p...@ssd.intel.com
> Intel
Her's my $.02 worth, as a user of the LGP-30 in the late 50s and its
successor the LGP-21 in the early sixties, and user of Monrobot.
In the beginning, before computers, there was Royal-McBee , a joint
venture of Royal, the typewriter folks, and McBee, the originators of
a clever pin-based card sorting system and producers of the so-called
McBee cards. Royal thought it would be neat to get into ofice
automation more than just typewriters.
There was also Librascope, a manufacturer of avionics like gyros, and
General Precision, another avionics maker if memory serves.
Librascope and General Precision collaborated on a drum-memory vacuum
tube computer introduced for use ibn offices (heretical place to put
computers but they were on the right track.) When I first used the
LGP-30, Librascope was in the process of backing out of the GP
computer business to stay in the avionics world. (LGP, you'll guess,
stood for Librascope-General Precision).
Royal-Mc Bee replaced Librascope in the joint venture, which I guess
became a three-way joint venture called Royal Precision Corporation,
owned jointly by Royal McBee and General Precision. They marketed the
LGP-30 and didn't change the "L" even though Librascope departed. In
1961 they introduced a solid-state LGP-21 (because it cost 21 grand.)
Later they marketed a machine with their own initials: the RPC4000.
As far as I remember, neither Monroe (who started with calculating
machines) and Litton (another avionics firm) had any connnection with
the LGP xx or RPC xxx family. Later on, in the mid 60s, Control Data
bought out the LGP21 produce line but kept the name. They also bought
out Bendix' G20 too as I remember.
I vaguely recall some Litton general purpose machines that were based
on their militarized computing family. Anybody else recall them?
--
****************************************************************
* * *
* John B. Campbell * This space *
* MITRE Corporation * *
* Bedford, MA 01730 * intentionally *
* (617)271-3434 * *
* <j...@mitre.org> * blank. *
* * *
****************************************************************
Guy Dawson
It's not...
Daves origional drum is not very deep. I mis-intrepreted it as wrongly drawn...
>
> --
> Don Stokes, ZL2TNM (DS555) d...@zl2tnm.gen.nz (home)
> Network Manager, Computing Services Centre d...@vuw.ac.nz (work)
> Victoria University of Wellington, New Zealand +64-4-495-5052
Guy
--
-- -----------------------------------------------------------------------------
Guy Dawson - Hoskyns Group Plc.
gu...@hoskyns.co.uk Tel Hoskyns UK - 71 251 2128
gu...@austin.ibm.com Tel IBM Austin USA - 512 838 3377
Tim Kirby
*Sigh*. I've been out for a while and missed the memories I stirred...
When the 6s was installed at BAe I was an operator; we learned to drive the
system as much by noise as by the teletype (I just loved the noise you got as
dumper was running through the essential system files just prior to generating
the "Increment Suitable for General Restore" (Has this stirred up any more
memories ?) ... I still have the G3 'admin' manual. Considering it's age (late
1960's), I have yet to see an operating system to beat it.
I even miss the line editor occasionally...
William B Dwinnell
I was wondering if anyone knew of a source of old (early 1980's)
computer magazines, especially "Compute!". Mail-order would be fine,
but actual stores in the Pittsburgh or Philadelphia areas would be
even better. Thanks!
David Breneman
:
: Sure: the IBM 305 RAMAC. It had a single head arm which *must* have been
: designed by someone who was familiar with the pre-WWII Wurlitzer juke
: boxes. When the unit was commanded to move to a different surface the
: head was swung clear of the disks, then dragged up or down a column,
: and re-inserted into the disk stack. The closest thing in today's
: environment to this type of motion is probably the monster multi-terabyte
: optical juke boxes. The STC tape silo doesn't even come close.
Well, not to be *too* nit-pickey...
The process you describe mirrors the process by a Seeburg juke box
design from the early '30s. The records, about a dozen of them,
were attached to a common vertical spindle with enough room for the
tone arm to swing in between and play the record selected. To make
a selection, the patron twisted a knob on front to the desired
number, raising or lowering the tone arm in relation to the stack
of records. Inserting the coin started the shaft turning, and
moved the tone arm into the start groove to play the record.
This system had two drawbacks: 1) No memory; you could only
select one song at a time. 2) If the spindle warped, the tone
arm would get wedged between the disk it was playing and the
underside of the disk above, possibly the world's first head crash!
The Wurlitzer Simplex mechanism of the mid-30's to late-40's had
each record in a swinging tray pivoting from a common vertical shaft.
The turntable dropped down past the plane of bottom of the rack of
trays, the tray for the selected record swung out over the turntable,
then the turntable rose through the extended tray, picking up the
record it encountered and lifting it to level of the tone arm which
was slightly above the plane of the topmost tray. After the selection
played, the turntable dropped down, leaving the record on its tray
which then swung back into the rack.
--
David Breneman Email: da...@jaws.engineering.dgtl.com
System Administrator,
Software Engineering Services
Digital Systems International, Inc. Voice: 206 881-7544 Fax: 206 556-8033
Neville Holmes
>[......]
>Yes, plated wire memory too. Much more advanced than 'core'... It was
>amazing what you could do in 25K on a 1904A if you had to.
Since the subject is ICL and wire and drums, I remember an ICT (or was it BTM?)
calculator with a drum main store. But the data was stored on a wire wrapped
around the drum. The wire was attached at each end by a screw. Each track
was three close packed turns, with a wider spacing between tracks.
I remember because one night the wire broke. Gave a new meaning to "rewiring" !
--
-------------------------------------------------------------------------------
Neville Holmes AARNET: Neville...@appcomp.utas.edu.au
Dept of Applied Computing & Maths Phone : +61 03 243 393 or (003) 243 393
University of Tasmania - Launceston Fax : +61 03 243 368 or (003) 243 368
Neville Holmes
>argument of "what is a drum". After all, I've seen a lot of disks mounted
>on their sides, (IBM were rather fond of doing that with (phisically!) big
>
Which ones ?? The 350 (late '50s) and 1405 (early '60s) were IBM's last
big ones, and the most popular, and they were two meters high with a vertical
axis. Later ones were head per surface at least, had vertical axes, and
weren't anywhere as big. Not the disks themselves. Some of the boxes
were big, but usually had disk drives in pairs, one above the other.
Now I did hear that Sperry-Univac's big disk file system of the late '50s
had a horizontal axis ! ?
BTW, since disks and drums seem popular nostalgia fodder, what about a thread
on NCR's CRAM and IBM's 2250 (was that the number ? names are so much easier
to remeber than numbers !)
Don Stokes
> Which ones ?? The 350 (late '50s) and 1405 (early '60s) were IBM's last
> big ones, and the most popular, and they were two meters high with a vertical
> axis. Later ones were head per surface at least, had vertical axes, and
> weren't anywhere as big. Not the disks themselves. Some of the boxes
> were big, but usually had disk drives in pairs, one above the other.
Big by modern standards -- 14" platters or thereabouts. The kinds of
drives you'd find on a System/38, although I'd seem them lurking outside
shops running much bigger systems. I'm no connoisseur of IBM gear, so
can't give you model numbers. (We were getting rid of the /38 -- I was
system managing the replacement VAX systems.)
Anyway, this thing had 14" or thereabouts Winchester drives, mounted with
the spindle horizontal, and the actuators at an odd angle. Sort of like:
_____________
| / -_ |
Actuators>-_ _----_ |
| -/ \ |
| \ disk / |
| -____- |
|_____________|
(Ugh, circles are hard to draw in ASCII!)
Henry Troup
|>Head-per track disk drives have been made, as have moving head drums.
Indeed. Head per track drives are often called "drums." We still call
our semi-conductor fast paging store "drums."
Henry Troup - H.T...@BNR.CA (Canada) - BNR owns but does not share my opinions
God gives us nuts, but He doesn't crack them.
Sam Drake
>In article <1115...@zl2tnm.gen.nz>, d...@zl2tnm.gen.nz (Don Stokes) writes:
>> After all, I've seen a lot of disks mounted
>>on their sides, (IBM were rather fond of doing that with (phisically!) big
>>drives, ....
>>
>Which ones ?? The 350 (late '50s) and 1405 (early '60s) were IBM's last
>big ones, and the most popular, and they were two meters high with a vertical
>axis.
The popular IBM 3380 disk drives, produced throughout the decade of the
1980s, all had horizontal axes, with two 14" head-disk assemblies
(HDAs) side-by-side in a 2 meter tall box.
I believe the IBM 3370 and IBM 3375 disk drives, circa 1980-1985, were also
mounted with horizontal axes.
Robert Bernecky
>tecdah1@sdc (Dave Hough,55095) writes:
>
>>p.s. Anyone out there ever seen a disk with fewer heads than surfaces that still
>> managed to read all the surfaces on the drive?
>
>Sure: the IBM 305 RAMAC. It had a single head arm which *must* have been
>designed by someone who was familiar with the pre-WWII Wurlitzer juke
>boxes. When the unit was commanded to move to a different surface the
>head was swung clear of the disks, then dragged up or down a column,
>and re-inserted into the disk stack. The closest thing in today's
>environment to this type of motion is probably the monster multi-terabyte
>optical juke boxes. The STC tape silo doesn't even come close.
There was one of these at Caltech in 1964, if memory serves me correctly,
connected to the 7044 and the 7094 via some sort of homebrewed
shared channel interface. (ANyone have details on this?)
It was this sharing that determined the need for command chaining
on disks. Without command chaining, you got the following:
7044: hmm. Time to read some disk. Lessee here, where's that
seek arm:
{i/o to read seek arm position}
7044: Rats. It's in the wrong place. I'll just move it where I
want it, and then go do the read.
{i/o to move arm}
7094: Hmm. Time to read some disk .Lessee here, I moved the
arm where I wanted it a while, ago, but just to be safe, I'll
check its position.
{i/o to read seek arm position}
7094: Rats. It's in the wrong place. I'll just move it...
(Do the above a lot of times until the disk drive breaks
or the operator notices.)
COmmand chaining assembled a non-breakable string of seek/search/read/write
commands, which would keep the other machine's paws out of the way,
at least during that set of commands.
Bob
Robert Bernecky r...@yrloc.ipsa.reuter.com bern...@itrchq.itrc.on.ca
Snake Island Research Inc (416) 368-6944 FAX: (416) 360-4694
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9
Canada
Jim Finnis
tom_va...@taligent.com (Tom Van Vleck) burbled:
>The Bryant salesman told us a story, may be urban legend, about an
>experimental drum, running at very high RPM in a vacuum box.
>Someone opened the door and the implosion drove the heads into the
>drum surface, causing the drum to hop out of its bearings and
>act like a 1-ton gyroscope, wandering the lab smashing equipment.
I seem to recall an anecdote about some high rpm disks installed here
which suffered a slight malfunction. As I recall, the axle sheared
due to metal fatigue and one platter immediately flew off, cut through the
(rather thick) enclosure and embedded itself six inches in the machine
room wall. Inches away from an operator's head. So, all you oppos out there
should hie you to your local insurance broker and get some cover for
occupational decapitation...
--
-----------------------------------------------------------------------------
Jim Finnis, | Unit 6A, Science Park, Aberystwyth, Dyfed, SY23 3AH
Clef Digital Systems |
cl...@aber.ac.uk | Tel.: 0970 626601 Overseas: +44 970 626601
Vadim Antonov
>>The Bryant salesman told us a story, may be urban legend, about an
>>experimental drum, running at very high RPM in a vacuum box.
Huh. Those drums and disks are chicken compared with ultracentrifuges (sp?)
microbiologists use to separate very tiny fractions. I've heard some real
bloody horror stories about them.
--vadim
Valdis Kletnieks
>The Bryant salesman told us a story, may be urban legend, about an
>experimental drum, running at very high RPM in a vacuum box.
>drum surface, causing the drum to hop out of its bearings and
>act like a 1-ton gyroscope, wandering the lab smashing equipment.
Urban legend.
At least the "open the door on the vacuum box" part is.
Let's say the door is a mere 12 inches by 24 inches. That
gives us 288 square inches of door. Let's assume the inside is
running about 0.3 atmospheres - that gives a 10 pounds/square inch
differential (of course, a *real* vacuum would be closer to 14. ;)
2,880 pounds of air pressure holding the door shut. Think you
can pull it open? It's *only* a ton and a half.. ;)
On the other hand, a sudden pressure-related structural failure
could be *quite* dramatic. ;)
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Tom Van Vleck
> Urban legend.
> At least the "open the door on the vacuum box" part is.
Valdis is probably right.
tom <tom_va...@taligent.com>
Hugh JE Davies
I too have heard the stories. (In a previous life, I was a biochemist.) For those
who've never seen an ultracentrifuge, they are generally the size of a chest freezer.
The samples you wish to centrifuge are placed in a conical aluminium holder about
a foot across, 8" high and weighing about 20lbs. These things are very finely balanced,
and the samples have to be likewise. The holder has an airtight lid, because it runs
in vacuum. Once you've sealed up the holder, you place it on a spindle inside the
centrifuge - it's not fastened down - then close a powered, armoured door over the
top. The door, like the whole of the sample chamber, is armoured, partly because
the chamber is evacuated, and partly because the failure modes of these beasts are,
um, interesting. Either the motor bearings fail and the sample holder comes off the
spindle, or the sample holder disintegrates (the sample holders have a lifetime
which must not be exceeded). Either way, 20lbs of aluminium, rotating
at some hundreds of thousands of rpm starts bouncing about inside the centrifuge.
It has been known for the entire centrifuge to launch itself through a wall and
set off down the corridor!
Absolutely nothing to do with a.f.c, but it *was* a previous career, before I
decided that software was more interesting, better paid and doesn't shorten
your lifespan.
---
Regards,
Hugh.
------------------------------------------------------------------
Huge...@rx.xerox.com Rank Xerox Technical Centre, WGC, UK.
I don't speak for Xerox, nor they for me.
"If there is anyone here who I have not insulted, I beg his
pardon." Johannes Brahms (1833-97).
Guy Dawson
If these are the 5000rps ones then tell us more...
>
> --vadim
Robert Bernecky
> tom_va...@taligent.com (Tom Van Vleck) burbled:
>
>>The Bryant salesman told us a story, may be urban legend, about an
>>experimental drum, running at very high RPM in a vacuum box.
>>Someone opened the door and the implosion drove the heads into the
>>drum surface, causing the drum to hop out of its bearings and
>>act like a 1-ton gyroscope, wandering the lab smashing equipment.
It ain't just drums that are potentially life-threatening:
When I was working at Roswell Park Memorial Institute (Cancer hospital
in Buffalo, NY) back in the dark ages, we had some tape drives
on a 704x system that were fairly fast, PARTICULARLY when they went into
high-speed rewind. In those days, a Large disk drive was somewhere around
7 megabytes, so any really large data was stored on tape, so rewind
time was important. These drives screamed when they went into high-speed
rewind!
Anywho, one evening I'm standing in the machine room with Tony, the
evening operator, when behind us, we hear BANG!, and then this black thing
goes flying between us, taking a hunk out of the far machine room wall.
It turns out the hub lock on the tape drive had broken, and once the
10" tape (which is fairly hefty - a few kilos) got moving at about
2000 RPM, it broke loose, smashed through the glass cover on the tape
drive, and went flying across the machine room like a mad frisbee,
albeit one you didn't have time nor inclination to catch. It succeeded
in unwinding a lot of itself around the machine room before it stopped,
and luckily didn't hit anybody, based on the damage it did to things
it DID hit.
It also took us a LONG time to clean up the mess.
Another night, the carriage control tape (tells the printer how long
the paper stick is, and where the top of form is, etc) got damaged, and
when the 1403 printer took its next page skip, it couldn't find
the top of the form, so it sat there skipping continuous forms at
the rate of 8feet per second or so. Very impressive to watch.
Unfortunately, we were out for coffee. When we got back, all 3000 pages
of that entire box of one-part had been skipped. Unfortunately, the
stacker hadn't been able to keep up with it, the printer cover had been
left open (An ear-damage no-no), so the paper skipped right up to ceiling height, and then
proceeded to fill the entire machine room with crumpled 14" wide paper.
That particular incident was fairly funny - walk by the machine window
with coffee in hand, and notice that the window is totally clogged with
paper... -- but the cleanup was even worse than the whirling dervish
runaway tape.
Computers aren't nearly as much fun any more.
Robert Bernecky r...@yrloc.ipsa.reuter.com
Snake Island Research Inc (416) 203-0854
Jim Haynes
In article <1993May19.1...@yrloc.ipsa.reuter.COM> r...@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>Another night, the carriage control tape (tells the printer how long
>the paper stick is, and where the top of form is, etc) got damaged, and
>when the 1403 printer took its next page skip, it couldn't find
>the top of the form, so it sat there skipping continuous forms at
>the rate of 8feet per second or so. Very impressive to watch.
Which makes you wonder why it didn't occur to IBM to do what some other
companies had done and put in a timer that would stop page skipping after
a few seconds of it. Failure of a carriage control tape was a fairly common
occurrence. But then you wonder why most everybody in the business used
carriage control tapes rather than storing the carriage control info
in a little memory attached to the printer. Or just having an assortment
of fast but finite skip distance commands that could be sent to the printer.
Having to prepare and find and change carriage control tapes was a lousy
waste of operator and machine time.
--
hay...@cats.ucsc.edu
hay...@cats.bitnet
"Ya can talk all ya wanna, but it's dif'rent than it was!"
"No it aint! But ya gotta know the territory!"
Meredith Willson: "The Music Man"