Support Mac format decode about greaseweazle HOT 21 CLOSED

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

from greaseweazle.

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?

from greaseweazle.

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.

from greaseweazle.

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.

from greaseweazle.

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.

from greaseweazle.

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:

from greaseweazle.

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.

from greaseweazle.

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. :)

from greaseweazle.

from greaseweazle.

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.

from greaseweazle.

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).

from greaseweazle.

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.

from greaseweazle.

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

from greaseweazle.

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).

from greaseweazle.

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?

from greaseweazle.

I've thought about that and yes it's a good idea! A drive characterisation test will happen, I think :)

from greaseweazle.

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.

from greaseweazle.

I have other things to test too (#29). So it's a sound plan.

from greaseweazle.

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.

from greaseweazle.

Looks like FluxEngine just added this, but the license is different.

It could still be useful for testing disk images against vs GreaseWeazle.

from greaseweazle.

I think fluxengine has had mac support for a while.

from greaseweazle.