50g: copy all stored objects to SD card individually

[matthiaspaul]

(10-13-2016 07:55 PM)DavidM Wrote:  Case Sensitivity

The calculator is case-sensitive regarding names, but the SD card file system
isn't. As such, it's possible to have multiple objects on the calculator in the
same directory that would not be allowed on the SD card (eg. "MyObj", "myobj",
"MYobj", etc.). If copying the object to the SD card generates a name conflict,
a suffix is added (starts with "2", then goes up to "20" before giving up).

There isn't much you can do about that within the limits of the original file system, but this approach will create problems when you want to restore the contents on the calculator later on - how should the calculator decide if the number was a regular part of the name or a suffix? Possibly, a more refined solution would be to copy the approach used in newRPL - it also uses tilde suffixes for the SFNs (short file names), but adds semicoli to the LFNs (long file names). See:

http://www.hpmuseum.org/forum/thread-464...l#pid59021
https://sourceforge.net/p/newrpl/sources.../fsystem.h

Quote:Character Set

The 50g character set includes many valid symbols for object names that would
not be suitable for the file system of the SD card. I've used a simplistic
approach for this; all characters including A-Z, a-z, 0-9, and "." are left
intact. Any other characters in an object name get converted to "$xx", where
"xx" is the hex code for the character.

Since you never mentioned the name of the file system, the calculator uses the industry standard FAT file system (or actually FAT12, FAT16 or FAT32, depending on the size of the medium). This is not specific to SD cards in any way. The calculator also supports VFAT LFNs on any of the underlying FAT12, FAT16 or FAT32 filesystems.

The FAT file system itself is character set agnostic, you can store file names in any OEM character set you want for as long as the operating environment (and the user) is able to cope with the possibly strange looking characters.

However, for maximum compatibility with environments lacking the resource files to support the RPL character set, the best approach is to translate the SFNs into codepage 437 (and optionally into codepage 850, 858 or 819 and perhaps a custom 1:1 "pass-through" codepage) - and replace untranslatable characters by "_". For untranslatable characters, this is a one-way process, of course, but this does not cause problems for as long as the VFAT LFNs are used as well - they can be utilized to recover the original characters.

The VFAT long file names should be converted to Unicode. See https://en.wikipedia.org/wiki/RPL_charac...age_layout for a suggested translation table.

Quote:Object Name Length

This one surprised me. I originally thought that the 50g SD card file system
wouldn't accept long-ish file names, but it seems to be OK with them. At least
up to my test case of 27 characters. I haven't tried longer ones yet.

SFNs are always limited to 8+3 characters in FAT, whereas VFAT LFNs can be officially up to 255 characters long (the design of the filesystem actually supports up to 403 characters, but not all platforms support this). In fact, on some platforms, VFAT LFNs are (artificially) limited to the maximum absolute path length for SFNs due to restrictions on internal buffer sizes - on some platforms this can down to 66 characters.

Greetings,

Matthias