You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It looks like Virtual II is rewriting the mounted disk image when ejecting, which does not play well with the build process; we update the .dsk image with the new binary and then trigger applescript to eject the mounted disk, which immediately reverts this change. To work around this you would need to first eject the disk and then update it with AppleCommander.
You can see this behaviour just by checking the timestamps on the .dsk file before and after ejecting a disk in Virtual II
I'm assuming this is a recent change in behaviour (I'm running the current version, 8.3). Arguably it might be also considered a regression in Virtual II.
The text was updated successfully, but these errors were encountered:
"You are right, Virtual ][ writes the disk image on ejecting, even if nothing has changed. This behavior is not intentional, and can be improved obviously; I will add it to the todo list.
[...]
I'm afraid this behavior is the result of a major refactoring I did for version 8.3, where I implemented woz disk support."
It looks like Virtual II is rewriting the mounted disk image when ejecting, which does not play well with the build process; we update the .dsk image with the new binary and then trigger applescript to eject the mounted disk, which immediately reverts this change. To work around this you would need to first eject the disk and then update it with AppleCommander.
You can see this behaviour just by checking the timestamps on the .dsk file before and after ejecting a disk in Virtual II
I'm assuming this is a recent change in behaviour (I'm running the current version, 8.3). Arguably it might be also considered a regression in Virtual II.
The text was updated successfully, but these errors were encountered: