Wizardry 1 and Mini vMac issue - any workarounds?

[beerslayer]

When trying to use Mini vMac to play the old Wizardry ("Proving Grounds of the Mad Overlord") game from disk images, it insists on reading the "master" disk (which must be write-protected) before it will proceed. On Mini vMac, this makes it impossible to run this program.

Here's the sequence of events:

0) Make two copies of the image file on the host system. Make sure one is write-protected and the other isn't.

1) Boot Mini vMac, then mount the unlocked image of the Wizardry disk (the "Scenario" disk).

2) Launch the Wizardry application from the scenario disk. It immediately prompts you for the "MASTER" disk. This prompt is a modal dialog, so no return to the OS is possible.

3) Mount a LOCKED image of the Wizardry disk (the "Master" disk). This satisfies the application, which then tries to prompt for the scenario disk again using another (sigh) modal dialog. (Why it doesn't believe that disk is already or still mounted, I don't know.)

4) Try to remount the same image from step 1, which fails (since Mini vMac sees the image file as being already in use).

5) Try to mount an identical image to the one used in step 1 - Wizardry rejects it since it is not the *exact* same one.

There is no way that I've found to get any farther using Mini vMac. The only thing I can do at this point is reset the emulator, since the modal dialog won't even let me get back to the system and does not respond to Cmd-Q or any other command that I can find.

If Mini vMac emulated some sort of "paper clip" ejection method, that might work here. Since I have no idea what disks the Wizardry application thinks are mounted at that point, nor why it won't resume using the already mounted scenario image, I do not know what other workaround might satisfy it.

If anyone can enlighten me as to a workaround that already exists, please let me know.

 

[Dog Cow]

You may be out of luck. The Wizardry disk is copy-protected. I have an original Wizardry disk with gold label, but it has gone bad over the ages, and I get the same problem when using my Mac Classic.

 

[beerslayer]

Dog Cow, thanks for the reply.

I'm not sure that copy protection is the culprit here. Although I own the original game from many years ago, I am using a disk image obtained from another source with the emulator since my original disk cannot be read by my host pc's external USB floppy drive. And the game is getting past the point where it asks for the master disk.

Once the locked master has been processed, the program prompts for the scenario disk again. If I remember correctly, on a physical Mac, the master would be physically ejected at that point so that the scenario could be re-inserted. But the game fails because the emulator sees the scenario image as still in use, and refuses to allow it to be mounted again. The application never sees the scenario disk being re-inserted, and never proceeds past that modal dialog.

My guess would be that there may be a bug in the disk mounting/dismounting routine in the emulator.

Again, Dog Cow, thanks for your help. I'm still hoping that someone out might know or be able to suggest a workaround.

 

[Mac128]

Pose this question directly to Paul Pratt if you haven't already. You seem to have a pretty firm grasp of what's happening.

 

[beerslayer]

Mac128, thanks for the reply (and the compliment).

I haven't contacted him directly yet. His website suggested that I try here first...

If nobody else suggests a magic fix in the next couple of days, I probably will write him directly.

 

[Dog Cow]

Here is my second uneducated guess:

Wizardry could be trying to access the floppy disk controller hardware directly (IE, through memory locations rather than Mac ToolBox) which is something that vMac doesn't emulate.

And thanks for making me feel worse about my copy of Wizardry, Mac128.

 

[beerslayer]

Dog Cow, thanks for trying again.

As I see it, while what you say about the hardware may be correct, I'm not sure it's relevant.

Here's what I think is happening:

In older System versions, there was an option to Eject a floppy without dragging it to the Trash. Ejecting a floppy in this way left it "semi-mounted" - a "ghost" image of the floppy would remain mounted on the desktop even though the disk itself had been physically ejected. Any attempt to access anything on that ghost image would result in the System prompting you to re-insert it (Ejecting whatever disk might be in the drive in the process and creating another ghost, but this is probably irrelevant).

I think this is what Wizardry is doing - Ejecting the scenario disk so that the master can be inserted. I suspect (but have not confirmed) that when this happens, a ghostly scenario disk still remains mounted (and the image file for that scenario disk remains open and in use).

Presumably, once the game has satisfied itself about the master disk, it prompts for the scenario disk by using some underlying System routine that deals with "ghost" disks. If you could physically re-insert the scenario at this point, the ghost would become resurrected, and the game would probably continue without incident. However, you cannot re-insert the scenario image, because the image file is already open in Mini vMac and cannot be opened twice. I've already tried to fool it by mounting an identical scenario image, but this doesn't work either.

Assuming I'm right, it seems like the problem could be solved in Mini vMac by closing the disk image file when the disk is Ejected, even if the ghost image remains behind. If the System prompts for that disk to be re-inserted, Mini vMac could then prompt the user to re-open the file, or even re-open it automatically all by itself.

If only Wizardry didn't use modal dialogs to do all of its prompting, I might be able to escape to the OS long enough to resolve the bottleneck. Unfortunately, this doesn't seem possible either.

Sigh. So close, yet so far... :'(

 

[prattp]

Hi, I'm catching up on mail after a trip. (I'm posting this same reply on both discussions on E-maculation and 68kmla.)

I believe that "Dog Cow" is generally correct, though this may or may not apply specifically to Wizardy. Mini vMac does not emulate the disk hardware at low level, and so most copy protection schemes won't work with it. For that matter, I don't believe the standard disk image format can accurately contain all the information on most disks with copy protection. No matter what Mini vMac did, the needed information from the Master disk just isn't there on your disk image copy.

At step 3 you say that the application is satisfied, and asks for the original disk back. But my guess is that it is not satisfied, and just wants the original disk back to get access to the code to display an error message. If it was satisfied, it would be extremely incompetent copy protection.

As for why it is asking for the original disk back when it already has it, my guess would be that it tried to eject the disk using a low level method that Mini vMac doesn't support, since it was already trying to use low level access for verifying the copy protection.

In summary, emulating the paper clip ejection method is a possible feature for Mini vMac, but I don't expect it would help you at all here, assuming the copy protection was implemented at all competently.

You might want to try the MESS emulator, whose Macintosh emulation appears to emulate disk access at a lower level. But I don't expect it will help. As I said, I think the needed information just isn't there.

Some people had a hobby of breaking copy protection on Mac 68k programs. I don't know what the DMCA law would say about breaking the copy protection on software you own for your own use, for software that predates that law.

 

[~Coxy]

Some people had a hobby of breaking copy protection on Mac 68k programs. I don't know what the DMCA law would say about breaking the copy protection on software you own for your own use, for software that predates that law.

There are specific exemptions to the law for the purposes of interoperability... now whether emulation would count is probably up to a lawyer and/or court. :?:

There are seven exemptions built into section 1201 of the DMCA, some of which permit the circumvention of access and copy controls for limited purposes, some of which allow for the limited distribution of circumvention tools in particular circumstances. These seven exemptions are for:
* Libraries, archives, and educational institutions for acquisition purposes; [1201(d)]

* Law enforcement and intelligence gathering activities; [1201(e)]

* Reverse engineering in order to develop interoperable programs; [1201(f)]

* Encryption Research; [1201(g)]

* Protecting minors from material on the Internet; [1201(h)]

* Protecting the privacy of personally identifying information; [1201(i)]

* Security Testing [1201(j)]

My lay reading of 1201(f) would lead me to believe that breaking the copy protection on a copy of Wizardry that you own legally would be allowable for the purposes of running the game inside a modern emulator.

Emphasis mine:

(f) Reverse Engineering. -
* (1) Notwithstanding the provisions of subsection (a)(1)(A), a person who has lawfully obtained the right to use a copy of a computer program may circumvent a technological measure that effectively controls access to a particular portion of that program for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs, and that have not previously been readily available to the person engaging in the circumvention, to the extent any such acts of identification and analysis do not constitute infringement under this title.

* (2) Notwithstanding the provisions of subsections (a)(2) and ( B) , a person may develop and employ technological means to circumvent a technological measure, or to circumvent protection afforded by a technological measure, in order to enable the identification and analysis under paragraph (1), or for the purpose of enabling interoperability of an independently created computer program with other programs, if such means are necessary to achieve such interoperability, to the extent that doing so does not constitute infringement under this title.

* (3) The information acquired through the acts permitted under paragraph (1), and the means permitted under paragraph (2), may be made available to others if the person referred to in paragraph (1) or (2), as the case may be, provides such information or means solely for the purpose of enabling interoperability of an independently created computer program with other programs, and to the extent that doing so does not constitute infringement under this title or violate applicable law other than this section.

* (4) For purposes of this subsection, the term ''interoperability'' means the ability of computer programs to exchange information, and of such programs mutually to use the information which has been exchanged.

 

[jwmcfarlin]

This is not really addressing the technical issue, but this is how I would get it done:

How about buy an old Mac and run it on that?

Best,

John

 

[shadow101101]

So I get that this thread is positively ancient, but just in case anyone else finds themselves in this same situation there is in fact a workaround to play Wizardry: Proving Grounds of the Mad Overlord v1.1 on Mini VMAC. There are a couple versions of the game disks floating around out there: an early version of the game which you can play right from the Scenario disk without issue and a set of version 1.1 disks. Version 1.1 has a few fixes and some additional features like animated monster sprites, but it also has some copy protection. Per the OP if you boot Mini VMAC, then mount the 1.1 Scenario disk and try to launch the game it will ask for the Master disk and then prompt you for the Scenario disk again, at which point you're stuck because there is no way to "eject" disks during the transaction and using a copy of the original Scenario disk gives an error about it not being the same disk. But if instead of booting and then mounting the disks you drag the 1.1 Scenario disk on top of the Mini VMAC executable, mount the 1.1 Master disk when it prompts you, and finally mount the 1.1 Scenario disk when it prompts for the Scenario disk again you will not get an error and will launch right into the game.