-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Finally A Way To Read 400K/800K Disks Without An Old Mac
- Thread starter Mac128
- Start date
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:
http://forum.kryoflux.com/
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.
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:
http://forum.kryoflux.com/
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.
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 ...
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 ...
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:
http://www.macintoshgarden.org/forum/archon-anybody#comment-10192
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:
http://www.applefritter.com/node/21551
http://www.macintoshgarden.org/forum/archon-anybody#comment-10192
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:
http://www.applefritter.com/node/21551
And this board has come up before ... It just looks like now it's fully functional with OS X & Linux.
viewtopic.php?f=16&t=12852
viewtopic.php?f=16&t=12852
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!
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!
I have just imaged three Mac disks I have. They are all Mac 800K disks, imaged to 819200 byte sector images by KryoFlux and here are some screenshots of them mounted in vMac:
http://kryoflux.com/pics/Mac.png
http://kryoflux.com/pics/CDROM-Toolkit.png
http://kryoflux.com/pics/IomegaZIP.png
http://kryoflux.com/pics/Mac.png
http://kryoflux.com/pics/CDROM-Toolkit.png
http://kryoflux.com/pics/IomegaZIP.png
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 .
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 .
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?
yes, but i kinda hijacked the thread. lol.
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?
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?
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.
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.
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.
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.
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?
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...
Similar threads
