Skip to main content
Home▸ Forums▸ 68kMLA▸ Wizardry 1 and Mini vMac issue - any workarounds? — #7
Post #7 by beerslayer
Source Forum68kMLA
CategoryTroubleshooting
Post DateSat, 3 Jul 2010 - 22:30
Original URLhttps://68kmla.org/bb/threads/wizardry-1-and-mini-vmac-issue-any-workarounds.20875/
Post
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... :'(