KryoFlux Support Forums

There were some questions on classic Mac forums about KryoFlux support for Mac 400K/800K disks, the ones with an MFS or HFS file system, and whether what we term "Apple DOS 400K/800K" sector images is the same format. These disks are quite different to most floppy systems because the have a "zoned CAV" system, where different parts of the disk are written with slightly different density - Apple's attempt at squeezing more onto a disk.

We assumed KryoFlux supported the Mac disks, but it's always nice to be able to say definitely this is the case. Since this doesn't seemed to have been mentioned on this forum, I thought I would post our investigation here for anyone who might be interested.

So I just imaged three Mac 800K disks to "Apple 400K/800K" sector images, of 819200 bytes each, which all mounted perfectly in the Mini vMac emulator, and here are some screenshots of each one.

Awesome. Would love to read the thread. Where was that?

There are two:
http://groups.google.com/group/vintage- ... f04a9c9d43
http://68kmla.org/forums/viewtopic.php?f=7&t=15294

Nice to know that it works. I dumped and submitted a couple of early Mac games, but they don't work from standard images due to protection (I think).

Great, thanks. I'm very interested in Mac stuff, so hopefully we can get to that stuff at some point.

Mac floppy disk formats are interesting. The IWM chip allows some level of raw access to the floppy disk, so you'll probably need to save raw GCR data for such copy-protected disks.

Even without copy protection, there's still something to preserve with 400K/800K images: these disks have "tags," which are mandatory for Lisa machines and sometimes used with Macs as well. Take a look at http://68kmla.org/wiki/index.php?title= ... cification for some detailed information on the DiskCopy 4.2 image format which we currently use for "regular" disks.

Currently we use DiskCopy 4.2 for regular 400K/800K disks. This preserves data and tags, but does not preserve stuff like order of tracks or invalid GCR data which some games use for copy protection.

There's a web page with a ton of information on Apple GCR (the physical format, as opposed to logical), but it's all in French. If any of you are interested, see http://www.hackzapple.com/DISKII/DISKIITECH.HTM . Unfortunately I don't know French.
Note that the on-disk GCR encoding for the Apple II isn't very different from Macintosh. Tags are a Lisa/Macintosh specific thing, however (Apple II disks just have 0 in their tag fields, unless weird copy protection that uses raw reading is used).

Hope this helps.

All of those are supported already: in order to decode a disk from flux transitions - regardless of format - you have to pretty much simulate what the hardware/firmware/software does on the target platform.
A sector on those decodes to 524 bytes, but only 512 bytes are actually stored in a sector dump - since there is nowhere to store the rest. With a suitable format the rest could be stored as well.

For non-analysed copy-protected disks DRAFT should be fine: ie personal backup, whether it's duplicated, error free and unmodified is unknown.
For fully analysed copy-protected disks they should be supported eventually by our analyser (CTA) and IPF files will be issued. For those duplication, being error free and unmodified is known.
Obviously, the latter being a lot of work, it will only happen if there is enough interest in the authentic and verified preservation of the platform's software.

IFW wrote:A sector on those decodes to 524 bytes, but only 512 bytes are actually stored in a sector dump - since there is nowhere to store the rest. With a suitable format the rest could be stored as well.

Please take a look at the DiskCopy 4.2 format spec that I linked above. The 12 bytes per sector are the "tag," and this is a sort-of standard format (probably as standard as you can get) that includes this data. mini vMac supports such images. The format doesn't require a resource fork, but DiskCopy 4.2 on a Mac won't recognize images if they don't have the type and creator code set. mini vMac doesn't care about this and just loads them.

Concerning mini vMac, you might have to compile it by hand for full tags support. I believe the official builds lack it, and it is a compile-time option.

IFW wrote:Obviously, the latter being a lot of work, it will only happen if there is enough interest in the authentic and verified preservation of the platform's software.

Good luck with it. Luckily Mac copy protection wasn't that intense. The worst that was out there was probably synchronized tracks — and all this can be duplicated with fast enough sampling.

Is there any information on your site about how this "verification" works exactly? I don't exactly want to send my disks to someone, if I can get all the equipment myself...

Also in case you're interested, there's a utility called Copy ][ Mac which does bit copies of copy-protected disks. Unfortunately it can't do images. If you want it, I'll link it here — requires an early 68K Mac though! (Mac Plus, SE, II, older Quadras/Performas).

Also, note that 1.44MB Macintosh disks are just standard MFM format. There's nothing special about them otherwise, and the Mac floppy chip doesn't allow raw access either. Some companies did implement bad sector based copy protection, though.

Most disks were professionally duplicated and used encoding that directly or indirectly could be detected and/or read by the target platform, but normally not written.

You do not have to send any disks if you have a KryoFlux device.
You can create images with KryoFlux right now, but for preservation we'll need the stream files produced (by KryoFlux), which is basically the flux transitions recorded.

As of verifying a disk:
- Each format must be fully understood. Note, that you can create any kind of format for duplication using FreeForm. We can do the same in CTA.
- Each disk has to be verified against its format(s). Most copy protected disks have several formats used on the same disk.
- A method must be devised that would verify whether it's modified and duplicated.

Just to clarify: we have done so for over 3600 games already, for Spectrum+3, Atari ST, Amstrad CPC and Amiga and more to come.
However since it's a huge amount of work, we do need the support of the respective community to make it happen.
Normally, before a platform gets supported we collect hundreds of images created using our tools from the target platform, but of course you could donate towards obtaning games, development etc if dumping disks is not possible.

KryoFlux is a (semi) commercial venture mostly made because when we came up with the hardware for preservation people asked us to produce the hardware ready made; originally users were expected to DIY, but it turned out to be unfeasable for the most.

Softpres is where all it comes from. On our Softpres site I'd recommend reading all the WIP, Wiki etc entries, they contain tons of information. It's a huge amount of text by now (might be several MB) in its entirity!
This is the Softpres site:
http://www.softpres.org