Best way to archive vintage Mac floppies & CD's to images

[balrog]

Again, though, if you're interested in flux imaging you'd be able to read the same data with a PC floppy drive.

 Technically speaking a controller that wanted to be able to read *any* Macintosh floppy would need to be capable of sampling variable data rates anyway because with the original Mac 128/512k's 400k floppy drive it was indeed possible to control the rotation speed of the drive by replacing the built-in floppy driver with a custom one and changing the PWM signal. Software that leveraged that for copy protection actually comprises a significant chunk of the small collection of software that only works on the "64k ROM" Macs verses the later ones; It's not the ROM, it's that the 800k and later drives ignore the PWM signal and simply rotate at different fixed speeds depending on what track they're on.

Not being able to vary the disk drive speed causes issues where the data separator / transition detector circuitry in the floppy drive has trouble detecting the transitions correctly. This makes it more difficult to read and especially write Macintosh GCR disks with a PC floppy drive — I believe there is a thread somewhere on the Kryoflux forum about this. Some drives work better than others for this.

The best solution is to use the type of drive that the disk was written with — and a 3.5" Sony 1.44MB drive for a Macintosh fits the bill.

 

[balrog]

That makes me think it is measuring the rotational speed of the devices, as Mac floppies can be variable speed, so that might be necessary to develop a good flux image. 

The rotational speed can be measured from the flux data, but the tracks can't be aligned as there is no absolute reference to go by. As the built-in tachometer output on the Sony 3.5" drive isn't that good, the index sensor is necessary to capture this data. But as referenced above — the index sensor is optional, as most disks do not depend on track alignment. It still is nice to have.

 

[Gorgonops]

data separator / transition detector circuitry in the floppy drive

So far as I'm aware data separators live in the controller, not on the floppy drive, with standard Shugart interface drives. I think "citation needed" applies here.

Way back in 1978 Commodore was building floppy controllers that used variable data rates on fixed speed spindles by varying the clocking of the read/write circuitry, something that's trivially done with PLLs today.

 

[balrog]

So far as I'm aware data separators live in the controller, not on the floppy drive, with standard Shugart interface drives. I think "citation needed" applies here.

 Way back in 1978 Commodore was building floppy drives that used variable data rates on fixed speed spindles by varying the clocking of the read/write circuitry, something that's trivially done with PLLs today.

Sorry — I'm referring to the component that takes the analog magnetic data off the disk, as read by the head amp, and converts it to a digital "0" or "1".

 

[Gorgonops]

Sorry — I'm referring to the component that takes the analog magnetic data off the disk, as read by the head amp, and converts it to a digital "0" or "1".

I suppose it's possible that some modern drives have implemented some sort of clocking window on the read circuitry to act as a pre-separator and improve reliability specifically for PC controller bitrates, but so far as I'm aware it's not a standard feature. It seems like plenty of people *have* succeeded in reading said disks with KryoFluxes (and SuperCard Pros, Catweasels, Copy II PC Option Boards...) so, yeah, I guess if you're really unlucky you'll have a problem?

 

[Gorgonops]

The Mac 3.5" drive has index sensing, but it was found to be subpar:

One other note: I was about to object that Macintosh floppy drives don't present an index signal on their interface so far as I know, but reading this it sounds like maybe the developer is using the "Tach" signal? I wonder if he's aware of the fact that the Tach signal only outputs valid data on 400k drives. (It's the necessary counterpart to the PWM signal for active speed control on the host side.) Here's a Citation.

If he's not looking at "tach", well, I have no idea. Looking in "Inside Macintosh" I see absolutely no reference to Index being available as one of the items available on the status output register. Page III-36:

Explanations of the Disk Registers

The information written to or read from the various disk registers can be interpreted as follows:

• The DIRTN signal sets the direction of subsequent head stepping: 0 causes steps to go toward the inside track (track 79), 1 causes them to go toward the outside track (track 0).

• CSTIN is 0 only when a disk is in the drive. • Setting STEP to 0 steps the head one full track in the direction last set by DIRTN. When the step is complete (about 12 msec), the disk drive sets STEP back to 1, and then you can step again.

• WRTPRT is 0 whenever the disk is locked. Do not write to a disk unless WRTPRT is 1.

• MOTORON controls the state of the disk motor: 0 turns on the motor, and 1 turns it off. The motor will run only if the drive is enabled and a disk is in place; otherwise, writing to this line will have no effect.

• TKO goes to 0 only if the head is at track 0. This is valid beginning 12 msec after the step that puts it at track 0.

• Writing 1 to EIECT ejects the disk from the drive. To eject a disk, you must hold LSTRB high for at least 1/2 second.

• The current disk speed is available as a pulse train on TACH. The TACH line produces 60 pulses for each rotation of the drive motor. The disk motor speed is controlled by the ASG as it reads the disk speed RAM buffer.

• RDDATAO and RDDATA1 carry the instantaneous data from the disk head.

• SIDES is always 0 on single-sided drives and 1 on double-sided drives.

• DRVIN is always 0 if the selected disk drive is physically connected to the Macintosh, otherwise it floats to 1.

EDIT: Or maybe he's only talking about SuperDrives? I assume they must present index pulse information somehow in order to successfully write PC compatible formats. In any case I can't imagine the add-on sensor ever being needed to image 400k/800k images, since the original hardware can't tell whether two adjacent tracks are aligned or not. I mean, I guess in theory you could write a fiendish copy protection program that steps between one cylinder and another and immediately performs a read X milliseconds later to confirm the alignment is original rather than displaced by a copy, but in practice that would probably fail all kinds of ways in the wild..

 

[pcamen]

I've verified that formatting a partition on a SCSI2SD v6 as HFS+, to be read / written by something with System 8 or System 9, and can be read / written via Mojave when the device is connected via USB.  I haven't tried mounting the card directly with an SD card adapter.  Anyways, I'm using a PowerBook 540c to archive hard drives, CD's, Floppies, etc. and it is convenient to dump the data onto my Mojave Mac via USB and also to write some files that will then be moved from the HFS+ partition to an HFS partition that other Macs running System 7 can access.  Works well (but a little slow on the read write on my Mojave Mac, but that's fine).

Another question is about archiving CD's on my Mojave Mac.  I know some CDs have multiple partitions for Mac and Windows drivers and such.  It would be easier to be able to create images of System 7-9 era CDs on a modern Mac from a work flow and speed perspective.  I tried archiving one via Disk Utility to CD / DVD master format, changed the .cdr extension to .img but the System 8.x Mac won't recognize and and Disk Copy 6.x won't see it to open it. 

Any suggestions here?  Can this be done?

 

[Cory5412]

multi-platform CDs are probably best imaged as bin-cue, from a preservation standpoint.  I've seen a couple of them as toast files and as ISO files made on PCs with PC burning software.

I wouldn't use Disk Utility on a modern Mac to try to image those CDs. (or any, really.)

For Mac-only CDs or CDs where it's okay to break up the different components, you could use Disk Copy 6 on a vintage Mac.

 

[pcamen]

Dang.  I was hoping for a solution on a modern Mac; those old CD drives really are slow. 

 

[nglevin]

Disk Utility does burn ISO files decently, fwiw. Still, I second that a Linux or Windows solution that can burn bin + cue is what you really want for those odd hybrid and old timey CDs.

The problem with ISO rips is that they assume the CD only has a single data track with no additional complexity, which isn't true for CDs that had an audio track and a data track, or multiple audio tracks. Early Voyager Company works and Apple Developer Connection CDs mixed audio tracks and data tracks quite frequently.

 

[LaPorta]

I've had an epiphany about SCSI2SD v6.  I've just created a 32 GB card with a 2, 4, and 23 GB partition on it at a single SCSI ID.  The 2 GB partition is intended to be a boot drive.  The 4GB one is for storing stuff from OS versions < 8.1.  The 23 GB one I've formatted as HFS+, which I can read and write to from Mojave.  So this can be my easy transfer device between modern and vintage systems; I just have to have a bridge device that can boot to 8.1 to copy whatever I need to the 4GB partition that is HFS or another drive.  Or, share it via Appleshare to other macOS systems of that era. 

That plus mounting in an external SCSI drive case has been my goal for a while now.

 

[pcamen]

That plus mounting in an external SCSI drive case has been my goal for a while now.

Yea, I'm using it primarily in an external SCSI case, but  the DB25 adapter from Inertial works equally well as an external SCSI device. 

 

[Cory5412]

Disk Utility does burn ISO files decently, fwiw. Still, I second that a Linux or Windows solution that can burn bin + cue is what you really want for those odd hybrid and old timey CDs.

It does, that's one of the reasons I like ISO files so much. I use Windows to image Mac CDs because my Windows machines generally have optical drives, they're new enough to read discs without errors, and because they can accurately be re-burned (and bootable) on Windows and Mac. I haven't had the time to test to see if the same is true for discs imaged on a Mac.

My thought here is that different CDs will need a different solution.

As always I'm approaching this from the perspective of using VTools on a vintage Mac to access relevant content.

For relatively normal CDs and/or for discs where it's only important to capture the data, I think DC6 on a vintage Mac is a reasonable way to go. Any CD that can be imaged this way should be able to be accessed by simply mounting the DC6 image.

For boot CDs, I think we should also have modern-burnable ISO files, like the ones at http://personal.stenoweb.net/oldmac/. (or bin-cue, if it's a CD that needs it. The best example is absolutely the BeOS R5 Pro CD.)

ISO or Bin-Cue for everything would be easy enough, but I know of no solutions to use Bin/Cue on old Macs, and ISOs require third party software on Mac OS 9, either Toast or another mounting utility.

The biggest problem is I don't know exactly how much we might be looking at, in the scope of all vintage Mac software, that might need to be duplicated.

The other gotcha/trouble is that if "simple" CDs are primarily imaged as DC6 files, they won't easily be burnable with a modern computer.

EDIT: Just as food for thought, the Macintosh Garden came to me via a torrent from the Internet Archive. Everything on that site, as of whenever it was harvested to make that torrent, was a bit over one terabyte, and most of that stuff isn't really full-proper CD images. If it is though, it's usually only one copy per.

The plan for VTools is to have 4*2TB hard disks full of "primary" data, incl. software, webs, user-homes, and public, plus another set for quick duplication, and then to do off-machine backups/duplication using USB.

 

[olePigeon]

In case anyone was wondering, I've been sending copy protected flux images of some of my software to John, maker of the Applesauce.  I first sent over my Ultima III game disk.  It has a single fake bad block which prevents the disk from being copied.  It's a very simple form of copy protection.

The next one I sent was MacWars.  This one he said has what he calls a "weak bit minefield."

"It has sequences of valid nibbles interspersed between empty space. So as this sector gets read, the data changes each time. The copy protection reads the sector multiple times looking for all of the good sequences that fall in and out of sync."

Sounds pretty clever.  Might explain why I couldn't make a clean copy of the disk even with DiskDup.

 

[LaPorta]

Cory, this is a fair point. "Old school" burners will no doubt someday fail, and replacements will not be readily available. We do need straight images, so ISO probably is the best way to go. What's been your easiest way of doing that? I was thinking of just making ISOs with my BluRay drive on my 10.14 iMac. Does that sound reasonable.

 

[pcamen]

I guess the mistake I made was naming the .cdr image to .img instead of .iso.  I am going to change the name and see what System 8 thinks. 

 

[pcamen]

Well that was a quick and fruitless test.  Disk Copy 6.x won't recognize the .iso file either.  What is necessary to mount .iso files in System 7 or 8?

 

[olePigeon]

@pcamen  I believe Toast will do it.

 

[Cory5412]

There's another utility, which I have on VTools, that recognizes ISO files and can mount them, but not IIRC burn them.

Just to be clear, it sounds like the way this has gone, opinion-wise, is that we should image all Mac discs that we can as plain ISOs (where bin-cue isn't needed) and then use Toast on vintage systems to mount/manage the images?

That's reasonable, Toast isn't very hard to pirate, but I want to make sure we're setting the direction correctly.

My reasoning for not just suggesting Toast in the first place is because it's kind of a heavy install and Toast 5 in particular kind of wants a relatively modern machine. I don't know off hand if Toast 4 or earlier can handle ISO files.

Toast and Disk Copy can collectively convert by mounting and reimaging. I've also got a pile of CD-RWs I've been using to burn/re-capture things.

 

[pcamen]

I think it would definitely be better if the images could be used without any third party software install.  Perhaps just imaging at vintage speeds is what is required.  I've got probably a hundred CD's and that many or more floppies to image, so I'll probably be setting up a few machines to do the work.  I think I've got two working Apple CD drives of the era (and two of the CDSC units that stubbornly refuse to work) so that might help the flow.