[TUHS] Old mainframe I/O speed (was: core)

[Erik E. Fair]

The VAX 8800 was also the advent of the DEC BI bus attempt to lock third-party I/O devices out of the VAX market and prevent "unauthorized" competition with their own overpriced and underperforming I/O devices.

In late 1988 or early 1989 my group at Apple ordered a VAX-8810 to replace two 11/780s on the promise from DEC that all our UniBus and MASSbus peripherals would still work ... which we knew (from others on the Internet who'd tried and reported their experiences) to be a lie.

After allowing DEC field circus to embarass themselves for a while trying to make it work, we cancelled our 8810 order and bought two 8650s instead (they cost half as much!), which we knew would run 4.3 BSD UNIX (unlike the 8800 series where we'd be stuck with Ultrix) and where all our old but still useful peripherals would still work. Surprise, DEC - your customers talk to each other and compare notes.

IIRC, as a consolation for DEC, we still bought a heavily discounted 6000 series BI machine with all new I/O to handle some other tasks that the 8650s weren't doing while also making clear to DEC that we understood the game they'd tried to play with us.

After that, Apple engineering concentrated on Sun & SGI gear, along with our Cray running UniCOS, but Apple IS&T (corporate IT) bought quite a bit of VAX gear to run VMS for certain applications they had to support.

Part of being in the Unix community was participating it as a community and sharing experiences like this for the benefit of all (and to keep hardware vendors honest) - the Unix-Wizards Internet mailing list, and comp.unix USENET newsgroup were invaluable in this regard.

	Erik Fair


>Date: Thu, 21 Jun 2018 16:39:23 -0400
>From: Paul Winalski <paul.winalski at gmail.com>
>
>On 6/21/18, Arrigo Triulzi <arrigo at alchemistowl.org> wrote:
>> On 21 Jun 2018, at 16:00, Paul Winalski <paul.winalski at gmail.com> wrote:
>> [...]
>>> for the microcode to customers.  There were several hacks in there to
>>> slow down the disk I/O so that it didn't outperform the model 30.
>>
>> Is this the origin of the lore on “the IBM slowdown deviceâ€>?
>>
>> I seem to recall there was also some trickery at the CPU level so that yo>u
>> could “field upgrade” between two models by removing it b>ut a) I cannot find
>> the source and b) my Pugh book is far and cannot scan through it.
>
>I don't know about that for IBM systems, but DEC pulled that trick
>with the VAX 8500 series.  Venus, the successor to the 11/780, was
>originally to be called the 11/790 and was done in ECL by the PDP-10
>folks.  The project suffered many delays and badly missed its initial
>market window.  It eventually was released as the VAX 8600.  It had a
>rather short market life because by that time the next generation CPU,
>codenamed Nautilus and implemented in TTL, was nearly ready for market
>and offered comparable performance.  There was also a slower and lower
>cost system in that series codenamed Skipjack.  When it finally came
>time to market these machines, it was found that the product line
>needed a reduced cost version of Skipjack.  Rather than design a new
>CPU, they just put NOPs in the Skipjack microcode to slow it down.
>The official code name for this machine was Flounder, but within DEC
>engineering we called it "Wimpjack".  Customers could buy a field
>upgrade for Flounder microcode that restored it to Skipjack
>performance levels.
>
>-Paul W.