greaseweazle
greaseweazle copied to clipboard
Support Mac format decode
following up from the recent facebook thrread: https://www.facebook.com/groups/greaseweazle/2750806445004959/?comment_id=2750883304997273&reply_comment_id=2752710231481247¬if_id=1581587463243708¬if_t=group_comment
i have been trying to dump some macintosh floppy disks with an f7 greaseweasle:
the first is a 400k mfs disk with a bootable copy of system 5, this is not a factory copied disk, i made a copy of the original using the macintosh native disk imager, Diskcopy4.2
the second disk is an 800k HFS floppy formatted on a real macintosh classic, and approximately half filled with random program files.
i am sure that the disks are mfs and HFS respectively because the macintosh system utility "disk first aid" can verify the hfs disk, and refuses to verify the mfs disk complaining that it is not an HFS disk.
i have confirmed the disks as working on a 1990 macintosh classic.
with my greaseweasle f7 i was able to copy and write a 1.44mb mac hfs disk which then sucessfully booted the macintosh, so i can be fairly certain that my greaseweasle is ok, and my drive is functioning normally.
after initailly trying to dump and write the disks with the greaseweasle without sucesses, it was suggested that i try some different drives, because there is some evidence to suggest that some PC floppy drives are unable to read these disks.
i have dumped the disks using the following drives:
two pc floppy drives, two amiga drives, (these drives might not be in excellent condition)
files too big to upload to github so link to google drive: https://drive.google.com/open?id=1mZ2rfp9uUsUztSIU5kN5Z7xDuQiCdZgS
ensoniq mirage drive (400k single sided): 800k mac disk
pc HD drive no.2 : 800k mac disk
pc hd drive no.1 : 800k mac disk
amiga 800k drive no.2 : 800k mac disk
amiga 800k drive no.1 : 800k mac disk
It looks to me like the drives don't like the higher angular bit densities on the outer tracks (note they're not really linearly more dense -- that's the point of the Mac CLV drive adjusting spin RPM).
So for example none of the drives see anything but randomness on tracks 0-15: That's the slowest RPM zone and thus has the shortest bit timings when read by a standard 300RPM drive. Most drives do better tracks 16-31 (but one still has no luck)... Things tend to get better as you move inward to slower bit timings.
This doesn't really match behaviour described on Kryoflux forums however. There it is suggested the slower bit timings are the main problem, as on some drives the AGC (Auto Gain Correction) kicks in and creates randomness.
Are the PC drives you used HD drives?
i updated the comment with the images to show which is which, github doesn't show filenames for images...
yes the pc drives were more recent hd drives without any jumpers.
i have some akai samplers that have older pc drives that still have all the jumpers, as opposed to the cost reduced pc drives. maybe i ì should try one of those too.
i have also assembled another greaseweasle perhaps i should try that too, i can't see why this would be caused by a faulty greaseweasle, but it wouldn't hurt to rule it out.
would it be more helpfull to test with a disk that is full of lorem ipsum text? or formatted but empty? both? that disk just had some random program files thrown onto it.
I've ordered some Macintosh disks off Ebay. Hopefully they are GCR 400k or 800k disks. Might make sense to wait for me to investigate those.
I received my disks, and they are indeed GCR 800k. On my default dump drive (NEC FD1231M) I see the exact same behaviour in the HxC analyser (cylinders 0-15 are random). However I'm now not sure I 100% believe HxC, and I may need to graph some of these tracks myself. Watch this space.
Here's a plot of track 0 (three revolutions) in gnuplot. y-axis is time (us), x-axis is flux number:
And here is the HxC plot of that track:
Do they look similar? Not really. So HxC is cooking[*] the input data even on track view. Worth remembering!
[*] At a guess, we see the bitcell timings after conversion to bitcells. Effectively the output of the synchronisation PLL. If the PLL isn't locked on, I guess this is what HxC's implementation of it looks like.
I had a quick look at track 0 of your dumps of mac800khfs again. All look plausible actually, except PC drive 2 (and PC drive 1 isn't super great either). But I'd now be much more confident that a replacement PC drive (after all, both of yours are the same model) would work fine. :)
I'm sorry, I am confused. What is the verdict? Are 400K and 800K HFS readable with Greaseweazle, but only with certain model drives? How might I go about determining which drives to use? Sorry if I'm slow on comprehending. Am very excited to see that these older discs will be readable.
On Sat, Feb 29, 2020 at 9:38 AM Keir Fraser [email protected] wrote:
I had a quick look at track 0 of your dumps of mac800khfs again. All look plausible actually, except PC drive 2 (and PC drive 1 isn't super great either). But I'd now be much more confident that a replacement PC drive (after all, both of yours are the same model) would work fine. :)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/keirf/Greaseweazle/issues/19?email_source=notifications&email_token=AA7PLVY4LWP2COL3EMXTRGDRFEVX5A5CNFSM4KVZ7N4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENL5CHY#issuecomment-592957727, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7PLV4XZK2FKPTIQJCUSTTRFEVX5ANCNFSM4KVZ7N4A .
-- David C. Sutherland | (310) 729-6411 (c) | Lindale, Texas
fantastic, i have 2 new* drives, i will dump the same disk again.
- more hd pc drives from the fleamarket, maybe i need to clean the heads of some of these drives. this is very good news.
there are historical solutions for reading GCR disks on Atari St and maybe also Amiga (an atari program called macdisk is available on the Spectre GC website, which supposedly doesn't need the spectre GCR hardware), i have only heard talk of the amiga solution.
I'm sorry, I am confused. What is the verdict? Are 400K and 800K HFS readable with Greaseweazle, but only with certain model drives? How might I go about determining which drives to use? Sorry if I'm slow on comprehending. Am very excited to see that these older discs will be readable. …
it's HxC that's not interpreting the data properly, any regular PC drive in good condition should work. kryoflux users have found that some drives are not capable of reading GCR floppies, but that's most probably not the problem we are having here. writing images is not yet solved though.
I had a quick look at track 0 of your dumps of mac800khfs again. All look plausible actually, except PC drive 2 (and PC drive 1 isn't super great either). But I'd now be much more confident that a replacement PC drive (after all, both of yours are the same model) would work fine. :)
the pc drives are different models, i should really document them. but the amiga drives are identical (and in horrible condition).
What we really need is full decode (and re-generation of raw track data) in GW. And this ticket can remain open to track that. I expect it will not be hard to find compatible drives for dumping: probably the majority of drives will work ok.
posting some relevant links(i'm sure you have seen most of this already keir):
ciderpress apple II and mac hfs disk converter, also has a disk analyser (bsd licence) the disk analyser: Disk Viewer - Examine disk images as 512-byte blocks, 256-byte sectors or raw nibblized tracks. Open and follow individual files and embedded sub-volumes. Examine blocks on CF cards and other Windows volumes. https://a2ciderpress.com/index.htm
writing mac disk images using kryoflux(somebody posted a disk converter utility): https://forum.kryoflux.com/viewtopic.php?f=10&t=1090&sid=5638a551d567d84419fd22e497883279&start=10
info about mfs: seems to be an overview of whats in "inside macintosh": https://www.macgui.com/news/article.php?t=482
inside macintosh volume 2 1984 developer documentation (information about how data is stored on disk in mfs volumes starts on page230): https://archive.org/details/bitsavers_applemacIn84_23664048/page/n229/mode/2up
For reference I leave link to dump of one of my 800k Mac disks on an NEC FD1231M and a Teac FD-235HF. https://drive.google.com/open?id=1AjinpN8Ll7CWoekE9Mruk7cq-lMfkLib
Also note the relevance to #29, as the inner-most tracks have bit times approx 4, 8, 12us. The latter of which has caused problems on some drives in custom Amiga sync words. If we plot a Mac inner track from my NEC drive, we do indeed see some random fluxes. They appear to vary from read to read so it may be possible to recover. Fortunately the Teac dump is good.
Note that both drives are fine with the outermost tracks with the short bitcells (approx 2.7, 5.4, 8.1us).
Would it be possible to have a characterization test that writes a pattern to a disk and reads it back, to determine if a drive is suitable for reading Mac and similar disks?
I've thought about that and yes it's a good idea! A drive characterisation test will happen, I think :)
Applesauce has such a thing for testing the performance of the MC3470 data separator on Disk II drives. I'm guessing this will be similar in function.
I have other things to test too (#29). So it's a sound plan.
There is a significant quantity of documentation on the Mac floppy design here: https://archive.org/details/SWIMDesignDocs
Ideally it would be nice to support hooking up an Apple drive, but the interface is completely different and the Applesauce already does it.
Looks like FluxEngine just added this, but the license is different.
It could still be useful for testing disk images against vs GreaseWeazle.
I think fluxengine has had mac support for a while.