newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[Claudio L.]

(07-30-2016 02:28 PM)matthiaspaul Wrote:  I'm afraid I have to disagree here. Unicode is great (although far from being perfect), but while it will be used on many new systems, I don't see codepages vanishing in the next few decades, either. Not only because many older systems exist and are still fully functional, but also because there are applications where Unicode does not offer benefits over 8-bit codepages, but just complicates a design.

What you declare as "rare occurance" would actually be the most common use case for me, transferring files from plain FAT volumes to the calculator.

Does your system support LFN names? If so, it is rare because your system will generate a Unicode LFN for any strange names.
If it doesn't (because of bad implementation), you can still guarantee an LFN will be created by appending a semicolon to the file name (you can do that for all files with a single rename command). That way you get rid of the code page problem forever, as the *source* system will do the OEM to Unicode conversion (in whatever code page is using). newRPL will ignore the semicolon so you'll see your original names in the calc.
If you are using plain DOS without LFN support, then I'd say "why?" You wrote the LFN support for DR-DOS, right? so at least you should use your own creation :-).

(07-30-2016 02:28 PM)matthiaspaul Wrote:  Regarding OEM character translation, I think, if only one codepage could be supported, codepage 437 would be the best choice, as this is the default hardware codepage used on most PCs. Adding support for a basic repertoire of other codepages does not seem like a waste of flash space to me. A more compact table representation could be found.
Another idea is to store the translation table(s) in a special binary system file in the root directory of the volume and have the filesystem use this table if present, and default to an internally stored table for 437 if not. This could be useful also for other implementations, so we could define a little FAT extension here.

If it was the Prime, there's plenty of flash, so I'd say no problem. On the 50g we have 2 MB and newRPL already uses 1.5 MB, so by the time newRPL is ready it will be tight in there. I'd put this in the backburner until newRPL is more finished. If there's space in ROM, then perhaps multi-CP can be added.
Regarding loading it in RAM, I think it's worse: we only have 512 kb of ram, I'm leaving about 32 kb max. for the file system to use, that's all so loading the table and leaving it permanently does more harm than good.