Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!anchor!olson
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: CD-ROM offer [ details on implementation ]
Message-ID: <1991Feb14.021900.8427@odin.corp.sgi.com>
Date: 14 Feb 91 02:19:00 GMT
References: <9102131750.AA08632@scripps.edu>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 57

In <9102131750.AA08632@scripps.edu> jwk@SCRIPPS.EDU (John Kupec) writes:

| I just got a fax from SGI heralding the CD-ROM offer. 
| 
| They tell me that the CD-ROM drive itself is currently only
| available for PI systems.  I have a PI but it may not be around
| for long.  My question is this:
| 
| If I have "hot-wired" a 3rd-party 8mm drive to the SCSI bus of a 210, 
| shouldn't I be able to similarly attach this so-called PI-only CD-ROM 
| drive to a 210?

Yes, but we won't support it if it doesn't work for you :)

The problem is that most of the earlier 4D machines (4D[678]0, not the
4D85, or the 4D[123]X0 machines) had a somewhat incorrect SCSI bus
cabling scheme (the stubs for the drives were much too long).

The 4D[123]X0 still don't have it completely correct, but it is much
better.  Still, these machines are more prone to problems with external
scsi devices.

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).

Newer machines (IP12, aka 4D35) will work even if the type is 5
(CDROM), however they still require a default block size of 512 bytes.
I've heard rumors that this is basicly what Sun did also.

The standalone programs, and the newer CPU proms issue a SCSI command
to cause the CDROM to revert (except for the block size) to looking
like a CDROM on the inquiry command, etc.  For those who might care,
the command is a 10 byte command, all zeros, except for the first byte,
which is 0xc9.  All the drives we are qualifying support playing audio
media out the headphone jack, and can be controlled over the SCSI bus
with vendor specific commands.

In other words, you won't be able to buy a random CDROM and use it for
installing bootable software, although you may be able to use it for
other purposes.

One more point: the bootable CDROM media will look very much like a
hard disk, in that it will have a standard SGI volume header, and an
EFS filesystem.  Future software releases of products that don't
require booting from the CDROM may be in some other format, such as
ISO-9660.
--

	Dave Olson

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