![]() Yellowstone Universal Disk Controller for Apple II The man in the middle (SheepShaver or else) is needed, as Apple prevents writing HFS volumes from user land.Floppy Emu Disk Emulator for vintage Apple II, Macintosh, and Lisa The procedure looks more complicated that it actually is. Sorry for some German in the screenshots. Press Control-J to create a HFS image from it and select the topmost entry in the pulldown menu for read/write.Īs the image is now in macOS, run MiniVMac II with your MacOS 7.5 and drag the new img onto the MiniVMac II screen. (The folder is named Classic in my case, YMMV)Ĭopy the folder to a SheepShaver Mac volume (not to the SheepShaver desktop). Move the folder to SheepShaver´s shared volume. Lets assume SheepShaver as your solution, as it looks easier.(Same procedure for Basilisk II)Īlso, lets take a Apeiron game folder from Macintoshgarden as an example. Usually you want to preserve the resource forks of your apps and data files.Īny Mac OS above 10.5 is incapable of writing HFS volumes in a simple way.Īs far as I can tell, you got these options: Moving files from 10.14 to 7.5 may be troublesome. Is there something else that I could try next? Unfortunately, the behavior of this newest version is the same as before: I cannot import files to the "MacHD" disk (or indeed the desktop). ![]() I followed your instructions above, creating a version of Mini vMac 36.04 identical to my earlier version, but with the addition of the -sony-sum 1 -sony-tag 1 parameters. I've finally had some time to get back to this. It has become clear that this was the wrong choice, and this code should be enabled by default. Arachelian), but it is added code that makes Mini vMac a little bit less "Mini". There is code to support updating the checksum correctly (thanks to zydeco and Ray A. Prior to version 3.2, Mini vMac would write to Disk Copy 4.2 images, but not update the checksums, resulting in an invalid image. (A demo version is sufficient for testing this.) You can test this by specifying -sony-sum 1 -sony-tag 1 in the Advanced Variations Service, to enable write support for Disk Copy 4.2 images. Though it became read only in Mini vMac 3.2, so it should be the same in your 3.3.2, unless it is a variation. It does sound like this could be a Disk Copy 4.2 image, which by default is read only in Mini vMac. ![]() The blank disks referenced in this thread will mount read-write.Ĥ) Paul is referencing your original error: "'You cannot move "filename" to the disk "MacHD", because the disk is locked.'" The main error with HFS Diskmaker is expected the resource fork error is not I should double check that Mojave's increased security hasn't prevented HFS Diskmaker from accessing named forks. It's possible that the version of Mini vMac you are using auto-locks disk images with the original NDIF headers (it's a compile-time feature) and your copy of 3.3.2 didn't. It won't save to your other disk, because that disk is locked.Ģ) It sounds like the issue is that either you're using different disks then you were with 3.3.2, or something has caused them to get locked under 36.04.ģ) If they're not locked in macOS, get info on them in Mini vMac and see if you can unlock them there. Then run ImportFL and attempt to save the file to that disk. I think there's been a bit of confusion here I'll try to talk to your points:ġ) Drag the blank disk image over Mini vMac: it will mount on the Mini vMac desktop. ![]()
0 Comments
Leave a Reply. |