[unix-pc.general] Optical disk for a unix-pc, is it possible?

hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (11/26/89)

While perusing the December issue of UNIX WORLD, I read about several
write/erasable optical disk systems.   On page 4-5, the 256 MB NeXT
optical storage was hyped.  On page 75, ERI described their 650
megabyte erasable and rewritable optical disk storage system
for AT&T 3B2s.  On pages 85-86 in a "Products of the Year" article,
the 594 megabyte "Artecon Erasable Optical Drive" was praised.
"...the drive itself is originally from Sony."  And on page 138, a
Micro Design Internation Inc. advertisement touted a 600 rewritable
CD-ROM for XENIX.

What would it take to put an erasable/rewritable optical disk on
a unix-pc?  Could it be make to work like a "second" hard disk?

Thank you,
A. Hybl                               UUCP: uunet!mimsy!mbph!hybl

lenny@icus.islp.ny.us (Lenny Tropiano) (11/27/89)

In article <614@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM) 
writes:
|>
|>While perusing the December issue of UNIX WORLD, I read about several
|>write/erasable optical disk systems.   On page 4-5, the 256 MB NeXT
|>optical storage was hyped.  On page 75, ERI described their 650
|>megabyte erasable and rewritable optical disk storage system
...
|>What would it take to put an erasable/rewritable optical disk on
|>a unix-pc?  Could it be make to work like a "second" hard disk?

The CD optical disk would have to be ST-506/MFM compatible.  If it's not, 
then you can pretty much forget it.  When and *if* the 3B1 ever sees a
SCSI interface, those opportunities will open right up.  Most likely
the CD technology quoted here was for the 3B2 SCSI products.   I'd pretty
much impossible to get 650MB using MFM recording.

-Lenny
-- 
| Lenny Tropiano            ICUS Software Systems      [w] +1 (516) 589-7930 |
| lenny@icus.islp.ny.us     Telex; 154232428 ICUS      [h] +1 (516) 968-8576 |
| {ames,pacbell,decuac,hombre,sbcs,attctc}!icus!lenny     attmail!icus!lenny |
+------- ICUS Software Systems -- PO Box 1;  Islip Terrace, NY  11752 -------+

bdb@becker.UUCP (Bruce Becker) (11/30/89)

In article <1037@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes:
|[...]
|The CD optical disk would have to be ST-506/MFM compatible.  If it's not, 
|then you can pretty much forget it.  When and *if* the 3B1 ever sees a
|SCSI interface, those opportunities will open right up.  Most likely
|the CD technology quoted here was for the 3B2 SCSI products.   I'd pretty
|much impossible to get 650MB using MFM recording.

	It's not impossible, but noone does it - RLL &
	similar encodings are generally used for large
	capacity magnetic drives.

	The 3B1 problem is addressability - 8 heads,
	1024 cylinders, 16 sectors/track, 1 drive. At
	512 bytes/sector, the total is 67,108,864 bytes.

	If a WD2010 controller is used, then one can
	use up to 2048 cylinders, for 134,217,728
	bytes, though I've never seen a ST506/MFM
	drive with that many cylinders.

	If the P5.1 upgrade is done, then 16 heads
	are addressable, for 268,435,456 bytes.
	With this upgrade it is also possible to
	have 2 drives, but the total maximum possible
	is still less that 650MB.

	The most that seems available are drives
	like the Maxtor 2190, with 1224 cylinders
	& 15 heads, giving 150,405,120 bytes/drive.

	SCSI, SCSI, SCSI, if I say it enough times
	will it magically appear? 8^)

Cheers,
-- 
   ^^ 	 Bruce Becker	Toronto, Ont.
w \**/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
 `/v/-e	 BitNet:   BECKER@HUMBER.BITNET
_/  >_	 Ceci n'est pas une |    - Rene Macwrite

jbm@uncle.UUCP (John B. Milton) (12/05/89)

In article <1226@becker.UUCP> bdb@becker.UUCP (Bruce Becker) writes:
>In article <1037@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes:
>|[...]
>	If a WD2010 controller is used, then one can
>	use up to 2048 cylinders, for 134,217,728
>	bytes, though I've never seen a ST506/MFM
>	drive with that many cylinders.

The actual limit with the WD2010 is (from /usr/include/gdisk.h):
gdisk.h:#define HDMAXCYL	1400	/* support a maximum of 1400 cylinders */
This is a compiled into the kernel value, we can't change it.


John
-- 
John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu
(614) h:252-8544, w:469-1990; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!

bdb@becker.UUCP (Bruce Becker) (12/08/89)

In article <617@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes:
|In article <1226@becker.UUCP> bdb@becker.UUCP (Bruce Becker) writes:
|>In article <1037@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes:
|>|[...]
|>	If a WD2010 controller is used, then one can
|>	use up to 2048 cylinders, for 134,217,728
|>	bytes, though I've never seen a ST506/MFM
|>	drive with that many cylinders.
|
|The actual limit with the WD2010 is (from /usr/include/gdisk.h):
|gdisk.h:#define HDMAXCYL	1400	/* support a maximum of 1400 cylinders */
|This is a compiled into the kernel value, we can't change it.

	Those of you with kernel source (8^) can
	grep for the use of this constant so as to
	discover where to patch... please post...

	It seems that Philips has a ST506 thingy which
	may be several spindles that looks like a very
	large single drive. This information comes from
	a German developer who makes disk interface
	hardware for the Amiga, etc.

	Granted the limited acees one might have to such
	a device - I still want SCSI, things would be easier.
	So where is the ST506-to-SCSI adapter card we all need?

Cheers,
-- 
   ^^ 	 Bruce Becker	Toronto, Ont.
w \**/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
 `/v/-e	 BitNet:   BECKER@HUMBER.BITNET
_/  >_	 "Modern Businessmen believe in Christiannuity" - Pres. George Bosch

jcm@mtunb.ATT.COM (John McMillan) (12/11/89)

In article <1286@becker.UUCP> bdb@becker.UUCP (Bruce Becker) writes:
>In article <617@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes:
:
>|The actual limit with the WD2010 is (from /usr/include/gdisk.h):
>|gdisk.h:#define HDMAXCYL	1400	/* support a maximum of 1400 cylinders */
>|This is a compiled into the kernel value, we can't change it.
>
>	Those of you with kernel source (8^) can
>	grep for the use of this constant so as to
>	discover where to patch... please post...

	And even without kernel source:
	those of you clever enough to bother to GREP
	for HDMAXCYL in the /usr/include/sys directory
	may notice it is used in the declaration of array
	sizes.  [If you have a single disk, you MIGHT get
	away with double the size (ie., 2800) by trashing
	the 2nd disk area's Bad Block Q array].

john mcmillan