newRPL: [UPDATED April 27-2017] Firmware for testing available for download
|
07-26-2016, 09:27 PM
Post: #347
|
|||
|
|||
RE: newRPL: [UPDATED July-25-16] Firmware for testing available for download
(07-26-2016 04:37 PM)matthiaspaul Wrote:(07-25-2016 09:46 PM)Claudio L. Wrote: * New SDFREE command to get the free space in the cardHi Claudio, Not implemented for a few reasons: a) It's not exactly reliable: if the card comes for example from another 50g with stock firmware (which doesn't update these fields), you get bad info. I figured exchanging cards between calcs would be quite common. b) Implementing it requires proper mount/unmount, which means if the user just pulls the card out then putting on a PC will indicate a "dirty" file system and will suggest (or force) disk checking procedures. c) To minimize fragmentation, the file system driver uses that "scan" to locate the largest block of free clusters in the disk. But now that I added SDHC support, with potentially much slower scan times I may have to rethink that. (07-26-2016 04:37 PM)matthiaspaul Wrote: 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.) Semicolon is not an allowed character in 8.3 names, so this is only for long names. SFN names do use the numeric tail in the classic way. But since potentially conflicting names are allowed, the SFN should not be relied upon when the LFN exists. One example: Let's say I create "BigFile", which has a SFN "BIGFILE". Now I want to create "BIGFILE", which has a conflict with the previous SFN. newRPL will create LFN="BIGFILE;" and the SFN="BIGFIL~1" will be used. Now somebody reading only SFN names might think BIGFILE is "BIGFILE", when in reality is "BigFile". Not sure if it makes sense, but that's why SFN names shouldn't be relied upon. Actually, modern windows sometimes assigns a completely random SFN, not sure under which conditions, but this is perfectly valid. (07-26-2016 04:37 PM)matthiaspaul Wrote: 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).None of the above. I just can't picture a multi-user calculator... how do you place more than 2 fingers on the same keyboard? :-) (07-26-2016 04:37 PM)matthiaspaul Wrote: Some of the SD-related commands are named SDCHDIR, SDMKDIR, SDPGDIR. I had them like that at first, but I renamed them all for consistency with the RPL names. PGDIR and SDPGDIR do the same, CRDIR and SDCRDIR, etc. (07-26-2016 04:37 PM)matthiaspaul Wrote: 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 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 current implementation writes all information when requested. It is safe to pull the card anytime, as long as there are no open files for writing. But if the user has an open file, for example, data corruption can occur when the user pulls the card out. Not done yet, but I'm planning to simply have an IRQ on the card detection pin, so if the user pulls the card when there's data to be written the system will throw an exception, asking the user to reinsert the card immediately. (07-26-2016 04:37 PM)matthiaspaul Wrote: The Unicode conversion tableYou're probably right, I'll double check. (07-26-2016 04:37 PM)matthiaspaul Wrote: Your Unicode <> OEM conversion is currently hardwired to codepage 850. Yes, mainly because it's not meant to exchange information with DOS 6.20 anymore. USA uses 437, most Europe and Latin America use 850, so 850 is more widespread than 437 from what I researched. This won't affect you in any way, it's only to translate short names with strange characters into readable names for the calculator (these files would've been created by older OS). As long as you have a long file name this is not used. I put it there for legacy, to have some way to show a file with strange characters, but code pages are in the past, newRPL is Unicode compliant and not apologizing for it. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 4 Guest(s)