Jump to content

Finally A Way To Read 400K/800K Disks Without An Old Mac

Recommended Posts

Was posted in the lounge by Gary_W ... should be here.






Finally a way to read 400/800K disks without an old Mac

by Gary_W » Fri Feb 04, 2011 5:51 pm


Title from a post I saw over at the vintage macs Google group. I thought some here would be interested. From the site:

"KryoFlux is a USB-based floppy controller designed specifically for reliability, precision, and getting low-level reads suitable for software preservation. "


And from the author I presume:

"I'd just like to add that, as of 19th January, it also supports Mac

and Linux.


Kieron "




If you check it out, let us know how it goes.



Link to post
Share on other sites

A most excellent find like this posted in the Lounge??? Sheesh.

Thank you, Mac128, for bringing this to our attention.


It looks very intriguing, however...


1) Nothing at all about dumping the contents of 400k MFS Macintosh disks is mentioned in their forum:



2) Nothing at all is mentioned about dumping the contents of copy protected disks. This is an important point of consideration, and for more than just the Macintosh platform too. I surprising amount of old 400k and 800k disks were copy protected, which is why I used CopyIIMac extensively on my compact Mac, back in the day. Therefore, it makes little sense to have one of these kits if the majority of disks you wish to archive are protected in a way that cannot "imaged" with this KryoFlux hardware kit.


3) Their forum's Search feature is dumb. Try to search for "copy protection" and it coughs up an error saying those terms are too common! No doubt it would say the same of supercalifragilisticexpialidocious, although I was to perturbed to try it. It also has one of those stupid, "you can't search more than once every several minutes because you might be a bot." Idiotic. Absolutely idiotic. Especially so when you compare with this site's search, which works in a fairly unobtrusive manner. (Thank you 68kMLA leadership for giving us user-friendly forum searching.)


All said, if it can do copy protected Mac 400k disks, I'd probably buy a kit AND spread the word atop every high hill I climb around the net. And that holds true even though I have vintage Macs which have the capability of doing that job already. It's just a neat and useful concept that I would like to support, if it can handle Macintosh 400k disks and copy protected ones.

Link to post
Share on other sites

I have a number of questions too which I posted over on the LEM Google forum to the knowledgable Kieron Wilkinson. Specifically the kryoflux site specifies DOS 400/800K disks, NOT MFS or HFS, thought I don't know why that would make a difference since they are both GCR. But, he assures me he has successfully copied 800K Macintosh disks.


Also, as I understand this application, it copies the magnetic fluxes exactly on the disk, which means it records the copy protection schemes exactly, so that they are recreated on the duplicate disk, which I would think would also include physical methods, like a hole punch (assuming the software would deal with such an anomaly). Presumably when it is capable of writing the image back to disk, it would recreate this magnetic flux exactly as on the original disk (perhaps even recreating a virtual hole), and thus behave exactly as the original disk. Would this work as a disk image? Not sure as I don't fully understand what the resulting data file is supposed to be, or whether it can be converted to a disk image. It seems primarily designed to make backup copies of disks without the original hardware, which seems sort of pointless, if the original hardware is necessary to use the resulting copy, in which case just use that. I suppose, it would be handy for exchanging these flux stream files with others and recreate the disks directly from the Internet, which if it preserved the copy protection schemes exactly would be a great way to distribute copy protected disks that Copy II disk won't duplicate, and more importantly, for relatively little money give someone with a single vintage Mac, the ability to create disks for it without investing in more vintage Mac hardware.


The good news, as posted in the lounge thread, is that one of our members CJ_Miller has a board and an SE to test it on. So hopefully, many of our questions will be answered shortly ...


My board arrived a few weeks ago. But it is shelved until write support happens. I can't exactly mount its flux streams on my SE... When I have some time I will set it up and start sorting through my box of floppy drives to test it. Archiving disks is useful but until I can write them back it is about as hopeful as cryogenically storing my body for future revival. I expect disk write capacity within 2011, sounds like it works on their test bench.

Link to post
Share on other sites

Well, if this kit means someone out there can finally copy their otherwise uncopyable Archon disk for me, I'm all for it. Archon is just one example of many software programs which I once owned, but the disk either died or was lost, and I can no longer find it on EBAY or otherwise purchase it now. More info on what prevents Archon from being copied here:




And you can see just how far back both you and I have been thinking about the topic of copy protection, from reading this AppleFritter thread:


Link to post
Share on other sites

Hi guys,


Probably I need to make a few clarifications here.


I'm going to try and image some disks tonight (GMT), just to double-check what I said on Vintage Mac, as well as try to mount in vMac. I tried to image some disks for a library ages ago, but I don't have access to that data or disks anymore. I have a couple of disks, I just need to pull them out of storage.


KryoFlux images disks at the lowest level possible out of a floppy drive. This is simply the timing between magnetic polarity changes picked up by the floppy read head (flux transition timing). This means that KryoFlux can image everything on a floppy disk. It also is built for reliability, so things like requiring precise index measurement and rotational speed timing, both of which are needed in order to reliably interpret that data, especially tricks pulled by various copy protection mechanisms.


So, since you can image anything on a disk, any copy protection can be represented. We try not to mention copy protection for probably obvious reasons. KryoFlux doesn't circumvent copy protection, it simply doesn't care about it. :)


Now, that all sounds great, but sadly, things are not so simple when you want to *use* such images.


If a disk is copy protected, you will not be able to produce a normal sector-by-sector image because obviously that image will not be able to represent the information required. So, you need an image format which can. If you have such an image format, you then either need to be able to write it back, or you need an emulator to support that image format.


So, here is the current situation with KryoFlux:


1) We save the "raw stream" captured from the disk, which can hold anything that is on it. However, this is optimised for on-the-fly transfer over USB by the device (optimised for bandwidth and simple processing), and is not exactly a good way to store images long term. One of our next tasks is to create a proper format (called DRAFT) that is more convenient for, say, an emulator to load.


2) We have a disk format (IPF), which is designed to represent the "master" disks, used by commercial duplicators at the time. This not only contains the data to be written, but "how" to write that data. Use of these disk images in emulators is basically a process of simulating the masting of the tracks as they are loaded. The down side to this is that you need to analyse the data to ensure that any copy protection is represented correctly, and that is not simple for copy protection mechanisms that we have not seen before. The analysation software that produces IPF files are also not public as they are part of a service which we supply to libraries and archives. For IPF files to be created, they will need to be sent to us at the Software Preservation Society (our pre-existing non-profit side of things - KryoFlux was in fact built primarily to solve the problems we were having).


3) We are currently working on implementing writing support. However, this will probably be limited to supporting IPF files to start with. We're starting small - since they are the master disks, and describe exactly how to write such information, they are the easiest and most reliable method. Next will probably be writing support for sector images, and then we can look at what it will take to write DRAFT files.


Now, although we hope to support writing of DRAFT files, there are fundamental problems with this method. You are effectively writing "blind". It is very similar in concept to copying VHS tapes, where each generation degrades in quality. This is obviously not good for representing digital data. There are also probably types of copy protection that cannot be written reliably this way, like perhaps weak/flaky bit protections. Nobody can get around that, hence our preference for IPF files.


Hopefully this summary of the complexities involved helps you to decide whether KryoFlux actually does what you need. It's very new, it's early days, and there is much to do yet. However, we are working on the currently missing features (writing, DRAFT). It's also not a silver bullet by any means. There are problems that everybody trying to solve these problems have to face, due to the nature of floppy disks.


Also, we are out of stock! Just last week in fact. We have ordered another production run, but this may take several weeks before more devices are on sale.


Some other points raised here I want to touch on:


1) Sorry about the search capability on the forums. It annoys me too. I'll see if we can get that sorted.

2) Physical methods such as hole punches and hard sectored disks are an unknown right now. We have no examples of such disks, and so we can't test them. We think it should be possible, but it might very well require some development support. Unfortunately, this will require somebody sending us an example disk.


Anything else you would like to know, or I have not been clear enough about, feel free to ask.


Sorry for the long post!

Link to post
Share on other sites

you would have to have a microcontroller that emulated the woz protocol and the GCR encoder/decoder, then write a driver API for it. and then add the API into basilisk/vMac that supported as well.


This brings up another question, Does the IWM have the GCR encoder/decoder onchip? so if you fed a 512byte sector, and track info to it, it encodes it into GCR to be written to disk .

Link to post
Share on other sites

I don't understand the last two posts, by Mac128 and TechKnight. From what I read from fiath in this thread, GCR doesn't matter because a normal PC edition 1.44MB floppy drive in combination with their hardware interface will copy any disk, including single sided 400k Macintosh MFS disks with copy protection. That's the way I read it. Am I wrong?

Link to post
Share on other sites

JDW didn't mean to confuse you. I was simply responding to the fact that the whole point of Kryoflux was that it used contemporary hardware and software to image vintage Mac disks, without the need for old equipment. So no, you are not wrong. GCR does not matter to the end user, however it matters great deal to Kryoflux, as it must know what kind of disk you are imaging in order to correctly format it.


I am curious how it works though. How does an HD drive head distinguish the discrete magnetic flux on tracks that are wider than the HD head is designed to read?

Link to post
Share on other sites

technight: Yes, exactly. And in fact, due to the fact that accurate floppy controller emulation was needed for systems with NEC765-like floppy controllers, we (at SPS) implemented a cycle-exact one, which is now part of our IPF library. That controller is used in many many systems, and so the effort we went to was justified. However, I don't think we have the resources to do that again, unfortunately...


What we have found in the past for other systems is, once games are available that require better emulation, it is then that the emulation is improved to support those games. There has been little need to do so thus far for Mac I would guess, but I am sure somebody will take up the task if there are games available as disk images waiting for it, and to test it with.

Link to post
Share on other sites

mac128: Hopefully I can answer your question by describing what we actually do. First, lets review the logical layers of data representation for floppy disks, which look something like this:


flux transitions -> bit cells -> encoding -> sector data -> file system


All we get out of the drive is a pulse when each flux transition occurs, as well as a signal when the index happens. We just need to very accuarately measure the time between these pulses and index signals (which we do), that timing information is transported over USB to the host PC, and then all the actual decoding is done there in software. The encoding (GCR, MFM, or whatever) and the variable track density zones on Mac disks simply don't matter at this level.


We can then do something similar to what an FDC does to decode, just in software. Now, this isn't easy of course, because if we actually just mimic what an FDC does, we would only be able decode stuff for the disks designed with that particular FDC in mind, and we would have to simulate each FDC for each system we wanted to decode. In this regard, an FDC has it easy, because they can assume a particular system-specific encoding to drive their decoding circuitry (bitcells are derived from the encoding) - but we obviously can't do that!


A "bit cell", in case you are unfamilar with the term, is basically the area in which a flux transition occurs, or does not occur. If you do not want to assume the encoding, it is not easy to be sure that a flux transition that occurs on a boundary is in one cell, rather than the adjacent cell - as the bit cell size and position float about depending on various different factors.


So, we had to find a better and more general way to do the bit cell decoding, quite unlike anything an FDC does. In fact we threw away several good algorithms before we got to the current one, because they did not quite work in all situations. Our current one we are very happy with though, and seems to be very good at reading disks that real FDC's now have trouble with.


Once we have that, decoding to sector data via GCR/MFM/FM/anything is quite simple.


Does that answer your question?


We have tons of information about this on our WIP pages over at: http://softpres.org/wip for 2009 and 2010. Having said that, they are not written very clearly, and are deeply technical.

Link to post
Share on other sites
3) Their forum's Search feature is dumb.


Use google - enter "keyword site:sitename.com"


fiath: Now that you are able to read and mount the floppy images in an emu, surely then one can image the disk using a Mac app inside the emu, save the file in a cross-platform safe archive (bin, hqx, sit etc) then transfer it to a real Mac that can write physical floppies? Or am I missing something here?

Link to post
Share on other sites

You could indeed. Perhaps I misunderstand your question, but KryoFlux can produce regular "sector-based" disk images, and that is what I did when mounting it using vMac above. So, maybe you can simply transfer and mount them on the Macintosh to write them, and so skip the emulator step? I guess it just depends on whether there is software for these older machines that support sector disk images - I am afraid I have no idea, but I would have assumed that was the case...

Link to post
Share on other sites

That sounds right. However, even though the image can be taken to an vintage Mac to write actual floppies, I am most eager to eventually be able to do it using Kryoflux hardware, without the need to maintain an intermediary Mac just to make floppies for my Pre-SuperDrive compacts.

Link to post
Share on other sites
  • 2 weeks later...

I finally just got all the pieces together and set up my Kryoflux board and software. It seems to be ready for action, but the box of drives I catalogued has not turned out so well... Many of these were field stripped from some of the many PCs which sprouted on the curb every week while I was living in the city, and have been dwelling in a tote bin for years. About 90% of them have turned out to be bad, including a few high-end ones I had high hopes for. And of the remaining few, none were good enough for archival purposes. By the weekend I will need to remove some drives from a few of my own better-kept boxen to try.


I am aiming to successfully archive and use a disk image by the end of this coming weekend.

Link to post
Share on other sites

Folks, a word of advice about floppies and drives. Don't throw away those old floppies before you are 100% sure the problem is NOT in the drive mechanism. I did this some years ago and regretted it later. I was using the internal floppy drive of my SE/30 to check my stock of old disks, some of which I had around since 1984. Most of them gave me read errors, but some worked fine. I therefore assumed that the disks were bad, so I with much pain and suffering threw them out. Over the coming weeks, I found that fewer and fewer of my floppies worked in my SE/30, even the floppies that once worked fine before. After much testing I found that it was my floppy drive heads that were the culprit. After resolving that problem, I had no read/write errors at all. So it probably was the case that I threw out many disks that were in fact just fine.


I suggest a head cleaning before you do anything. And keep in mind that if you have a bad or iffy head, a head cleaning won't solve that. Make sure your floppy drive itself is in optimal shape before you consider any disk "bad."

Link to post
Share on other sites
  • 3 months later...

My Kyroflux controller arrived yesterday (31/05/2011). I decided to get a known working FDD supplied with it, as the half dozen drives I've already got have been having problems with reading the 1.44 MS-DOS FDs. So, as soon as time permits, I'll start archiving all my A2 and Mac 3.5" floppies. I don't mind putting down the cash as a small investment that saves my machines from any undue wear and tear, and being able to archive the images directly on my QS2002.


Having all my floppies imaged, will allow me to create virtual instances of each real machine, it's software, and then only power up the real deal when I need the full retro fix.

Link to post
Share on other sites
  • 6 months later...
My Kyroflux controller arrived yesterday (31/05/2011)... as soon as time permits, I'll start archiving all my A2 and Mac 3.5" floppies.

You got your controller around June 1st 2011. It's now Dec. 22, 2011. You've had almost 7 months to tinker and test.

What has been your experience in working with 400k and 800k Mac disks, both with and without copy protection?




Will this Kyroflux kit truly allow us to image our 400k and 800k and 1.4MB floppies (even with copy protection) via USB on our modern Macs running OS X 10.7 Lion?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...