bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (05/22/87)
I just got off the phone with Central Coast Software. Their hackers are able
to reliably read all tracks of a Mac disk. They are building a product
around that ability and plan to have it available within 3-4 months.
The person I talked to made one request -> "We are not taking orders, and
need to spend our time working, not answering the phone." "We hope to have
the product out in 3-4 months, it will be announced and advertised when
available."
-------------
Ack! (NAK,EOT,SOH)
|\ /| .
{o O} . bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
( " )
U Single tasking? Just say *NO!*kim@amdahl.amdahl.com (Kim DeVaughn) (05/23/87)
In article <8705221955.AA05310@cogsci.berkeley.edu>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: > I just got off the phone with Central Coast Software. Their hackers are able > to reliably read all tracks of a Mac disk. They are building a product > around that ability and plan to have it available within 3-4 months. Uh, Bryce ... you really shouldn't be wasting the net's time and bandwidth with this kind of thing ... I mean, afterall, this is "impossible" to do (as we all should well know by now), and therefore any such discussions (and, by implication, any such *PRODUCTS*) are pointless! Oh, and by the way, bumblebees can't fly, and the human body cannot survive a sustained speed in excess of 32 mph, and people will never reach the moon, and ... Kudos to Central Coast Software for once again proving that "impossible" is just a word! Sorry, I just couldn't resist :-) :-) :-) /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
hah@isum.intel.com (Hans Hansen) (05/23/87)
In article <6938@amdahl.amdahl.com> kim@amdahl.amdahl.com (Kim DeVaughn) writes: >In article <8705221955.AA05310@cogsci.berkeley.edu>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >> I just got off the phone with Central Coast Software. Their hackers are able >> to reliably read all tracks of a Mac disk. They are building a product >> around that ability and plan to have it available within 3-4 months. > >Uh, Bryce ... you really shouldn't be wasting the net's time and bandwidth >with this kind of thing ... I mean, afterall, this is "impossible" to do >(as we all should well know by now), and therefore any such discussions >(and, by implication, any such *PRODUCTS*) are pointless! >/kim Before you all drown in your own sarcasm.... WHAT was said in the original posting ?? NOTHING ! The posting by Bryce simply said that some one was working on something, BUT DON'T ASK ME ABOUT IT ! My response is :: is it only a software package or a combination of SW and HW ? What will this phantom pkg sell for if it ever reaches the stores? I'll believe it when I can see it running on MY A1000 at home ! Vaporware forever !!! Hans I disclaim everything... all of the above is a figment of my employers imagination.
hadeishi@husc7.HARVARD.EDU (Mitsuharu Hadeishi) (05/24/87)
In article <8705221955.AA05310@cogsci.berkeley.edu>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: > I just got off the phone with Central Coast Software. Their hackers are able > to reliably read all tracks of a Mac disk. They are building a product > around that ability and plan to have it available within 3-4 months. This is FANTASTIC news; an Amiga Magic Sac that can read Mac disks directly would be GREAT. Copy protected software would still be a problem, however, but there are many well-behaved programs (such as Lightspeed C, etc.) which would probably run fine. I surely hope a Mac emulator can be done with relative ease; it should be possible---and QuickDraw could even conceivably be rewritten to utilize the blitter! Dream on. -Mitsu P.S. Amiga-Mac ROMs in Kickstart!?!
scotty@l5comp.UUCP (05/25/87)
In article <6938@amdahl.amdahl.com> kim@amdahl.amdahl.com (Kim DeVaughn) writes: >Uh, Bryce ... you really shouldn't be wasting the net's time and bandwidth >with this kind of thing ... I mean, afterall, this is "impossible" to do >(as we all should well know by now), and therefore any such discussions >(and, by implication, any such *PRODUCTS*) are pointless! > >Oh, and by the way, bumblebees can't fly, and the human body cannot >survive a sustained speed in excess of 32 mph, and people will never >reach the moon, and ... The Titanic was unsinkable. :-) However, unless someone out there can explain Apple's CRC routine the impossible may just remain that. :( Could it be this is the REAL reason we can't read Mac disks? I don't think so because my mailbox get's these letters telling me it can't be done for other reasons. :) The last one was: Disk pulsing isn't reliable and it's bad for the drive. Ergo you can't read Mac disks... Either pass the info to me or contact Central Coast Software. CCS isn't on the net, but they are on BIX. So you could also post it on BIX and they would get it. I don't work for CCS, but I haven't worked for any of the other firms I've helped link up with the info they require. I get no cash benifit from passing this info along. I'll get a free copy of the program, but I'll get that wether I connect them with the CRC info or not (lucky me, I get to beta test it). Just think of me as an un-reformed Eagle Scout. Also, there IS another group working on reading Mac disks as well. If the info reaches me I can pass it along to BOTH groups... Neither group wished to be placed under a time pressure, hence I hadn't used their names, but Bryce just had to take a guess and put the gun to one of them... But I had nothing to do with that and I'm NOT rolling over on the other bunch. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
kleef@ark.UUCP (05/28/87)
In article <148@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >However, unless someone can explain Apple's CRC routine the impossible >may just remain that. :( Could it be this is the REAL reason we can't read Mac >disks? I don't think so because my mailbox get's these letters telling me it >can't be done for other reasons. :) The last one was: Disk pulsing isn't >reliable and it's bad for the drive. Ergo you can't read Mac disks... > >Either pass the info to me or contact Central Coast Software. CCS isn't on the >net, but they are on BIX. So you could also post it on BIX and they would get >it. > > >Scott Turner > > This information can hardly be passed thru this sort of medium. Go read Beneath Apple ProDOS or Beneath Apple DOS (Quality Software). Both books contain detailed information on how data is stored on Apple disks. Although both concern Apple ][ disks (DOS 3.3 and ProDOS), they will prove helpful, because the Mac also uses the same diskcontroller the Apple ][ uses and maintains the same 'raw' diskformat. Cheers, P. Disclaim? Wot me disclaim?
scotty@l5comp.UUCP (Scott Turner) (05/29/87)
In article <1026@ark.cs.vu.nl> kleef@cs.vu.nl (Patrick van Kleef) writes: I'm posting this public so that others won't think the answer has been found. ie PLEASE use E-Mail to respond on this topic. I'm all for public discussion but having to clean out discussions in other newsgroups on my un*x machine (I LOVE cleaning the ST groups ;) I can see how other system admins might object to all the data flow in our newsgroup. >This information can hardly be passed thru this sort of medium. I don't see why it can't? >Go read Beneath Apple ProDOS or Beneath Apple DOS (Quality Software). >Both books contain detailed information on how data is stored >on Apple disks. Although both concern Apple ][ disks (DOS 3.3 and ProDOS), >they will prove helpful, because the Mac also uses the same >diskcontroller the Apple ][ uses and maintains the same 'raw' diskformat. I've already read both works (many moons ago). And they are both excellent books for the Apple ][ series. BUT... You are incorrect about the Mac maintaining the same raw diskformat. In addition to having 512 byte sectors (the apple ]['s use 256 byte) they also have those sector tags for storing file system recovery info in. And worst of all the Mac uses a CRC rather than the simple checksum used on the Apple ]['s. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to off wyn (nd