Post Reply 
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 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.

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.
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).

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 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?
You'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.
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 - Claudio L. - 07-26-2016 09:27 PM



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