This page is a wiki. Please login or create an account to begin editing.


38 posts / 0 new
Last post
Balrog's picture
Offline
Joined: 2009 Apr 24
IMPORTANT: Disk Copy for images (RULE: always use DiskCopy 4.2!)

Please, unless absolutely necessary, always use Disk Copy 4.2, the software itself and not any later version, for floppy disks. It does not matter if they're 800K or 1.4MB.

ALL versions of Apple's Disk Copy 6.x omit important metadata from the floppy disks.

I'm referring to the software, not just the format — use of Disk Copy 6.x in "DiskCopy 4.2 mode" doesn't count — the data is still omitted.

DART will also create good images, but I don't recommend it because its compression scheme is very obscure.

For non-floppy disks, Disk Copy 6.x is fine, though Toast also works.

Comments

xy's picture
xy
Offline
Joined: 2009 Aug 7

What do you recommend for Mac OS 9.2.2? On my Mac OS 9.2.2 Disk Copy 4.2 refuses to work.

Protocol 7's picture
Offline
Joined: 2010 Aug 7

I'm pretty sure I've used it on 9.2.2 without any trouble.

xy's picture
xy
Offline
Joined: 2009 Aug 7

Okay, I'll try again. However, I fear the problem might be that my Mac does not have a built in floppy drive. I have to use an external USB floppy drive.

bertyboy's picture
Offline
Joined: 2009 Jun 14

Do you still make images from original floppies on your Mac with OS9.2.2 ? So how is it an issue ?

Protocol 7's picture
Offline
Joined: 2010 Aug 7

I use a USB floppy too. Perhaps some are more compatible than others. I just tried it on my iBook with 9.2.2 and it reads and writes fine.

Balrog's picture
Offline
Joined: 2009 Apr 24

Disk Copy 4.2 with an external USB floppy drive probably will not work. Better to use Linux and 'dd' or another "raw image" creation program (I'm not sure if one exists for OS9 though), if you're stuck with one of those. In OS X, you'd do as follows in Terminal:

df (find the device name for the disk)
diskutil umount devicename (devicename is from the list generated by df)
dd if=devicename of=file.img (create the image)
and there you go. Be careful with dd, if you specify a device as of= it will overwrite the disk (unless it's physically locked)! ALWAYS LOCK YOUR DISKS!

The reason is that Disk Copy 6.3.3 not only destroys tag information, but also zeroes unallocated sectors. Why is this a problem? Because often disks were used for multiple purposes, and interesting things can exist in this unallocated space. Even source code (yes, it's been documented).

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

@Balrog added:

The reason is that Disk Copy 6.3.3 not only destroys tag information, but also zeroes unallocated sectors.

There is a preference setting in Disk Copy's Preferences: "Zero Block" (on/off). Since turning this off when copying floppies - and also making certain to choose the 1.4MB or 800K floppy setting - not 1440 K or 800 K (partition size) it always defaults to, I seem to get fairly accurate copies. I could be wrong though, so perhaps you can confirm?

BootSector's picture
Offline
Joined: 2018 Feb 18

So, I've just performed an experiment with Disk Copy 4.2 and Disk Copy 6.3.3. This was done using a PowerBook 190 running System 7.5.2.

First, I zeroed out and reformatted a 1.40 MB Floppy Disk. On this disk I wrote two different text files both containing their own short message. I also wrote some data directly to unused space at 0xA0000 on the disk using a hex editor.

Second, I created the following images:

Raw image using WinImage 9.00 (USB Floppy Drive)
Disk Copy 4.2 using Disk Copy 4.2
Disk Copy 4.2 (1.4 MB Floppy) using Disk Copy 6.3.3 (Zero Sectors option enabled)
Disk Copy 4.2 (1.4 MB Floppy) using Disk Copy 6.3.3 (Zero Sectors option disabled)
Disk Copy Read-Only Compressed (1.4 MB Floppy) using Disk Copy 6.3.3 (Zero Sectors options disabled)

The raw sector dump (after removing any disk copy file headers) across the first four images was identical. I got the same exact image using either version of Disk Copy and the zero sectors option seems to be ignored either way. The image contained the data from the deleted text file and the data I manually hacked in all three.

The data fork of the two Disk Copy 6.3.3 images were binary identical. The Disk Copy 4.2 only differed from the 6.3.3 ones by a single byte located at 0x51 in the Disk Copy header. Seems 4.2 sets the bit which indicates the 1.4 MB disk are double sided whereas 6.3.3 doesn't set this bit.

The other interesting thing that I noticed was that image created by the Disk Copy 4.2 program didn't include any tags data. I don't know if this is because it never includes the tags for the high density disks, it's because of something that I'm personally doing, or if it's because of the specific hardware I'm using. 4.2 does write the tags when I image an 800K disk though.

Finally, using the "Convert" function of Disk Copy 6.3.3, I created a Disk Copy 4.2 image from the compressed image. As expected the previously compressed image was zeroed-out in the deleted file and hacked data sectors but otherwise the raw image was identical to the other four.

So, the result of my analysis here seems to indicate that there's no advantage at all to imaging high density disks using 4.2 over 6.3.3. As long as you use Disk Copy 4.2 format and set it to 1.4 MB Floppy Mode (as opposed to 1440 MB Partition Size) you get the same image you would have gotten had you used the earlier version of the software.

I assume that the same would hold for 800K (or even 400K) disks as well except of course for the missing tag data which 4.2 does generate and 6.3.3 does not. I'd like to repeat this experiment with a 800K disk to confirm but I don't currently have a blank one or know where I could get one. I'll take a look through my collection of software published on 800K disks and see if I can find one that has some unused sectors with data.

I welcome any feedback and criticisms on my approach.

Thanks!

SwedeBear's picture
Offline
Joined: 2009 Apr 18

•Protocol 7: what make/model is the drive?

Protocol 7's picture
Offline
Joined: 2010 Aug 7

It's a combined floppy and card reader. Floppy drive just shows up as "Mitsumi USB FDD", there's no model number.

Balrog's picture
Offline
Joined: 2009 Apr 24

USB floppy drives will never work with Disk Copy 4.2. It's only designed to work with the IWM/SWIM interface in Old World Macs.

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

@Balrog notes:

USB floppy drives will never work with Disk Copy 4.2. It's only designed to work with the IWM/SWIM interface in Old World Macs.

Interesting. Disk Copy 4.2 is what does work with my USB floppy drive under Basilisk II on Windows. Whereas Disk Copy 6.3.x fails with a -39 unexpected EOD error. - Disk Copy 4.2 (and likely the B2 emulation) is a winner here Smile

Have yet to try the drive on my QuickSilver - will probably do so shortly. The drive is a TEAC external USB floppy drive. I expect it will fail on the New World hardware, but will check.

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

@MikeTomTom previous mused:

Have yet to try the drive on my QuickSilver - will probably do so shortly. The drive is a TEAC external USB floppy drive. I expect it will fail on the New World hardware, but will check.

Yes. This USB drive works well on the QuickSilver. Both Disk Copy 4.2 and 6.3 make byte perfect copies from floppy disk media mounted in the USB drive to Disk Copy 4.2 format image files. However, it is only useful for imaging 1.4MB media. My Teac USB drive does not support mounting 800K or 400K media.

Back to the Centris 660AV for me for serious data copying Smile

SwedeBear's picture
Offline
Joined: 2009 Apr 18

How would it work under emulation? There´s a way to boot from a (real) (USB-) floppy in BasiliskII and to some extent also manipulate a floppy in a (real) (USB-) floppy in SheepShaver, so could it be made with Disk Copy 4.2 under emulation?

IIGS_User's picture
Offline
Joined: 2009 Apr 8

How would it work under emulation?

This would be my question, too. Is it possible to create newly images (not based on real floppies) using 4.2?

I'll take a look to DiskCharmer, mentioned by Balrog.

Balrog's picture
Offline
Joined: 2009 Apr 24

There isn't any need to, if you use a "raw" imaging utility like dd in Linux/OS X or something similar in Windows. Zip it immediately afterwards. I'll test a few utilities and respond with results.

Vitoarc's picture
Offline
Joined: 2010 Aug 15

SweedeBear if you know some trick to get a USB floppy to be recognized in Basiliskll please share it.

The official word that I've seen from Emaculation is that it's not possible.

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

@Vitoarc asked:

SweedeBear if you know some trick to get a USB floppy to be recognized in Basiliskll please share it. - The official word that I've seen from Emaculation is that it's not possible.

Well, I know how I use a USB floppy disk drive in Basilisk II. Ironically perhaps, because I run an earlier Basilisk II port on a Windows OS!

Of the various Basilisk II's out there, I only use the now old and no longer developed "Lauri Pesonen" Windows final port 142 from 2001 in preference to newer ports. Why?:

a). It can read/write/boot floppy media via any floppy disk drive including USB - Caveat; only 1.4MB media support, a hardware limitation of Windows (and external USB) f/disk drives.

b). SCSI support, can mount read/write/boot actual SCSI HFS formatted drives (including Iomega zip). Requires SCSI hardware controllers on the Windows side tho'.

c). Full TCP/IP ethernet and AppleTalk over TCP/IP support. Can set a fixed IP address for the emulator in your Mac OS's Control Panels if desired.

d). Excellent keyboard re-mapping at hand.

Anyway I digress. Perhaps that official "not possible" you read in Emaculation could be rephrased a little tho' Wink

Balrog's picture
Offline
Joined: 2009 Apr 24

Disk Charmer is also good.

EDIT: Yes, this one does create proper images.

Vitoarc's picture
Offline
Joined: 2010 Aug 15

Perhaps that official "not possible" you read in Emaculation could be rephrased a little tho'

Here's the thread: http://www.emaculation.com/forum/viewtopic.php?t=5662&sid=9fcc7d54e9b586...

But there is a way to get it working in Windows, as you've found, and now I know... Smile

http://www.emaculation.com/forum/viewtopic.php?t=5853&sid=e4a61ac48bd2cc...

By the way Mike. I'd really appreciate it, if it's possible, if you could please upload Virex 6x so that it can be used along with the latest definitions (through 2007 I believe was the last update).

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

@Vitoarc:

there is a way to get it working in Windows, as you've found

Yes, though in that last forum link there was no mention of which Basilisk II port they were using. With the Lauri Pesonen 142 port it seems to be even easier than mentioned in those descriptions. Map whatever Windows drive numbers you want to use in the B2 Gui and tell it to detect media when inserted, then forget about it. - I dimly recall that I needed to install ASPI drivers when I used this B2 under Windows 98, but haven't needed these since Win 2K - XP - Haven't run the Lauri Pesonen port under Vista or Win 7 so don't know if it still works OK under those OS versions.

I'll put up the Virex software soon. Its version 6.1 - That last def file thats still available is for 6.2 but it works OK with 6.1, some (non critical) function has to be turned off in 6.1 to stop the alert messages.

Balrog's picture
Offline
Joined: 2009 Apr 24

If you look at the data in a hex editor, unallocated blocks are turned into blocks of zeroes. This isn't what we want -- we want that data to be preserved.

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

@Balrog: Yes I understand this.
What I want to know is if you turn off the "Zero Block" setting in Disk Copy 6.3 does it not stop zeroing blocks of data?

I have tested this in Disk Copy 4.2 and Disk Copy 6.3 (with Zero Block turned off); saved disk image files in Disk Copy 4.2 format using both programs by copying from mounted floppy disks.
I compared the resulting image files in HexEdit and found no differences in either. That is, I cannot detect Disk Copy 6.3 writing zeros (that aren't already present) to data blocks with that preference setting turned off. MD5sums and CRCsums are the same in both types too.

Perhaps you have found otherwise. Or I'm still looking at the wrong thing.

SwedeBear's picture
Offline
Joined: 2009 Apr 18

@Vitoarc: as MikeTomTom says, the limit in which media lays in the device. I can boot BasiliskII from a floppy in my USB Y-E DATA FlashBuster, though this: http://forumbilder.se/show.aspx?iid=9a6201083456Afa79 shows the importance of knowing which machines are supported…

Here´s also a short instruction on the procedure under OS X: http://www.emaculation.com/forum/viewtopic.php?t=6245&highlight=usb+andf...
and a longer, the original also under OS X: http://www.emaculation.com/forum/viewtopic.php?t=5844&highlight=usb+andf...

IIRC you could also boot a SCSI device with an ID. I´ll dig out one 'bread chest' to check this when time permits. Alas this leaves emulation out when it comes to 800/400 kB. Unless you´re a happy owner of a 'CatWeasel'[sp?] or a LC (me). Smile

Balrog's picture
Offline
Joined: 2009 Apr 24

@MikeTomTom: I'll look into this. Even so, for 400 and 800K disks always use Disk Copy 4.2 (it stores tags which most other utilities don't).

SwedeBear's picture
Offline
Joined: 2009 Apr 18

…and (can´t resist it) here´s Sheepshaver with a mounted floppy from my USB floppy drive:
http://www.ladda-upp.com/bilder/41038/ss-floppy-aware

Edit:
For the OS X user; there´s a vital difference between Tiger and Leopard when it comes to mount/dismount and control a volume. Basilisk is not affected in the same way as Sheepshaver due to differences in the code.

Virtual PC users will also be aware of this; under Leopard there´s no longer any access to real CD-ROM or floppy because of changes between Tiger and Leopard.

Under SL I have no idea.

Protocol 7's picture
Offline
Joined: 2010 Aug 7

As I mentioned earlier, I can read and write floppies just fine with Disk Copy 4.2 and a USB floppy drive. So it does appear to work.

xy's picture
xy
Offline
Joined: 2009 Aug 7

I can confirm Mike Tom Tom's test: TEAC external USB drive works for 1.4 MB disk images from real floppys' (file extension: .image) on a real Mac (Powerbook G3 Lombard).

I will also test your question, IIGS User (new images). Cannot test emulator, though, as I don't use one.

I can tell you so much already: Disk Copy 4.2 only works if the external drive is plugged in (no matter with or without a floppy). If not, the program refuses to work.

Balrog's picture
Offline
Joined: 2009 Apr 24

@IIGS_User:

If you're creating disk images not based on floppies, use any tool: there's no data which would be lost, to begin with. Disk Copy 6.x is fine for this purpose, as it is for imaging hard drives.

IIGS_User's picture
Offline
Joined: 2009 Apr 8

If you're creating disk images not based on floppies, use any tool: there's no data which would be lost, to begin with. Disk Copy 6.x is fine for this purpose, as it is for imaging hard drives.

Balrog, thanks for further explanation. Smile

xy's picture
xy
Offline
Joined: 2009 Aug 7

Disk Copy 4.2 does not seem to be able to create disk images out of nothing. It only seems to be able to copy real disks or disk images.

Vitoarc's picture
Offline
Joined: 2010 Aug 15

It's too bad that "Disk Copy 4.2" was not named "Floppy Disk Copy 4.2" because that's it's main function, to work with floppies. It performs this duty well.

The name "Disk Copy 6.3.3" is more generic, and the name is appropriate in my opinion since it performs other functions besides copying floppies.

The nomenclature has been a source of confusion for so many, for so long. Smile

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Vitoarc mentioned:

It's too bad that "Disk Copy 4.2" was not named "Floppy Disk Copy 4.2" because that's it's main function, to work with floppies. It performs this duty well.
[...]
The nomenclature has been a source of confusion for so many, for so long.

If you look at its full name (on the DC 4.2 Spashscreen) you'll see its named:
Disk Copy 3.5" Floppy Disk Duplicator, v4.2

And in DC 4.2's main UI its name changes again, to:
Apple 3.5" Disk Duplicator, v4.2

Perhaps this could've been named Disk Duplicator instead... Talk about confused Wink

Say Vito; You about?

Balrog's picture
Offline
Joined: 2009 Apr 24

@IIGS_User:

Always mark such images as not from original media, to reduce confusion.

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Remember folks..

  Please, unless absolutely necessary always use Disk Copy 4.2, - the software itself and not any later version, for floppy disks. It does not matter if they're 800K or 1.4MB.

This is perhaps the most important consideration before archiving Mac floppy disks, when uploading them to the MG.

If you can; Please make a habit of it.

BootSector's picture
Offline
Joined: 2018 Feb 18

Hi MikeTomTom,

I completely understand the value of not zeroing the unallocated sectors. No argument here.

Can you explain the value of the tags data? The thread repeatedly says the tags are important but I don't see anywhere that says why.

For one, PC imaging utilities make perfectly valid images of DOS/Windows disks without any similar concept. For two, most or all of the Mac emulators mount and work perfectly well with an image of just the raw sector dumps. Mini vMac will read the DC42 format but, I think, it ignores the tags.

https://wiki.68kmla.org/DiskCopy_4.2_format_specification

Looking at the file format specification it seems like the tags don't describe the physical media itself but really just the file system. Since it's describing the data I don't see why there wouldn't be a way to just generate that information later from the raw dump if it was really needed for some reason. So, if you have a good clean dump of every unmodified sector it seems like the tags really don't have a lot of value.

What am I missing?

Thanks!

MikeTomTom's picture
Offline
Joined: 2009 Dec 7

Hello BootSector.

Balrog in his 2nd post above, last paragraph, alludes to other potential uses of floppy tag data.

My interest tho' is solely preservation of the entire original floppy media whenever possible. So as far as my concerns go, you aren't missing much Wink

As far as getting "information later from the raw dump if it was really needed for some reason" goes:

This still depends on there being a floppy disk drive at some random time in the future, a computer that can use it, plus a valid floppy disk to raw dump. Even now I don't know if it would be possible for example to use dd on 400k & 800k Macintosh media on non classic hardware, or more recent classic hardware with a USB floppy drive that can only read/write 720k and 1.4MB media.

The beginning of this thread now goes back almost 8 years. It's intent at the time I believe was (and still is), aimed at those who possessed classic Macintosh hardware with built-in floppy disk drives and had collections of original Mac floppy media to archive. That is, archiving floppy media under those conditions, Disk Copy 4.2 is the best option.