Storage Computer looking for PDP-8/11 I/O Edge Connector Blocks
Michael E Willett
The solid state disk folks at Storage Computer are looking for a lot
of 36 pin DEC I/O Edge Connector Blocks (green). These connectors
are found on DEC PDP-8 and PDP-11s, on back planes, interconnect
connectors, RK05 disk drives and many other DEC peripherals. Storage
Computer can use either the wire wrap or solder type connector. They
are also willing to strip them from existing PCBs. They need at
least 100 connectors right away for some PDP modernizations.
The key PDP connector contact in the Storage Computer solid state disk
group is Joe DiGilio at tel. (603) 880-3005.
Mike Willett, Storage Computer, Tel. (603)-880-3005
Nashua, NH
http://www.storage.com/
R. D. Davis
In article <Du95v...@world.std.com>,
Michael E Willett <m...@world.std.com> hideously wrote:
>The solid state disk folks at Storage Computer are looking for a lot
>of 36 pin DEC I/O Edge Connector Blocks (green). These connectors
>are found on DEC PDP-8 and PDP-11s, on back planes, interconnect
>connectors, RK05 disk drives and many other DEC peripherals. Storage
>Computer can use either the wire wrap or solder type connector. They
>are also willing to strip them from existing PCBs. They need at
>least 100 connectors right away for some PDP modernizations.
This appears to one of the sickest, most deranged, postings that I've
seen on the net. Don't these creeps know that PDP-8s are becoming
rare enough without cretins like them attempting to ruin what's left?
PDP-11s aren't being made anymore either, and they don't need to be
destroyed for their connectors, for "modernization" purposes, of all
things.
>The key PDP connector contact in the Storage Computer solid state disk
>group is Joe DiGilio at tel. (603) 880-3005.
He's not getting my PDP-8 or 11s to destroy. Hopefully what he and
the SPAMmer, Mr. Willett, who posted this ad, with the apparent
purpose of PDP destruction, will get are lots of flames; the hotter,
the better. If he needs the connectors this badly, let him first try
to purchase the connectors from DEC if they're still in stock,
manufacture his own connectors, or else make do with a soldering iron.
>Mike Willett, Storage Computer, Tel. (603)-880-3005
If don't mind spending a few cents, dial tha above number and tell
them what you think of their SPAM and what they're doing to our supply
of PDP-8s and 11s, and computer history. I, for one, certainly plan
to do so.
I don't know why they bothered to look in these newsgroups when
they're not too far away from that, in my opinion, computer disection
and bit-sales palace, also known as the Boston Computer Museum, which,
I hear, sells off pieces of history from time to time - they should
have looked there first.
--
R. D. Davis * http://www.access.digex.net/~rdd * Eccentrics have more fun!
Computer preservationist - unwanted older systems removed free of charge :-)
PERQ Logic Systems & Unconventional Computer Consulting
divisions of Transpower Industries, Inc. +1 410 744-4900
Ron Natalie
Far more PDP-11's go into the junk pile than Systems Industries
could ever canabalize into RK05 emulators. Much as I have fond
memories of the PDP-11's, they are by and large junk today. I
extended the lives of many PDP-11's when UNIX became too bloated
to run on them anymore by recycling them into Internet routers
(for a period of time, I had the busiest router on the internet,
a PDP-11/70), but even the time for this use has passed. When
I disposed of these things, NOBODY was interested in them. Hell,
I've got more culturally significant things that I had to dump
as well for lack of a good owner (I had a model 37 teletype, an
upper/lower case thing with a big "NEWLINE" key, and goes a long
way to explain some UNIX quirks than anything else).
However, have manufacturers completely given up on Unibus, such
that new Unibus backplanes aren't available anymore.
-Ron
A.R. Duell
r...@access1.digex.net (R. D. Davis) writes:
[DEC connectors wanted]
>This appears to one of the sickest, most deranged, postings that I've
>seen on the net. Don't these creeps know that PDP-8s are becoming
Oh come on Bob, it's not as bad as that. At least they're not asking for old
computer hardware to 'refine' the gold from. Now that is sick!
>rare enough without cretins like them attempting to ruin what's left?
>PDP-11s aren't being made anymore either, and they don't need to be
>destroyed for their connectors, for "modernization" purposes, of all
>things.
Well, if it's _never_ acceptable to extract parts from old computers,
then you might as well flame me now. The ether-can-tape card in my PERQ
contains 9403 FIFO chips that I removed (non-destructively) from a spare
EIO card. Come on, flame me for 'ruining' an EIO...
At least these connectors are being used to keep some PDP11's running, so
hopefully more systems will be preserved.
>>The key PDP connector contact in the Storage Computer solid state disk
>>group is Joe DiGilio at tel. (603) 880-3005.
>He's not getting my PDP-8 or 11s to destroy. Hopefully what he and
He's not getting mine either, if only because I am still using them, but
these connector blocks are not rare either. While IMHO it is _sick_ to
rip apart one of the rare flip-chip backplanes (like a DX11-B or
something), there's not exactly a shortage of DD11-D unibus system units
is there ?
>the SPAMmer, Mr. Willett, who posted this ad, with the apparent
>purpose of PDP destruction, will get are lots of flames; the hotter,
>the better. If he needs the connectors this badly, let him first try
>to purchase the connectors from DEC if they're still in stock,
If DEC can still supply them, I agree. You shouldn't strip down old
computers for parts if the parts are still available new. But if DEC can
no longer supply them, then you have to get them from elsewhere.
>manufacture his own connectors, or else make do with a soldering iron.
One 3rd-party unibus peripheral I have seen used S100 connectors (100
pin, 0.125" pitch) with bits of blank circuit board epoxyed into them to
make the cable locate correctly. That may be a possible solution.
>R. D. Davis * http://www.access.digex.net/~rdd * Eccentrics have more fun!
--
-tony
ar...@eng.cam.ac.uk
The gates in my computer are AND,OR and NOT, not Bill
Tim Shoppa
In article <4rtr74$5...@access1.digex.net>,
R. D. Davis <r...@access1.digex.net> wrote:
>In article <Du95v...@world.std.com>,
>Michael E Willett <m...@world.std.com> hideously wrote:
>>The solid state disk folks at Storage Computer are looking for a lot
>>of 36 pin DEC I/O Edge Connector Blocks (green). These connectors
>
>seen on the net. Don't these creeps know that PDP-8s are becoming
>PDP-11s aren't being made anymore either, and they don't need to be
>destroyed for their connectors, for "modernization" purposes, of all
>things.
If the good work that the folks at Storage Computer wasn't done,
useful machines would end up being sent to the junk pile because of the
lack of modern compatible peripherals. Is this what you want to see?
You may see PDP-8's and -11's as collectors items, but in the two
decades that I've been working with them I've seen them doing enough
useful things that I'd prefer they continue doing useful work, rather
than sit in somebody's garage. I have absolutely no qualms about
taking a couple of connectors out of a unused backplane if it helps keeps
a fine machine useful.
Tim. (sho...@triumf.ca)
R. D. Davis
In article <4ru2ph$o...@lyra.csx.cam.ac.uk>,
A.R. Duell <ar...@eng.cam.ac.uk> wrote:
>r...@access1.digex.net (R. D. Davis) writes:
>
>[DEC connectors wanted]
>
>>seen on the net. Don't these creeps know that PDP-8s are becoming
>
>computer hardware to 'refine' the gold from. Now that is sick!
Awwww, did you have to go and mention something disgusting like that?
It's enough to ruin one's day. :-<
>>rare enough without cretins like them attempting to ruin what's left?
>>PDP-11s aren't being made anymore either, and they don't need to be
>>destroyed for their connectors, for "modernization" purposes, of all
>>things.
>
>Well, if it's _never_ acceptable to extract parts from old computers,
I didn't mean never acceptible. If it was never acceptible, then I'd
have to flame myself as well (which I have done in the past). I don't
like scavenging, but I've had to do it to keep some of my systems
alive. It's just tha I don't approve of the idea of obtaining large
quantities of parts this way for the purposes of modernization. Now
then, if he'd stated that they wanted non-working systems for parts so
that they can use them to keep other systems running, I'd not have
flamed the poster.
>then you might as well flame me now. The ether-can-tape card in my PERQ
>contains 9403 FIFO chips that I removed (non-destructively) from a spare
>EIO card. Come on, flame me for 'ruining' an EIO...
No. That's an entirely different matter.
>At least these connectors are being used to keep some PDP11's running, so
>hopefully more systems will be preserved.
Hopefully I was wrong in my interpretation of that posting; I took his
message to mean that he wanted to use these bits with new equipment of
some sort that is being used to modernize things, not to keep older
PDP-11s or PDP-8s running.
>>>The key PDP connector contact in the Storage Computer solid state disk
>>>group is Joe DiGilio at tel. (603) 880-3005.
>
>>He's not getting my PDP-8 or 11s to destroy. Hopefully what he and
>
>He's not getting mine either, if only because I am still using them, but
>these connector blocks are not rare either. While IMHO it is _sick_ to
>rip apart one of the rare flip-chip backplanes (like a DX11-B or
>something), there's not exactly a shortage of DD11-D unibus system units
>is there ?
If the DD11-D is what I think it is, the answer should be no.
> >the SPAMmer, Mr. Willett, who posted this ad, with the apparent
>>purpose of PDP destruction, will get are lots of flames; the hotter,
>>the better. If he needs the connectors this badly, let him first try
>>to purchase the connectors from DEC if they're still in stock,
>
>If DEC can still supply them, I agree. You shouldn't strip down old
>computers for parts if the parts are still available new. But if DEC can
>no longer supply them, then you have to get them from elsewhere.
Precisely. Since DEC is just discontinuing their PDPs, including the
11/84 (or is that the 11/94?) systems, they should have plenty of
Unibus backplane bits in stock. Hence, a company that wants these
bits for commercial usage doesn't need to destroy lots of other older
systems to get these bits.
Of course, if the parts are no longer available, and they want to do
what I think that they want to do, then they ought to use a soldering
iron and connect something that way. A perfectly simple solution,
what?
--
R. D. Davis * http://www.access.digex.net/~rdd * Eccentrics have more fun!
A.R. Duell
sho...@alph02.triumf.ca (Tim Shoppa) writes:
>You may see PDP-8's and -11's as collectors items, but in the two
PDP8's and PDP11's _are_ collectors items, if only because they're not
being made any more. IMHO, any that are not doing useful work should be
rescued, restored, and used.
That does not stop them being used for useful work, of course. Running an
old computer shouldn't damage it.
>decades that I've been working with them I've seen them doing enough
>useful things that I'd prefer they continue doing useful work, rather
>than sit in somebody's garage. I have absolutely no qualms about
And I'd rather see them in somebody's garage (or machine room) than in a
skip...
>taking a couple of connectors out of a unused backplane if it helps keeps
>a fine machine useful.
Ditto, provided that backplane is relatively common. There are a few
flip-chip based PDP11 peripherals (and I guess PDP8 peripherals) that are
not at all common, and should be preserved as collectors items. I would
not want to strip those for the (relatively common) connector blocks.
>Tim. (sho...@triumf.ca)
A.R. Duell
r...@access1.digex.net (R. D. Davis) writes:
>>At least these connectors are being used to keep some PDP11's running, so
>>hopefully more systems will be preserved.
>Hopefully I was wrong in my interpretation of that posting; I took his
>message to mean that he wanted to use these bits with new equipment of
>some sort that is being used to modernize things, not to keep older
>PDP-11s or PDP-8s running.
I believe this company manufactures disk drives and similar peripherals
that are used with PDP-11's, to replace the somewhat low-capacity (and
unreliable if not properly maintained) older DEC devices.
Now, while _I_ enjoy looking after my rack of RK05's and RL's, I can
quite understand that a lot of commercial sites would prefer to replace
them with winchesters or semiconductor storage.
>If the DD11-D is what I think it is, the answer should be no.
The DD11-D is the common 9-slot unibus backplane that seems to be very
common.
>Of course, if the parts are no longer available, and they want to do
>what I think that they want to do, then they ought to use a soldering
>iron and connect something that way. A perfectly simple solution,
>what?
Well, considering these devices are meant to plug in to the standard
Unibus (or RK05) cables, I would have thought that getting the right
connectors was the correct thing to do. I'd rather not have to solder
wires to the end of a cable when it's fitted with a perfectly good edge
plug, thanks...
>R. D. Davis * http://www.access.digex.net/~rdd * Eccentrics have more fun!
--
R. D. Davis
In article <4ru4n3$p...@lyra.csx.cam.ac.uk>,
A.R. Duell <ar...@eng.cam.ac.uk> wrote:
>sho...@alph02.triumf.ca (Tim Shoppa) writes:
>
>>You may see PDP-8's and -11's as collectors items, but in the two
>
>PDP8's and PDP11's _are_ collectors items, if only because they're not
>being made any more. IMHO, any that are not doing useful work should be
>rescued, restored, and used.
Well said.
>That does not stop them being used for useful work, of course. Running an
>old computer shouldn't damage it.
Very true. While running them may caus some wear on some
electro-mechanical parts, and help some components to deteriorate
(even if ever so slightly, like EEPROMs), it can also be harmful to
the computers to not use them. Hence, one may as well use them and
get the enjoyment that comes from using them, as not using them won't
really help very much. Just my two cents worth on this matter.
>>decades that I've been working with them I've seen them doing enough
>>useful things that I'd prefer they continue doing useful work, rather
>>than sit in somebody's garage. I have absolutely no qualms about
>
>And I'd rather see them in somebody's garage (or machine room) than in a
>skip...
Indeed. Of course, as I mentioned earlier, we wouldn't have some of
the nice things that we have if no one ever tossed such things into
skips. However, I cringe at the thought of someone tossing such
equipment into a skip that no one will get to rescue before the skip
gets dumped into a garbage truck.
--
R. D. Davis * http://www.access.digex.net/~rdd * Eccentrics have more fun!
David M. Razler
r...@access1.digex.net (R. D. Davis) wrote:
>In article <Du95v...@world.std.com>,
>Michael E Willett <m...@world.std.com> hideously wrote:
>>The solid state disk folks at Storage Computer are looking for a lot
>>of 36 pin DEC I/O Edge Connector Blocks (green). These connectors
>>are found on DEC PDP-8 and PDP-11s, on back planes, interconnect
>>connectors, RK05 disk drives and many other DEC peripherals. Storage
>>Computer can use either the wire wrap or solder type connector. They
>>are also willing to strip them from existing PCBs. They need at
>>least 100 connectors right away for some PDP modernizations.
>
>This appears to one of the sickest, most deranged, postings that I've
>seen on the net. Don't these creeps know that PDP-8s are becoming
>rare enough without cretins like them attempting to ruin what's left?
>PDP-11s aren't being made anymore either, and they don't need to be
>destroyed for their connectors, for "modernization" purposes, of all
>things.
>
>He's not getting my PDP-8 or 11s to destroy. Hopefully what he and
>the SPAMmer, Mr. Willett, who posted this ad, with the apparent
>purpose of PDP destruction, will get are lots of flames; the hotter,
>the better. If he needs the connectors this badly, let him first try
>to purchase the connectors from DEC if they're still in stock,
>manufacture his own connectors, or else make do with a soldering iron.
>
>>Mike Willett, Storage Computer, Tel. (603)-880-3005
>
>If don't mind spending a few cents, dial tha above number and tell
>them what you think of their SPAM and what they're doing to our supply
>of PDP-8s and 11s, and computer history. I, for one, certainly plan
>to do so.
>
>I don't know why they bothered to look in these newsgroups when
>they're not too far away from that, in my opinion, computer disection
>and bit-sales palace, also known as the Boston Computer Museum, which,
>I hear, sells off pieces of history from time to time - they should
>have looked there first.
>
Well, maybe someone *else* wants what is left of my burned-out module-less
M-series backplanes for a PDP-15 and several 18-bit memory modules? <that
*seems* to be what they want> I called to check.
I would never damage a good or repairable machine. But I have a few complete
18-bit PDP-15 backplanes that were given to me *as* scrap, for me to unwrap,
cut apart, etc., something that never happened.
Now if anyone wants to give them a good home, like the rest of my unwanted old
hardware, they're up for grabs.
But if all they are *ever* going to do is collect dust....
<again, I have no idea if those dark green M-board connectors are what the
company wants, since the post itself was kind of badly writ and it seems the
author doesn't really know and has promised me a tech will call me back with
the real specs.>
dmr
David M. Razler
david....@worldnet.att.net
Douglas W. Jones,201H MLH,3193350740,3193382879
From article <4rtr74$5...@access1.digex.net>,
by r...@access1.digex.net (R. D. Davis):
>>The solid state disk folks at Storage Computer are looking for a lot
>>of 36 pin DEC I/O Edge Connector Blocks (green). These connectors
>>are found on DEC PDP-8 and PDP-11s, on back planes ....
>
> This appears to one of the sickest, most deranged, postings that I've
> seen on the net. Don't these creeps know that PDP-8s are becoming
> rare enough without cretins like them attempting to ruin what's left?
> PDP-11s aren't being made anymore either, and they don't need to be
> destroyed for their connectors, for "modernization" purposes ...
Give the guy a break. His company is selling solid state disk drive
replacements for PDP-8 and PDP-11 systems. The market is there -- there
are plenty of working -8 and -11 systems with useful lifetimes that can
be extended by quite a bit if only the old RK05 disk drives could be
replaced. For example, GE Canada has a problem with the PDP-8 systems
that run the refueling cycle on the Candu nuclear reactors. Getting new
hardware and software certified for that application is monsterously
expensive, and the supply of RK05 disk drives and parts has become a
potential limiting factor in the lifetimes of those power plants.
The availablity of modern replacements has allowed GE Canada to replace
a drive here and there with modern (and fairly easy to certify) hardware,
scrapping the drives they replace in order to get parts for other drives.
So, the problem they face is, if you're building PDP 8/11 compatable
hardware, how do you interface it to the PDP 8/11 disk controller. The
company designed their stuff to be plug compatable, relying on the fact
that they could buy the necessary connector blocks from DEC.
> If he needs the connectors this badly, let him first try
> to purchase the connectors from DEC if they're still in stock ...
DEC has discontinued the connector blocks used to manufacture FLIP-CHIP
compatable backplanes and interconnect systems.
While we who are interested in antique computers hate to see equipment
go to the scrapyard, there are plenty of DEC thinguses that are being
scrapped. Better to salvage what can be used than to shred them.
Furthermore, there are plenty of one-off mystery peripherals out there
that were built from DEC FlipChip modules by customers and that nobody
will ever manage to figure out and use. The modules in those mystery
backplanes make a fine source of spares, but what about the backplanes
themselves? I propose that unwrapping the mystery backplanes and
reusing the connector blocks is far better than junking them!
Doug Jones
jo...@cs.uiowa.edu
John Wilson
In article <Du95v...@world.std.com>,
Michael E Willett <m...@world.std.com> wrote:
>The solid state disk folks at Storage Computer are looking for a lot
>of 36 pin DEC I/O Edge Connector Blocks (green).
The AMP PCB connector catalog has DEC-style connectors listed on a page
marked "AMP PACE Connector Specials ... (Can be made available upon request)",
which presumably means you pay through the nose but it's better than nothing.
The part numbers are 119552-2 for .74" pins (i.e. wire wrap style) or 119880-1
for .18" pins, this is for one dual-height double-sided connector with the
usual .125" spacing and keyed slots so you'll probably need to stack them up.
You might also try surplus. Radar Electronics in Seattle used to have a few
unused DEC H863 4x2 connector blocks for $.95 each, so it happens. But they're
all gone now.
John Wilson
D BIT
Harry H Conover
R. D. Davis (r...@access1.digex.net) wrote:
: This appears to one of the sickest, most deranged, postings that I've
: seen on the net. Don't these creeps know that PDP-8s are becoming
: rare enough without cretins like them attempting to ruin what's left?
: PDP-11s aren't being made anymore either, and they don't need to be
: destroyed for their connectors, for "modernization" purposes, of all
: things.
Why doesn't he just check with Amp, and get a price. They'll likely
sell him all of theese connectors he wants.
Harry C.
David M. Razler
To all those who may wish to kill me now, an explanation first:
I just furnished ST with some blocks - from the ghost of a PDP-15. It
hurt me to do so, but... A long time ago, I was given a fairly non-functional
PDP-15, its core and cpu backplanes so patched that they *never* ran right. I
worked like hell on the thing, but the best I ever got it to do was run as CPU
and first 8K of memory, for the IO and memory buses were not in accordance to
anything resembling spec.
A *second* PDP-15 came my way, sans cabinets. Set me back $2,000. A
brain transplant was performed, and the new machine ran like a champ for me
until I was forced to pass it on to someone who had room for my seven-cabinet
system. The modules from the brain-dead CPU became spares, and most got used
in the end. Backplanes that ran when cards were properly installed were
filled, some were given away for other 18-bit machines, others were traded.
I was left with backplane, loaded with wrap wire, useless. It still,
as I said, hurt like hell to dissect it, though I knew there was no way that I
was ever going to get a complete set of PDP-15 CPU boards ever again, nor
would the old backplane work properly, even with the boards.
For 18 years, the backplanes sat empty, unused, unwanted by anyone for
trade or gift. Now they are gone. a "computer" sans logic (for that matter all
electronics) and cabinets is no more. sic transit gloria 18-bits.
Joe Digilio
The reason that we are looking for the PDP-8/11 I/O Edge Connector Blocks is for our
Solid State Disk Emulator. The Solid State Disk is a plug compatible replacement
for the legacy DEC RK05 disk drives. We are providing a solution to PDP 8 and PDP
11 users who like their systems and want to continue to use them. The problem that
they face is RK05 disk drive failures/repairs. Our solution preserves the PDP 8s
and PDP 11s.
BELOW IS FURTHER INFORMATION ON OUR Solid-State Disk Emulator.
What is a Solid-State Disk Emulator?
A Solid-State Disk is a device that contains no moving parts and is made up of
Highly-Reliable Dynamic Random Access Memory chips. The Solid-State Disk replaces
your old, aging 14-inch mechanical cartridge disk drives in "form, fit, and
function."
What disk drives does the Solid-State Disk replace?
The Solid-State Disk replaces the 14-inch cartridge disk drives and drum (head per
track) memories that were manufactured in the 70’s and early 80’s. These disk
drives are referred to as either the cartridge type devices or the SMD type devices.
Typical cartridge type devices are the CDC Hawk, Diablo, RK05, RL01, RL02, Pertec,
and Wangco, and contain 2 to 20 MB of data. The SMD type devices are the CDC 9762
and CDC 9766, and contain 80 to 300 MB of data. the SMD disk drive are typically
referred to as "washing machines" because of their physical size.
How do I know if there is an application for a Solid-State Disk Emulator?
Do you have an old computer system (like a PDP 11 or PDP 8) that you must keep
operating due to the large investment in hardware and more importantly software? If
the answer is yes, then the Solid-State Disk is your solution to mechanical disk
drives that are prone to failure, obsolescence, and are difficult to maintain and
service.
Does the Solid-State Disk Emulator require any Hardware or Software Changes to my
host computer system?
No! The Solid-State Disk is a plug compatible device to the existing host and
requires no changes to your current hardware or software.
How do I get my data from the 14-inch Cartridge/Platters to the Solid-State Disk
Emulator?
The procedure to transfer your data is both simply and easy. All you need to do is
daisy-chain the Solid-State disk to the existing disk drive on your system, format
as normal and do a disk copy. Once the data has been transferred to the Solid-State
Disk, simply save it to the removable backup media; disk or tape.
Why should I buy a Solid- State Disk Emulator?
FEATURE BENEFIT
System Immortality.....................Preserves Legacy Systems
High reliability - Solid State Disk....Satisfied Users
Fault Resilient, 11.5 years MTBF.......No System Downtime
Plug Compatible........................No Software Changes
........................No Hardware Changes
UPS....................................Guaranteed Data Integrity
Removable Media........................Transportability, Archival of
Critical Data
Joe Digilio, email: jdig...@storage.com: tel 603-880-3005
Solid State Disk Group
Storage Computer Corp., Nashua, NH
Michael E Willett
con...@tiac.net (Harry H Conover) writes:
>R. D. Davis (r...@access1.digex.net) wrote:
>: This appears to one of the sickest, most deranged, postings that I've
>: seen on the net. Don't these creeps know that PDP-8s are becoming
>: rare enough without cretins like them attempting to ruin what's left?
>: PDP-11s aren't being made anymore either, and they don't need to be
>: destroyed for their connectors, for "modernization" purposes, of all
>: things.
They're not taking any operational PDPs whatsoever out of any IT production
sites. Rather, they're updating those PDPs with modern, highly reliable,
very fast storage, extending the operational lives of the PDPs.
M Willett
mwil...@storage.com
Storage Computer
11 Riverside St.
Nashua, NH 03062
Tel 603-880-3005
http://www.storage.com/
R. D. Davis
In article <DuEpI...@world.std.com>,
Michael E Willett <m...@world.std.com> wrote:
>They're not taking any operational PDPs whatsoever out of any IT production
>sites. Rather, they're updating those PDPs with modern, highly reliable,
>very fast storage, extending the operational lives of the PDPs.
I apologize for the rather strong flames, and do appreciate that
you're extending the operational lives of PDPs - this will be very
helpful to many people. However, I would hope that you'd kindly look
into all possible alternatives before you decide to use any parts
which are either rare, or on their way to becoming rare, such as
Omnibus backplanes, and that you'd not tear apart any working systems
just for these parts if any other alternatives are available.
David Moisan
ar...@eng.cam.ac.uk (A.R. Duell) wrote:
>Well, if it's _never_ acceptable to extract parts from old computers,
>then you might as well flame me now. The ether-can-tape card in my PERQ
>contains 9403 FIFO chips that I removed (non-destructively) from a spare
>EIO card. Come on, flame me for 'ruining' an EIO...
What Mr. Davis is missing: If one is going to restore an old computer
to use, cannabilization or modernization is a fact of life. Period.
Else what's the point in keeping these machines? When I first started
reading alt.sys.pdp8 to keep my DECMate going, almost all the posters
either bemoaned the fact that no one was using such systems or boasted
about using their systems for real work.
(I use my DM to log on to the net occasionally. After I finish
unpacking it from a move, I intend to port KA9Q to it to use as a
router. It's not a vanity system--I am an old DEC hacker who's as
reverent of the company as anyone else here.)
I've had to cannabilize two VR201 monitors to make one good one--one
monitor had bad electronics and a good tube and the other had a bad
tube but good electronics, so shoot me as well. When I was using a
Tek RM15 scope, I had to scavenge parts for the plug-ins I needed from
junked, busted plug-ins. You try finding the rear connector for a Tek
1- or 3- series in a catalog, to say nothing of knobs and switch
decks.
(And because I'm moving into a smaller apartment, I have to be rid of
the Tek. :( Where are the tears? Where are the purists in the Boston
area running to take this piece of valuable history off my hands?)
Dave
| David Moisan, N1KGH Email: dmo...@shore.net |
| WWW: http://www.shore.net/~dmoisan n1...@amsat.org |
| Invisible Disabilities Page: |
| http://www.shore.net/~dmoisan/invisible_disability.html |
DoN. Nichols
In article <4s4m7m$a...@access1.digex.net>,
>Michael E Willett <m...@world.std.com> wrote:
>
>>They're not taking any operational PDPs whatsoever out of any IT production
>>sites. Rather, they're updating those PDPs with modern, highly reliable,
>>very fast storage, extending the operational lives of the PDPs.
>
>I apologize for the rather strong flames, and do appreciate that
>you're extending the operational lives of PDPs - this will be very
>helpful to many people. However, I would hope that you'd kindly look
>into all possible alternatives before you decide to use any parts
>which are either rare, or on their way to becoming rare, such as
>Omnibus backplanes, and that you'd not tear apart any working systems
>just for these parts if any other alternatives are available.
Just as a point of information, for those of us who are not familiar
with the various backplanes, but may encounter one at a hamfest or surplus
sale:
How are we to recognize a particular backplane? What would
distinguish an Omnibus backplane from any of the many others (other than
part numbers, which are likely to be easy to forget, and not present when you
encounter the backplane in question?
Thanks,
DoN.
--
Email: <dnic...@d-and-d.com> | Donald Nichols (DoN.)
Voice Days: (703) 704-2280 | Eves: (703) 938-4564
My Concertina web page: | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
A.R. Duell
Joe Digilio <jdig...@storage.com> writes:
[...]
>How do I know if there is an application for a Solid-State Disk Emulator?
>Do you have an old computer system (like a PDP 11 or PDP 8) that you must keep
>operating due to the large investment in hardware and more importantly software? If
>the answer is yes, then the Solid-State Disk is your solution to mechanical disk
>drives that are prone to failure, obsolescence, and are difficult to maintain and
>service.
Just out of curiousity, how easy is the Solid-State Disk Emulator to
service? The RK05's, RL's, CDC's, etc that it replaces are, IMHO, very
easy to keep running. There are excellent technical manuals available,
there are no hard-to-find custom chips (all the chips in these drives are
still available AFAIK), etc. Replacing the heads and realigning an RK05
takes about an hour, and an RL is even quicker. How does your product
compare?
Do you supply full technical manuals/schematics, or am I going to have
problems in 10 years time when the chips start failing?
Am I even going to be able to find the spare chips in 10 years time?
> Joe Digilio, email: jdig...@storage.com: tel 603-880-3005
> Solid State Disk Group
> Storage Computer Corp., Nashua, NH
--
Tim Shoppa
In article <4sdqrb$m...@helios.oit.unc.edu>,
Charles Lasner <las...@helios.oit.unc.edu> wrote:
>While it may be true on certain PDP-11 systems, Most PDP-8 systems aren't
>as much "captive" to the mediocre design of the RK05, thus there is far
>less impetus to slavishly clone this unimpressive beast.
>
>Originally, even PDP-11 systems had the relative ease of having their
>drivers changed to accomodate third-party (and often far superior) disk
>sub-systems. Eventually, DEC changed all that by withholding the
>necessary documentation and/or utilities to make for alternate devices,
>etc.
Really? I've had no problem using the standard documentation to
write device drivers for RT-11 and RSX-11M and 11M+ for custom tape,
disk, and data acquisition devices. The RT and RSX manuals have,
as far as I know, always included an entire binder dedicated to
walking you through the process of writing, debugging, and installing
a device driver.
> thus newer systems were often lock-step Digital; third-party makes
>produced totally-compatible peripherals, even when this meant a drastic
>drop in potential performance.
Yes, third-party boards often emulate DEC devices. This is very
convenient if, say, you are installing from tape and don't have a
DEC disk drive. The bootstrap code on the tape only knows how to
drive DEC devices, after all!
>Contrast this with the CESI MDC8 interface which allows up to 32K of
>12-bit transfers from a single SCSI read/write request off-loaded to the
>onboard micro.
If I wanted to buy a CESI MDC8, where could I get one?
Tim. (sho...@triumf.ca)
Ron Natalie
I bet the heads don't crash as much on the solid state ones :-)
Frankly, our biggest problem was the cartridges picking up crap.
Can you still get these things?
Jeez, I was happy when I could replace the boot devices on our
last PDP-11's (that were playing internet router) with floopys.
-Ron
A.R. Duell
Ron Natalie <r...@sensor.com> writes:
>I bet the heads don't crash as much on the solid state ones :-)
My experience suggests that if you follow the PM schedule in the manual,
and even do a few more things (stripping the fan motor and lubricating
the bearings, for example), then RK05's are very reliable - certainly a
lot more reliable than the sort of floppy drives you find in PCs.
I've only ever come across one headcrash on an RK05, and that was not on
any of the drives I was maintaining. No idea what happened, - the upper
(down) head decided to crash. It took about an hour to replace it and
realign the drive.
>Frankly, our biggest problem was the cartridges picking up crap.
You should clean the cartridges every 6 months, I think. Unless you are
doing something silly, they do not 'pick up crap' in my experience. Of
course you should keep them in as dust-free a location as possible. Of
course damaged heads or a blocked air filter can lead to disk damage, and
then to more head damage, etc.
>Can you still get these things?
Yes, AFAIK you can. They're pretty common second-hand as well.
>Jeez, I was happy when I could replace the boot devices on our
>last PDP-11's (that were playing internet router) with floopys.
Odd... I'm trying to replace the unreliable floppies I now get with
RK05's.....
>-Ron
R. D. Davis
In article <4s16sp$3...@RedDragon.Empire.Net>,
Joe Digilio <jdig...@storage.com> wrote:
>The reason that we are looking for the PDP-8/11 I/O Edge Connector Blocks
>is for our
>Solid State Disk Emulator. The Solid State Disk is a plug compatible
>replacement
>for the legacy DEC RK05 disk drives.
The RK05 disk drive is a very repairablke drive; perhaps you should be
concentrating on providing third-party replacement parts to keep these
drives running, instead of producing things which may possibly be
rather difficult to repair in a few years' time.
Before I pass judgement on your solig-state disk drives, there's something
which you need to tell all of us who use PDP-8 and PDP-11 systems: if you're
going to make schematic diagrams, detailed information about any custom ICs
used, firmware source code (if applicable), etc. available to purchasers
of your pdoducts, for a reasonable cost.
>We are providing a solution to
Ah, but you fail to state whether the solution which you are providing
is a good or a bad solution. Methinks it to be a not so good one based
upon what I've read thus far - hopefully you'll prove me wrong.
>PDP 8 and PDP
>11 users who like their systems and want to continue to use them. The
>problem that
>they face is RK05 disk drive failures/repairs. Our solution preserves the
>PDP 8s
>and PDP 11s.
A better solution would be to help PDP-8 and -11 users keep these disk
drives running - they're more fun to use and more impressive to look
at than the average little tiny solid-state "disk" drive.
>BELOW IS FURTHER INFORMATION ON OUR Solid-State Disk Emulator.
>
>What is a Solid-State Disk Emulator?
>
>A Solid-State Disk is a device that contains no moving parts and is made
>up of
>Highly-Reliable Dynamic Random Access Memory chips. The Solid-State Disk
>replaces
>your old, aging 14-inch mechanical cartridge disk drives in "form, fit, and
>function."
What makes you think that some of us want to replace our 14" hard drives?
I'd rather be able to keep mine running. The same goes for my 8" hard
drives and 8" floppy drives.
>What disk drives does the Solid-State Disk replace?
Devices which are more easily repairable and more fun to use than a
so-called solid-state disk drive. Actually, all of my disk dives are
solid state anyway, as their active electronic components are all
solid-state - not one electron valve in one of my disk drives.
Perhaps it would be a fun experiment to replace a few of the power
transistors with electron valves. :-)
>The Solid-State Disk replaces the 14-inch cartridge disk drives and drum
>(head per
>track) memories that were manufactured in the 70’s and early 80’s.
>These disk
>drives are referred to as either the cartridge type devices or the SMD
>type devices.
I still don't understand why anyone would want to replace these if
they could keep these devices running. Perhaps you could develop some
versions of these with higher capacity units which use the same types
of cabinets and the same basic types of components.
> Typical cartridge type devices are the CDC Hawk, Diablo, RK05, RL01, RL02,
>Pertec,
>and Wangco, and contain 2 to 20 MB of data. The SMD type devices are the
>CDC 9762
>and CDC 9766, and contain 80 to 300 MB of data. the SMD disk drive are
>typically
>referred to as "washing machines" because of their physical size.
My Fujitsu 2311 and 2312 SMD drives are hardly the size of washing
machines.
>How do I know if there is an application for a Solid-State Disk Emulator?
I can hardly wait to see the answer to this. :-) :-) :-)
>Do you have an old computer system (like a PDP 11 or PDP 8) that you must
>keep
>operating due to the large investment in hardware and more importantly
>software? If
>the answer is yes, then the Solid-State Disk is your solution to
Yes, again, you're saying that it's a solution, which it is; however,
you neglect to mention whether it's a good or a bad soltion.
>mechanical disk
>drives that are prone to failure, obsolescence, and are difficult to
>maintain and
>service.
Well then, why don't you do something for us which will make it easier to
maintain and service these drives, such as making replacement parts
available for them?
>Why should I buy a Solid- State Disk Emulator?
>
> FEATURE BENEFIT
>
> System Immortality.....................Preserves Legacy Systems
No more so than would the availability of parts fo the older 14" hard
drives, etc.
> High reliability - Solid State Disk....Satisfied Users
Will it last as long as these other drives have?
> Fault Resilient, 11.5 years MTBF.......No System Downtime
When it fails 11.5 years from now, how easy will it be to repair it,
and to find replacement parts for what's failed?
Lastly, please keep the lines in your messages shorter than 80 columns
wide.
Charles Lasner
While it may be true on certain PDP-11 systems, Most PDP-8 systems aren't
as much "captive" to the mediocre design of the RK05, thus there is far
less impetus to slavishly clone this unimpressive beast.
Originally, even PDP-11 systems had the relative ease of having their
drivers changed to accomodate third-party (and often far superior) disk
sub-systems. Eventually, DEC changed all that by withholding the
necessary documentation and/or utilities to make for alternate devices,
etc. thus newer systems were often lock-step Digital; third-party makes
produced totally-compatible peripherals, even when this meant a drastic
drop in potential performance. (Witness SCSI devices that translate the
commands of the RL disks via an onboard micro to the requirements of the
SCSI disk, etc.)
With regard to the PDP-8 version, the RK05 interface comes off rather poor
(although better than the dreadful RL interface!). Specifically, the
following restrictions apply:
1) Sequential reads are only possible if the software overhead is minimal
at the point of inter-sector transfer. In essence, the interface is a
onesy process; each transaction has to be setup, and there is only about
100 usec to get it ready, else you suffer a one-revolution latency, etc.
(Note: there was an obscure attempt to fix this using the "RKS8E" which
could accomplish multiple sequential transfers within a few
semi-reasonable restrictions, but it never really caught on. Presumably
the makers of the solid-state RK replacement will be compatible with this
controller should anyone be using it.)
Things are so bad, there are users who deliberately mapped the disk to
provide a 2:1 interleave during the data-taking process of certain
critical real-time work, since two passes around guaranteed is a better
compromise than a 16 pass performance penalty.
Contrast this with the CESI MDC8 interface which allows up to 32K of
12-bit transfers from a single SCSI read/write request off-loaded to the
onboard micro. The PDP-8 is informed of the data transfer via interrupt
after the DMA has been accomplished; the -8 can perform other tasks while
otherwise waiting, etc. Using the proper SCSI controller and disks,
transfers can easily be accomplished with a 1:1 interleave. Some
practical examples include the SMS/Omti 4000 series SCSI/MFM controller
(and the 7000 series ESDI disk "cousins") and the SyQuest SQ555 drive.
While perhaps relatively small compared to today's disks, it is totally
reasonable to put almost 200 MB on each disk on a PDP-8 using 6-year-old
technology still available today. Contrast this with the effort being
suggested whereby a 2.5 MB disk is being proliferated, and the maximum
imaginable configuration is at most 8 drives for a total of 20 MB. (Note:
the smallest version of what is suggested above is the SQ555, which is
also as removable as the RK05, internally uses RLL recording, and weighs
in at 45 MB! The RK05 solid-state replacement will not be on removable
media, etc.)
2) While not a factor on the replacement system, the RK interface doesn't
support the concept of writing versus formatting! Each transfer to the
disk interface involves deciding whether to set a "don't check" bit or
not. This means that the interface has to read the latest sector flying
by to determine if this is the desired track (and thus there wasn't a
cylinder seek error). If the check bit is set, the sector cannot be used
for data transfer purposes. Thus, the software has the additional
overhead (all wasted in the replacement!) of determining whether to set
this bit. (The bit is set on each initial block transfer, and
subsequentially on each additional block whereby the head would have to
move to another track, etc. It must otherwise be cleared to prevent
once-around rotational latency, etc.)
In point of fact, the RK05 formatting program is merely a writer of the
entire disk with the don't check bit always set. The data area is written
with self-identification data. The formatter performs a second pass using
the usual read method; all data is checked to see if it actually is what
it's supposed to be, and of course that there are no seek or data errors,
etc.
3) With regard to the replacement system: Unless a mechanism to
"throttle" the data is provided, the DMA rate of the DRAM pseudo-disk can
prevent interrupt handlers, etc. from running in the intended manner.
Critical programs have been written that are timed to run in the degraded
manner of a somewhat slow-motion machine during the attendent DMA
overhead while the transfer is in progress. Should this overhead get
worse, the programs will fail.
The MDC8 is theoretically also guilty of this, but practical systems
built with reasonable size MFM disks were "slow" enough that this wasn't
a problem for most applications.
In any case, virtually all disk-systems software on the PDP-8 has been
shown to be modifiable with handlers for third-party devices; I
personally have written quite a few of them for several O/S'es, etc.
It would perhaps be more productive to spend some engineering effort on
improving the disk and interface to use more modern stuff rather than
replicating the problems of the past. What interface to what disk is not
germain to what matters in the world of PDP-8.
cjl
David M. Razler
Having been placed under no secrecy agreement when I sold ST a bunch of
useless 18-bit backplanes complete with blocks (because I couldn't find a way
to remove the blocks without first unwrapping almost every wire and do not
have an unwrap gun), I think I can explain to those of you who wish to keep
old machines going the logic behind the changeover to solid-state disks:
The devices sit on moving military objects. The kind subject to salt spray and
rocking and tumbling, and, despite the best sealed rooms, not the best
environment for moving magnetic media.
The company is also required to deliver a device that is socket- and
electronic-/code- compatible with the existing system.
Now DEC disks are robust - I forget the designation of the big pack that was
sold with the low-boy PDP-11s, but I know a company that used one for half a
dozen years *without* performing any maintenance.
When the pack finally crashed, the DEC service guy came in, pulled a
half-pound of lint, dust, random debris, etc, from the pack and set to work
figuring out why it had kept running...
Bob Manners
I've only ever come across one headcrash on an RK05, and that was not on
any of the drives I was maintaining. No idea what happened, - the upper
(down) head decided to crash. It took about an hour to replace it and
realign the drive.
That was (unless I'm much mistaken) on my drive. Thanks again for the
head replacement, Tony!
For the record, I think this may have been due to a damaged pack,
which I was writing for the first time. I still have that pack (with
the intention of making the platter into a clock). It has a 1cm wide
band of oxide missing from the upper face ... should have heard the
noise when it crashed!!
Bob.
--
----------------------------------------------------------------------------
Robert Manners Osney Laboratory
r...@swift.eng.ox.ac.uk Dept of Engineering Science
University of Oxford
01865 288762
Computer Museum: http://swift.eng.ox.ac.uk/rjm/museum.html
Also: http://swift.eng.ox.ac.uk
"The comfort you've demanded is now mandatory" - Jello Biafra
----------------------------------------------------------------------------
A.R. Duell
r...@swift.eng.ox.ac.uk (Bob Manners) writes:
> I've only ever come across one headcrash on an RK05, and that was not on
> any of the drives I was maintaining. No idea what happened, - the upper
> (down) head decided to crash. It took about an hour to replace it and
> realign the drive.
>That was (unless I'm much mistaken) on my drive. Thanks again for the
>head replacement, Tony!
Yep it was your drive... Please don't make a habbit of getting
headcrashes, though :-)
>For the record, I think this may have been due to a damaged pack,
That sounds likely...
>which I was writing for the first time. I still have that pack (with
>the intention of making the platter into a clock). It has a 1cm wide
>band of oxide missing from the upper face ... should have heard the
>noise when it crashed!!
Pity you didn't audio-record it... But I guess you wanted to retract the
heads just in case the head was still useable, and before the up head
crashed.
I've heard a headcrash described as sounding like 'a cat being fed
backwards into a lawnmower'. Is that anything like correct ?
>Bob.
Bob Manners
I've heard a headcrash described as sounding like 'a cat being fed
backwards into a lawnmower'. Is that anything like correct ?
More or less sums it up. Only louder and more agonising.
Milton Campbell
R. D. Davis (r...@access1.digex.net) wrote:
: The RK05 disk drive is a very repairablke drive; perhaps you should be
: concentrating on providing third-party replacement parts to keep these
: drives running, instead of producing things which may possibly be
: rather difficult to repair in a few years' time.
Perhaps their product is for people who don't find it economical to
maintain these drives. While large, old drives may be esthetically
appealing, they do tend to be more expensive. Unless it is a hobby, it
may not make sense to fool with them.
Milton Campbell
Douglas W. Jones,201H MLH,3193350740,3193382879
From article <RJM.96Ju...@swift.eng.ox.ac.uk>, by r...@swift.eng.ox.ac.uk (Bob Manners):
>
> I've heard a headcrash described as sounding like 'a cat being fed
> backwards into a lawnmower'. Is that anything like correct ?
>
> More or less sums it up. Only louder and more agonising.
The most impressive head crash I've seen was on a MODCOMP IV computer
where the main disk drives were top-loading 20 surface disk drives made
by CDC. I came in one morning and found that the machine was halted,
so I rebooted, but it didn't respond. Then I noticed that the boot drive
was off-line, so I cycled the power on that drive to reset it and, after
it spun up to speed, the heads loaded with the most awful combination of
screeching and clattering I've ever heard.
(Drive capacity? 400 tracks per surface, 20 surfaces, 20 sectors per
track, 512 bytes per sector gives about 80 megabytes. We had two drives
plus a tape drive for backups.)
The problem? A head had crashed overnight, and the dust it raised caused
more heads to crash -- remember, there were 20 and nobody was there at
the time to notice the sound and hit the stop button.
Eventually, the drive shut itself off, but before it did, about 8 of the
heads had worn through the oxide down to the aluminum. At that point, the
coeficient of friction got rather high, and the heads began to friction
weld themselves to the aluminum. When a head did this, it ripped itself
free from the mounting and either got flung, at very high speed, into the
enclosure, or it stayed attached to the disk surface and got carried for
one trip around, at which point it hit the head support arm and clattered
out. What a mess!
We were paying for low-class maintenance, so it wasn't until the next day
that the service guy got there to fix it, but it only took him a day to
clean up the mess, replace the filters and then replace and realigh all
20 heads.
Fortunately, we had a haphazard but working backup policy.
Doug Jones
jo...@cs.uiowa.edu
A.R. Duell
r...@access1.digex.net (R. D. Davis) writes:
>In article <4sfp6t$n...@lyra.csx.cam.ac.uk>,
>A.R. Duell <ar...@eng.cam.ac.uk> wrote:
>>r...@swift.eng.ox.ac.uk (Bob Manners) writes:
>>Pity you didn't audio-record it... But I guess you wanted to retract the
>>heads just in case the head was still useable, and before the up head
>>crashed.
>Just how difficult to find are these heads? Is DEC still selling
They're not hard to find, but they're not common either. I have a few
spare sets, including some still in the original boxes.
Last time I saw them for sale they were over \pounds 100.00 each.
>them? If they're not at all rare, would you care to try an
>experiment, which requires the use of a tape recorder? :-)
I am not causing a headcrash to see what it sounds like. Period.
Bob, I thought you were in favour of computer preservation. There is a
limited supply of RK05 heads, disks and air filters after all.
>R. D. Davis * http://www.access.digex.net/~rdd * Eccentrics have more fun!
--
R. D. Davis
In article <4sgam1$7...@lyra.csx.cam.ac.uk>,
>>Just how difficult to find are these heads? Is DEC still selling
>
>They're not hard to find, but they're not common either. I have a few
>spare sets, including some still in the original boxes.
Since they're not presently being manufactured and are not commonly
available through DEC, and likewise for certain other RK05 bits,
please disregard what I hinted at, regarding a certain recording.
>>them? If they're not at all rare, would you care to try an
>>experiment, which requires the use of a tape recorder? :-)
>
>I am not causing a headcrash to see what it sounds like. Period.
>Bob, I thought you were in favour of computer preservation. There is a
>limited supply of RK05 heads, disks and air filters after all.
Oh, I am; I am very much in favor of computer preservation. Since
there is a limited supply of RK05 parts, such as heads, disks and air
filters, it would make no sense at all to cause an RK05 head crash
just to hear what one sounds like.
>-tony
>The gates in my computer are AND,OR and NOT, not Bill
--
R. D. Davis * http://www.access.digex.net/~rdd * Eccentrics have more fun!
R. D. Davis
In article <4sfp6t$n...@lyra.csx.cam.ac.uk>,
>Pity you didn't audio-record it... But I guess you wanted to retract the
>heads just in case the head was still useable, and before the up head
>crashed.
Just how difficult to find are these heads? Is DEC still selling
them? If they're not at all rare, would you care to try an
experiment, which requires the use of a tape recorder? :-)
--
Elizabeth Power
The old discs (12 inches or so across) which were victims of the sort
of head crash so beautifully described earlier made nice souvenirs
when mounted on green felt covered board and framed. We had a few done
for leaving gifts. Rainbow effects of scraped-off oxide in various
thicknesses and bare metal are quite pretty.
--
Elizabeth Power
Carl R. Friend
Douglas W. Jones,201H MLH,3193350740,3193382879 wrote:
>
> From article <RJM.96Ju...@swift.eng.ox.ac.uk>, by r...@swift.eng.ox.ac.uk (Bob Manners):
> >
> > I've heard a headcrash described as sounding like 'a cat being fed
> > backwards into a lawnmower'. Is that anything like correct ?
> >
> > More or less sums it up. Only louder and more agonising.
>
> The most impressive head crash I've seen was on a MODCOMP IV computer
> where the main disk drives were top-loading 20 surface disk drives made
> by CDC. I came in one morning and found that the machine was halted,
> so I rebooted, but it didn't respond. Then I noticed that the boot drive
> was off-line, so I cycled the power on that drive to reset it and, after
> it spun up to speed, the heads loaded with the most awful combination of
> screeching and clattering I've ever heard.
>
Actually, the only one I've ever heard first-hand was when the upper head
on my Diablo Mod 33 (drive 0) crashed on my Nova. No "screeching". No "howling".
The sound I seem te remember was sort of a "pinging scrape". Needless to say I
pegged the "UNLOAD" switch mighty fast!
After a thorough head cleaning (and close inspection) no blatant damage was to
be seen and I put the drive back to work. Still no troubles to date (this was
a year or so ago).
> The problem? A head had crashed overnight, and the dust it raised caused
> more heads to crash -- remember, there were 20 and nobody was there at
> the time to notice the sound and hit the stop button.
The worst one I ever saw was when a drive apparently crashed on a late
Friday afternoon after work. The next we saw of it was on Monday morning.
Needless to say it was a _mess_. The head, proper, had long since been
ripped from it's arm, and the drive for some unexplainable reason didn't
do an emergency retract. The platter had been severred neatly along the
track line where the arm hit the surface after the head was shorn away.
Not a pretty sight...
> Eventually, the drive shut itself off, but before it did, about 8 of the
> heads had worn through the oxide down to the aluminum. At that point, the
> coeficient of friction got rather high, and the heads began to friction
> weld themselves to the aluminum. When a head did this, it ripped itself
> free from the mounting and either got flung, at very high speed, into the
> enclosure, or it stayed attached to the disk surface and got carried for
> one trip around, at which point it hit the head support arm and clattered
> out. What a mess!
Only eight heads? You got lucky. There wasn't enough left of this drive
inside the "basket" to do anything but a post mortem...
--
______________________________________________________________________
| | |
| Carl Richard Friend (UNIX Sysadmin) | West Boylston |
| Minicomputer Collector / Enthusiast | Massachusetts, USA |
| mailto:carl....@cliff.swec.com | |
| http://www.ultranet.com/~engelbrt/carl/museum | ICBM: N42:22 W71:47 |
|________________________________________________|_____________________|
Charlie Gibbs
Although not nearly as impressive as other head crashes that people
have described, I witnessed one that was much more insidious. One
night I was prepping a new pack on a drive that had a noisy spindle
bearing. The pack crashed as soon as the heads loaded, but any noise
just sounded like the bearing noise, but a bit louder. Eventually
it got loud enough, though, that I suspected that something was wrong
and shut down the drive. One surface of the pack was scoured down to
the aluminum.
We had three Univac CEs and two reps from Control Data (who made
the pack) on site the next day pointing fingers at each other.
(We didn't care which one paid for the new heads - it wasn't our
fault.)
At the time, Univac was giving dire warnings to everyone not to
use CDC packs on the 8418 drives most people had on their 90/30s.
But Univac couldn't produce enough packs themselves to meet the
demand, so most people had no choice. In the experience of local
shops, a CDC pack would either crash the first time you mounted
it, or run forever.
Charli...@mindlink.bc.ca
If your nose runs and your feet smell, you're built umop-apisdn.
Bob Manners
Just how difficult to find are these heads? Is DEC still selling
them? If they're not at all rare, would you care to try an
experiment, which requires the use of a tape recorder? :-)
They're rarer than 'common' I think. besides alignment is enough of a
game to make deliberate crashes a little foolish :)
A watched drive never crashes anyhow ...
--
----------------------------------------------------------------------------
Robert Manners Osney Laboratory
r...@swift.eng.ox.ac.uk Dept of Engineering Science
University of Oxford
01865 288762
Computer Museum: http://swift.eng.ox.ac.uk/rjm/museum.html
Also: http://swift.eng.ox.ac.uk
"We're all planning our careers,
We're all planning our careers,
We're all planning our careers,
He says we're growing old!" - Jello Biafra
----------------------------------------------------------------------------
Bob Rudolph
In a previous life, I was a field engineer for places like Memorex, and cleaned up LOTS of head
crashes in the 1969-1973 timeframe....
Once saw a pack mounted that had a bottom surface so bent that when the heads loaded, the
bottommost was snipped off by being stiffed between the bottommost surface and the sector
disk....
STILL remember the day we caught one at an insurance company (I heard it when I walked in for a
courtesy visit) and ended up having to inspect several hundred packs - and threw out 53 with
crashes, many of which were crashed on surfaces that we hadn't yet had a crash on.
Glad to be away from hardware....
--
Robert A. Rudolph, Systems Programmer
Baltimore County Public Schools
Division of Support Services
Information Management Systems
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
VSE/ESA, VM/ESA, and OS/2 - all winners
mailto:rrud...@mail.bcpl.lib.md.us
Mark Bartelt
[ R. D. Davis ]
>> it would make no sense at all to cause an RK05 head crash
>> just to hear what one sounds like.
It would make no sense at all, but it might be a lot of fun! ;-)
Mark Bartelt 416/978-5619
Canadian Institute for ma...@cita.toronto.edu
Theoretical Astrophysics ma...@cita.utoronto.ca
"Clothes not busy being worn are busy drying." -- Dylan, on laundry day
[ singing "It's all right, ma (I'm only bleaching)" ]
Charles Lasner
In article <4sdtln$7...@nntp.ucs.ubc.ca>,
Tim Shoppa <sho...@alph02.triumf.ca> wrote:
>In article <4sdqrb$m...@helios.oit.unc.edu>,
>Charles Lasner <las...@helios.oit.unc.edu> wrote:
>>as much "captive" to the mediocre design of the RK05, thus there is far
>>less impetus to slavishly clone this unimpressive beast.
>>
>>Originally, even PDP-11 systems had the relative ease of having their
>>drivers changed to accomodate third-party (and often far superior) disk
>>sub-systems. Eventually, DEC changed all that by withholding the
>>necessary documentation and/or utilities to make for alternate devices,
>>etc.
>
>write device drivers for RT-11 and RSX-11M and 11M+ for custom tape,
>disk, and data acquisition devices. The RT and RSX manuals have,
>as far as I know, always included an entire binder dedicated to
>walking you through the process of writing, debugging, and installing
>a device driver.
Perhaps true, and you are well-qualified to do so. But it scared off
enough companies that they instead built hardware that was software
compatible with DEC's stuff, limitations and all. Also, below you
contradict part of this, since the tape utilities won't let in a
third-party disk driver/interface, etc.
The main point is that the systems become somewhat hostile to non-DEC
devices. There is no parallel on the PDP-8 systems that "matter" today.
Admittedly I am leaving out the likes of WPS-8 and to some extent COS,
but these systems are DEC-locked in other ways, such as limited support
for printers DEC was selling that week. They couldn't support older
Digital printers, much less other party's, etc.
>
>> thus newer systems were often lock-step Digital; third-party makes
>>produced totally-compatible peripherals, even when this meant a drastic
>>drop in potential performance.
>
>Yes, third-party boards often emulate DEC devices. This is very
>convenient if, say, you are installing from tape and don't have a
>DEC disk drive. The bootstrap code on the tape only knows how to
>drive DEC devices, after all!
Again, a DEC lock-in. There's no sane reason why a third-party driver
cannot be added to a tape utility in a useful fashion. DEC just chose to
make the utilities non-extensible.
>
>>Contrast this with the CESI MDC8 interface which allows up to 32K of
>>12-bit transfers from a single SCSI read/write request off-loaded to the
>>onboard micro.
>
>If I wanted to buy a CESI MDC8, where could I get one?
Several people have indicated that the company is sort of mothballed, but
not entirely gone. Apparently, the owner is still around, etc.
In any case, my point is that if someone wants to spend real engineering
effort on a project to support older machines, it's true in the PDP-8
world that you can do better supplying never-before-from-DEC hardware and
software that takes advantage of newer technology that would be easily
adapted to the existing systems that would otherwise be a candidate for
the proposed RK05 replacement.
A side issue: The RK8E is one of the more difficult boards to maintain.
I have had personal bouts with this beast, so I know of what I speak. A
replacement system should be easier to maintain, albeit likely somewhat
modularly disposable. (A SCSI host adapter and a SCSI controller and a
SCSI disk are likely gonna break in only one area, thus throw that bad
one away and replace with a cheap new one, etc.)
>
>Tim. (sho...@triumf.ca)
cjl
Ron Natalie
Charles Lasner wrote:
> Today you could seal up a smaller drive and the dirt would only be in the
> outer case. Good filtering prevents this from being a consideration.
> Remember, we are talking about replacing drives that are 10.5 inches of
> rack space and weight over 90 lbs. for a capacity of only 2.5 MB each!
>
Ah yes, I have fond memories. UNIX used to fit on one of these. These
days you can't even fit the kernel binary on one.
I remember my first UNIX system: One RK05 for root and user. Two for
the permanently mounted home directories. Two more for mountable user
packs. We used an RF11 for the swap disk. Now let me tell you,
the sound of an RK05 head crash ain't nothing compared to listening
to the RF self destruct.
-Ron
Charles Lasner
In article <31eb0d01...@netnews.worldnet.att.net>,
David M. Razler <david....@worldnet.att.net> wrote:
>
>Having been placed under no secrecy agreement when I sold ST a bunch of
>useless 18-bit backplanes complete with blocks (because I couldn't find a way
>to remove the blocks without first unwrapping almost every wire and do not
>have an unwrap gun),
I can get you an unwrap gun from Gardner-Denver, so don't let that stop
you! I have some junked KI-10 memory controllers taken from DEC salvage
years ago, that periodically have been unwrapped when someone wanted
them; some of the blocks are broken, most are not. (Side note to DMR:
WDAG obtained a few of these from me years ago; we spent a few hours
"liberating" them from the KI-10, etc.)
BTW, here's another topic:
HOW TO REPAIR BROKEN BLOCKS.
Often, when the green blocks get broken, a piece comes out that makes the
pins short unless you insert a spacer (punched card or cardboard) or a
module into the slot.
The fix is to go and break another block! The reason is that invariably
the blocks break in predictable ways. Thus, there are only a few cases
of jagged green object that are needed. One of them will fit amazingly
perfectly into your damaged block (perhaps requiring a slight amount of
filing or a Dremel tool or whatever to fixup). Just epoxy in the
replacement and you're done.
I use the damaged blocks of the KI-10 as a source for the replacement
cracked-off parts that are missing on the working Omnibus planes I
encountered, etc.
> I think I can explain to those of you who wish to keep
>old machines going the logic behind the changeover to solid-state disks:
There is a flaw in the logic because it involves the military. Remember
that there are many oxymorons in life. Remember terms such as Military
Intelligence and Computer Science :-).
>
>The devices sit on moving military objects. The kind subject to salt spray and
>rocking and tumbling, and, despite the best sealed rooms, not the best
>environment for moving magnetic media.
True, but modern disks far exceed these requirements. I would dare say
that the military achieved something where the relatively fragile RK
drives managed to survive. Using more modern moving media it gets a
whole lot easier. Going to solid-state disk is overkill.
>
>The company is also required to deliver a device that is socket- and
>electronic-/code- compatible with the existing system.
Good ol' Military Intelligence at its best/worst. Any reasonable user
would want a replacement system, not a replacement component. I would
sell the user the replacement hardware and update all of their software
to use it. There is *nothing* that could have been done on an RK system
that cannot be done as easy or better on a more modern interface.
Instead of dealing with a contankerous device, use something more elegant
to program. If the software managed to barely work because of a 100 usec
window, use a device that has no such limitation.
I have written device handlers for the RK8E. Some are for real-time
application systems with complex queuing, and others are just
space-saving system handlers for P?S/8 and OS/8-style operation. While
not the world's worst interface (not in the RL category!), the
limitations are pathetic by comparison to the nicer stuff that came along
since (RL's and the like aside!).
>
>Now DEC disks are robust - I forget the designation of the big pack that was
>sold with the low-boy PDP-11s, but I know a company that used one for half a
>dozen years *without* performing any maintenance.
>
>When the pack finally crashed, the DEC service guy came in, pulled a
>half-pound of lint, dust, random debris, etc, from the pack and set to work
>figuring out why it had kept running...
Today you could seal up a smaller drive and the dirt would only be in the
outer case. Good filtering prevents this from being a consideration.
Remember, we are talking about replacing drives that are 10.5 inches of
rack space and weight over 90 lbs. for a capacity of only 2.5 MB each!
>
> dmr
>
>
>David M. Razler
>david....@worldnet.att.net
cjl
Tony Duell
In article <4sj9ca$b...@calzone.unc.edu>
las...@calzone.unc.edu "Charles Lasner" writes:
[Modifying DEC OS's for new devices]
> Perhaps true, and you are well-qualified to do so. But it scared off
> enough companies that they instead built hardware that was software
> compatible with DEC's stuff, limitations and all. Also, below you
> contradict part of this, since the tape utilities won't let in a
> third-party disk driver/interface, etc.
AFAIK you _can_ modify standalone BRU (The RSX install-from-tape program),
particularly if you've got a source license _but only after you've installed
the OS_. It's a chicken and egg problem - you need BRU working to install
RSX, but you need RSX installed to modify standalone BRU.
Can you install OS/8 on a non-DEC disk without having it installed on
another system first? If so, how?
(Note, toggling in code from the front panel doesn't count - you could in
theory boot RSX standalone BRU, patch it from the panel, run it, and load the
OS onto the non-standard device).
[...]
> A side issue: The RK8E is one of the more difficult boards to maintain.
In what sense? I know about the compatability problems between RK8E's, TD8E's
EAE boards, etc if everything is not at the right ECO, but provided the system
worked properly in the first place, the RK8E doesn't look hard to maintain
given a logic analyser. All the chips are standard, there's a good tech manual
available, etc.
> I have had personal bouts with this beast, so I know of what I speak. A
> replacement system should be easier to maintain, albeit likely somewhat
> modularly disposable. (A SCSI host adapter and a SCSI controller and a
> SCSI disk are likely gonna break in only one area, thus throw that bad
> one away and replace with a cheap new one, etc.)
Provided you can get a replacement. A lot of early 1980's machines used ST506
drives that are getting very hard to find nowadays. PC owners can (in general)
replace them with IDE drives, but that's no help to PERQ, PDP, HP150, etc
owners like myself who are trying to maintain such machines.
It's alright to install a SCSI system now, but in 10 years time, the mainstream
computing market will have (almost certainly) moved on to something else. What
are you going to do for parts then?
> cjl
-tony
David M. Razler
My all-time favorite head crash was the one that was virtually *guaranteed* by
the manufacturer, the Bryant swapping drum <sold through DEC> for the KA-10
CPU
The unit defined the word "boat anchor," even possessing a loop fitted to the
top for lifting it <550 lbs + if I recall correctly> into a cabinet or
suspending it from a chain. It was designed so, as time and heads wore on,
heads would crash, the beast would begin sounding like a man of a million
fingernales scraping along the world's longest chalkboard and the controller
would reconfigure around the bad heads. One used said device until sufficient
heads crashed that operating it became a system liability as opposed to a
speed advantage, ripped out the B-212 modules, etc. from the controller and
sent it to the Great Scrap Heap in the sky.
dmr
<note: the proliferation of our new pocket-sized disk drives has led to more
interesting failures, albeit without any of the old-fashioned sound and light
shows: I have an old Seagate 200-series 5 /14 drive sitting here, looking like
a sculputure from one of the old Seagate ads with , uh, interesting stain
patterns on the surfaces from the smoke generated when the power supply on the
main unit burned and forced smoke through the supposedly sealed drive. A
friend has a similarly-mounted 3 1/2" SCSI which blew either head mover or
controller. Don't know, don't care. All we know is that one day it ceased
being a disk drive and became one of the current computer world's more
expensive percussion instruments, playing out an endless varied series of
irregular beats of cuta-tink, cuta tink, cuta-cuta.... tink... If hit hadn't
crashed the system, we probably would have left it in for fun and game <Icon
marked drumblaster>
David M. Razler
david....@worldnet.att.net
Michael E Willett
The solid state disk people at Storage Computer appreciate all those
connectors everyone's been sending in, and they can still use a lot
more. The URL for SSD PDP info is http://www.storage.com/vermont.html
Thanks, M Willett, Storage Computer, http://www.storage.com/
Nashua, NH
Leatherhead, Surrey
James W. Birdsall
In article <837637...@p850ug1.demon.co.uk> a...@p850ug1.demon.co.uk writes:
>Provided you can get a replacement. A lot of early 1980's machines used ST506
>drives that are getting very hard to find nowadays. PC owners can (in general)
>replace them with IDE drives, but that's no help to PERQ, PDP, HP150, etc
>owners like myself who are trying to maintain such machines.
>
>It's alright to install a SCSI system now, but in 10 years time, the mainstream
>computing market will have (almost certainly) moved on to something else. What
>are you going to do for parts then?
Well, sooner or later anything will become unavailable. But if I had to
bet on a currently-cheap technology still being available in ten years,
SCSI would be a good one. So far they've been doing an excellent job on
backward compatibility. When the original MFM drive in my Sun 2/120 started
making too much noise, I replaced it with a SCSI-2 drive ten years newer
than the Multibus SCSI controller it was connected to. Worked perfectly
right off and has been running 24x7 for months now with no problems.
--
James W. Birdsall http://www.picarefy.com/~jwbirdsa/ jwbi...@picarefy.com
"For it is the doom of men that they forget." -- Merlin
Get the Sun Hardware Reference from ftp.picarefy.com:/pub/Sun-Hardware-Ref
Sun Hardware Reference Web Page: http://sun-www.picarefy.com/
Tom Watson
In article <RJM.96Ju...@swift.eng.ox.ac.uk>, r...@swift.eng.ox.ac.uk
(Bob Manners) wrote:
> I've heard a headcrash described as sounding like 'a cat being fed
> backwards into a lawnmower'. Is that anything like correct ?
>
> More or less sums it up. Only louder and more agonising.
>
You need to combine the screams of the user who discovers the incident.
The volume of that noise usually drowns out the sound of the headcrash,
but as always, your milage does vary.
One story I heard was that of the poor user in the era of removable disk
packs (are they still in use??) moving the pack from drive to drive,
wondering what was wrong. When someone "in the know" came around the
neophite asked what all this "rust type dust" was, to which our hero
answered "data". Fill in the place where someone screams anywhere you
like...
Subject changed, newsgroups trimmed, you're welcome.
--
Tom Watson
t...@3do.com (Home: t...@johana.com)
Ron Natalie
Back in my Univac days, the standard Univac storage device was a
Faststran
flying head drum unit. The maintenance panel had an array of "hit
detector
lights" you can imagine what this says about the mean time between head
crashes.
Simon Slavin
In article <86895-8...@mindlink.bc.ca>,
Charli...@mindlink.bc.ca (Charlie Gibbs) wrote:
> At the time, Univac was giving dire warnings to everyone not to
> use CDC packs on the 8418 drives most people had on their 90/30s.
Not folklore, for which I apologise, but could someone tell me how
many bytes fit on a /modern/ disk pack ? Something designed in the
last few years, perhaps. I remember figures of about 100Meg for
the type of packs you're discussing and I used to work with but I
haven't used any of the newer mainframes. Now they fit 3/4 Meg in
a laptop routinely I wondered what the capacity of a large removable
disc was.
Hey, not only off-topic but off-charter !
ObThread: I observed only two head crashes in person. In each case
it was the bottom platter and in each case it was system code which
got destroyed. Luckily, though some sites don't have daily backups
of data, they can normally come up with a working copy of the OS.
Simon.
--
Simon Slavin -- Computing Contractor Ordinaire
That's 'portable' in the Navy sense, as a 16" gun is 'portable'
because it can be mounted on a ship and moved around.
-- a...@ix.netcom.com (ANDREW GRYGUS)
Charles Lasner
In article <837637...@p850ug1.demon.co.uk>,
Tony Duell <a...@p850ug1.demon.co.uk> wrote:
>In article <4sj9ca$b...@calzone.unc.edu>
> las...@calzone.unc.edu "Charles Lasner" writes:
>
>[Modifying DEC OS's for new devices]
>
>> Perhaps true, and you are well-qualified to do so. But it scared off
>> enough companies that they instead built hardware that was software
>> compatible with DEC's stuff, limitations and all. Also, below you
>> contradict part of this, since the tape utilities won't let in a
>> third-party disk driver/interface, etc.
>
>AFAIK you _can_ modify standalone BRU (The RSX install-from-tape program),
>particularly if you've got a source license _but only after you've installed
>the OS_. It's a chicken and egg problem - you need BRU working to install
>RSX, but you need RSX installed to modify standalone BRU.
I assume you mean that you not only need RSX already running on a
DEC-sold disk system, but also a DEC-sold tape system is what BRU is used
from.
On the PDP-8, tapes were not only rare, but largely non-DEC. The
TU10/TM8E was used, but often it might be an IOMEC or a few others.
However, there really wasn't a common usage of a boot-from-tape to get
the system up, although I wrote a few of those for application-specific
systems for my employer at the time. They chose to have quite a few
systems sans disk, but since the application required 2-5 tape drives, it
was obviously the way to go. BTW, someone did get a handler for the
IOMEC tape to be read/write using the large tape gaps method to allow
pseudo-block replaceablility ala DECtape. The thing ran *real* slow, but
considering there's no disk around, we couldn't complain :-). (BTW, this
was the first handler that used the 7016 instruction to figure out what
page it was loaded into to save code, thus the handler could be written
in one page, etc. I modified it to be at offset 0015 of the page so that
it could also run on a KK8A as well as an -8/e; the peripheral was
Omnibus only, so this was acceptible, etc.)
>
>Can you install OS/8 on a non-DEC disk without having it installed on
>another system first? If so, how?
Yes, using paper-tape. The early systems depended on a lot of tape
reading including the binary of your handler. Later, the BUILD program
could load it all in via the PTR: or perhaps cassettes. (Note: BUILD.SV
itself can be punched back into a paper-tape and run standalone; it
doesn't use OS/8 itself unless you want to build the system the usual way,
i.e., use a resident-within-build handler image for the new system. The
way BUILD works is to swap the BUILD-resident handler into 07600 and 27600
to write out the new system while using the old memory contents to read
the current system. Thus, the system gets copied onto the new device,
etc. But all other usage of BUILD is truly stand-alone. If you read in a
paper-tape of part of the system, the system-device you chose from within
BUILD is used to write out the just-read-in system component, etc. The
system-device itself is part of BUILD's own core-image. How it got there
is another story. BUILD can read in system and non-system handler images,
but only up to what fits within 8K including BUILD itself. Thus, BUILD
has commands to unload and load handlers since there is a small finite
space, etc. Any particular copy of BUILD thus has a configuration or 2 or
3 or 4 in mind, not an infinite variety. Generally, we save copies of
BUILD.SV under different names pre-setup to just do one command (BOOT) to
write out our preferred system configuration. Since I have a lot of
hardware choices (RK8E, MDC8/SCSI/hard disk, MDC8/SCSI/HD-Floppy,
LINCtapes via InterProcessor-Buffer to LINC-8, RX01, RX02, TC08 DECtapes)
for a system device on my main machine, I tend to have a lot of copies of
BUILD saved under names such as RKEBLD.SV, RX2BLD.SV, LTBLD.SV, etc.)
>
>(Note, toggling in code from the front panel doesn't count - you could in
>theory boot RSX standalone BRU, patch it from the panel, run it, and load the
>OS onto the non-standard device).
I agree, although I did that once when I had to switch from a TD8E to a
TC08. I loaded the TD8E system that uses the MR8E-C field 7 ROM. This
was done on a machine sans TD8E using some toggled in TC08 code. Then I
toggled in code to read in the first two system blocks from an older
version into where they belonged and restarted the system. The result was
a tenuous system running on the TC08/TU56. I was able to then access the
handlers to update the system in-place.
>
>[...]
>
>> A side issue: The RK8E is one of the more difficult boards to maintain.
>
>In what sense? I know about the compatability problems between RK8E's, TD8E's
>EAE boards, etc if everything is not at the right ECO, but provided the system
>worked properly in the first place, the RK8E doesn't look hard to maintain
>given a logic analyser. All the chips are standard, there's a good tech manual
>available, etc.
I didn't have the luxury of a logic analyser, but the problem is that a
lot of the automatic operations of the RK8E are only fleeting and are
hard to 'scope out. Especially when failure modes of chips still produce
semi-plausible results. Thus, you wind up having to change a few more
chips than more sophisticated sleuthing might allow, etc.
In any case, changing TTL on those boards is far worse a job than on
other similar boards. The holes are rather small (no, I didn't have to
count them all! :-)) and forget about recovering a chip you pulled. The
small size is such that only a vacuum-pump-driven desolderer gets out
enough solder that you don't ruin plate-throughs removing a (former)
chip's pins. Beyond that, the cards are also more easily damaged due to
the smaller land size in general. (And we won't talk about cards where
the word "TOP" is ignored!)
I once had to fix an RK8E where the system was eventually isolated to the
fact that it read standard disks fine, but it wrote a non-standard header
out. (Remember, there is really no difference between formatting and
writing!) And of course it liked its non-standard headers! The CRC
logic was blown in a curious way where it basically ignored the results
but wrote out a defective variant pattern, etc. I think the bad chip
(the one which when removed made a difference after several wrong guesses
made for no forward progress!) was a shift register pair, etc.
>
>> I have had personal bouts with this beast, so I know of what I speak. A
>> replacement system should be easier to maintain, albeit likely somewhat
>> modularly disposable. (A SCSI host adapter and a SCSI controller and a
>> SCSI disk are likely gonna break in only one area, thus throw that bad
>> one away and replace with a cheap new one, etc.)
>
>Provided you can get a replacement. A lot of early 1980's machines used ST506
>drives that are getting very hard to find nowadays.
They're still out there. Certainly easier to get than RK parts!
> PC owners can (in general)
>replace them with IDE drives, but that's no help to PERQ, PDP, HP150, etc
>owners like myself who are trying to maintain such machines.
Agreed.
>
>It's alright to install a SCSI system now, but in 10 years time, the mainstream
>computing market will have (almost certainly) moved on to something else. What
>are you going to do for parts then?
I don't think backward-compatible SCSI is gonna go away so fast. I'm
sure SCSI 29 will still talk to a SCSI 1 disk :-).
On the MDC8 which is SCSI, we have one problem:
The design of the original MDC8 was dropped in favor of a "better" one
which while overall better, dropped an important feature that affects
OS/8 and to a lesser extent P?S/8:
OS/8 demands that we address logical blocks of 256 12-bit words, so in
theory this means that we want the common 512 byte blocks. The problem
is that OS/8 needs to specify to the nearest 128 words of transfer.
Thus, it is willing to sacrifice the ability to get to the "odd" page of
a pair of pages in a transfer. Notice that the SAVE command won't let
you save memory in an "odd" page without also getting the "even" page,
but an "even" page without the "odd" page is allowed:
.SAVE SYS FOO.SV 200-201
this actually saves 00000-00377, while
.SAVE SYS BAR.SV 0-1
actually saves 00000-00177. This is the direct consequence of the
limitations of the way you have to call the handler, etc.
Thus, OS/8 requires the ability to write out one page, not two pages, of
a two-page call to the handler. Actually, what generally happens is that
the two-page write function is used where junk data (perhaps what's next
to the desired contents of the first page in memory) is written into the
second page half of the disk contents. As long as the entire record can
be read back later, this is fine, since there is no guarantee of
preserving that second half of the record from before the write
operation, etc.
In the particular case of the RK8E, there is a "one-page" bit, which when
set means that the second half of the record is written out with 0000 in
each of the 128 12-bit words. This is controller automatic, not DMA; the
overall CRC is calculated for what was actually written of course.
When you read back the data, you can set a "one-page" bit for reading on
the RK8E. Thus, the data is read back for CRC purposes only in the
second page after the first page is transferred. Thus, this serves
OS/8's needs precisely.
The early MDC8 had this feature (at my insistence!) and also handled the
problem. But the newer version (not influenced by me during the time of
the major design upheaval) left this out! Thus, the newer version is
whole-blocks-oriented. The only way to use it for OS/8 with a simple
handler is to make the blocks 256 bytes. This severely limits the list
of devices that are compatible with it.
P?S/8 has a different problem with devices that are inherently 256 12-bit
words at the physical level, since it's a system based on logical blocks
of 128 words. (Which is fine for DECtapes and LINCtapes where this is
natural; OS/8 doubles the callers logical record value to map it into a
physical block value on these devices; P?S/8 just uses the argument as
is, etc.)
Thus, P?S/8 has a handler for addressing to the nearest 1/2 physical RK8E
record. This is done by using a handler-internal two-page buffer. If
the call is similar to OS/8, meaning either a well-bounded read or write,
the transfer is done similarly to OS/8. If the call (ends with or) is
for an even page single read, this is also handled the same as OS/8.
There are three problem cases:
1) There is a single-read to a second half of a record.
2) There is a single-write to a first half of a record.
3) There is a single-write to a second half of a record.
(Note: any problem case could either preceed or follow a bunch of
no-problem operations within any handler call.)
The read problem is handled as first read the entire record into the
two-page buffer, then move the data from the second half to the user's
specified buffer. The write problem is to first read in the data from
the disk, then move the user's data into the appropriate buffer half,
then write back the disk buffer.
Since P?S/8 allows 9-page system handlers and 32 page non-system
handlers, this is easily accomplished. (The actual code is 4 pages
system and non-system, including the two-page buffer.)
But OS/8 only allows two-page handlers at best, preferring one-page
handlers (as does P?S/8). Thus, the problem cannot be solved.
So, OS/8 is limited to "better" devices where the data is handled with a
"one-page" bit. Such a bit is helpful to P?S/8, but hardly mandatory.
Thus, in the future, should SCSI not be available for 256 byte devices,
the MDC8 using the current controller code model will not be able to
support OS/8, but this shouldn't bother P?S/8. By that time, we would
consider disassembling the 6809 code and revamping it :-).
>
>
>> cjl
>
>-tony
>
cjl
Frank McConnell
Simon Slavin <sla...@hearsay.demon.co.uk> wrote:
>Not folklore, for which I apologise, but could someone tell me how
>many bytes fit on a /modern/ disk pack ? Something designed in the
>last few years, perhaps.
Have there been any removable-pack designs in the last few years? Way
back in 1981 or 1982, HP introduced the 7933 and 7935 404MB
removable-pack drives. The next generation of disks from HP was the
7937, which were sealed-pack 571MB drives, and all the new disks
larger than 100MB I've seen since have been sealed-pack things.
(Well, OK, there are those new Jaz drives.)
Actually the 7933 is not exactly a removable-pack drive. It is
considered to be a fixed-pack drive, but you can get the pack out
after you pop the top latch (with screwdriver through rear vent) and
remove the top.
>ObThread: I observed only two head crashes in person. In each case
>it was the bottom platter and in each case it was system code which
>got destroyed. Luckily, though some sites don't have daily backups
>of data, they can normally come up with a working copy of the OS.
I observed one in person. For some reason, HP did some preventive
maintenance on the 7933 drives that involved replacing early-model
packs with later packs. We scheduled such a maintenance for a day on
which we were closed due to some state holiday. I went in to do the
backup, let the CE in, and do the reload once the pack was replaced.
So he swapped the pack, did his stuff, and loaded diagnostics on the
HP 3000 to format and test the pack. I wandered around the computer
room. When I got behind the disk, I smelled something funny, and
called him over. He smelled it too. We agreed it smelled like
something burning, but we had no idea what. It wasn't long before the
diagnostic started reporting errors on the console. When he
dismounted the pack, he could see the scoring through the access door
in the side of the pack.
-Frank McConnell
<f...@aphasia.us.com>
Tony Duell
In article <4slibt$c...@calzone.unc.edu>
las...@calzone.unc.edu "Charles Lasner" writes:
> >AFAIK you _can_ modify standalone BRU (The RSX install-from-tape program),
> >particularly if you've got a source license _but only after you've installed
> >the OS_. It's a chicken and egg problem - you need BRU working to install
> >RSX, but you need RSX installed to modify standalone BRU.
>
> I assume you mean that you not only need RSX already running on a
> DEC-sold disk system, but also a DEC-sold tape system is what BRU is used
> from.
AFAIK, if you have a running RSX system (on whatever sort of disk) you can use
it to modify BRU to read/write whatever sort of devices you like. You may need
a source license to get the BRU sources, though.
[PDP8 tape info deleted]
> >Can you install OS/8 on a non-DEC disk without having it installed on
> >another system first? If so, how?
>
> Yes, using paper-tape. The early systems depended on a lot of tape
Yes, but the paper tape reader had better be compatable with the DEC one, or
the BUILD program won't load. I could link up a Trend HSR500P to a DR8E, and
no way would OS/8 install from it. The initial load device had better
be something that the loader/installation program knows about.
And how do you _write_ the custom handler for the system disk? You could
use the front panel or a standalone assembler, but by that argument, you could
modify RSX11 BRU in a similar way.
[Repairing RK8E's]
> I didn't have the luxury of a logic analyser, but the problem is that a
A logic analyser would certainly be useful, but I suspect you could manage
without one if you had to.
> lot of the automatic operations of the RK8E are only fleeting and are
The same is true about a lot of other boards I could mention. You can often use
hacked-together logic wired to the board under test to detect the condition
you are looking for and trigger the 'scope on it. Having a storage 'scope, or
at least one with a long-persistance phosphor helps a lot. Of course a logic
analyser with a word recogniser is even more useful.
> hard to 'scope out. Especially when failure modes of chips still produce
> semi-plausible results. Thus, you wind up having to change a few more
> chips than more sophisticated sleuthing might allow, etc.
OK, so you have to change a few more chips. The chips on the RK8E are cheap,
and in general easy to obtain. It's no big hassle to change a few more (even
though there's a certain satisfaction in working out the faulty component and
getting it right).
>
> In any case, changing TTL on those boards is far worse a job than on
> other similar boards. The holes are rather small (no, I didn't have to
The holes on my RK8E are no smaller than the ones on any other DEC board of
the time. DEC always used smaller holes than most other companies.
> count them all! :-)) and forget about recovering a chip you pulled. The
If you know the chip is dead, or it's easy to get, then you clip off the pins
and desolder them separately. That said, careful use of a temperature
controlled iron and a good solder sucker will get the chip out without damaging
chip or board. The tricks are :
1) Resolder all the joints first
2) Don't be afraid of overheating the chip. Get the solder molten before you
suck
3) Break the bod between the chip and the board by pressing each pin inwards
with a screwdriver before pulling the chip
4) Don't force anything. If a pin is stuck, resolder it, resuck, and try again
I've removed chips from various boards in the 8/e (and the peripherals), and
never had problems.
> small size is such that only a vacuum-pump-driven desolderer gets out
> enough solder that you don't ruin plate-throughs removing a (former)
If you do rip out the plating, then you can always solder the pin on both sides
when you fit the new chip/DIL socket.
> chip's pins. Beyond that, the cards are also more easily damaged due to
> the smaller land size in general. (And we won't talk about cards where
The RK8E pad size is much larger than that on modern boards. They're much
easier to work on than (say) a board from a PC.
> the word "TOP" is ignored!)
Well, if you misuse the hardware then you deserve problems IMHO.
> >Provided you can get a replacement. A lot of early 1980's machines used ST506
> >drives that are getting very hard to find nowadays.
>
> They're still out there. Certainly easier to get than RK parts!
The RK05 _electrical and electronic_ parts are still very easy to obtain. The
local Maplin (an electronics hobbyist's shop) stocks a lot of the ones that
are commonly needed. As regards mechanical parts, the motors can be rebuilt
(I've done it), the heads are not that rare (although too rare to crash for
the fun of it), and can I am told be rebuilt, and I've never had a spindle
fail. I would claim that most RK05 faults are easy to repair, and parts are
still easy to get.
Now, most winchesters use ASICS that you'll never be able to find. And there's
no hope of fixing a mechanical failure without a clean room.
Some of the older winchesters, like the Micropolis 1200 in one of my
workstations (and in one of my PDP11-a-likes) use standard chips in the
electronics, at least in the most part, and are thus repairable. Unfortunately,
in this case, the servo power amp is the very rare LM379S, which is non-trivial
to get, and which seems to fail too often.
> cjl
>
>
-tony
Lee K. Gleason
Back when I started in the computer field, we used DEC RM03 drives
(a whopping 67 Mbytes). I think they were made by CDC...anyway,
when they had a head crash, they didn't make any unusual noise,
but they did emit a burning electronics sort of smell, as the
friction between the mangled head and the platter burned up the
oxide.
Every year, come winter, when we would turn on the building
heating system, the dust in the furnace would cause a very similar
smell to waft out of the heating vents...every year, we would
smell it, mistake it for the head crash smell, and go tearing into
the machine room, looking for disaster...each time we would sheepishly
remember, "Oh yeah, it's the furnace".
Lee K. Gleason N5ZMR
Control-G Consultants
gle...@mwk.com
David Moisan
david....@postoffice.worldnet.att.net (David M. Razler) wrote:
>being a disk drive and became one of the current computer world's more
>expensive percussion instruments, playing out an endless varied series of
>irregular beats of cuta-tink, cuta tink, cuta-cuta.... tink... If hit hadn't
>crashed the system, we probably would have left it in for fun and game <Icon
>marked drumblaster>
I've been wondering something: Some current drives are made with
plated glass platters. Remember that plane whose jet engine decided
to fail destructively, throwing tiny pieces of titanium everywhere, a
few weeks ago? I'm thinking the same thing the moment some MBA tries
to reboot his laptop after dropping it hard.
(I *have* heard of laserdisk players destroying themselves when the
disk becomes unbalanced. I wonder if it's ever happened to a CD?)
Dave
| David Moisan, N1KGH Email: dmo...@shore.net |
| WWW: http://www.shore.net/~dmoisan n1...@amsat.org |
| Invisible Disabilities Page: |
| http://www.shore.net/~dmoisan/invisible_disability.html |
David M. Razler
dmo...@shore.net (David Moisan) wrote:
>I've been wondering something: Some current drives are made with
>plated glass platters. Remember that plane whose jet engine decided
>to fail destructively, throwing tiny pieces of titanium everywhere, a
>few weeks ago? I'm thinking the same thing the moment some MBA tries
>to reboot his laptop after dropping it hard.
>
Hello tech support? Funny noise then some sand poured out of my laptop. Sand.
Brownish. Yeh, ....
David Moisan
david....@postoffice.worldnet.att.net (David M. Razler) wrote:
>>
>Hello tech support? Funny noise then some sand poured out of my laptop. Sand.
>Brownish. Yeh, ....
You might be surprised to know that plated media isn't oxide brown;
in fact, it's a mirror surface.
I fear the scenario would be more like: "Hello, tech support? My
laptop blew up! My HD? Ummmm, most of it's embedded in me..."
DoN. Nichols
In article <RJM.96Ju...@swift.eng.ox.ac.uk>,
Bob Manners <r...@swift.eng.ox.ac.uk> wrote:
>
> Just how difficult to find are these heads? Is DEC still selling
> them? If they're not at all rare, would you care to try an
> experiment, which requires the use of a tape recorder? :-)
>
>They're rarer than 'common' I think. besides alignment is enough of a
>game to make deliberate crashes a little foolish :)
>
>A watched drive never crashes anyhow ...
In that case -- here's a suggestion to ensure that your disks last
*forever*. Set up a pair of good microphones a mixer, and several DAT
recorders, connected to timers. (Perhaps use the computer istself for
issuing the commands.) Run DAT 'A' to record sounds *not* coming from
drive. When DAT 'A' is about five minutes from end of tape, start DAT 'B'
recording. Let 'A' run till end of tape, then rewind tape. Similarly, when
'B' gets close to end, start DAT 'C'. I figure that four drives should be
enough to make sure that you *could* get a clean recording if it ever
happens, so it won't. :-)
Obviously, if the computer senses problems with the disk, allow the
current DAT drive to run till the EOT. If there is less than an hour left
on the tape, start the next as before. Then cease recording, because the
event has happened.
DoN.
--
Email: <dnic...@d-and-d.com> | Donald Nichols (DoN.)
Voice Days: (703) 704-2280 | Eves: (703) 938-4564
My Concertina web page: | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---
DoN. Nichols
In article <1996Jul18....@picarefy.picarefy.com>,
James W. Birdsall <jwbi...@picarefy.picarefy.com> wrote:
>In article <837637...@p850ug1.demon.co.uk> a...@p850ug1.demon.co.uk writes:
>>replace them with IDE drives, but that's no help to PERQ, PDP, HP150, etc
>>owners like myself who are trying to maintain such machines.
[ ... ]
> Well, sooner or later anything will become unavailable. But if I had to
>bet on a currently-cheap technology still being available in ten years,
>SCSI would be a good one. So far they've been doing an excellent job on
>backward compatibility. When the original MFM drive in my Sun 2/120 started
>making too much noise, I replaced it with a SCSI-2 drive ten years newer
>than the Multibus SCSI controller it was connected to.
*And* -- you did it by *removing* an extra layer of hardware -- the
SCSI-->MFM card bolted onto the side of the chassis.
> Worked perfectly
>right off and has been running 24x7 for months now with no problems.
Certainly the way to go.
Carl R. Friend
DoN. Nichols wrote:
>
> In article <RJM.96Ju...@swift.eng.ox.ac.uk>,
> Bob Manners <r...@swift.eng.ox.ac.uk> wrote:
> >
> >A watched drive never crashes anyhow ...
>
> In that case -- here's a suggestion to ensure that your disks last
> *forever*. Set up a pair of good microphones a mixer, and several DAT
> recorders, connected to timers. (Perhaps use the computer istself for
> issuing the commands.) Run DAT 'A' to record sounds *not* coming from
> drive. When DAT 'A' is about five minutes from end of tape, start DAT 'B'
> recording. Let 'A' run till end of tape, then rewind tape. Similarly, when
> 'B' gets close to end, start DAT 'C'. I figure that four drives should be
> enough to make sure that you *could* get a clean recording if it ever
> happens, so it won't. :-)
I'd suspect that Murphy is a bit more clever than that. What would
probably happen is a head crash along with a simultaneous DAT drive
failure...
Good thought, though.
R. D. Davis
In article <4sjaol$g...@calzone.unc.edu>,
Charles Lasner <las...@calzone.unc.edu> wrote:
>In article <31eb0d01...@netnews.worldnet.att.net>,
>David M. Razler <david....@worldnet.att.net> wrote:
>>The devices sit on moving military objects. The kind subject to salt spray
>>and
>>rocking and tumbling, and, despite the best sealed rooms, not the best
>>environment for moving magnetic media.
>
>True, but modern disks far exceed these requirements. I would dare say
>that the military achieved something where the relatively fragile RK
>drives managed to survive. Using more modern moving media it gets a
>whole lot easier. Going to solid-state disk is overkill.
I agree. Even semi-modern disks exceed such requirements, such as the
PERQ-1 workstation with a 14" Shugart drive which was mounted
appropriately so as to be somewhat insulated from the pitch and roll
of the small craft that it was in - this was back in the early to mid
1980's during the America's Cup race.
>Good ol' Military Intelligence at its best/worst. Any reasonable user
>would want a replacement system, not a replacement component. I would
Sorry, but I must disagree. The U.S. military is doing the right
thing here, and I give them credit for it. If more private companies
and individuals would repair more things, instead of replacing them,
whenever possible when it makes sense ot do so, we'd all be much
better off.
>sell the user the replacement hardware and update all of their software
>to use it. There is *nothing* that could have been done on an RK system
>that cannot be done as easy or better on a more modern interface.
If the old sysem still does the work that it was intended to do when
originally purchased, satisfactorily, why bother to purchase a new
system? To purchase a new system, voluntarily, when one can still do
quite well with the old system, seems quite senseless.
Would you also advocate scrapping every warship which has been
motballed, and replacing the engine on every ship that needs minor
repairs? Would you scrap a car just because it needs a couple of
engine bearings replaced? The answer to these two questions should be
a resounding no.
>Remember, we are talking about replacing drives that are 10.5 inches of
>rack space and weight over 90 lbs. for a capacity of only 2.5 MB each!
Yes, and remember, moving about such drives is rather good
exercise. :-)
--
R. D. Davis * http://www.access.digex.net/~rdd * Eccentrics have more fun!
Computer preservationist - unwanted older systems removed free of charge :-)
PERQ Logic Systems & Unconventional Computer Consulting
divisions of Transpower Industries, Inc. +1 410 744-4900
DoN. Nichols
I've set Followups to a.f.c only. What I have to add has no relation to the
pdp-11 newsgroups in the crossposting. I'm leaving them in for this post
just in case someone in the other newsgroups wants to follow the discussion
to a.f.c. (It *is* nice to see computer folkore in a.f.c again. :-)
In article <31ed768...@netnews.worldnet.att.net>,
David M. Razler <david....@worldnet.att.net> wrote:
>
>My all-time favorite head crash was the one that was virtually *guaranteed* by
>the manufacturer, the Bryant swapping drum <sold through DEC> for the KA-10
>CPU
>
>The unit defined the word "boat anchor," even possessing a loop fitted to the
Wonderful!
[ ... ]
><note: the proliferation of our new pocket-sized disk drives has led to more
>interesting failures, albeit without any of the old-fashioned sound and light
>shows: I have an old Seagate 200-series 5 /14 drive sitting here, looking like
>a sculputure from one of the old Seagate ads with , uh, interesting stain
>patterns on the surfaces from the smoke generated when the power supply on the
>main unit burned and forced smoke through the supposedly sealed drive.
Depending on just where one of these was mounted, and how much the
owner knew about it, things could get pretty bad even with these units.
A friend got from a surplus sale an HP drive box for use with the
98xx series machines (you know the type -- IEEE-488 interface on the back,
3.5" floppy drive and 5.25" hard drive (the original ST506 in this case),
and firmware in there to make the drive look like four 1.25MB drives to the
computer.
I'm not sure just how long they kept trying to use this (or was the
system unattended for a long time?), but when I powered it up to check it
out with one of the HP computers at work, the sounds caused me to
immediately shut it off. They were't *that* loud, but such a sound should
*not* come from a disk box. :-)
I brought it back home, and next time he came over, I described my
findings, so we opened it up, verified that it *was* the disk drive
producing the sound, and yanked it out for post-mortem.
Well ... it had failed on some head or other, but it was not
possible to determine which went first. By the time we opened it, the
damage had progressed to all four surfaces, the heads were either off the
arms and bouncing around, or just dust. The dust had been in there so long
that it had bypassed the internal recirculation filter, and was being sucked
up the hub, and out a set of three holes in the spacer ring between the
platters. From those points, there were three neat spiral arms of deposited
dust, crossing two cleared bands of (very rough) aluminum on each surface.
I kept it as a wall-hanging at work till the patterns were finally destroyed
by too much handling (too many reorganizations/moves). The two cleared
bands corresponded to the first two of the four partitions on the disk.
Presumably, the "thinking" on the part of the original owners went: "Well,
the first disk is bad, let's use the second disk.", never realizing that
they were in actuallity two partitions on the same physical disk. :-)
I'm just not sure about equipment which hides too much of its
internals from the user. :-)
Jay R. Jaeger
Ron Natalie <r...@sensor.com> wrote:
Univac was a really Sperry Rand. That was FastRand, no? That's the
name I remember for those beasties, anyway. As I recall, the
substrate on them was glass.
---
Jay R. Jaeger The Computer Collection
Jay.J...@msn.fullfeed.com visit http://www.msn.fullfeed.com/~cube
Ron Natalie
Of course you're right... Fastrand.
Silly of a man who had a cat named FURPUR to miss that.
-Ron
DATA IGNORED--IN CONTROL MODE
Charles Lasner
In article <837816...@p850ug1.demon.co.uk>,
Tony Duell <a...@p850ug1.demon.co.uk> wrote:
>In article <4slibt$c...@calzone.unc.edu>
> las...@calzone.unc.edu "Charles Lasner" writes:
>
>> >AFAIK you _can_ modify standalone BRU (The RSX install-from-tape program),
>> >particularly if you've got a source license _but only after you've installed
>> >the OS_. It's a chicken and egg problem - you need BRU working to install
>> >RSX, but you need RSX installed to modify standalone BRU.
>>
>> I assume you mean that you not only need RSX already running on a
>> DEC-sold disk system, but also a DEC-sold tape system is what BRU is used
>> from.
>
>AFAIK, if you have a running RSX system (on whatever sort of disk) you can use
>it to modify BRU to read/write whatever sort of devices you like. You may need
>a source license to get the BRU sources, though.
In general, third-party devices tend to be supported by migrating away
from all-DEC machines that the devices are attached to as "guests." The
system gets reconfigured to require the new device and not the original
DEC device, etc. If some form of interface-independent media is
available, then in theory you can port an image of the system on it to be
accessed from some other code perhaps for another device that is merely
media-compatible, but not code compatible, etc. In the case of the
PDP-8, rarely was this magtape, but often it could be paper-tape if
required. In many cases, it wasn't an issue because the user already had
some other low-performance but adequate device such as DECtape to get the
system configuration established. A typical case would be sending the
binary of an OS/8 driver on paper tape along with a disk drive and
controller/interface. You read in the driver, which even on a teletype
only takes a few seconds (drivers are only 128 or 256 12-bit words tops
in the world of OS/8, so a device successfully achieving a working
handler can have its driver punched out on a tiny piece of tape, etc.),
and you now have the ability to configure a disk system from the running
tape system, etc. After the system is transferred, you configure the
disk system to support non-system tape handlers. Thus, you now have the
ability to run from a much faster device and also access your original
data from the original lower-powered configuration. Admittedly, had
these configurations been configured to less than functional
storage-based systems, it would be a whole lot harder, but fortunately,
the systems with at least the minimum complement of storage hardware was
the norm at the time, etc.
>
>
>[PDP8 tape info deleted]
>
>> >Can you install OS/8 on a non-DEC disk without having it installed on
>> >another system first? If so, how?
>>
>> Yes, using paper-tape. The early systems depended on a lot of tape
>
>Yes, but the paper tape reader had better be compatable with the DEC one, or
>the BUILD program won't load. I could link up a Trend HSR500P to a DR8E, and
>no way would OS/8 install from it. The initial load device had better
>be something that the loader/installation program knows about.
In the PDP-8 world, the trivial device 01 interface was generally
mimicked. You are technically correct, but businesses generally decided
to do it compatibly. In any case, a driver could be written to handle
your version if you need it. That of course presupposes there is an
otherwise running system! However, we have had systems running based
merely on serial interfaces to a serving machine, so a pre-running system
isn't necessarily all that hard to achieve. (Again, we are not talking
about high-performance, merely the ability to get the device up.
Presumably you want to use the device as part of improving the performance
of the entire system, etc.
>
>And how do you _write_ the custom handler for the system disk? You could
>use the front panel or a standalone assembler, but by that argument, you could
>modify RSX11 BRU in a similar way.
Writing the handler in the OS/8 world involves several steps:
1) The device ought to be attached to an already well-configured
system. Thus, it's desirable to already have another disk, a decent
terminal, running development software, and hopefully an LPT:. I was
fortunate that early on I was granted a "real" development system, etc.
In some cases, I had to walk the binary to the target system that had
much more minimal hardware after developing it on the "big" machine. A
good example was developing the P?S/8 system for the TD8E with MR8E-C
ROM. This was accomplished on a machine which had a 10 MB hard disk (not
bad for the middle '70's!) as well as TC08/TU56 DECtape. The attempt was
written out on the DECtape and the tape walked to another site that had
the most minimal configuration: 8K, TTY:, and a TD8E and a TU56H (one
drive). The binary had to get read in on the spot using the MR8E-C ROM,
and in-memory patching done to debug the code until either it worked or I
had to give up and head back for the development machine. If I had it
to do over again, I would have requested that the TD8E be transferred to
the development machine while temporarily disabling the TC08. In any
case, after a few iterations, I got P?S/8 up totally on the TD8E. From
then onwards, the TD8E support was merely an ongoing part of the
supported devices section, etc.
2) Regardless of where you develop it or for that matter debug it, it's
a task that "separates the men from the boys" in the PDP-8 world.
Writing handlers is likely the most difficult code ever done. The reason
is that generally it's a job stated as nearly impossible! OS/8 handlers
desire to be entirely self-contained in about 128 12-bit words. Within
that environment there are two different types: non-system handlers that
can use the entire 128 word space, system handlers that only get about
3/4 of the space due to a whole lot of reserved locations. Two-page
handlers are allowed, but there is a lot of cross-page overhead such that
you really don't get more than about 1.5 times the space you started
with. Additionally, the two-page system handler has further restrictions
on code placement, and also a few reserved and unavailable locations
more, etc.
As such, writing handlers is essentially a "no holds barred" approach.
You come in ahead of time attempting to optimize the code even before you
write it. You seek out situations to define nifty useful constants that
are the instructions themselves, knowing that it's highly unlikely there
will be room for the relative luxury of "real" constants. You start
considering which bits of any constant that are essentially don't-care,
thus allowing consideration of which instructions will yield
effective-enough constants. For example, some registers can be
guaranteed to not provide non-zero bits in bits[0-3] while you read back
the low-order 8 bits into the 12-bit AC. Thus, if you need a constant
0003 to .AND. against the low-order 8 bits, it's acceptable to use the
constant 0203 instead of 0003. By contrivanace, it's possible to
position a certain data location at relative 0003 of the page. Thus, an
AND instruction to that location is also useful as the constant 0203.
Therefore, it would also be referenced as a constant 0203 besides being
the normal instruction to perform that required AND operation, etc.
Similarly, constants can be formed by using superfluous bits in OPR
instructions. (You really have to be sure the bits are superfluous!)
This is how constants such as 7600, 7700, 7740, 7750, 7760, 7770 can be
formed without wasting another word, etc.
Unfortunately, the small space also means a whole lot of performance
compromise and/or error recovery problems. One of the worst cases is the
RX diskette interface. In most instances of code, an inefficient divide
routine is used based on repetitive subtraction. This is the heart of a
routine used to map the disk sectors into a 2:1 interleave. (You
basically divide the caller's requested logical sector by the number of
sectors on each track to get a track number. However, you divide by half
the number of sectors on a track and shift one bit over. In the process,
the remainder includes a bit to determine the interleave, etc.) By
performing the divide with an inefficient piece of code that takes the
smallest amount of space, certain calls are handled inefficiently,
because the diskette is rotating during the slow divide to the point that
the throughput suffers on actual machines! (Note: the RX interface
appears on the VT78 which is only 20-40% of the speed of the PDP-8/e. In
point of fact, the original OS/8 handler for the RX01 ran at 1/13th the
speed of it attached to the PDP-8/e. Even the final OS/8 handler still
writes at 1/13th the speed, and this is a two-page handler, etc. The
original one-page handler has been dropped, albeit largely for unrelated
reasons, etc.)
In P?S/8, there is a slightly different model at work: If possible, it
is as desirable as in OS/8 to achieve a one-page handler. Non-system
handlers have the entire one (or more) pages to themselves entirely as in
OS/8, but have slightly more work to accomplish due to the handler being
marginally more powerful. (Unlike OS/8's non-system handler requirement
to be merely page relocatable, P?S/8's non-system handlers also have to be
FIELD relocatable.)
However, system handlers have to do a bit more work in a bit less space
for P?S/8 than in OS/8. (Error recovery is defined to have to actually
be able to attempt a recovery expected to recover! In OS/8, it's
allowed, albeit a cop-out, to have a handle merely take an "error return"
that is essentially a fatal and non-recoverable condition. In OS/8, the
caller of the handler could opt to reissue the call, thus creating an
infinite retry situation. If the handler cannot recover, this means that
it hangs. In P?S/8, the retry is built into the handler. The call could
contain either an automatic infinite retry situation, a manual restart
after a HLT thus requiring a front panel and an operator, or an elegant
mechanism leading to a screen status display and operator intervention
dialogue. Each of the three choices is available depending on the
overall configuration of P?S/8, etc. In any case, a handler that gives
up with no possibility of error recovery is unacceptable, etc.
Regardless, DEC has been guilty of distributing handlers for OS/8 that
had no hope of recovery should the error return be taken, etc. This did
in fact lead to loss of user data, and eventually to withdrawing at least
one version of a handler written too fanatically to run in 8K instead of
12K. I can elaborate on this if anyone requests it.) (Additional note:
P?S/8 system handlers have more reserved locations than OS/8 because the
system is inherently a 4K system. OS/8 has the relative "luxury" of
being able to reserve locations in a second field, thus the handlers
aren't quite as strapped for space. I think the final tally is that the
body of an OS/8 handler is about 92 words and the count for a comparable
P?S/8 handler is about 86 words. In any case, neither of these cases
represents an "easy" implementation!)
Assuming that one page isn't enough, P?S/8 has it a whole lot easier than
OS/8. OS/8 only gets an additional nearly-available page with a few
restrictions. P?S/8 system handlers get an additional eight complete
pages! The P?S/8 system handler for the RX01 actually fits in three
pages (but includes other features that are beyond the scope of an
inter-system comparison; these are optional features of P?S/8 that were
implemented on the RX01, but have been left out of other devices due to
either space restrictions or inapplicability, etc.). Additionally, no
aspect of either performance or error recovery was compromised within
this handler.
Instead of using a simple but inefficient smallest-code-space divide
routine, the code was replaced with an elegant speed-optimized algorithm
(based on hardware EAE divide) and a second-order piece of code used for
all subsequent calculations that calculates the next sector and track
based on the previous sector and track by much faster means. As a
result, this handler manages to run as fast as possible even on a VT78, etc.
Non-system P?S/8 handlers can be as long as 32 pages, but waste is
frowned on. To date, no handler has ever been written that is longer
than 7 pages. Fanatic optimization is thus limited to one-page handlers,
with the same zeal that is always necessary for all OS/8 handlers, etc.
3) Once you have your handler written, it's really not much work to get
it where you need it. In OS/8, the handler is at most 256 12-bit words
plus about 20-30 words of header info and perhaps a secondary boot piece
of code meant for use in the first half of the boot record. (The handler
resides in the second half in 8K systems. The job of the first half is
to get both itself and the second half located where they are needed.
The first half is largely reserved, so this secondary boot code is of
necessity rather short, etc.) The handler could be typed into BUILD in
extreme cases. BUILD can take care of the rest, as long as you have the
rest of OS/8 available on either another disk device that happens to be
on the machine, or available on paper-tape, or even cassettes.
For myself, it's generally true that I get the device added onto an
already quite viable development machine, thus, the task at hand reduces
down mostly to "merely" writing the code itself!
>
>[Repairing RK8E's]
>
>> I didn't have the luxury of a logic analyser, but the problem is that a
>
>A logic analyser would certainly be useful, but I suspect you could manage
>without one if you had to.
>
>> lot of the automatic operations of the RK8E are only fleeting and are
>
>The same is true about a lot of other boards I could mention. You can often use
>hacked-together logic wired to the board under test to detect the condition
>you are looking for and trigger the 'scope on it. Having a storage 'scope, or
>at least one with a long-persistance phosphor helps a lot. Of course a logic
>analyser with a word recogniser is even more useful.
>
>> hard to 'scope out. Especially when failure modes of chips still produce
>> semi-plausible results. Thus, you wind up having to change a few more
>> chips than more sophisticated sleuthing might allow, etc.
>
>OK, so you have to change a few more chips. The chips on the RK8E are cheap,
>and in general easy to obtain. It's no big hassle to change a few more (even
>though there's a certain satisfaction in working out the faulty component and
>getting it right).
Yes, we all like to guess correctly. But on the RK boards, it's a whole
lot harder to remove the chips than on the other DEC boards of that era.
>
>>
>> In any case, changing TTL on those boards is far worse a job than on
>> other similar boards. The holes are rather small (no, I didn't have to
>
>The holes on my RK8E are no smaller than the ones on any other DEC board of
>the time. DEC always used smaller holes than most other companies.
Simply not true. Compare the M7104,5,6 lands with the CPU boards for
example. The lands are always ripped out on an RK board that wasn't
handled extra carefully compared to the other boards.
>
>> count them all! :-)) and forget about recovering a chip you pulled. The
>
>If you know the chip is dead, or it's easy to get, then you clip off the pins
>and desolder them separately.
But on the RK board, you really don't know if the chip is dead, so you
are guessing. Generally you wind up changing 5-6 chips before finding
the culprit. And each is really that much more difficult than it should
be. Some of the chips aren't all that expendable, yet virtually all will
get destroyed, etc.
>That said, careful use of a temperature
>controlled iron and a good solder sucker will get the chip out without damaging
>chip or board. The tricks are :
Agreed. The vacuum desolderer made it more likely to survive without
pulling out lands. But still the chips have to be destroyed and removed
pin by pin.
>1) Resolder all the joints first
Yes, unless there is enough solder present, you cannot suck out
completely a scant amount that was enough for the original purpose, etc.
>2) Don't be afraid of overheating the chip. Get the solder molten before you
>suck
Again, presupposes wanting to kill the chip, but largely not an option.
>3) Break the bod between the chip and the board by pressing each pin inwards
^^^^ I assume bond
>with a screwdriver before pulling the chip
Often two screwdrivers or a chip puller.
>4) Don't force anything. If a pin is stuck, resolder it, resuck, and try again
>
Exactly. They look sucked out, but aren't sometimes!
>I've removed chips from various boards in the 8/e (and the peripherals), and
>never had problems.
A whole lot easier than on the RK boards. I have used a temperature
controlled iron and a Solda-Pullit for most of the other boards with easy
success; another story entirely on RK boards :-(.
>
>> small size is such that only a vacuum-pump-driven desolderer gets out
>> enough solder that you don't ruin plate-throughs removing a (former)
>
>If you do rip out the plating, then you can always solder the pin on both sides
>when you fit the new chip/DIL socket.
True, but all too often what was done, etc.
>
>> chip's pins. Beyond that, the cards are also more easily damaged due to
>> the smaller land size in general. (And we won't talk about cards where
>
>The RK8E pad size is much larger than that on modern boards. They're much
>easier to work on than (say) a board from a PC.
Likely, but we are comparing the boards of that era to each other.
>
>> the word "TOP" is ignored!)
>
>Well, if you misuse the hardware then you deserve problems IMHO.
It doesn't say "Only put this board into the buss so that the word "TOP"
can be read in the normal manner." Instead it just says "TOP." Real
spectacular and sparky smoky burny things happen when you ignore this!
Recovery needs a whole lot of long skinny long-run land repair. I opted
to use wire-wrap wire on the one I fixed for them, etc.
>
>> >Provided you can get a replacement. A lot of early 1980's machines used ST506
>> >drives that are getting very hard to find nowadays.
>>
>> They're still out there. Certainly easier to get than RK parts!
>
>The RK05 _electrical and electronic_ parts are still very easy to obtain. The
>local Maplin (an electronics hobbyist's shop) stocks a lot of the ones that
>are commonly needed. As regards mechanical parts, the motors can be rebuilt
>(I've done it), the heads are not that rare (although too rare to crash for
>the fun of it), and can I am told be rebuilt, and I've never had a spindle
>fail. I would claim that most RK05 faults are easy to repair, and parts are
>still easy to get.
>
>Now, most winchesters use ASICS that you'll never be able to find. And there's
>no hope of fixing a mechanical failure without a clean room.
>
>Some of the older winchesters, like the Micropolis 1200 in one of my
>workstations (and in one of my PDP11-a-likes) use standard chips in the
>electronics, at least in the most part, and are thus repairable. Unfortunately,
>in this case, the servo power amp is the very rare LM379S, which is non-trivial
>to get, and which seems to fail too often.
>
>> cjl
>>
>>
>
>-tony
>
cjl
Charles Lasner
In article <4ssak9$6...@access1.digex.net>,
R. D. Davis <r...@access1.digex.net> wrote:
>In article <4sjaol$g...@calzone.unc.edu>,
>Charles Lasner <las...@calzone.unc.edu> wrote:
>>David M. Razler <david....@worldnet.att.net> wrote:
>
>>>The devices sit on moving military objects. The kind subject to salt spray
>>>and
>>>rocking and tumbling, and, despite the best sealed rooms, not the best
>>>environment for moving magnetic media.
>>
>>True, but modern disks far exceed these requirements. I would dare say
>>that the military achieved something where the relatively fragile RK
>>drives managed to survive. Using more modern moving media it gets a
>>whole lot easier. Going to solid-state disk is overkill.
>
>PERQ-1 workstation with a 14" Shugart drive which was mounted
>appropriately so as to be somewhat insulated from the pitch and roll
>of the small craft that it was in - this was back in the early to mid
>1980's during the America's Cup race.
>
>>would want a replacement system, not a replacement component. I would
>
>thing here, and I give them credit for it. If more private companies
>and individuals would repair more things, instead of replacing them,
>whenever possible when it makes sense ot do so, we'd all be much
>better off.
But who decides that it makes sense? I am stating my position from years
of experience:
It simply isn't worth preserving the mediocre design of the RK disk.
Even though it wasn't as vile as the RL (which I would actively compaign
to stamp out every scrap of existence for), it represents a mediocre disk
subsystem that PDP-8's and -11's deserve far better to be attached to
them. Even in its heyday there were third-party vendors of far-better
disks. I was personally responsible for recommending several of them
based on the Diablo 40 type cartridge (later raped by DEC as the RL). On
the PDP-8, the interface was far superior on these other disks, the
throughput better, the overall size larger, more reliability, lower cost,
ease of programming, better ability to get high-performance throughput, etc.
Clearly the original programmers of the RK did little past mimicing the
DEC-supplied handlers; there really isn't too much you can do for the RK
disk other than that. (Note: OS/8 handlers are great compromises where
the entire game is to get a handler that fits in a small space. As a
result, it's highly likely that the result is low-performance dependency
on the disk interface. In fact, I would wager that their programs don't
even have any RK programming in them at all, merely copping out to OS/8
system calls to have the disk I/O done for them automagically, which
severely limits the real-time aspects of the application, assuming there
are any in the disk sub-system at all! Such a collection of applications
can be trivially rewritten for a better device such as the MDC8, even if
source code is long gone, since it's trivial to spot the RK8E code.
Remember, on the PDP-8, I/O is done with device codes, thus you can
easily spot the disk I/O code even in a sea of 12-bit binary, etc. BTW,
I've done this sort of thing more than a few times.)
>
>>sell the user the replacement hardware and update all of their software
>>to use it. There is *nothing* that could have been done on an RK system
>>that cannot be done as easy or better on a more modern interface.
>
>If the old sysem still does the work that it was intended to do when
>originally purchased, satisfactorily, why bother to purchase a new
>system? To purchase a new system, voluntarily, when one can still do
>quite well with the old system, seems quite senseless.
The subject matter was in fact to redesign an entirely new system that
merely mimics the old system, limitations and all. The question is
whether or not it makes sense to uphold the requirement of a strictly
no-code-change spec. In the PDP-8 world at least, this isn't as
important as it would be taken perhaps elsewhere, etc.
>
>Would you also advocate scrapping every warship which has been
>motballed, and replacing the engine on every ship that needs minor
>repairs? Would you scrap a car just because it needs a couple of
>engine bearings replaced? The answer to these two questions should be
>a resounding no.
I would tend to agree, but I don't agree to the analogy. I would have to
scrap anything for a proverbial want-of-a-nail. (Unless of course
someone has a large bag of nails :-).)
>
>>Remember, we are talking about replacing drives that are 10.5 inches of
>>rack space and weight over 90 lbs. for a capacity of only 2.5 MB each!
>
>Yes, and remember, moving about such drives is rather good
>exercise. :-)
But not when they break loose of their bulkheads and land on your toe :-(.
>
>--
>R. D. Davis * http://www.access.digex.net/~rdd * Eccentrics have more fun!
>Computer preservationist - unwanted older systems removed free of charge :-)
> PERQ Logic Systems & Unconventional Computer Consulting
> divisions of Transpower Industries, Inc. +1 410 744-4900
cjl
Tony Duell
In article <4t5jlr$s...@calzone.unc.edu>
las...@calzone.unc.edu "Charles Lasner" writes:
> In general, third-party devices tend to be supported by migrating away
> from all-DEC machines that the devices are attached to as "guests." The
And if you're doing that (i.e. an initial install only used DEC devices), then
there's no reason that I can think of _not_ to use a non-DEC device as a
system device under any of the PDP11 OS's.
> >Yes, but the paper tape reader had better be compatable with the DEC one, or
> >the BUILD program won't load. I could link up a Trend HSR500P to a DR8E, and
> >no way would OS/8 install from it. The initial load device had better
> >be something that the loader/installation program knows about.
>
> In the PDP-8 world, the trivial device 01 interface was generally
> mimicked. You are technically correct, but businesses generally decided
But why? A high speed paper tape reader (and there have been paper tape readers
that could read 5000 chars/sec) could benefit from some kind of DMA. So you
are deliberately holding back the capabilities of the device for compatability.
Unfortunatly, on the PDP8 (this doens't apply to the PDP11 AFAIK), there are
subtle differences between the Paper tape interface and the standard serial
card. It's not trivial to link up a high speed reader to a serial card (either
using a serial interface or by removing the UART and using a parallel link)
and get it to work with standard DEC software. And DEC PC04's are not well
designed readers IMHO - any reader that is sprocket-fed is going to mangle
at least one important tape sometime. The sprocket-sensing capstan-fed readers,
like the Trend HSR's and UDR's are much nicer. Unfortunately, interface cards
for these are not common (I am looking for one if anyone has a spare, hint,
hint)
> 2) Regardless of where you develop it or for that matter debug it, it's
> a task that "separates the men from the boys" in the PDP-8 world.
> Writing handlers is likely the most difficult code ever done. The reason
> is that generally it's a job stated as nearly impossible! OS/8 handlers
> desire to be entirely self-contained in about 128 12-bit words. Within
Fortunately, this does not apply to PDP11's, where AFAIK there's no limit to
driver size under any of the OS's. But you were claiming earlier that it was
on PDP11's where you had to be 100% compatable with a DEC device.
[...]
[Reparing the RK8E]
> >OK, so you have to change a few more chips. The chips on the RK8E are cheap,
> >and in general easy to obtain. It's no big hassle to change a few more (even
> >though there's a certain satisfaction in working out the faulty component and
> >getting it right).
>
> Yes, we all like to guess correctly. But on the RK boards, it's a whole
> lot harder to remove the chips than on the other DEC boards of that era.
Yes, BUT... It's a whole lot easier than on the modern boards that you are
suggesting we replace them by. I've just opened up my 8/e and pulled the
RK8E cards. Yes, the pads are a little smaller than on the TD8E I happened to
have on top of the machine, but not much. The traces are a lot thinner, I will
agree, but that shouldn't make much difference.
Actually, the RK8E boards look to have similar size features to the PC-clone
boards I've just looked at. Since I've repaired those on several occasions,
I don't think the RK8E will be any worse.
> Simply not true. Compare the M7104,5,6 lands with the CPU boards for
I just have done. The RK8E does have smaller pads than the 8/e CPU, but they're
no smaller than on the PC-clone board I just mentioned, or than those on
several PDP11 cards like the M8109 I've just picked up. You are lucky that the
8/e CPU has larger pads, and is thus easier to repair - the RK8E is the
more 'standard' size.
> example. The lands are always ripped out on an RK board that wasn't
> handled extra carefully compared to the other boards.
But you should always handle these boards carefully. If you do so, then you'll
have no problems.
> But on the RK board, you really don't know if the chip is dead, so you
There are plenty of ways of in-circuit testing the chips on the RK8E. The best
one involves a logic analyser and a set of extender boards, but even without
such luxuries, you can often force the pins into known states. Most faults are
easy to trace if you can do that.
I've repaired a large number of such computer systems, and only once have I
_needed_ a logic analyser (to trace a microcode problem in a PERQ workstation).
On all other occasions, I've managed to figure it out using simpler test gear.
> >2) Don't be afraid of overheating the chip. Get the solder molten before you
> >suck
>
> Again, presupposes wanting to kill the chip, but largely not an option.
Not at all. You will not damage a chip by overheating it with a normal
soldering iron unless you are very careless. I've used an iron on the pins of
a chip from the _component side_ (which obviously gets the chip a lot hotter
internally) with no damage. I have never overheated a chip when soldering or
desoldering it.
>
> >3) Break the bod between the chip and the board by pressing each pin inwards
> ^^^^ I assume bond
> >with a screwdriver before pulling the chip
>
> Often two screwdrivers or a chip puller.
NO WAY. That's the way to lift pads or damage plating. You're not trying to
lift the chip out at this point - what you are doing is cracking the remaining
bond between the pin and the PCB. It's done like this
IC body
=====\
|+
=====/ |
|<------------Press with small screwdriver here, in direction of arrow
-------|--------- PCB after desoldering
|
I've often desoldered 20-30 programmed chips from extremely rare boards,
examined the contents and put them back in again. These were 6 layer boards
with pads and traces smaller than the RK8E
[...]
> Likely, but we are comparing the boards of that era to each other.
I'm also comparing the RK8E to the sort of board you are suggesting I replace
it with.
>
> >
> >> the word "TOP" is ignored!)
> >
> >Well, if you misuse the hardware then you deserve problems IMHO.
>
> It doesn't say "Only put this board into the buss so that the word "TOP"
> can be read in the normal manner." Instead it just says "TOP." Real
> spectacular and sparky smoky burny things happen when you ignore this!
> Recovery needs a whole lot of long skinny long-run land repair. I opted
> to use wire-wrap wire on the one I fixed for them, etc.
My board (I've just pulled it to check) says TOP in capital letters and has
2 arrows alongside it (one at each end) pointing upwards. If you can't
understand that, you shouldn't be repairing 8/e's IMHO. Now, we've all made
mistakes (I certainly have - like the time I blew up a rare 7482 full adder
by putting a flip-chip card into a spare backplane to test it, not realising
that DEC used B2 (the standard -15V line) as a Carry In on this card), but
don't blame it on the hardware.
The printset also shows how to insert the card.
> cjl
-tony
Tony Duell
In article <4t5eh5$5...@calzone.unc.edu>
las...@calzone.unc.edu "Charles Lasner" writes:
> It simply isn't worth preserving the mediocre design of the RK disk.
> Even though it wasn't as vile as the RL (which I would actively compaign
What's wrong with the RL? I've used them on PDP11's (never on PDP8's, although
I have an RL8 in my 8/a), and I find them to be simple and reliable drives.
The RL01 was one of the first embedded servo drives, and of course, head
alignment is thus reasonably unimportant. I've battled through the servo
system with a scope on a couple of occasions, and provided it's set up
properly (something the manual is not that good on), it will work, and it
will work well.
Now, the RL11 controller is a bit more of a problem. It seems to work OK, but
compared to the RK11, it's nowhere near as nice to program IMHO (a trivial
example - you have to give it a cylinder difference rather than an absolute
cylinder, and you can't cross a track boundary on a single operation). I
can't comment on the repairability of it - I've only ever had one problem on
an RL11 - loss of the 8V line due to a defective regulator. And I've never
had an RLV11 do anything stupid.
To return to the RK's. On the PDP11, I find them reliable, mainatainable, and
just plain simple. Given a KM11, both common PDP11 controllers can be diagnosed
quit quickly. Without that module, you need a bit more hacking to find the
problem.
The only problem I've had with the RK11-C (yep, the 100+ flip-chip one) was a
checksum failure. This was my first DEC logic fault, and took about 2 hours
to trace. But it would take me a lot less time to find it now.
Provided you maintain these drives and controllers (and that means going
through the PM list in the manual, and then some more, and checking every
adjustable setting in the electronics), they don't seem to cause any problems.
> to stamp out every scrap of existence for), it represents a mediocre disk
> subsystem that PDP-8's and -11's deserve far better to be attached to
> them. Even in its heyday there were third-party vendors of far-better
I've had many more problems with 3rd party disks systems. Most of them stem
from totally inadequate documentation -
Lack of setup information ( 'This can't be set in the field' means 'We don't
give field servoids a scope'). This was fine when you could send the module back
for repair, or get a replacement. Now, I'm often stuck looking at a 'scope or
logic analyser working out just how to set up an undocumented PLL.
Lack of microcode documentation - a lot of the 3rd party controllers I've
come across use the AM2900 series chips for everything, even bus address
decode. Without a source of the microcode, or at least the entry points to
the main routines (something which generally came with DEC-supplied controllers
of the time), you haven't a hope of figuring out what it's doing
Lack of schematics - a couple of companies never even supplied schematics. Well,
I'm not having that sort of board in my system.
Lack of mechanical info - One CDC drive has 3 fixed platters that come mounted
on an alignment jig from the factory. You put this in the drive, screw in the
fixings, remove the jig. Fine, except that :
a) if you get it wrong, you have to send the new platters back to CDC to have
the jig re-installed and then try again.
b) you have to remove the fixed platters to do some other operation (I forget
what). So you then send your 3 platters back to CDC to have a jig fixed to them
and then try to reinstall them. No thanks!. I'll stick to drives I can
repair on my own.
> disks. I was personally responsible for recommending several of them
> based on the Diablo 40 type cartridge (later raped by DEC as the RL). On
The RL drive was IMHO very different to the others using the same type of
cartridge, if only because DEC put servo bursts in the sector headers
> I would tend to agree, but I don't agree to the analogy. I would have to
> scrap anything for a proverbial want-of-a-nail. (Unless of course
> someone has a large bag of nails :-).)
I disagree 100% here. If you want something as simple as a nail, you go and
make one. Similarly if you need some long-gone TTL-like chip for a PDP8, you
program a PAL or GAL to replace it and kludge-wire it in.
> >>Remember, we are talking about replacing drives that are 10.5 inches of
> >>rack space and weight over 90 lbs. for a capacity of only 2.5 MB each!
One thing I always point out to people when I show them an RK05. I tell them
that the pack has the same amount of storage as 2 modern 3.5" disks (1.44M ones)
I then point out that the pack is 20 years old and _still readable_. That's a
lot more reliable than most modern drives, and is sometimes the important
thing.
-tony
G. R. Garyo Zempel
In article <4t40j8$t...@tricia.msn.fullfeed.com>,
Jay.J...@msn.fullfeed.com (Jay R. Jaeger) wrote:
>Ron Natalie <r...@sensor.com> wrote:
>
>>Back in my Univac days, the standard Univac storage device was a
>>Faststran
[snip]
>Univac was a really Sperry Rand. That was FastRand, no? That's the
[snip]
I don't think "beasties" quite captures it for me:
ours was a BEAST filling a small room. The room was
glass walled, and you went by it from the Computer
Science dept. when you went to Dispatch to turn in
your card decks or pick up you output.
We liked to picture the damage to the nextdoor offices
if its bearings failed.
-- G.R. Zempel(Gary/Garyo) -- Krmr...@IConn.Net --
-- My lame first Web page: http://members.aol.com/garyzempel/lame.html --
---------- Standing up here on the shoulders of giants, -----------------
------------ an urgent task is learning how to keep our balance. --------
**** (What have you done TODAY to make information more accessible?) ****
Williams, Steve
Interesting(?) Fastrand facts^H^H^H^H^H urban tales:
o Fastrand drums were the culmination of a direct line of development
from an original drum designed by ERA in the late '40s, refined
through the LARC program. The original prototype had a magnetic
surface composed of ferrite coated recording tape wrapped around a
drum which was advance by stepper motor.
o A Fastrand comprised two horizontal drums about 7 feet long weighing
<mumble> tons. If the brakes failed they would take days to stop
spinning after they were powered down. Some customer engineers would
polish the drums while they were still spinning, but don't let your
hand get caught between the two drums. The momentum could tear your
arm off.
o The drums themselves were manufactured from pipeline stock which was
machined down to the correct dimensions, balanced, plated and mounted
on spindles.
o Union Bank Switzerland has one stripped of its skins on display in
the entrance to their Zurich computer centre. At least one other
Fastrand was retired and the drums used to make rollers for lawn
tennis courts.
o Fastrands mounted experimentally on a destroyer in the 1960's had to
be taken out of service since the gyroscopic action of all those tons
of spinning metal affected the manoeuvrability of the ship.
o Similarly, a newly manufactured drum which was crated up as part of
an emergency shipment from the St Paul plant jumped off its fork lift
truck the first time the truck tried to make a turn. It appears the
drum had been still spinning after its final checkout.
o These were really cool looking units. The cabinets were modernistic
1960s design with a smoked glass window showing the two rotating drums
which had a flawless (in normal circumstances) mirrored silver finish.
Visually, computers were much more interesting then. Anyone ever used
a Univac 1110 maintenance panel?
Steve (never got used to Sperry, let alone Unisys) Williams.
Eric van der Meer
: Ron Natalie <r...@sensor.com> wrote:
:
: >Back in my Univac days, the standard Univac storage device was a
: >Faststran
: >flying head drum unit. The maintenance panel had an array of "hit
: >detector
: >lights" you can imagine what this says about the mean time between head
: >crashes.
:
: Univac was a really Sperry Rand. That was FastRand, no? That's the
: name I remember for those beasties, anyway. As I recall, the
: substrate on them was glass.
:
: ---
: Jay R. Jaeger The Computer Collection
: Jay.J...@msn.fullfeed.com visit http://www.msn.fullfeed.com/~cube
Incidentally, in a way the organization of the Fastrand drum lives on even
today. On Unisys 1100 and 2200 systems, disk files are presented to the
programmer as a number of sectors. Each sector contains 28 words (of 36
bits), 64 sectors form a track, and 64 tracks a position. This is
irrespective of the underlying hardware, which is in sharp contrast to teh
situation in the IBM world.
Just a note from an old Univac/Sperry/Unisys programmer.
Eric
Charles Lasner
In article <838251...@p850ug1.demon.co.uk>,
Tony Duell <a...@p850ug1.demon.co.uk> wrote:
>In article <4t5jlr$s...@calzone.unc.edu>
> las...@calzone.unc.edu "Charles Lasner" writes:
>
>> In general, third-party devices tend to be supported by migrating away
>> from all-DEC machines that the devices are attached to as "guests." The
>
>And if you're doing that (i.e. an initial install only used DEC devices), then
>there's no reason that I can think of _not_ to use a non-DEC device as a
>system device under any of the PDP11 OS's.
True. And that's why there have been so many third-party vendors. They
assume you have a viable, albeit underpowered, configuration such as RX's
only, so they can sell you a better disk you can get up merely by
supplying the drivers, etc.
>
>> >Yes, but the paper tape reader had better be compatable with the DEC one, or
>> >the BUILD program won't load. I could link up a Trend HSR500P to a DR8E, and
>> >no way would OS/8 install from it. The initial load device had better
>> >be something that the loader/installation program knows about.
>>
>> In the PDP-8 world, the trivial device 01 interface was generally
>> mimicked. You are technically correct, but businesses generally decided
>
>But why?
I said businesses.
Again, this is at the heart of the matter I raised earlier: why make a
lock-step compatible device when you can make a better one as long as
there is adequate access to all of the software situations that matter,
etc. In the PDP-8 world, this is especially true in the disk device area.
However, in the world of PDP-8 paper-tape, remember that the whole issue
of paper-tape is driven by the need to support the RIM loader as a
minimal toggle-in task. Any other solution will not only be
incompatible, but more imporatantly would take more locations to toggle
into. There was just too much paper-tape-oriented software that won't
tolerate this.
>A high speed paper tape reader (and there have been paper tape readers
>that could read 5000 chars/sec) could benefit from some kind of DMA. So you
>are deliberately holding back the capabilities of the device for compatability.
Absolutely correct. That's what they did. But since DEC charged so much
for a low-performance unit, they knocked it off to provided either the
same for less or more for the same. You are asking for something that's
a whole lot more but incompatible. That didn't fit the model. Today, I
think the whole issue of paper-tape is largely unimportant, and I would
hope that one of the aims of PDP-8 enthusiasts is to get past this stage
of depending on long streams of paper-tapes. Of course if you want to
pursue the hobby project of a hot-rod paper-tape reader, by all means go
for it, etc.
>
>Unfortunatly, on the PDP8 (this doens't apply to the PDP11 AFAIK), there are
>subtle differences between the Paper tape interface and the standard serial
>card.
Not really an issue. Look at the RIM loader for the HSR and the TTY.
They are the same size. As long as the code fits, you are allowed to
make any device code or IOT specific change you want, etc.
BTW, DEC field circus used a medium-speed serial interfaced paper-tape
reader for loading diagnostics into machines such as the VT78. The
device is essentially a device 01 keyboard interface. All works fine
except that the interface cannot hold back the frames. Thus, it's only
usable for the intended purpose: read a diagnostic into memory and then
start it up. As the program starts, the out-of-control ignored reader is
still spewing forth frames until the physical end of tape, etc. But you
wouldn't want this device on an OS/8 machines to read in paper-tapes into
files!
>It's not trivial to link up a high speed reader to a serial card (either
>using a serial interface or by removing the UART and using a parallel link)
>and get it to work with standard DEC software.
See above.
>And DEC PC04's are not well
>designed readers IMHO - any reader that is sprocket-fed is going to mangle
>at least one important tape sometime.
Maintained correctly, it doesn't.
>The sprocket-sensing capstan-fed readers,
>like the Trend HSR's and UDR's are much nicer.
Sounds like it, but most of us didn't really care.
>Unfortunately, interface cards
>for these are not common (I am looking for one if anyone has a spare, hint,
>hint)
You could always roll your own. Especially if DMA is useful.
>
>> 2) Regardless of where you develop it or for that matter debug it, it's
>> a task that "separates the men from the boys" in the PDP-8 world.
>> Writing handlers is likely the most difficult code ever done. The reason
>> is that generally it's a job stated as nearly impossible! OS/8 handlers
>> desire to be entirely self-contained in about 128 12-bit words. Within
>
>Fortunately, this does not apply to PDP11's, where AFAIK there's no limit to
>driver size under any of the OS's.
I belive that's not technically true, but clearly not as fanatical as
OS/8. But P?S/8 was originally a system for 4K machines and OS/8 was a
system for 4K machines that happened to have 8K. (Meaning it still has
the 4K-type loading restrictions such as unavailability of x7600-x7777
for any field x.) When these systems were designed, it seemed reasonable
to expect a one-page system device. This has largely been proven true
for the original devices such as TC01/08/TU55/56 DECtape and DF32/RF08.
But many devices became troublesome, thus *the* TD8E handler was
developed for 12K OS/8 as a kludge later revisited as any system device
that could be developed in the same two pages as the TD8E. Thus, the
same fanatic need to make it fit becomes more unworkable and compromised as
the device interfaces got more feeble (such as the RL).
Since P?S/8 already had an advantage over OS/8 of requiring in general 4K
less, I decided to formalize a mechanism to allow an additional 1K (8
more pages) should a device not be able to fit into one page. With few
exceptions, devices either fit comfortably into one page, or they
severely cannot. Thus, a lot of OS/8 compromised two-page handlers.
(Note: the RX interface was originally attempted as a one page handler!
It has the dubious distinction of being the only official handler
officially withdrawn due to fatal flaws! The two-page handler that
replaces it is merely compromised, but not flawed, etc. The
corresponding uncompromised P?S/8 handler is either 3 pages or 4 pages
depending on which component you are comparing, etc.)
Thus, there are effectively 7K P?S/8 systems where the last 1K of field 1
is reserved for the rest of the system handler. Should more memory be
available, the rest of the handler is relocated to the highest extended
memory field's last 1K, thus the largest linear address space available
is available to the user (contrast with OS/8 that essentially reserves
x7600-x7777 for every field x).
As P?S/8 has evolved, some of the handlers have been revisited in various
forms. One interesting one is the TC01/08 DECtape. In OS/8 and P?S/8,
the system handler attempts to remember the best-guess initial search
direction. (Note: Unfortunately in OS/8 as distributed by DEC, the
handlers literally ignore this information, and instead are told by the
caller what to do. The problem is that there are only a small handful of
calls sprinkled within OS/8 that actually set this bit! Thus, virtually
all calls are told to reverse the tape as the initial guess, even though
clearly many of these calls would have been better to spin the tape
forwards first. The few that are guaranteed to be correct to spin
forwards first are the ones hard-coded into OS/8. The rest represent a
lost opportunity for efficiency. I have solved this by supplying a
replacement handler that ignores the caller and instead uses its own
information to provide a reliable guess that is usually correct, etc.)
The P?S/8 (and my replacement TC01/08 OS/8 system handler) maintain a
last-block-transferred location used to create the initial guess for
search direction. This feature makes a noticeable improvement in tape
transfer time, etc.
But there's a problem in the system handler (and also the replacement
OS/8 handler) that resides in one page (likewise for OS/8). When the
handler is used to transfer data from a different logical unit, the
information is taken from the old unit, not the current unit. Thus, each
time the device is changed, this invariably leads to a wrongfully
calculated guess direction (although the second guess is taken from
updated information from the latest transfer. However, there can be a
perverse case where the caller makes alternating calls such as in a copy
program, etc.)
The reason for this problem is of course because there isn't room to
support a unit-select table of last transfer blocks. Such a handler
wouldn't fit in one page in either system, etc.
P?S/8 can be configured for what is known as the Console Overlay. This
is a collection of configurable routines that basically redirect the
standard devices to a logical collection of devices that are
user-defined. The I/O consists of standardized calls for the console
keyboard, console output, line printer output. Additionally, the line
printer is conceptualized as a bi-directional device that the console
overlay has to deal with internally. Thus, applications oriented to
doing their own device 66 LPT: output can instead make calls to the
Console Overlay for LPT: output with impunity; should the device require
reverse direction ^S/^Q support, this is invisible to the caller. Thus,
the overlay concept can be configured for a whole bunch of devices beyond
the scope of OS/8 (which is not actually device independent other than
for disks). To add this support costs you 7K, which works out well where
the handler could occupy the other 1K of the highest field. Thus, the
minimal configuration to run this is an 8K machine, which curiously is
also the minimum OS/8 configuration. (Of course, the application
environment is reduced to 4K in that case! While in OS/8 it stays at 8K
not counting the last-page restriction in every field, etc.) (Note:
P?S/8 standard system programs generally can take advantage of 7K or
other multiples where appropriate. Just because an entire field isn't
available doesn't mean you shouldn't take advantage of a partial field!
For example, the P?S/8 PAL assembler will load symbols into any memory it
can grab, be it the rest of field 0 only, or that plus 7K, or that plus
8K, or whatever, etc. There are status bits available to size up any
viable memory configuration, etc.)
Should the system device be a TC01/08, the following enhancements are
added by the Console Overlay:
1) A check for Timeout Error is added. Occasionally, TC01/08 get
"confused" causing handlers to hang up. This is evident in both OS/8 and
P?S/8. In this enhancement, the handler's infinite wait loop is replaced
by one that times out. A software Timeout Error bit is returned in the
soft version of the error status that is available to the handler along
with the other hardware generated bit in their usual places.
(Essentially does an enhanced version of the DTRB instruction with a new
status bit created, etc.)
2) The best-guess search direction table is created, thus multiple unit
calls don't affect the guess-work. This can be quite noticable when
copying information from one tape to another when the absolute blocks
aren't the same (meaning copying one part of one tape to another part of
another one as opposed to doing block-for-block copying. In the latter
case, the guess block is the same regardless of unit, thus the guess is
always correct anyway, etc.).
3) All errors are handled through a user error prompt on the console
screen. Depending on the device, this could be an elaborate error panel
display or merely a well-separated screen roll-up of the error status.
The notion is to inform the user of the complete particulars of the
problem and allow user intervention to either fix the problem or abort.
(Yes, we are talking about MS-DOS Abort, Retry, Fail except this predates
MS-DOS by about 8 years. And the PDP-9/15 IOPS4 predates that by about
another 7 years!)
Thus, instead of having an N-page handler, P?S/8 allows the user to
enable the Console Overlay which eats up another field and get the
handler enhanced to handle some problems largely ignored in the original
one-page version. Yet, you can always revert to the original handler
with the original limitations should you need the space back for awhile, etc.
>But you were claiming earlier that it was
>on PDP11's where you had to be 100% compatable with a DEC device.
No, hardy individuals can get past this. But some of it is quite hard to
gain access to the relevant source code. In any case, I pointed out that
there were far more business decisions in the -11 world where companies
marketed lock-step DEC software compatible devices than in the -8 world.
And more of them would be quite pathetic, such as devices that are
inherently SCSI that are mapped to instead look like the RL, etc.
>
>[...]
>[Reparing the RK8E]
>
>> >OK, so you have to change a few more chips. The chips on the RK8E are cheap,
>> >and in general easy to obtain. It's no big hassle to change a few more (even
>> >though there's a certain satisfaction in working out the faulty component and
>> >getting it right).
>>
>> Yes, we all like to guess correctly. But on the RK boards, it's a whole
>> lot harder to remove the chips than on the other DEC boards of that era.
>
>Yes, BUT... It's a whole lot easier than on the modern boards that you are
>suggesting we replace them by.
Not quite. I am recognizing that today, most of the stuff is
throw-away. It's often easier to get a cheap replacement, so don't fight
it. It goes against my grain as a repair-person, but I recognize the
economic realities, etc. Few of these newer boards ever get repaired.
>I've just opened up my 8/e and pulled the
>RK8E cards. Yes, the pads are a little smaller than on the TD8E I happened to
>have on top of the machine, but not much. The traces are a lot thinner, I will
>agree, but that shouldn't make much difference.
It makes quite a bit of a difference. Compare to the processor cards; I
suspect the TD8E might be an intermediate size.
>
>Actually, the RK8E boards look to have similar size features to the PC-clone
>boards I've just looked at. Since I've repaired those on several occasions,
>I don't think the RK8E will be any worse.
It's probably slightly better. But a whole lot worse than dealing with
anything on an M8650 or whatever.
>
>
>> Simply not true. Compare the M7104,5,6 lands with the CPU boards for
>
>I just have done. The RK8E does have smaller pads than the 8/e CPU, but they're
>no smaller than on the PC-clone board I just mentioned, or than those on
>several PDP11 cards like the M8109 I've just picked up. You are lucky that the
>8/e CPU has larger pads, and is thus easier to repair - the RK8E is the
>more 'standard' size.
Not by the standards of the time. It was the "intruder" while the CPU,
etc. was the "standard" size. Field Circus could never deal with board
repair from the beginning had what we have now been in effect back then, etc.
>
>> example. The lands are always ripped out on an RK board that wasn't
>> handled extra carefully compared to the other boards.
>
>But you should always handle these boards carefully. If you do so, then you'll
>have no problems.
I'm not advocating slopiness, but it's really that much worse!
>
>> But on the RK board, you really don't know if the chip is dead, so you
>
>There are plenty of ways of in-circuit testing the chips on the RK8E. The best
>one involves a logic analyser and a set of extender boards, but even without
>such luxuries, you can often force the pins into known states. Most faults are
>easy to trace if you can do that.
It can be pretty messy; the RK was largely a sore point in terms of
deciding how to fix the boards, etc.
>
>I've repaired a large number of such computer systems, and only once have I
>_needed_ a logic analyser (to trace a microcode problem in a PERQ workstation).
>On all other occasions, I've managed to figure it out using simpler test gear.
>
>> >2) Don't be afraid of overheating the chip. Get the solder molten before you
>> >suck
>>
>> Again, presupposes wanting to kill the chip, but largely not an option.
>
>Not at all. You will not damage a chip by overheating it with a normal
>soldering iron unless you are very careless. I've used an iron on the pins of
>a chip from the _component side_ (which obviously gets the chip a lot hotter
>internally) with no damage. I have never overheated a chip when soldering or
>desoldering it.
I think we wouldn't define it as overheating, but rather just getting to
the max allowed short-time temperature.
>
>
>>
>> >3) Break the bod between the chip and the board by pressing each pin inwards
>> ^^^^ I assume bond
>> >with a screwdriver before pulling the chip
>>
>> Often two screwdrivers or a chip puller.
>
>NO WAY. That's the way to lift pads or damage plating. You're not trying to
>lift the chip out at this point - what you are doing is cracking the remaining
>bond between the pin and the PCB. It's done like this
>
>
> IC body
>=====\
> |+
>=====/ |
> |<------------Press with small screwdriver here, in direction of arrow
>-------|--------- PCB after desoldering
> |
>
>I've often desoldered 20-30 programmed chips from extremely rare boards,
>examined the contents and put them back in again. These were 6 layer boards
>with pads and traces smaller than the RK8E
I don't mean to apply force per se. I mean to apply a small force and
then an iron to release the pins while hot, etc.
>
>[...]
>
>> Likely, but we are comparing the boards of that era to each other.
>
>I'm also comparing the RK8E to the sort of board you are suggesting I replace
>it with.
True, but I am largely suggesting chucking the new board if necessary; it
won't be worth attempting the repair.
>
>>
>> >
>> >> the word "TOP" is ignored!)
>> >
>> >Well, if you misuse the hardware then you deserve problems IMHO.
>>
>> It doesn't say "Only put this board into the buss so that the word "TOP"
>> can be read in the normal manner." Instead it just says "TOP." Real
>> spectacular and sparky smoky burny things happen when you ignore this!
>> Recovery needs a whole lot of long skinny long-run land repair. I opted
>> to use wire-wrap wire on the one I fixed for them, etc.
>
>My board (I've just pulled it to check) says TOP in capital letters and has
>2 arrows alongside it (one at each end) pointing upwards. If you can't
>understand that, you shouldn't be repairing 8/e's IMHO.
The repairer and the person creating the need to repair are two different
people :-).
>Now, we've all made
>mistakes (I certainly have - like the time I blew up a rare 7482 full adder
>by putting a flip-chip card into a spare backplane to test it, not realising
>that DEC used B2 (the standard -15V line) as a Carry In on this card), but
>don't blame it on the hardware.
Yes, this is a nut-behind-wheel problem.
>
>The printset also shows how to insert the card.
Who said users can read :-).
>
>
>> cjl
>
>-tony
>
cjl
Tony Duell
In article <4t8ck8$p...@calzone.unc.edu>
las...@calzone.unc.edu "Charles Lasner" writes:
> a whole lot more but incompatible. That didn't fit the model. Today, I
> think the whole issue of paper-tape is largely unimportant, and I would
> hope that one of the aims of PDP-8 enthusiasts is to get past this stage
> of depending on long streams of paper-tapes. Of course if you want to
The one advantage of paper tape is that (given a good reader) it's very
reliable, much more so in my experience than magnetic media. I keep all my
important data backed up onto paper tape. This advantage is largely negated if
you have a reader that mangles tapes.
Also, paper tape _can_ be read with the naked eye without any electronic stuff
at all. The electronic readers are simple, reliable, and easy to maintain (more
so than a disk drive, for example), and thus are an ideal device to load
diagnostics from
Most people who dislike paper tape have simply never used a decent reader. If
your experience is with sprocket-fed readers (or worse still, fully mechanical
readers like those on the ASR33) then try a good optical reader before
rejecting paper tape totally.
> BTW, DEC field circus used a medium-speed serial interfaced paper-tape
> reader for loading diagnostics into machines such as the VT78. The
> device is essentially a device 01 keyboard interface. All works fine
> except that the interface cannot hold back the frames. Thus, it's only
> usable for the intended purpose: read a diagnostic into memory and then
> start it up. As the program starts, the out-of-control ignored reader is
> still spewing forth frames until the physical end of tape, etc. But you
> wouldn't want this device on an OS/8 machines to read in paper-tapes into
> files!
Why on earth didn't they implement the Reader Run Relay that was
used with ASR33's linked up to M8650's, etc? That was a fully documented way
of doing reader control on the teletype interface, and one which DEC software
supported.
> >And DEC PC04's are not well
> >designed readers IMHO - any reader that is sprocket-fed is going to mangle
> >at least one important tape sometime.
>
> Maintained correctly, it doesn't.
I beg to differ. A sprocket-fed reader will rip tape holes if the tape is
held back for any reason - even (at higher speeds) if the layers of
fanfold tape stick together. A capstan-fed reader won't.
> >suggesting we replace them by.
>
> Not quite. I am recognizing that today, most of the stuff is
> throw-away. It's often easier to get a cheap replacement, so don't fight
It may be easier to get a 'cheap replacement' today (except that many
cards are anything but cheap, and if they happen to fail the night before
some important work, I'd better be able to fix them with the contents of
my junk box) but what about in 10 years time. I prefer my systems to be
maintainable in the future as well.
> it. It goes against my grain as a repair-person, but I recognize the
> economic realities, etc. Few of these newer boards ever get repaired.
Well, I certainly repair them...
>
> >I've just opened up my 8/e and pulled the
> >RK8E cards. Yes, the pads are a little smaller than on the TD8E I happened to
> >have on top of the machine, but not much. The traces are a lot thinner, I will
> >agree, but that shouldn't make much difference.
>
> It makes quite a bit of a difference. Compare to the processor cards; I
> suspect the TD8E might be an intermediate size.
The TD8E has the same size pads as the CPU, memory and M8650 cards. The RK8E
has the same pads as the M8109 (=PDP11/45 Clock Generator, from 1972) and
most other DEC boards of the time.
In other words, 8/e owners are lucky. The CPU and TTY boards have the
older-style pads on them, and are thus easier to work on. Anything
DEC designed a couple of years later seems to have the smaller (RK8E) pads
[... More board comparisons]
> Not by the standards of the time. It was the "intruder" while the CPU,
Yes, by the standards of the time. That M8109 card I mentioned is a 1972
card. It's only 2 years later than the 8/E and contempory with the RK8E.
The 8/e CPU is the older design, and while easier to work on, it's certainly
not typical of DEC boards of that period
> etc. was the "standard" size. Field Circus could never deal with board
> repair from the beginning had what we have now been in effect back then, etc.
Don't compare what field circus could do in the field with the average field
tool kit with what a good repairman can do at a well-equiped workbench.
The tools for soldering and desoldering have improved since 1972 (although the
ones I use are based on an old design) and there's no reason not to use the
best tools available when repairing the RK8E
> I'm not advocating slopiness, but it's really that much worse!
No it's not. It's no worse that (say) desoldering the microcode PROMs from an
11/05, reading them out, comparing them with the listing in the printset and
then soldering them back in. It's not hard to remove a chip from an RK8E
> >> >2) Don't be afraid of overheating the chip. Get the solder molten before you> >> >suck
> >>
> >> Again, presupposes wanting to kill the chip, but largely not an option.
> >
> >Not at all. You will not damage a chip by overheating it with a normal
> >soldering iron unless you are very careless. I've used an iron on the pins of
> >a chip from the _component side_ (which obviously gets the chip a lot hotter
> >internally) with no damage. I have never overheated a chip when soldering or
> >desoldering it.
>
> I think we wouldn't define it as overheating, but rather just getting to
> the max allowed short-time temperature.
Hence my original comment 'Don't be afraid of overheating the chip'. You'll
not overheat the chip using a normal soldering iron. So make sure the solder
is molten before you try sucking it.
[... Lifting the chip]
> I don't mean to apply force per se. I mean to apply a small force and
> then an iron to release the pins while hot, etc.
NO!. Pulling the chip with the pad still hot will lift pads. The 'glue' used
to fix the copper to the board is weakened by heating. Make sure the board is
cold before removing the chip.
[...]
> True, but I am largely suggesting chucking the new board if necessary; it
> won't be worth attempting the repair.
Fine today (Assuming you can get a new board in time), no good in 10 years
time.
> The repairer and the person creating the need to repair are two different
> people :-).
Not in my case, fortunately :-). But seriously, I can think of 101 ways to
damage an 8/e by being stupid. Plugging one of the RK8E boards in upside down
is just one of them. and if you don't read what's on the board, and if
you don't RTFM before inserting boards, then you will have problems
It's the same with PCs. If I plug the (male-ended) serial cable from my
11/44 into my PC's printer port, I'm going to blow a chip (at least). If
the PC happens to be a laptop, it's going to be a hard-to-get ASIC on the
]expensive motherboard. So I RTFM before plugging things in.
> >The printset also shows how to insert the card.
>
> Who said users can read :-).
Those that can't have problems :-)
> cjl
-tony
The Daves Collective
Yeah!!! I was once privileged to witness a power cut in a Univac 1106 machine
room. Deathly silence, *except* for the astonishing rumble of the drum unit
over at the back. The damn thing kept on for at least twenty minutes all by
itself!
And that maintenance panel was the BEST THING EVER!
Sean Case
>Univac was a really Sperry Rand. That was FastRand, no? That's the
>name I remember for those beasties, anyway. As I recall, the
>substrate on them was glass.
As _I_ recall, the substrate was surplus sewer pipe. Although it may have
been a glass substrate over a metal core.
The angular momentum of a running Fastrand unit was staggering - if the
power went off, it took days for the unit to spin down. Restarting one
before it had spun down would cause it to leap ten or so metres in a
random direction (up, down, or across) without stopping for little things
like walls. Headcrashes were quite minor annoyances in comparison.
FASTRAND n. [(c) Sperry Rand Corporation.] A nonfloppy rotating
cylindrical device used for storing angular momentum.
-- Stan Kelly-Bootle
The Fastrand sector - 28 x 36 bit words - is still the basic unit of
disk storage for the 1100/2200 series machines. The number 28 is often
referred to by such names as "von Fastrand's constant."
Sean Case
---------------------------------------------
Sean Case gsc...@tpgi.com.au
Code is an illusion. Only assertions are real.
David M. Razler
gsc...@tpgi.com.au (Sean Case) wrote:
>
>As _I_ recall, the substrate was surplus sewer pipe. Although it may have
>been a glass substrate over a metal core.
>
>The angular momentum of a running Fastrand unit was staggering - if the
>power went off, it took days for the unit to spin down. Restarting one
>before it had spun down would cause it to leap ten or so metres in a
>random direction (up, down, or across) without stopping for little things
>like walls. Headcrashes were quite minor annoyances in comparison.
>
OK, great! I'll take it! Anyone got a spare?
Pete O'Such
Sean Case (gsc...@tpgi.com.au) wrote:
: As _I_ recall, the substrate was surplus sewer pipe. Although it may have
: been a glass substrate over a metal core.
: The angular momentum of a running Fastrand unit was staggering - if the
: power went off, it took days for the unit to spin down. Restarting one
: before it had spun down would cause it to leap ten or so metres in a
: random direction (up, down, or across) without stopping for little things
: like walls. Headcrashes were quite minor annoyances in comparison.
I'm having a hard time picturing this device. About how long was the
"pipe?" What diameter? I'm guessing the data was encoded on the
sides of the device, so was there just one head that traversed the
entired length, or where there multiples? Any one have reliable RPM
numbers or weight measurements for either the "pipe" or the entire
device?
David M. Razler
*Moving* head on a drum? <rotfl>
Sorry, the only revenge when the July 8 edition of EE Times prints a primer on
"what is a vacuum tube."
OK, every drum I ever ran into was designed with 1 or more heads per track, a
track being the diameter of the exterior of the <physical> cylinder. The most
advanced rum I ever ran into, in fact the only one I had the <grit teeth>
pleasure to use personally, was at least not perfectly round. Slightly
conical, it didn't move fully against the heads until it was up to speed.
Now, it must be remembered that before Project Winchester, disk and drum heads
either made physical contact with the flying surface <albeit in the case of
the first DEC disks, and similar device, separated by a layer of wax> or by
fixed mechanical separators, which, due to tolerance problems, is what
sometimes failed, producing spectacular crashes. Some of the oldest heads were
in size and appearance close to those on magtape drives.
Big Blue's Project Winchester produced the ultra-light air-cushioned head <now
almost universal> that actually "fly." Further progress has eliminated or
all-but eliminated the need for external air to be pumped over the platter(s)
reducing those great things that could happen if anything from a dust particle
or larger got between head and surface.
Landon Dyer
Sean Case (gsc...@tpgi.com.au) wrote:
:
: >Univac was a really Sperry Rand. That was FastRand, no? That's the
: >name I remember for those beasties, anyway. As I recall, the
: >substrate on them was glass.
: As _I_ recall, the substrate was surplus sewer pipe. Although it may have
: been a glass substrate over a metal core.
"rotating sewer pipe" was a term i heard over and over again at NBS
(now NIST) and the university of maryland. the moniker could have
been more funny than accurate, though.
while i never saw the actual installation, i heard that the drums at
MD were mounted on bare concrete rather than machine-room flooring, in
case of a bearing seizure. (whereupon, it was assumed, the drum would
do a quite spectacular take-off...)
--
landon dyer (lan...@netcom.com)
"you've got to be kidding."
Lawrence E. McKnight
nor...@bigdipper.umd.edu (Pete O'Such) wrote:
>Sean Case (gsc...@tpgi.com.au) wrote:
>: As _I_ recall, the substrate was surplus sewer pipe. Although it may have
>: been a glass substrate over a metal core.
>
>: The angular momentum of a running Fastrand unit was staggering - if the
>: power went off, it took days for the unit to spin down. Restarting one
>: before it had spun down would cause it to leap ten or so metres in a
>: random direction (up, down, or across) without stopping for little things
>: like walls. Headcrashes were quite minor annoyances in comparison.
>
>I'm having a hard time picturing this device. About how long was the
>"pipe?" What diameter? I'm guessing the data was encoded on the
>sides of the device, so was there just one head that traversed the
>entired length, or where there multiples? Any one have reliable RPM
>numbers or weight measurements for either the "pipe" or the entire
>device?
Hmm. Just going from memory (and guesses) here, but the drum was about 6
feet long and a few feet in diameter. (Hmm. The proportion seems off.
It might have been 8x3). There were a bunch of heads (96, as I recall)
on a moveable boom. The boom movement was slooowwww. Average access
time was about 92 ms. As for RPM, I don't recall, but it was
considerably lower than other Univac drums, like the FH-432.
---------------
Larry McKnight
(this space unintentionally left blank.....
Lawrence E. McKnight
david....@postoffice.worldnet.att.net (David M. Razler) wrote:
>
>*Moving* head on a drum? <rotfl>
Yep. The Fastrand had heads on a moveable boom. No joke.
William H. Ivey
In <31fbe7e5...@netnews.worldnet.att.net>
david....@postoffice.worldnet.att.net (David M. Razler) writes:
>
[...]
>Big Blue's Project Winchester produced the ultra-light air-cushioned
>head <now almost universal> that actually "fly." Further progress has
>eliminated or all-but eliminated the need for external air to be
>pumped over the platter(s) reducing those great things that could
>happen if anything from a dust particle or larger got between head and
>surface.
Actually, air-cushioned disk heads preceded Project Winchester - I
started programming on an NCR Century 100 system that had twin 300KB
disk drives (the size of washing machines) with air-cushioned heads,
and that's circa 1970 or earlier. Winchester drives eliminated the
pumped air system.-Wm
Joe Morris
david....@postoffice.worldnet.att.net (David M. Razler) writes:
>OK, every drum I ever ran into was designed with 1 or more heads per track, a
>track being the diameter of the exterior of the <physical> cylinder. The most
>advanced rum I ever ran into, in fact the only one I had the <grit teeth>
>pleasure to use personally, was at least not perfectly round. Slightly
>conical, it didn't move fully against the heads until it was up to speed.
That sounds like the IBM 2301 drum. The axis of rotation was vertical; when
the drive running the drum moved up to place the heads in the correct
location and distance from the recording surface. The idea was that in
the event of a power loss (UPS boxes weren't that common 'way back then)
the drum would drop away from the heads, thus providing a mechanical
failsafe process. I assume <g> that the logic would abort any write in
progress before the drum fell away from the head.
Speaking of head crashes again -- I never used the FastRand drums (the
Univac proposals I received were ... um, "unimpressive") but some of
the Univac shops near my PPOE reported that the early FastRand drums
had a nasty habit of dropping onto the heads (at the bottom of the
box) in the event of a power failure. I never had any independent
confirmation of this; does someone here in a.f.c have experience with
the early FastRand designs?
Joe Morris / MITRE
Tony Konashenok
|> The angular momentum of a running Fastrand unit was staggering - if the
|> power went off, it took days for the unit to spin down. Restarting one
|> before it had spun down would cause it to leap ten or so metres in a
|> random direction (up, down, or across) without stopping for little things
|> like walls. Headcrashes were quite minor annoyances in comparison.
Reminds me of an incident which happened at St.Petersburg (Leningrad back
then) State University in Russia in the 70's. The operators didn't pay
attention to excessive noise coming from the bearings of a drum on an M-222
computer, until the bearings actually went south. The drum wound up one floor
ABOVE the computer room. Fortunately, it happened at night -- I think even a
mere sight of something making its way up through your floor could have caused
a couple of heart attacks...
Tony Konashenok
Terry Kennedy, Operations Mgr.
In article <31fbe7e5...@netnews.worldnet.att.net>, david....@postoffice.worldnet.att.net (David M. Razler) writes:
> Big Blue's Project Winchester produced the ultra-light air-cushioned head <now
> almost universal> that actually "fly." Further progress has eliminated or
> all-but eliminated the need for external air to be pumped over the platter(s)
> reducing those great things that could happen if anything from a dust particle
> or larger got between head and surface.
Actually, Winchester heads were the ones that landed on the media rather
than retracting completely when the drive was spun down. Previous disks used
flying heads (2315, 3330, etc.) that just retracted.
Here's a snippet from Mike Cowlishaw's (sp?) IBM Jargon Dictionary:
Winchester disk, n. Hard disk whose head actually rests upon the surface of
the disk when stationary. The name "Winchester" was first used as the code
name for a disk storage device being developed at the IBM San Jose
engineering laboratories around 1973, and has since become the industry
generic term for that disk technology. The rationale for the name was the
original size of the twin storage modules, which were 30 megabytes each,
matching by analogy (30+30) the calibre of a Winchester 30/30 rifle.
Winchester was the first device whose read/write head could actually rest
upon the surface of the disk without disastrous consequences. The head
assembly mass was reduced from 300 grammes for the 3330 disk to a feathery
18 grammes, thus successfully fulfilling the original aim of eliminating
the costly head-unloading mechanism. The direct cost of the head dropped
from $28 to $8 as a consequence of this. The capacity of the disk that was
actually released as the 3340 later grew to 35 and 70M, but the name stuck.
(Mike Hartung has a notebook entry for 9 Sep 73 recording a conversation
with Max Parker who used the name.)
Terry Kennedy Operations Manager, Academic Computing
te...@spcvxa.spc.edu St. Peter's College, Jersey City, NJ USA
+1 201 915 9381 (voice) +1 201 435-3662 (FAX)
Williams, Steve
david....@postoffice.worldnet.att.net (David M. Razler) wrote:
>*Moving* head on a drum? <rotfl>
>Sorry, the only revenge when the July 8 edition of EE Times prints a primer on
>"what is a vacuum tube."
>OK, every drum I ever ran into was designed with 1 or more heads per track, a
--snip--
The Fastrand has a movable boom with 64 heads mounted on it. The boom
can move to any one of 158 positions. This gives a total storage of
158 x 64 x 1792 x 4.5 bytes, or 77+ megabytes, assuming Format 'C'.
The OS allows you to to allocate files in track granularity, in which
case you may need head movement to access a track, or in position
granularity (64 tracks) which means you can read all the tracks under
the 64 heads without head movement. The heads are rigidly fixed to the
boom at a fixed distance from the drums (not flying, but not
touching).
>Now, it must be remembered that before Project Winchester, disk and drum heads
>either made physical contact with the flying surface <albeit in the case of
>the first DEC disks, and similar device, separated by a layer of wax> or by
>fixed mechanical separators, which, due to tolerance problems, is what
>sometimes failed, producing spectacular crashes. Some of the oldest heads were
>in size and appearance close to those on magtape drives.
>Big Blue's Project Winchester produced the ultra-light air-cushioned head <now
>almost universal> that actually "fly."
Yes, the wonderful 30/30. But compare that with the FH 432 drum of
1964 which rotates at 7200 RPM and has an average access time of 4.25
ms. It has true flying heads (each about the size of a cigarette
pack). The Bernoulli effect of a drum at that speed means that the
heads have to be forced *down* towards the drum to get the head gap
small enough to be usable. Unfortunately a single drum only holds 256K
words (36 bits), or a capacity less than a 5-1/4" floppy. And it is
definitely not removable. I have one sitting next to my desk and it
must weigh 250 lb.
In comparison with PC disks, the Fastrand was overtaken in capacity
and speed around 1984. I would think overall speed of a FH432 still
hasn't yet been exceeded by rotating disks. Even though they rotate at
7200 RPM they don't have a read/write head per track.
Steve.
Jerry Leslie
Pete O'Such (nor...@bigdipper.umd.edu) wrote:
: Sean Case (gsc...@tpgi.com.au) wrote:
: : As _I_ recall, the substrate was surplus sewer pipe. Although it may have
: : been a glass substrate over a metal core.
: : The angular momentum of a running Fastrand unit was staggering - if the
: : power went off, it took days for the unit to spin down. Restarting one
: : before it had spun down would cause it to leap ten or so metres in a
: : random direction (up, down, or across) without stopping for little things
: : like walls. Headcrashes were quite minor annoyances in comparison.
: I'm having a hard time picturing this device. About how long was the
: "pipe?" What diameter? I'm guessing the data was encoded on the
: sides of the device, so was there just one head that traversed the
: entired length, or where there multiples? Any one have reliable RPM
: numbers or weight measurements for either the "pipe" or the entire
: device?
I don't recall the size, but a Fastrand II weighed 5,500 pounds.
--Jerry,
Gerald (Jerry) R. Leslie Aspen Technology, Inc. (my opinions are my own)
jerry....@aspentech.com jle...@dmccorp.com gle...@isvsrv.enet.dec.com
Eric Werme
jcmo...@mwunix.mitre.org (Joe Morris) writes:
>That sounds like the IBM 2301 drum.
And the Byrant drum DEC sold as the RD10.
The axis of rotation was vertical; when
>the drive running the drum moved up to place the heads in the correct
>location and distance from the recording surface. The idea was that in
>the event of a power loss (UPS boxes weren't that common 'way back then)
>the drum would drop away from the heads, thus providing a mechanical
>failsafe process. I assume <g> that the logic would abort any write in
>progress before the drum fell away from the head.
The write completed several minutes before the drum shifted down.
On the RD10 the lift mechanism was a cetrifugal beast, so it took a big
change in RPM before the drum lowered.
--
Eric (Ric) Werme | we...@zk3.dec.com
Digital Equipment Corp. | This space intentionally left blank.
Chuck Greenwald
In article <4thb85$p...@dfw-ixnews3.ix.netcom.com>, wi...@ix.netcom.com(William H. Ivey) writes:
|> In <31fbe7e5...@netnews.worldnet.att.net>|> [...]
|> >Big Blue's Project Winchester produced the ultra-light air-cushioned
|> >eliminated or all-but eliminated the need for external air to be
|> >pumped over the platter(s) reducing those great things that could
|> >happen if anything from a dust particle or larger got between head and
|> >surface.
|>
|> started programming on an NCR Century 100 system that had twin 300KB
|> disk drives (the size of washing machines) with air-cushioned heads,
|> and that's circa 1970 or earlier. Winchester drives eliminated the
|> pumped air system.-Wm
Ah yes, the NCR 655 drives. They were more the size of a two drawer
file cabinet. The drive had a glass plate in the lid (so you could see
if a pack was mounted?) -- folklore has it that NCR switched to armor glass
after some rather spectacular head crashes (the aluminum platters
shattered and then ....).
NCR drives from the '70s:
655 - (described above)
656 - CDC Falcon, one fixed and one removable 1.2MB platter
657 - highboy cabinet with two removable media drives in drawers
658 - IBM 3330 clone (from CDC) with a NCR 605 mini. as the controller
I don't know if NCR built the 657 itself or gave up after the 655.
NCR also had one of the first virtual machine environments;
the mid-'70s B3 and B4 operating system were quite compact --
they ran multiple virtual Century machines each of which ran either
the earlier B1 (batch) or B2 (online) operating system. Each
job started by rebooting the virtual machine.
------------------------------------------------------------------------
Chuck Greenwald | All opinions are | chu...@meaddata.com
Lexis/Nexis | my own. | (513) 865-1020
Brian Abernathy
Reminds me of a couple of HDI's I heard about. One I can confirm, the other
makes an interesting story.
First of all, the "real" story: Years ago, Georgia Tech had a Burroughs
system, with a nice LARGE drum storage device. It was eventually retired,
and the plant department was called upon to remove it from the computer
room.
They came in, powered off the breakers, disconnected the power, and started
out the door (all in a straight line, I might add). They tried to turn the
corner, but because the drive was still spinning, it went straight - into
the brick wall. (This story was told to me by someone who saw the damage.)
Second story: Big Blue engineer working on a large drum storage device.
Screwdriver slips, hits *SOMETHING* which causes bearings to seize. CE
manages to get out of cabinet just as drive turns into giant gyro, tipping
up on one corner of cabinet, and spins slowly down aisle, ripping cables
loose. At the end of the aisle is a nice picture window (computer room is
on second floor.) End of story: drive 'jumps' out second story window.
Getting back to the piece of the thread about the sewer pipe: heard that
from my CS instructor back in the late 60s, and saw one firsthand at AF
base in Alabama. They are HUGE!
Brian Abernathy
Kevin Oberman
c...@hpuerci.atl.hp.com (Brian Abernathy) writes:
> Getting back to the piece of the thread about the sewer pipe: heard that
> from my CS instructor back in the late 60s, and saw one firsthand at AF
> base in Alabama. They are HUGE!
Saw one at an AF base in Denver. They are, indeed, huge!
If this is turning into a drum memory thread (which it has), I guess
I'll have to mention the crank-start computer.
Back in school we learned computer basics on a Bendix G-15 from the
1950s. (Hey, we were broke and the only things we could get for free
were 15 year old machines.) This was advertised as the world's first "portable"
computer. (It had wheels and so did the hard-wired console desk It
also had tubes and not transistors.) It also had drum memory and (if I
remember right) 29 bit words.
And you had to crank start it.
The drum (tiny compared to the FastRand) had enough mass and the motor
driving it had enough torque that you could not apply power to the
motor and have it spin up the drum. Instead, you opened the side of
the computer and grabbed a rubber grip on the drive shaft. You then
spun the drum, pulled out your hand, and turned on the motor.
If you forgot and just turned on the power, the safety pin sheared and
you had the fun of replacing it. It had no ability to sense whether
the drum was already spinning...that probably would have taken more
processing power than the whole G-15!
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634
Tom Watson
In article <31fbe7e5...@netnews.worldnet.att.net>,
david....@worldnet.att.net wrote:
> Now, it must be remembered that before Project Winchester, disk and drum heads
> either made physical contact with the flying surface <albeit in the case of
> the first DEC disks, and similar device, separated by a layer of wax> or by
> fixed mechanical separators, which, due to tolerance problems, is what
> sometimes failed, producing spectacular crashes. Some of the oldest heads were
> in size and appearance close to those on magtape drives.
>
> Big Blue's Project Winchester produced the ultra-light air-cushioned head <now
> almost universal> that actually "fly." Further progress has eliminated or
> all-but eliminated the need for external air to be pumped over the platter(s)
> reducing those great things that could happen if anything from a dust particle
> or larger got between head and surface.
>
> dmr
Your sense of history is a littly shakey....
Long before IBM's "winchester" disk drives heads were flying over disks.
In fact they had lots of special "ramps" to achieve this. The heads
themselves were aerodynamically designed, and had holes to produce the
desired effects. This technology dates back to probably the 1950's (late)
and the IBM 'RAMAC' disks.
What was new for the "winchester" type drives is that they "landed" in a
landing area where data wasn't recorded. Ever notice in the BIOS setup
where a "landing area" is specified, well, that's what it is for. The
"winchester" technology also included smaller heads (instead of the
ceramic being about the size of a dime, they got to be a much smaller
square shape (I don't know the exact details). They also flew at a MUCH
lower height. The surface of the disk was also coated to allow the heads
to land when the power was turned off. In some manufacturers drives, this
caused problems because the heads would "stick" and the motor didn't have
enough starting torque to get the spindle going. This was the famous
"sticktion" problem.
As for the air requirement, drives always needed air (still do) but with
older drives the packs were removable, and to blow away the dust and other
crud filtered air was circulated in the assembly. Now days drives are put
together "sealed" and to equalize the air pressure between the inner drive
and the atmosphere an "absolute" filter about the diameter of a cigarette
is used. If it didn't have it, it would probably "blow up" (quite
dramatically, I suspect) if there was a large difference in air pressure
from inside to outside (like when they are shipped in an unpressureized
cargo hold of an aircraft).
.....or that's the way I remember it..... :-)
--
Tom Watson
t...@3do.com (Home: t...@johana.com)
Jack Patteeuw
>>
>>And the Byrant drum DEC sold as the RD10.
>
If my folklore is correct, the Bryant disk was manufactored by Pilco Ford.
There is a single platter of a Bryant hanging in the enterance way to the
Ford Motor Company Engineering Computer Center. It's about 4 feet in diameter.
Jack Patteeuw
My opinions are my own and not my employer's, my wife's, or my children !
"I used to do VMS, Stolen from a good friend:
Now I do Unix; "A mind is like a parachute ...
It's a living" It only works when it is open !"
John Mullan
Chuck Greenwald wrote:
>
> In article <4thb85$p...@dfw-ixnews3.ix.netcom.com>, wi...@ix.netcom.com(William H. Ivey) writes:
> |> In <31fbe7e5...@netnews.worldnet.att.net>
> |> david....@postoffice.worldnet.att.net (David M. Razler) writes:
> |> >
> |> [...]
> |> >head <now almost universal> that actually "fly." Further progress has
> |> >eliminated or all-but eliminated the need for external air to be
> |> >pumped over the platter(s) reducing those great things that could
> |> >happen if anything from a dust particle or larger got between head and
> |> >surface.
> |>
> |> started programming on an NCR Century 100 system that had twin 300KB
> |> disk drives (the size of washing machines) with air-cushioned heads,
> |> and that's circa 1970 or earlier. Winchester drives eliminated the
> |> pumped air system.-Wm
>
> Ah yes, the NCR 655 drives. They were more the size of a two drawer
> file cabinet. The drive had a glass plate in the lid (so you could see
> if a pack was mounted?) -- folklore has it that NCR switched to armor glass
> after some rather spectacular head crashes (the aluminum platters
> shattered and then ....).
>
> NCR drives from the '70s:
>
> 655 - (described above)
> 656 - CDC Falcon, one fixed and one removable 1.2MB platter
> 657 - highboy cabinet with two removable media drives in drawers
> 658 - IBM 3330 clone (from CDC) with a NCR 605 mini. as the controller
>
> I don't know if NCR built the 657 itself or gave up after the 655.
>
> NCR also had one of the first virtual machine environments;
> the mid-'70s B3 and B4 operating system were quite compact --
> they ran multiple virtual Century machines each of which ran either
> the earlier B1 (batch) or B2 (online) operating system. Each
> job started by rebooting the virtual machine.
>
consortiums set up by CDC, CPI which was printers and other unit record
equipment, and MPI which was magnetic peripherals. Honeywell was another
player in at least MPI. I believe that the 656 and later were MPI
devices with the NCR label. Some of the NCR printers were CPI devices.
Anyone remember NCR's CRAM? It was a magnetic card memory, cards were
hung in a rack and selectively dropped to wrap around a drum for
read/write operations. When the cards got worn, it was possible for two
to drop at the same time. What a delightful sound it made when it did
that. Made fingernails on a blackboard seem soothing.
Brett Dixon
In article <Dv3F...@rsvl.unisys.com>, st...@lgx.unisys.ch (Williams,
Steve) wrote:
> Interesting(?) Fastrand facts^H^H^H^H^H urban tales:
> o A Fastrand comprised two horizontal drums about 7 feet long weighing
> <mumble> tons. If the brakes failed they would take days to stop
> spinning after they were powered down. Some customer engineers would
> polish the drums while they were still spinning, but don't let your
> hand get caught between the two drums. The momentum could tear your
> arm off.
While the device you are talking about has (probably) faded away, take a
look at a modern printing plant... Where i work, there are well over a
hundred sets of rollers somewhat similar to your Fastrand. It is not
uncommon to use a small piece of plastic to pick a small gob of whatever
of the plate surface. just don't let anyone catch you. BTW, these rllers
spin fast enough to move paper at something like 1500 feet per minute. Do
you get Electronic Engineering Times? I work on it some weeks...
David M. Razler
we...@alingo.zk3.dec.com (Eric Werme) wrote:
>jcmo...@mwunix.mitre.org (Joe Morris) writes:
>
>
>And the Byrant drum DEC sold as the RD10.
That was *my* angel, er, daemon.
>>
>The write completed several minutes before the drum shifted down.
>On the RD10 the lift mechanism was a cetrifugal beast, so it took a big
>change in RPM before the drum lowered.
It was still an Evil Beast designed to self-destruct. <I loved the
pre-installed lifting eye at the top of the sealed Bryant container for
turning it into a genuine boat anchor>
ellingsen_jim
Actually I think that it was the 432 & 1782 drums that
were made from sewer pipes at the Univac plant in
Bristol Tenn. Rumor was that it was less expensive
to pick out the best sewer pipes rather than have
them sepcially made. FASTRANs were huge beasts. When
I worked for Univac I remember someone describing the
basement in their new home as a 8 FASTRAN basement.
Probably folklore however there was a tale floating
around at the time that the Navy tried to install a
432 or 1782 drum on a ship and found that it acted like
a gyroscope and caused navigation problems.
Simon Slavin
In article <31fc27b0...@nntp.ix.netcom.com>,
mckn...@ix.netcom.com (Lawrence E. McKnight) wrote:
> david....@postoffice.worldnet.att.net (David M. Razler) wrote:
>
> >*Moving* head on a drum? <rotfl>
>
> Yep. The Fastrand had heads on a moveable boom. No joke.
Of course. The heads have less mass than the drum. Therefore it
takes less energy to move the heads, the device gets up to speed
faster, and the whole thing does less damage when freaked.
What's the problem here ? :-)
Simon.
--
Simon Slavin -- Computing Contractor Ordinaire
WARNING: sending me junk-email will be interpreted as granting permission to
bomb your offices and machine-gun your children. (I just got 10 in 12 days.)
The above clause have been appended to every post I've made since 27/7/1996.
Hank Oredson
David M. Razler wrote:
>
> nor...@bigdipper.umd.edu (Pete O'Such) wrote:
>
> >Sean Case (gsc...@tpgi.com.au) wrote:
> >: As _I_ recall, the substrate was surplus sewer pipe. Although it may have
> >: been a glass substrate over a metal core.
> >
> >: The angular momentum of a running Fastrand unit was staggering - if the
> >: power went off, it took days for the unit to spin down. Restarting one
> >: before it had spun down would cause it to leap ten or so metres in a
> >: random direction (up, down, or across) without stopping for little things
> >: like walls. Headcrashes were quite minor annoyances in comparison.
> >
> >I'm having a hard time picturing this device. About how long was the
> >"pipe?" What diameter? I'm guessing the data was encoded on the
> >sides of the device, so was there just one head that traversed the
> >entired length, or where there multiples? Any one have reliable RPM
> >numbers or weight measurements for either the "pipe" or the entire
> >device?
>
Univac Fastrand 1782 has moving heads.
432 has fixed heads.
Have a photograph of "prototype #1" vintage perhaps 1950 (earlier?)
which shows 6" dia drum about 3-4" wide with perhaps 4 fixed heads.
Have to dig that pix out of the archives sometime ...
J. Chris Hausler
Williams, Steve <st...@lgx.unisys.ch> writes:
>The Fastrand has a movable boom with 64 heads mounted on it. The boom
>can move to any one of 158 positions. This gives a total storage of
>158 x 64 x 1792 x 4.5 bytes, or 77+ megabytes, assuming Format 'C'.
>The OS allows you to to allocate files in track granularity, in which
>case you may need head movement to access a track, or in position
>granularity (64 tracks) which means you can read all the tracks under
>the 64 heads without head movement. The heads are rigidly fixed to the
>boom at a fixed distance from the drums (not flying, but not
>touching).
I quote from my copy of, "UNIVAC 1108 EXEC II Operator's Reference",
section 3 page 55:
Each FASTRAND II Mass Storage Unit in the subsystem contains two
magnetic drums similar to those used in the FH-880 Magnetic Drum
Subsystem in that they employ flying heads. However, the read/write
heads on these drums move laterally over many recording tracks
rather than being fixed.
Also an earlier post implied the unit had to be mounted on a
concrete floor, not a typical false floor found in a computer room
of the time. The unit at CMU (CIT :-) in the late 60's and early
70's was mounted on a false floor with no apparent problems.
Regards,
Chris