9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: W B Hacker <wbh@conducive.org>
To: lucio@proxima.alt.za,
	Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] /sys/include/ip.h 5c(1) - LONG POST
Date: Sat, 10 Oct 2009 04:15:59 +0800	[thread overview]
Message-ID: <4ACF99FF.9030809@conducive.org> (raw)
In-Reply-To: <bb872b2e5467b40c754a6a97e1071084@proxima.alt.za>

lucio@proxima.alt.za wrote:
>> wikipedia agrees with lucio on this point
>> http://en.wikipedia.org/wiki/Micro_Channel_architecture#Marketshare_issues
>>
>>> The majority within IBM never wanted into that part of the market in the first
>>> place, as it was seen as cannibalizing not only 3XXX terminal sales, but the
>>> entire, highly profitable, big-iron+interface+network+services infrastructure
>>> behind said terminals.
>> do you have a reference for this?
>
> There's truth on both sides, IBM had committed to the PC because Apple
> was stealing the show,

No - they neither knew nor cared about that.

Thinking here is being boxed by a 'personal computer' worldview.

Big bucks NOW - small change THEN. Vanishing margins now.

Let's talk about IBM's middle initial - where the money was.

'Business'

They 'committed' to the PC because it was 3270-capable, yet was far more
flexible than a 3270 AND could go head-to-head with everything from an ADM-3A,
SOROQ IQ-120, TVI-9xx, Wyse 1XX thru 3XX (color) DEC VT-52 up (including color)
  HP terminals, Sun workstation (low-end), Xerox, Wang, Data General, [GE,
Honeywell, Bull] (eventually merged), CDC, ICL/Fujitsu/Siemens, Nixdorf,
Burroughs, Univac --> Unisys, etc.. any or all of whom were lining up to eat at
least a slice of what IBM saw as 'their' lunch, low, middle, or high end.

DEC alone DID eat a very large chunk of it at their peak, and HP MPE-3000 still
won't die.

Having a configurable box that could be a dumb OR smart terminal OR go
head-to-head with a Xerox, Wang, or baby DEC - moreover a box with an IBM logo -
made selling the mainframe and midframe and support much easier, simplified
inventory, and started to erode the low-end of all the OTHER competitors.

Poisoning THE OTHER GUY's well more than IBM's well, if you will.

Apple, CP/M, AT&T Bellmac and the entire Unix movement - were not even a blip on
the radar *commercially*.

The 'enemy' was DEC .. and to a lesser extent, HP, SUN, Unisys, and even Wang's
quite competent office networks.

 >  but within IBM there were definitely movements
> keeping the PC at bay.  My understanding was that the 8250, crappy
> UART that it was, was used specifically because SDLC required
> synchronous RS-232 and the 8250 didn't have it.

The INS8250 most certainly DID have it. All you had to do was connect the lines.

I've run them on the George Morrow Designs 'Empire' S-100 board at 112KBps
synchronous and 56 KBps async for hours on end.

The only 'glue' needed was level-shifters - discrete transistors on my OSI
Challenger II, Motorola 1488 & 1489 diode-coupled-logic on everything up until
the 16XXX derivative of the 8250 was sucked into a 'bridge' chipset.

The 'can't do more than 9.6' issue was purely an OS problem on the PC.

The same 240-odd byte Forth routine that ran the chipsets on the Morrow S-100
boar ported with no more than a base-address change to the IBM PC. Under LMI
Forth, the PCDOS and its brain-dead interrupt handling used to boot into LMI
Forth were pushed aside, and the 'can't do' IBM PC MB also ran well at baud
rates not to be seen again until OS/2 on 386 with 16550.

>  Note that the 8251
> was compatible with the 8088 (both Intel designs, if I'm not
> mistaken), where the 8250 came from National Semiconductors and
> required additional glue logic (and had write-only registers and no
> RESET, shudder!).

Not accurate. The problem is that there were TWO chips with the '8250' name, and
they were not alike.

The INS8250 adopted by IBM had only ONE byte of buffering - but it was enough if
you were a machine-code, ASM, or Forth programmer.

PCDOS was lousy at I/O, and Windows no better.

In telco logging gear, OS/2, by comparison, could drive dozens of the same
chipset serial ports at the same time - every one of them at speeds Windows
wouldn't be able to match on ONE port for a decade or more.

BTW - The 'Empire' also used a pair of the Intel 8259 PIC, but correctly
cascaded: 8 X 8 = 64 less the cascade line = 63 hardware interrupt lines.

IBM Boca not only FUBARRED by tying the NMI line to a (generally non-existent)
memory parity checker, insuring there was NFW to analyze or recover from such an
error, they ran the 8259 PIC on the AT in add-on instead of cascade:

8 + 8 = 16, less the cascade line (2/9) = 15 usable interrupts.

Dumb.
>
> Fact is, IBM had distinct, sometimes contrasting marketing objectives.
> I suspect that fighting the Taiwanese menace was as high on the agenda
> as anything could possibly get.

IBM's turnover exceeds that of many entire nations. MS edges them as a 'software
company' - but software is nearly 100% of MS biz, and only 20% of IBM's.

IBM's global headcount exceeds that of many US cities, and even a few entire
state populations.

That is going to insure a good deal of 'sometimes contrasting' contradiction.
It wasn't Taiwan back then, but the *Japanese* who were seen as a threat to IBM
revenue - especially after ex-IBM'er Gene Amdahl got Hitachi to make
plug-compatible mainframes.

NEC and Hitachi/Fujitsu (same parent Keidanren) are about the only competition
IBM have now for volume production 'Big iron'.

>  In "Big Blues" (I think that is the
> book title) it is suggested that IBM did not have a proper focus and
> the PC was a knee-jerk reaction that should have been planned
> considerably better.
>

'Pee Cee' centric thinking. IBM was 'dumb like a Fox' ...again.

The PC did what it was strategically intended to do - left IBM as last-man
standing in the US and European mainframe and midframe business, and able to buy
PC and server parts cheaper than make them.

IBM will not go there again in the same way.

This go, they are using Linux to suck Sun (accomplished) and HP (in work) into a
black hole and cause Redmond to spend a ton of cash. All the while, service &
support is ever more important.  IBM has more of that than all others combined.

If/as/when it makes business sense to do so, IBM will exit the computer biz
entirely in favor of food production, electric cars, space travel - Hell *time*
travel - or whatever else they see a solid one-hundred-year profit run in.

You don't have to love 'em. Few do.

Just never ignore the resources they command.

Bill




  reply	other threads:[~2009-10-09 20:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<4ACED151.8060901@conducive.org>
2009-10-09 15:12 ` [9fans] /sys/include/ip.h 5c(1) erik quanstrom
2009-10-09 17:51   ` [9fans] /sys/include/ip.h 5c(1) LONG POST W B Hacker
2009-10-09 18:25   ` [9fans] /sys/include/ip.h 5c(1) lucio
2009-10-09 20:15     ` W B Hacker [this message]
2009-10-10  1:34       ` [9fans] /sys/include/ip.h 5c(1) - LONG POST Ethan Grammatikidis
2009-10-10  2:30         ` W B Hacker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ACF99FF.9030809@conducive.org \
    --to=wbh@conducive.org \
    --cc=9fans@9fans.net \
    --cc=lucio@proxima.alt.za \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).