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
#17
For the record, is writing unaligned spliced images actually supposed to work?
Reply
#18
Yes, it works fine for Amiga, PC, Atari ST, and Atari 400/800 disks... likely others as well. The SPLICE routine works by locating the first non-valid bitcell length AFTER a full revolution of data, and using that as the stopping point for the write.
Reply
#19
Ok, then I wonder what is going on here: http://s000.tinyupload.com/?file_id=3400...7457917531

This include a sample Macintosh 3.5" 800k disk I dumped (dump checks out OK), and then a dump of a copy made with the SCP. The copy shows at least one bad sector per track.

To stay on topic I used a Mac disk, but I have been trying Apple II disks with similar results. Testinig shows at least one bad sector per track.

Also finally got around to trying a8rawconv only to find it won't encode/write Apple II disk images from 140k DSK files, yet will write for every other platform.
Reply
#20
I'm curious to know whether the problem here has been determined. My understanding from post #12 above is that the SCP software would have to be updated with an improved splice routine. Did my disk image help to reveal what the problem might be? I'm happy provide any assistance in this process, as I have several 800K disks available.
Reply




Users browsing this thread: 2 Guest(s)