Post Reply 
newRPL: [UPDATED April 27-2017] Firmware for testing available for download
07-26-2016, 04:37 PM (This post was last modified: 07-27-2016 07:13 PM by matthiaspaul.)
Post: #345
RE: newRPL: [UPDATED July-25-16] Firmware for testing available for download
(07-25-2016 09:46 PM)Claudio L. Wrote:  * New SDFREE command to get the free space in the card
Hi Claudio,

it's great to see you're working on SD card support!

Some unsorted comments/remarks/questions/requests: ;-)

Do you support the two entries in the FS info sector already? Do you maintain the media and volume mount flags during mount/unmount/startup/sleep/shutdown? I'm asking because I had a (very) quick look at the sources and couldn't find it in there (but it is well possible that I have overlooked it, although this http://www.hpmuseum.org/forum/thread-656...l#pid58965 suggests that it isn't implemented yet). For some details, see:

http://www.hpmuseum.org/forum/thread-656...l#pid58783

I can provide more details if necessary.

Regarding your semicolon trick (http://www.hpmuseum.org/forum/thread-464...l#pid57755), do I take it right, that this only affects the LFN, whereas the SFN will not get a semicolon appended? If a SFN would conflict with another SFN this would be solved by changing the numeric tail (~1 etc.), wouldn't it? (I'm asking because SFNs with trailing semicolon is ringing an alarm bell with me as it may make such files inaccessible in some implementations - I will have to check this myself, though.)
Somewhat related, have you considered adding support for DR-style directory and file access passwords and (single-user) access permissions (read/write/execute/delete rights on a file-by-file basis), so that password-protected files and directories can be accessed only when the correct password was given (either as global password, as part of the filespec: "C:\DIR.EXT;DIRPWD\FILE.EXT;FILEPWD", or in a pop-up window opening when trying to access such files)? This can be used also to put and process files in groups (using the same password) with wildcards (something like DEL *.HP;FILEPWD would delete only those files in *.HP with a matching password FILEPWD). Password hashes and permissions are stored in reserved areas in the FAT file system. If this sounds interesting, I can provide the necessary details how this FAT extension is implemented in operating systems of Digital Research origin, so that unaware OSes won't hick up on it (they just see them as hidden files).

Some of the SD-related commands are named SDCHDIR, SDMKDIR, SDPGDIR.
Wouldn't it be better to rename SDPGDIR into SDRMDIR to use the "standard" names. Perhaps they are so frequently used to warrant shortcuts like SDCD, SDMD and SDRD as well?

For similar reasons I would rename SDPURGE into SDERASE with shortcut SDDEL (or even SDERA, although ERA is only supported by DR shells, not by MS ones).

How do you propose to ensure file system integrity if a program needs to prompt a user with something like "Please remove SD card from slot"? Is there something like a SDFLUSH or SDUNMOUNT command returning only after any pending writes are written out and the file system is in a clean state? Or does the implementation write-through stuff immediately leaving the file-system in a semi-unmounted state that is ready for safe card removal but without trashing internal data so that an on-demand-remount can happen without time penalty for as long as the card was not removed?

The Unicode conversion table

const int const cp850toUnicode[128] = {
0x00C7, 0x00FC, 0x00E9, 0x00E2, 0x00E4, 0x00E0, 0x00E5, 0x00E7,
0xEEEA, 0x00EB, 0x00E8, 0x00EF, 0x00EE, 0x00EC, 0x00C4, 0x00C5,
...

appears to contain a bug. The code point at 0x88 should be 0x00EA rather
than 0xEEEA, shouldn't it?

Your Unicode <> OEM conversion is currently hardwired to codepage 850.
I would like to suggest to make this configurable by a command like SDCHCP, SDCP, SDOEMCP, SDCODEPAGE or similar. While 850 is not uncommon, most
LFN implementations default to codepage 437, as this is the default hardware codepage used on Western PCs. Most users of 850 would be better off with codepage 858, anyway - it is the same as 850 except for that the Turkish dotless i (0x0131) at codepoint +D5h was replaced by the euro currency symbol 0x20AC. Also important would be ISO 8559-1 codepage 819 (0x0333) and a CDRA user-variant of it (58163, 0xE333) for a 1:1 implementation of the HP 48/49/50 RPL character set. Ideally, we'd have a number of predefined codepages and at least one user-definable vector.
There's one more potential problem as in some code pages some code points correspond with more than one Unicode character, Greek beta and German sharp s being one example. For files created under newRPL, this could be solved by expanding/modifying the tables, but how to solve this for files created externally with only a SFN - the calculator simply cannot know if a character at code point 0xE1 in the codepage was meant to be a Greek beta or a German sharp s?

Greetings,

Matthias


--
"Programs are poems for computers."
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: newRPL: [UPDATED July-25-16] Firmware for testing available for download - matthiaspaul - 07-26-2016 04:37 PM



User(s) browsing this thread: 2 Guest(s)