On real hardware, Calliope cannot recover from an SD card swap.

[mooinglemur]

After removing and swapping or reinserting the SD card, Calliope gets completely lost. DOS returns to the root directory of the SD card, and Calliope has no idea that it needs to refresh the listing.

Related, I think Calliope doing a pseudo-chroot() at start is unnecessary. The top level directory on FAT32 is distinguishable from a subdirectory because there is no . or .. directory entry at the top level, and it might be relatively safe to assume that fact on the X16.

Since Calliope really need not chroot(), recovering from an error doing a DOS operation like entering a directory can usually be recovered from by refreshing the directory listing. You won't be in the directory you were in, but that's not necessarily possible since the user might have swapped SD cards to a different one. While polling the pwd would be nice to be able to do, and it should be added into CMDR-DOS, I don't think it's necessary in order to improve Calliope's behavior. Knowing pwd won't help Calliope if the user put a different SD card in.

Why would anyone want to swap SD cards with Calliope open? To play a new ZSM without re-opening the program! :)

[mooinglemur]

I know SD card reinsertion and not knowing the pwd will likely screw up playlist playback as the relative path of the files isn't necessarily the absolute path. Knowing the pwd will help for sure in that instance.

I guess a workaround could be forcing Calliope's browser to start at the root of the SD card every time rather than the directory it was started in. All paths would then be absolute.