CD-ROM offer [ details on implementation ]

[Dave Olson]

In <1991Feb14.155649.20613 at utstat.uucp> tg at utstat.uucp (Tom Glinos) writes:

| In article <1991Feb14.021900.8427 at odin.corp.sgi.com> olson at anchor.esd.sgi.com (Dave Olson) writes:
| >In <9102131750.AA08632 at scripps.edu> jwk at SCRIPPS.EDU (John Kupec) writes:
| >
| >
| >By the way, the CDROM drive(s) we end up supporting will have custom
| >proms in the drive, in order to support booting from existing CPU
| >proms.  The main change is to default to 512 byte blocks instead of
| >2048, and secondarily to claim in the inquiry command that they are
| >device type 0 (hard disk).  Re-powering the drive, or a SCSI bus reset
| >will cause it to revert to the hard-disk mode (it has to do it on a bus
| >reset for installs to work correctly after an init 0 without
| >re-powering the CPU).
| >
| 
| Why not change the boot proms on the CPU side instead?
| 
| Convince me that this would be more expensive than the charging scheme
| that I see on the back of the CD-ROM jewel case.

I don't know anything about the fees that will be charged for CDROM
software updates, except that they are supposed to be less than
for tape.

Upgrading CPU proms has 2 main problems, of which the first is probably
the most significant to the engineering community, and the second to
the bean counters:

1) creating AND testing new proms for every machine and configuration
   out there would be a huge engineering job, and one that no one
   wants to do (we would rather give you new features on existing
   machines, and new machines).

2) changing cpu proms would require an FE for many sites (not all).
   Any time you open up a machine and take out the boards, you tend
   to expose problems that were lurking (heat stress, oxidized connectors,
   etc., etc., and then you are looking at downtime for the customer
   and even more expense.  someone has to pay for it, either directly,
   or indirectly in higher costs on future products.

NOTE: as always, these are my opinions, and not the official opinion
of SGI...
--

	Dave Olson

Life would be so much easier if we could just look at the source code.