I now have an Applesauce and have successfully created flux images of un-cracked copies of Lode Runner (1984), Star Trek: The Kobayashi Alternative, and Hacker II: The Doomsday Papers. All three are single-sided MFS disks with disk-based copy protection. The resulting files (A2R) weigh around 15 megabytes in size. They contain a detailed account of the flux transitions on these original disks.

Here is an explanation from John Keoni Morris—the developer behind the Applesauce—on this beefy file format:

Why did I bother with creating the A2R format when everybody just wants to play with WOZ files? There are a few reasons for this decision. First off is that creating WOZ files is an insanely complex process. It isn’t even remotely like just capturing bits and stuffing them into a file. There is a ton of signal processing, analysis and validation that goes on in order to make everything work. This leaves a lot of room for mistakes to happen in the process. The second is that many floppy disks don’t have a lot of life left in them. Bits are rotting away and we may not have many more opportunities to capture this data. So, with these factors in mind, I created an intermediate file format. One that contains purely the lowest level information at the highest resolution that is possible to capture from a disk. No analysis or discarding of potentially useful information. The A2R file stores the data below the bit level. It records the amount of time that exists between flux transitions on the media surface with an accuracy of 125 nanoseconds (that is 125 billionths of a second). This gives us the ability to preserve and work with data that is an exact copy of a floppy disk.

I will upload the A2R files for each of these titles to their corresponding pages. Eventually these files will be (A) transformable into whatever WOZ-like file format John Keoni Morris devises, which will be (B, hope willing) runnable in all the best Mac emulators. In the interim, they are interesting and valuable artifacts which can be opened and viewed with the Applesauce client software.

Applesauce was recently updated and now supports the ability to write Macintosh WOZ disk images back to 3.5" floppies. I performed some tests tonight on Star Trek: The Kobayashi Alternative, Lode Runner, and Hacker II: The Doomsday Papers. All three copied disks booted and ran on my 4-megabyte Macintosh Plus. This is a very encouraging development.

I intend to image more copy-protected software from my private collection and upload it here to the Macintosh Garden. If you are thinking about getting an Applesauce FDC, this device has my endorsement and recommendation.

I imaged a handful more copy-protected titles tonight but had a lot less success in getting the software to function after writing them back to a blank floppy.

MacWars boots up to the title screen, but it stops there and goes no further.

The Lüscher Profile bombed with a system error after booting. The original floppy does not.

The same thing happened with Deluxe Music Construction Set. Its original floppy works.

Archon’s brutal copy protection caused the Applesauce client software to crash when I tried writing the WOZ image to disk. I asked John Keoni Morris if he’d be interested in looking at the image file.

I was able to successfully image and make functioning copies of Microsoft Flight Simulator and Financial Cookbook, an unpreserved EA title that is really boring. I’ll upload both sometime soon.

Morris has observed there are a lot of Mac software titles that use synchronized tracks. The 3.5" floppy controller cannot see this synchronization, but Morris makes a sync sensor you can install in the drive to accurately image these synchronized tracks. I am going to purchase and install one of his sensors, then try imaging these troublemakers again.

Last week I installed a sync sensor in my 3.5" drive and went about imaging and duplicating a batch of copy-protected titles. Alas, the synced images were unsuccessful in making functioning copies.

I wrote to John Morris and sent him the images, which he examined. His findings went into a recent update to the client software, which I just tried.

The new version (v1.1.7) succeeded in making a functioning copy of Accolade’s HardBall!, which previously had failed. Unfortunately, I was unable to make functioning copies of MacWars and The Lüscher Profile. Again, I shared my findings with Morris.

I would upload the HardBall! images, but it seems this would get us in trouble with Tommo/Retroism.

John Morris wrote back and said the code for accurately writing protected 3.5" disks is still forthcoming. I must have won at copy protection roulette; he said HardBall! works only because of dumb luck.

Incidentally, I’m documenting my experience here with the hope these records will confirm the value and reliability of Applesauce, so early Mac enthusiasts (and archivists) can buy one with confidence.

Morris sunk his teeth into Macintosh copy protection routines on Twitter the other day.

https://twitter.com/DiskBlitz/status/1151991247399084033

Copy protection for 400K Mac disks was a pretty interesting affair. There were a few one offs of the typical variety, like marker changes and such. But then in 1985, a number of companies gravitated to a single protection scheme. It looked like this.

A bunch of good nibbles in a sea of bad ones. The bad nibbles were of course not real. They were large gaps between the good nibbles that got filled with random garbage as the automatic gain control of the drive struggle and failed to find valid data.

With no synchronization nibbles, these good nibble sequences went in and out of sync randomly every time you tried to read the sector. Making it virtually impossible to copy. It proved so good, that companies like Electronic Arts, Activision, Epyx, and many others flocked to it.

It was so good that even though Applesauce could capture it and knew that something was VERY fishy about it, it couldn't figure out how to sort it out. In the new 1.1.8 release, I have taught it how to detect and unwind all of the insanity. This is what the real data looks like.

The protection looks for the CB D9 nibbles to know that it found one of its sequences. It then grabs the next two nibbles which are a 4&4 encoded that are used as an index into a table. It keeps reading this until it fills out all of the table entries.

Every read has sequences randomly appearing and disappearing. So a bit copy would be extremely unlikely to get all of them correct. A pretty darned clever protection scheme. But interestingly, the first time I saw this technique used was from 1984 by @rolandgust on the Apple II.