newRPL: [UPDATED April 27-2017] Firmware for testing available for download
|
07-31-2016, 02:41 AM
Post: #358
|
|||
|
|||
RE: newRPL: [UPDATED July-25-16] Firmware for testing available for download
(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.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. 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. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 8 Guest(s)