Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!well!dsmall
From: dsmall@well.sf.ca.us (David Small)
Newsgroups: comp.sys.next
Subject: Re: Mac Disk Reader for NeXT Announced !
Message-ID: <22790@well.sf.ca.us>
Date: 21 Jan 91 23:31:01 GMT
References: <1991Jan18.002212.688@agate.berkeley.edu> <7621@plains.NoDak.edu> <2181@autodesk.COM>
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 69


(the thread centers around reading Mac disks on the NeXT and the difficulty
thereof).

	The Mac on its 400/800K disks uses group-code format, which is highly
different than IBM modified-frequency-format (e.g., double density) format.
You can't buy an off-the-shelf GCR disk controller that does all the dirty
work for you like you can with the IBM (say, an NEC 765, or a WD 177x or 179x,
or 279x for internal data seperator versions).

	The Mac GCR approach is a low-hardware, extreme software approach,
where the disk OS software handled all the bit encode/decode that satisfies
the
magnetic requirements of media. Heck, the Apple ][ GCR scheme made the Apple ][
disk
drive inexpensive and probably was a key factor in Apple ever going anywhere.

	The Mac GCR disks also seperate the disk into five speed zones. If
you understand hex, they're at the $x0 division (e.g., tracks 0-f are one
speed,
$10-1f are another speed, etc). There are also varying number of sectors per
track, a particularly strange CRC schemes to validate sector data, and
I think I can describe formatting the disks (repeatedly laying down the track
until the gaps match, and until you don't blow away the first sector by
writing the last one) as a "nightmare".

	Doing all this on a constant-speed drive is no joke at all. Central
Point has done it with their IBM board, and we do it with Spectre GCR, reading
and writing Mac disks with constant-speed drives. Given that the Mac disks are
written at close to 600 RPM on some tracks, and 300 RPM on others, you can
imagine how much fun this is; I'm looking into Minoxodil to regrow my hair
after
doing these assembly routines ...

	Also, some drives (notably the NEC 1035,1036,1037) have an LC filter
which literally filters out the Mac data, interpreting it as noise. (I *think*
it is intended as part of a notch filter to only let valid data through).
Anyway, Mac data is at a different speed. This causes innermost tracks,
$40-$4f, to go blooie a lot of the time.

	Naturally, if you get a mechanism that self-adjusts its speed to the
Mac standards, you can avoid some of the hassles and read/write at a constant
rate. I don't know how to do that -- call sony? You got me.

	I also don't yet know the exact details of the Apple higher density
format... did they go MFM or GCR for their 1.44 meg ("FDHD") drives? If anyone
can email this info that knows for sure, I would be very grateful.

	At the point where you get sector I/O working, you then have to
contend with HFS, the file system from hell. Pardon me for my opinion, but
even working with MS-DOS at the FAT level and trying to figure out what
sectors comprise a file is tricky; HFS is a complete bitch for me to work out,
with its B*-trees, and allocation schemes apparently written after listening
to "White Rabbit". (Not that it doesn't work, it does. It just drives me up
a wall).

	I think anyone who has slogged through all this work and gotten something
working at *least* deserves an award for effort. 

	Seems like I spoke to the Mac-drive-for-NeXT people at MacWorld as
well; it's a natural to include in some sort of Mac emulator for the NeXT,
which is definitely a do-able project. Whether or not it will be done probably
depends on the perceived interest in it. 

	Sorry for the long windedness.

	-- thanks, Dave / Gadgets by Small

[I'm not clever enough to dream up a witty saying after my signature.]