I did some further reading and it seemed that the On Three Uncopyprotect driver would also work for Apple Writer /// (version3.0). I found a copy of the disk images for this on the apple3.org website and booted up the first disk, AppleWriter30MSTR.dsk, in Mess. It failed to start, but came up with a different error message than Visicalc, SYSTEM FAILURE = $06.
I then used the SCP and added the uncopyprotect driver to the disk image and then booted it again in Mess. This time success!
AppleWriter /// is using the same inbuilt copy protection and the same key as Visicalc. Interesting that it gives a different error. This would depend on the the jump taken in the still encrypted sos.interp file after the protection validation has failed. I traced with the Mess debugger and it jumps to the NMI handler routine, and then jumps to the system death routine which gives the above error.
I have seen this error for other disk images and had wondered why they gave that error. Looks like it could be due to copy protection failing for the disks.
I did some more searching and there is a copy of AppleWriter /// v4.1 in the WAP disks (APPLE-3-WAP-wdp-01a.dsk), and this one is not copy protected. So that's the easiest option to get it running and avoid this problem. Though we really need some NIB or better format images of the original v3.0 disks to preserve them in running condition.
Another disk image that I have seen reported before as broken, is the Apple3SystemDemo disk. I downloaded the disk image of this from apple3.org, Apple3SystemDemo.dsk and booted it in Mess. This also gives the same SYSTEM FAILURE=$06.
I then thought I would try to copy in the uncopyprotect driver to the disk and see if this would also work. One catch though, from the disassembly in the previous blog entry, it needs SOS1.3 to work, and this disk has SOS1.1 on it. I used the Apple3SystemUtilities to copy over the SOS1.3 and driver file with the uncopyprotectdriver on it. (for some reason Ciderpress complains about a damaged directory entry, so i had to do this the long way)
With the new sos.kernel file and the sos.driver file, the disk actually boots. but.. then gives an error about a sos call. I suspect this is due to the change from SOS1.1 to 1.3. The uncopyprotect driver did however, help to successfully decode the sos.interp file (which is business basic) and was able to run it. It must therefore use the same protection key as the other programs. I think this also means that SOS 1.1 had the same copy protection support built in.