Writing Macintosh Floppies
#11
Everything you say about flux makes perfect sense.  Flux is flux, however, I can't ignore my observations.

To test the theory of dirty drive heads, I simply made .scp images and duplicates of other types of disks.  I've now made dozens of working copies of IBM 720K, IBM 1.44MB, and Macintosh 1.4MB disks, using both of my drives and index copy mode only.  I then tried a couple Mac 800K disks, which invariably failed.  To humor the cleaning idea, I cleaned the SD-800's heads, but the 800K disks still failed.  Surely it doesn't make sense that 800K disk don't work due to dirty heads, but all of those other formats somehow do.

Can you tell me a specific model of any drive that has been reported to work with Macintosh LD disks, or perhaps one that you have used?  I seem to have no other option than to try drives that are known to work, empirically speaking.
Reply
#12
All disk drives work with Mac format.  There is really nothing different from a flux stand point from Amiga or other formats.  If you can duplicate 720K and 1.44MB disks, then the issue is my SPLICE routine for these types of disks then.  Send me a 800K disk image copied with SPLICE (2 revs) to data @ cbmstuff.com and I can look at it.  It's likely that your disks were not commercially produced on a TRACE machine, so the tracks are not indexed and my SPLICE routine (which has to figure out the start/stop of a track) is just not working well for Mac disks.

You could take the .scp image that you create (2 revs) and run it through PCE tools to see if it says the disk data is good.  I think you can also do that with a8rawconv as well.
Reply
#13
Hi, I'm the one who experimented with Mac images a while back, and I'm afraid I simply have had zero luck copying or writing Mac 400k/800k disk using the SCP. It has been a little while since I last tried, and I have not yet tried a8rawconv.

I believe there were several different issues.

First, I never had any success simply copying/writing a direct SCP dump of any non-index aligned Macintosh disk. Each attempt resulted in at least one bad sector per tack. Similar issues with Apple II disks. I only have a few factory original Mac titles, but none of what I have was index aligned (I can see this with HxC). I was using splice mode.

Also, when dumping SCP files and decoding Mac non-index aligned disks with PCE, I have found I have needed three revolutions, and I must tell PCE to use the second revolution. Otherwise I would see some bad sectors. Logically, 2 should be enough, so there must be some limitation with PCE's decoding algorithm.

There is a method for using PCE to convert 400k or 800k IMG files (sector images) to a flux stream. However it seemed to store some bogus RPM or bitrate data. Running the results through HxC partially ironed things out, but the results would not write using a SCP. (a particular different flux writing device somehow compensates for this mess and succeeds in writing). Of course, such a manufactured flux image is index aligned.
Reply
#14
I had no problems copying some Apple 6.x system disks when I first designed SuperCard Pro, so there is nothing inheritantly wrong with the low density GCR data.  Having a single bad sector on each track makes sense because that would mean the write splice ended up somewhere within a valid sector instead of the track gap.  I know that a8rawconv can read/decode low density Mac disks as well as Apple II disks.
Reply
#15
I've emailed a disk image as requested.
Reply
#16
Thanks... I will take a look at it.
Reply




Users browsing this thread: 1 Guest(s)