Re: 3B2 Disks

In article <slrngmleaj.hl.dnichols@xxxxxxxxxxxxxxxxxx>,
"DoN. Nichols" <dnichols@xxxxxxxxxxx> writes:
On 2009-01-12, Bill Gunshannon <billg999@xxxxxxxxxxx> wrote:
In article <slrngml5q6.hl.dnichols@xxxxxxxxxxxxxxxxxx>,
"DoN. Nichols" <dnichols@xxxxxxxxxxx> writes:
On 2009-01-11, Bill Gunshannon <billg999@xxxxxxxxxxx> wrote:

[ ... ]

The 3B1 and the 3B2 have nothing in common with each other.

The vendor. And the fact that they both are computers.

And the fact that they both ran SysVr? OS versions (with various
add-ons. :-)

And -- I've got a 3B2 external drive housing attached to one of
my 3B1s, to hold both the boot drive (no longer internal) and the second
drive, plus a "floppy tape" drive. Granted, it took a bit of creative
wiring to do that all.

[ ... ]

I gave some thought to recommending hooking one of the disks up
to another computer, but regardless of the possibility of the
filesystems being compatable I doubt the controllers used would
allow for something other than another member of the 3B2 family
(3B12/3B15/3B20) being able to read the disk in its present format.
But I suppose there would be no loss in trying.

If it is purely a MFM drive, yes, it would be difficult to
access from another system.

Mine were, 2 MFM drives on a custom (Western Electric) controller.


But a friend had a 3B2 which had a SCSI interface, and used MFM
(or were they IDSE) drives on a shared adaptor. I believe that the
adaptor could handle up to four drives at once, but he only had two on
it.

I have seen SCSI<->MFM adapters (I actually have one, but have no idea
what it came out of) but the only SCSI I heard about on the 3B's used
pure SCSI disks.


Those drives, *with* the adaptor, could be accessed a sector at
a time from any SCSI system using the "raw" interface. It would be
fairly easy to write a C program which would do that and look for a
sector which started "root:.*:0:0:" (Wildcarding for the password field
to allow for no password (not the case here),

Actually, you could. drop the password, move the uid and gid and use
the GCOS field to suck up the extra character spaces.

a real password, or a
redirection to a shadow password, depending on the age of the system.

Never saw shadow passwords on an 3B I worked with. I don;t think they
were around long enough for that to become the practice.

If a redirection, then re-do the program to look for "root:.*:" without
the "0:0:".

Given the age of the system, the length of the password field
would be constant with the standard password hashing system, making it
easy to do a raw disk edit on that one sector to replace it with the
hash of a *known* password. (Anything which changed the length of the
field would of course require adjusting everything which followed in the
password file.

Putting in a known hash is probably the easiest way but you could also
do what I said above to get rid of the password entirely.


And *any* SCSI disk (if his system uses SCSI, either a direct
SCSI disk, or a MFM or such adapted to SCSI by an external card) should
be readable on a sector-by-sector basis to allow some of my suggestions
to work. After all -- the two systems which I described gaining access
to were not even AT&T products -- one was Tektronix with the NS 32016
CPU, and the other was Intergraph with a Fairchild "clipper" CPU. The
first ran a BSD flavor of OS, and the second a SysV flavor. The first I
broke the password on using a 3B1 as the password cracking engine, and
the second I accessed the raw sectors on using a Sun 2/140 (BSD to
access a drive from a SysV based system.

I guess anything is worth the try if the alternative is to use them
as doorstops (something they do quite well, actually).

You want a serious doorstop? Try my Ingergraph Interact 32/C.
Two 19" monitors mounted on top of a wheeled chassis containing most of
the rest, with a big (24x36" IIRC) digitizing tablet hinged to the front
with an air cylinder to allow adjusting the angle while a pressure point
was pinched. The digitizing tablet and the puck acted as the mouse,
with about a dozen buttons on it.

It was designed as a graphics workstation, but I didn't have the
software to use it as such. I now have the software, but I don't have
the license keys to allow me to use the software.

The edge of the digitizing tablet had another pair of pressure
points to raise or lower the tablet and the monitors as a unit, and
another pair to tilt the monitors forward or back to adjust so you
could use it comfortably seated low, on a draftsman's stool, or
standing.

OK, I'll see your Intergraph and raise you a Tektronix 4300 family
graphics station. Ran not only thier custom stuff but also CPM-86.
I still keep a couple of the magnets fopr biasing the digitizing
tablets around for erasing disks. The magnet was so powerful they
came packed inside a steel pipe when you bought a terminal. :-)

And then, I used to have an Apollo Workstation. Now there's a boat
anchor.


Funny you
should mention SCSI. I actually heard there was a 3Bfamily SCSI
controller but I suspect they were even rarer than QBUS or UNIBUS
SCSI controllers. Well, maybe they became popular after NCR took
over the running of AT&T's 3Bfamily.

Hmm ... I'm afraid that I can't ask the friend about it, as he
is no longer with us.

Did you ever hear about the
NCR "upgrade" for the 3B2 computer systems? :-)

No -- how bad was it?

As you may or may not know, after the big court fight when AT&T actually
got permission to be in the computer business commercially, they decided
they didn't want to. So they brought in NCR to run that division. NCR's
first move was to "upgrade" the 3B2. Simple upgrade, really. Open case.
dump all 3B2 related parts into garbage can. Insert NCR designed and
manufactured M68K based computer into case. Upgrade completed. :-)


The 3B1 was
a Convergent Technologies box sold by AT&T and the 3B2 was an AT&T designed
and manufactured box using the WE32000 CPU.

Both with the AT&T "Death Star" logo, and similar color schemes,
FWIMBW.

Yeah, also sported by the AT&T 6300 family which was made by Olivetti
in Italy. And wasn't compatable with anything, not even the IBM PC
which was the actual model for the hardware.

And -- it had to have the date routine in the OS patched every
eight years. The clock chip in that only counted through eight years
(just enough so it would keep the right years as leap years), and the
patch added the proper starting point to the eight-year count in the
chip.

Didn't know about that one but then I never saw one that lasted 8 years. :-)



A friend was still working at a place which used these things
when the *second* update time came around, and I was able to get the
patch for her through the help of someone in this very newsgroup. But
imagine a *business* still using a 16-year old PC sorta clone. :-)

I will look later today, but,
sadly, I believe I threw all my 3B2 software away years ago when my last
3B2 died. If I still have any of them, they yours for the postage.

And -- if you *don't* have them, it is still possible that he
may be able to use some of the ideas which I covered.

He is free to do whatever he wants. It's just that having had a number
of them myself I was offering my experience which was that they were
not really compatable with anything (that, I am fairly certain, was by
design) and by todays standards not really worth a lot of effort.

Well ... I just recently acquired a SGI Indigo 2 (the version
with the really weird R8000 MIPS processor which had floating point as
fast as integer math.

I got rid of a pair of Indigos a while ago. I do still have an O2.
Also SPARCStation-II, Ultra Sparc, a couple of original MAC's, a bunch
of newer M68K MAC's, a bunch of PDP-11's and VAXen. Also a bunch of
APPLE ]['s and Tandy computers. And I almost forgot all my 3B1's. One
of these days I hope to actually set up amd operate a computer museum.


One reason for wanting to bring it back to life is that they had
the only DAT drives which were capable of reading and writing *audio*
DATs as well as backup tapes -- complete with a graphical sound editing
program back in 1995. :-)

While
I really liked the processor (and I have the architecture manual here
somewhere, I know I kept that for my library) many of the components were
did not seem particularly well made and eventually all of mine failed.
Compare that to how many other, much older computers are still in
almost daily use.

But -- the 3B2 was the porting base for unix for some time. (I
guess that the higher numbered 3B* systems were a fairly easy port from
the 3B2 software.

They maintained very good compatability along the whole line. But then,
they had to, they were running the phone system with them and that was
their bread and butter.


And I've still got (but have retired) my first unix box, a
COSMOS CMS16/UNX (Motorola 8 MHz 68000 CPU with v7 unix in an Intel
Multibus chassis.) *And* -- I still have the manuals and the 11 8" DSDD
floppies which made the OS distribution.

My first Unix system was a pre-release Tandy Model 16. I got it when
I was working for Martin Marietta and we were trying to sell a certain
government site on replacing Terak 8510's running UCSD Pascal with
something a bit more business practical. I started this project while
I was in the Army and then worked it from the other side when I got out
and became a contractor. In the end, I got to keep the original machine
we had acquired from Tandy before they started selling them.


I wish him luck. Oh yeah, I looked. Either I gave away or threw away
all the sets of software I had. I suspect gave away as I seldom throw
any software out and would more likely have recycled the floppy disks.
I do still have the floppy drives, the floppy tapes and I think I may
even still have the hard disks here somewhere. I have always wanted to
see if I could write a driver to let me use the tape drives on something
like a PDP-11.

Did you ever hear of the PDP-11 which ran unix from a DECTAPE?
Swapping and everything on that one tape drive. :-)

No. And I can't imagine swapping to a DECTAPE at all. But, I do know
there is a version of mini-Unix that runs on the TERAK 8510. LSI-11/02,
28K Words of memory and an 8" floppy. :-) There was a time when Unix
was not nearly as bloated as it later became.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@xxxxxxxxxxxxxxx | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
.

Quantcast