[TUHS] Reaction to the 3B2 at Bell Labs

[Clem Cole]

Seth, I've often said the only reason they sold any of them was that AT&T
required you to buy one as the reference system for SVR3 - so anyone that
wanted to port it tended to buy one 3B2 just to have it as the reference
box.

Rob's comment about the BELLMAC-32 was interesting.  I could never quite
understand why AT&T wanted to create its own microprocessor and associated
ISA and try to sell it against the other merchant microprocessors (just as
I never could understand why HP and IBM did either - but they were already
formally in the computer business).   Selling chips to other people to use
for their designs is a difficult business that needs a sophisticated sales
and marketing team.   Even if AT&T could create a technically
competitive device and get the manufacturing cost structure in line
with Moto or Intel so that the street price could be competitive, the
previous sales and marketing scheme of abandoning UNIX on your doorstep was
not going to work, and it was having a new technical sales support team to
match Intel and Moto was just not going to happen any time soon.

Supporting the operating companies is a different beast than supporting,
say, a start-up trying to build a hot new device -> that company's
product.   While I suspect Rob and Bart built their own tools for the
redox of the Blit, Rob I ask you -- truly if you have been outside of AT&T,
could you imagine trying to use that device? I can't.

I've told the details of the story elsewhere, and they don't really matter
here. But I remember being at Masscomp and finding a bug in the new FP chip
for the 68020 - which was causing a 'stop shop' on our newest product -
when one of the factory exercisers/diags started to fail.   We were paying
a premium at the time and Moto's local folks did not want to listen at
first.  Our head of HW came to me because he knew that I knew a bit about
the application program they were using as a test from my grad school
days.   With the end help of the Fortran compiler back-end guys in a few
hours of debugging, I was able to isolate the chip failure.  Then I wrote a
new 10-line Fortran example and associated assembler code, which we faxed
to Moto.  Moto had a 'Technical Consulting Engineer' on the line from
Austin, and indeed it was validated as a problem, and less than 12 hrs
later their team had figured out what was going on in the chip.

I bring this up because I just don't see AT&T has been able to react that
way, although, in the end, we had to solve it once Moto figure out what the
cause of the error was (a slow charge circuit was wiping out the exponent
in R/R instructions under certain conditions - so we changed the compiler
not generate the sequence so we should still ship).
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221126/4bfa35e5/attachment.htm>