spenton@sag4.ssl.berkeley.edu (01/18/91)
Check this out ! Copied Directly From 1-14-90 issue of INFO WORLD magazine. =================================================== NeXT Talks to Mac. Floppy Works, a $250 file transfer program from Digital Instrumentation Technology, Inc., makes it easier for users to swap files between the Mac and NeXT Computer Systems. The utility runs on NeXT systems but allows users to insert Mac disks and user the browserlike NeXT windows to format, read, and write Mac disks, as well as files under DOS and OS/2. (505) 662-1459 ===================================================== Sounds good! Steve Penton (spenton@ssl.berkeley.edu) Center for EUV Astrophysics Remember, " Astrologers have Venus envy. "
glaeske@plains.NoDak.edu (Brian Glaeske) (01/18/91)
In article <1991Jan18.002212.688@agate.berkeley.edu> spenton@ssl.berkeley.edu () writes: >Check this out ! Copied Directly From 1-14-90 issue >of INFO WORLD magazine. > >=================================================== > >NeXT Talks to Mac. Floppy Works, a $250 file transfer Isn't this a little high of a price for a program to read a different format of disks? Seems to me that the hardest problem about reading a Mac disk is deciding what to do with that resource fork, and a Mac resource fork is pretty worthless to anything but a Mac (and possibly a Mac emulator :-)). I guess I'll just have to try my hand at writing a similer program when I get my NeXT. -- Brian Glaeske - /| glaeske@plains.NoDak.edu [Internet] o.O` --Ooop ACK!! glaeske@plains [BITNET ] =(___)= ..!uunet!plains!glaeske [UUCP ] U "Bloom County Forever!!"
madler@pooh.caltech.edu (Mark Adler) (01/18/91)
spenton@sag4.ssl.berkeley.edu notices: >> NeXT Talks to Mac. Floppy Works, a $250 file transfer >> program from Digital Instrumentation Technology, Inc., ... >> Sounds good! Caveat emptor. I bought a CubeFloppy 1.4 from those guys a while back and sent it back since the software was so bad. They may have drastically improved their software since then, but I kind of doubt it. I would surely like to hear from anyone who buys this software anyway, or their CubeFloppy 2.9 (which optionally comes with the software for Mac and DOS transfers). Mark Adler madler@pooh.caltech.edu
glang@Autodesk.COM (Gary Lang) (01/21/91)
> and a Mac resource fork is >pretty worthless to anything but a Mac (and possibly a Mac emulator :-)). I see. Really don't need the bitmaps from a MacPaint file or icons or anything else eh? If I were grabbing Macintosh files, I'd worry about resource on a case-by-case basis. You can't arbitrarily throw away the resource fork and expect things to work; it's the Mac app. designer's perogative to put data in the resource fork and it's done quite often. If you have MacLink on you're Mac, and can stretch a cable between the mac and the cube, I think you're better off. If not, then the DIT thing is probably your only recourse. Nice idea though; wish I had this for an IBM-PC. -g -- Gary T. Lang (415)332-2344 x2702 Autodesk, Inc. Sausalito, CA. MCI: 370-0730
dsmall@well.sf.ca.us (David Small) (01/22/91)
(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.]