Threaded Mode | Linear Mode

Claudio L. · 08-02-2016, 03:17 AM

(08-01-2016 01:31 AM)matthiaspaul Wrote: So much for now, but there's more... ;-)

Hope it helps,

Matthias

Thanks! I wrote this FAT file system driver sometime around 2007, so your assumption that I know every detail by heart is completely flawed :-). Your review of the code on the other hand is quite accurate.
Back in the day I had only one document from Microsoft for basic FAT (so all other variants were not known to me), LFN was hardly documented anywhere. MS was keeping it tight, to the point they had forced other open source FAT drivers to be taken down, so I decided to include only binary code in hpgcc, and never published the sources. Times have changed, and now this code has finally seen the light of day, and with luck it fell in your hands for proper review.

I'll work on these fixes you mentioned (I have to confess, never heard of DELWATCH before). If you happen to see anything else of course let me know. And if you prefer to clone the git repository, do the patches yourself and send me pull requests, you are welcome to do so as well.

Claudio L. · 08-02-2016, 03:20 AM

(08-02-2016 02:30 AM)RMollov Wrote: On another note I flashed my HP49g with the latest firmware which eat fresh set of batteries over the weekend being untouched.
Strange?

You are the second to report a 49G+ with power drain issues. I'm still not sure what could cause it, unfortunately my 49G+ died many years ago so I can't test it.
We'll keep trying to find the cause so don't give up just yet.

RMollov · 08-02-2016, 04:01 AM

(08-02-2016 03:20 AM)Claudio L. Wrote:
(08-02-2016 02:30 AM)RMollov Wrote: On another note I flashed my HP49g with the latest firmware which eat fresh set of batteries over the weekend being untouched.
Strange?

You are the second to report a 49G+ with power drain issues. I'm still not sure what could cause it, unfortunately my 49G+ died many years ago so I can't test it.
We'll keep trying to find the cause so don't give up just yet.

With previous built batteries lasted at least a week and they weren't fresh too.
Cheers

Claudio L. · 08-02-2016, 04:59 PM

(08-02-2016 04:01 AM)RMollov Wrote:
(08-02-2016 03:20 AM)Claudio L. Wrote: You are the second to report a 49G+ with power drain issues. I'm still not sure what could cause it, unfortunately my 49G+ died many years ago so I can't test it.
We'll keep trying to find the cause so don't give up just yet.

With previous built batteries lasted at least a week and they weren't fresh too.
Cheers

Nothing changed from previous build, except now SD card is enabled. Do you have an SD card inserted permanently or not?

Claudio L. · 08-02-2016, 07:14 PM

(08-01-2016 01:31 AM)matthiaspaul Wrote: While I don't have the time to really dig deep into the sources, I have had a closer look and already identified a few bugs and compatibility issues. In some cases, the necessary changes are local enough, so that I can provide improved/fixed source code excerpts, in other cases I'll just give some hints.

Some FAT related data structures have evolved over time or have entries where the proper interpretation depends on various conditions. Several bugs in the implementation are down to not checking the presence of particular data structure versions (f.e. BPB variants) or not testing on the conditions under which they are valid.

I had a deeper look at these issues. I don't know where specifically you mention that a variant of the BPB needed to be detected. This implementation avoids anything that's non-standard, it's based directly on an official specification by MS (second external link on Wikipedia). I reviewed the code and it seems to comply. Can you point to any examples where it does not?

(08-01-2016 01:31 AM)matthiaspaul Wrote: https://sourceforge.net/p/newrpl/sources...extentry.c

...
while(FSReadLL(buffer,32,dir,fs)==32)
{
if(buffer[0]==0) return FS_EOF;
if(buffer[0]==0xe5) continue; // DELETED ENTRY, USE NEXT ENTRY
if( (buffer[11]&FSATTR_LONGMASK) == FSATTR_LONGNAME) {
// TREAT AS LONG FILENAME
...

The LONGMASK (0x0F) condition above is incomplete. On FAT12 and FAT16 volumes, the attribute combination 0x0F can also occur as part of a valid pending delete file under DELWATCH...

This seems to be only happening on one (yours?) non-standard implementation of FAT 12/16, incompatible with the FAT32 spec.
While this is simple to support, I'm not sure it's in the best interest of the newRPL project to put much effort into supporting these minor variants.

(08-01-2016 01:31 AM)matthiaspaul Wrote: There's another bug when retrieving the start cluster value:

entry->FirstCluster = buffer[26] + (buffer[27]<<8) + (buffer[20]<<16) + (buffer[21]<<24);

The code above is only valid on FAT32 volumes; on FAT12 and FAT16 it would have to read as follows, as the 16-bit entry at 0x14 holds other information on those volumes:

entry->FirstCluster = buffer[0x1A] + (buffer[0x1B]<<8);

So, this could become something like:

entry->FirstCluster = buffer[0x1A] + (buffer[0x1B]<<8);
if (type == TYPE_FAT32)
entry->FirstCluster += (buffer[0x14]<<16) + (buffer[0x15]<<24);

I've seen similar code sections in quite a few other source files as well (you probably know them by heart, whereas I haven't written them down yet) and they need to be changed as well. In general, it is invalid to assume that the 16-bit entry at 0x14 in directory entries is 0 on FAT12 and FAT16 volumes.

This is fine, although the MS official specification of FAT I linked above actually says the high bytes of cluster number must be set to 0 on FAT16/FAT12 implementations.

(08-01-2016 01:31 AM)matthiaspaul Wrote: There's another potential problem here: The contents of entries in directory entries, which are not used by the implementation, must not be changed. So, in the above example, the code most probably would still have to store away the value at offset 0x14 even on FAT12 and FAT16 volumes for later restoration (just not treat it as cluster entry).

See, for example, this file:

https://sourceforge.net/p/newrpl/sources...direntry.c
fsupdatedirentry.c:

...
mainentry = buffer + 32*(file->DirEntryNum-1);
// write new properties
mainentry[11] = file->Attr;
// mainentry[12] = file->NTRes;
mainentry[13] = file->CrtTmTenth;
WriteInt32(mainentry+14, file->CreatTimeDate);
WriteInt16(mainentry+18, file->LastAccDate);
WriteInt16(mainentry+20, file->FirstCluster>>16);
WriteInt16(mainentry+26, file->FirstCluster);
WriteInt32(mainentry+28, (file->Attr&FSATTR_DIR) ? 0 : file->FileSize);
WriteInt32(mainentry+22, file->WriteTimeDate);
...

Unless this would be on a FAT32 volume, it would be invalid to overwrite the contents of the 16-bit entry at offset 20 with the high cluster (unless this would hold the original contents when opening the file - however, this would make it necessary to change the usage of the FirstCluster variable as cluster variable).

Same as before, this code is consistent with the MS FAT specification, so it's not a bug at all and should be compatible with all other compliant FAT implementations.

(08-01-2016 01:31 AM)matthiaspaul Wrote: For some reasons, restoring the original value of the NTRes byte was commented out here. This byte is used for various purposes. It is important that the implementation does not change the contents of bits 7-5 and 2-0. It may change bits 3 and 4 when dealing with LFNs, and it may clear all bits when creating a new file. However, in an already existing file, the bits must not be changed.

That's exactly the reason why it's commented out: the bits must not be changed. This function does read-modify-write on an existing entry, only to update the size, date, etc. when you close the file, and it only modifies what needs to be modified, then writes back.

(08-01-2016 01:31 AM)matthiaspaul Wrote: In the following file:

https://sourceforge.net/p/newrpl/sources...direntry.c
fsdeletedirentry.c

the following excerpt can be found:

...
mainentry = buffer;

for (f = 0; f < file->DirEntryNum; ++f, mainentry += 32) {
mainentry[0] = 0xE5;
}
...

This should be changed to something like the following in order to allow files to be undeleted without having to enter the first character of the files again:

...
mainentry = buffer;

for (f = file->DirEntryNum; f > 0; --f, mainentry += 32) {
if (f == 1) {
mainentry[0x0D] = mainentry[0]; // save 1st char of SFN at 0x0D for later undeletion (overwrite no longer needed creation ms)
(u32*)mainentry[0x0E] = 0; // clear 0x0E..0x11 creation date & time of deleted file
}
mainentry[0] = 0xE5;
}
...

Is this something standard that many undelete programs use? or it's just the undelete feature of DR-DOS? I wonder if it's worth supporting or not (same as the other changes you suggested). I can't find any specifications other than the sections of Wikipedia, most of them written also by you so it seems pertinent to ask you the question.
I don't mean to disrespect your work on DR-DOS, I'm just not trying to rewrite DR-DOS but RPL :-), disk access is a secondary feature that as long as it's standards compliant doesn't deserve much attention, especially while we have only 20% of the RPL commands implemented.
These bugs you found so far are not actual bugs, but minor incompatibilities with a particular variant of FAT that's not widely in use today (unless you tell me Linux and Windows have incorporated these changes lately, then I'll be forced to do it).
Now these code changes seem simple and doable, so I might incorporate them just for good measures to bullet-proof the code in case of corrupted data.
Now if you volunteer to improve and maintain newRPL's file system... that's a different story, then you can do all these changes and more while I work on RPL :-)

RMollov · (This post was last modified: 08-03-2016 12:22 AM by RMollov.)

(08-02-2016 04:59 PM)Claudio L. Wrote:
(08-02-2016 04:01 AM)RMollov Wrote: With previous built batteries lasted at least a week and they weren't fresh too.
Cheers

Nothing changed from previous build, except now SD card is enabled. Do you have an SD card inserted permanently or not?

Yes, it's plugged-in all the time. Could this cause battery drain even when turned off? I'll give it another go with SD card kept out to see what happens and will report.
Cheers

Claudio L. · 08-03-2016, 02:40 AM

(08-03-2016 12:17 AM)RMollov Wrote: Yes, it's plugged-in all the time. Could this cause battery drain even when turned off? I'll give it another go with SD card kept out to see what happens and will report.
Cheers

Yes, please, if they last longer then at least I know where to look.

RMollov · 08-08-2016, 06:41 AM

(08-03-2016 02:40 AM)Claudio L. Wrote:
(08-03-2016 12:17 AM)RMollov Wrote: Yes, it's plugged-in all the time. Could this cause battery drain even when turned off? I'll give it another go with SD card kept out to see what happens and will report.
Cheers

Yes, please, if they last longer then at least I know where to look.

No good, another set of fresh batteries dead after 4 days without the SD card...

Claudio L. · 08-08-2016, 01:04 PM

(08-08-2016 06:41 AM)RMollov Wrote: No good, another set of fresh batteries dead after 4 days without the SD card...

Only 4 days? That's a massive current leak. The good news is we ruled out the SD card pins as the problem, the bad news is that it doesn't solve the problem.

matthiaspaul · (This post was last modified: 09-10-2016 01:51 PM by matthiaspaul.)

Hi Claudio.

(08-02-2016 07:14 PM)Claudio L. Wrote: I had a deeper look at these issues. I don't know where specifically you mention that a variant of the BPB needed to be detected.

I mentioned BPB issues as I thought they would be an obvious example, however, as it's quite complicated to reliably detect the correct BPB format, I planned to discuss this later in conjunction with other stuff related to disk login (there are several issues).

Quote:This implementation avoids anything that's non-standard, it's based directly on an official specification by MS (second external link on Wikipedia).

Unfortunately, Microsoft's "spec" is full of bugs and omissions, leaving out many important details. It is impossible to implement a 100% compatible FAT filesystem relying on this spec alone.

Quote:
Quote:The LONGMASK (0x0F) condition above is incomplete. On FAT12 and FAT16 volumes, the attribute combination 0x0F can also occur as part of a valid pending delete file under DELWATCH...
This seems to be only happening on one (yours?) non-standard implementation of FAT 12/16, incompatible with the FAT32 spec.

DELWATCH is DR DOS' dynamically loadable deletion tracking component. It hooks into and expands the FDOS to track and protect deleted files to allow reliable later undeletion, regardless of the number of subsequent writes to the volume, its fill level and fragmentation status, to a limited extent even of several versions of the same file. It can be configured to check for various patterns, filenames, attributes, ownerships, dates, ages, count of queued files, etc.). DELWATCH also enables the FDOS to use more sophisticated allocation strategies than the default ones (discussed last week).

Discussing DELWATCH's inner workings is not in the focus here, however, it is important to note that DELWATCH utilizes the volume attribute to do its magic. This volume attribute trick was later copied by Microsoft for their VFAT LFN implementation.

The good news is that both features can coexist peacefully on the same volume, but it is nevertheless important to distinguish between DELWATCH and VFAT entries. If you do not, your VFAT implementation will misinterpret DELWATCH entries as LFN entries causing all sorts of strange effects - potentially up to serious crashes or filesystem corruption (I'd have to closer analyze your code to examine how your implementation would actually react on this, but it should be obvious that it will cause problems - and at least on FAT12 and FAT16 volumes it is easy to avoid such problems).

Quote:While this is simple to support, I'm not sure it's in the best interest of the newRPL project to put much effort into supporting these minor variants.

IMO, it should be in the best interest for any filesystem implemention to work under any conditions, which can occur in practice. At the minimum, an implementation should not malfunction but bail out safely and refuse to work with volumes containing structures not supported.
So, your implementation surely does not need to implement various peculiarities for CHS access on FAT volumes any more, as they cannot occur on an SD card. But DELWATCH entries on FAT12 or FAT16 is well among the things a good implementation should be able to deal with (passively, that is).

Quote:
(08-01-2016 01:31 AM)matthiaspaul Wrote: There's another bug when retrieving the start cluster value:

entry->FirstCluster = buffer[26] + (buffer[27]<<8) + (buffer[20]<<16) + (buffer[21]<<24);

The code above is only valid on FAT32 volumes; on FAT12 and FAT16 it would have to read as follows, as the 16-bit entry at 0x14 holds other information on those volumes:

entry->FirstCluster = buffer[0x1A] + (buffer[0x1B]<<8);

So, this could become something like:

entry->FirstCluster = buffer[0x1A] + (buffer[0x1B]<<8);
if (type == TYPE_FAT32)
entry->FirstCluster += (buffer[0x14]<<16) + (buffer[0x15]<<24);

I've seen similar code sections in quite a few other source files as well (you probably know them by heart, whereas I haven't written them down yet) and they need to be changed as well. In general, it is invalid to assume that the 16-bit entry at 0x14 in directory entries is 0 on FAT12 and FAT16 volumes.
This is fine, although the MS official specification of FAT I linked above actually says the high bytes of cluster number must be set to 0 on FAT16/FAT12 implementations.

Yes, it can be set to 0 on file creation (to initialize the reserved entry), but relying on it to be 0 as the high word of the cluster value when later opening the file will send your code to nirvana if any of the implementations for which this was declared as reserved would have changed it from 0 in the meantime.

Quote:
(08-01-2016 01:31 AM)matthiaspaul Wrote: ...
// mainentry[12] = file->NTRes;
...
WriteInt16(mainentry+20, file->FirstCluster>>16);
WriteInt16(mainentry+26, file->FirstCluster);
...

Unless this would be on a FAT32 volume, it would be invalid to overwrite the contents of the 16-bit entry at offset 20 with the high cluster (unless this would hold the original contents when opening the file - however, this would make it necessary to change the usage of the FirstCluster variable as cluster variable).
Same as before, this code is consistent with the MS FAT specification, so it's not a bug at all and should be compatible with all other compliant FAT implementations.

Unfortunately, it isn't. Even Microsoft's own implementation distinguishes between 16-bit and 32-bit values here, as on FAT12 and FAT16 volumes this entry is used for the access rights bitmap under any version of DR DOS, PalmDOS, Novell DOS, OpenDOS, DRMK, FlexOS, 4680 OS, 4690 OS, Concurrent DOS, Multiuser DOS, System Manager and REAL/32, and for the extended attributes cluster under multitasking MS-DOS 4.0/4.1, (IIRC also: PC DOS 3.4), OS/2, eComstation and Windows NT.

Quote:
(08-01-2016 01:31 AM)matthiaspaul Wrote: For some reasons, restoring the original value of the NTRes byte was commented out here. This byte is used for various purposes. It is important that the implementation does not change the contents of bits 7-5 and 2-0. It may change bits 3 and 4 when dealing with LFNs, and it may clear all bits when creating a new file. However, in an already existing file, the bits must not be changed.
That's exactly the reason why it's commented out: the bits must not be changed. This function does read-modify-write on an existing entry, only to update the size, date, etc. when you close the file, and it only modifies what needs to be modified, then writes back.

Okay, thanks for the explanation. Obviously, I am not familiar with the exact "dynamics" of your code yet. Clarifying this was exactly the reason why I brought this up for discussion.

Quote:
(08-01-2016 01:31 AM)matthiaspaul Wrote: This should be changed to something like the following in order to allow files to be undeleted without having to enter the first character of the files again:

...
mainentry = buffer;

for (f = file->DirEntryNum; f > 0; --f, mainentry += 32) {
if (f == 1) {
mainentry[0x0D] = mainentry[0]; // save 1st char of SFN at 0x0D for later undeletion (overwrite no longer needed creation ms)
(u32*)mainentry[0x0E] = 0; // clear 0x0E..0x11 creation date & time of deleted file
}
mainentry[0] = 0xE5;
}
...
Is this something standard that many undelete programs use? or it's just the undelete feature of DR-DOS? I wonder if it's worth supporting or not (same as the other changes you suggested).

It's supported by the DR-DOS and PTS-DOS families, and by WinDOS. PTS-DOS even has a CONFIG.SYS directive named SAVENAME to enable or disable this feature. Not sure about FreeDOS, RxDOS and Linux right now. It is also supported by third-party suites of disk tools like Norton Utilities and PC Tools. (As Microsoft used Central Point's library, it might be even supported by Microsoft's UNDELETE utility, but I'm not sure about that any more).

(Sidenote regarding configurability: MS-DOS and Windows 9x have a CONFIG.SYS directive named ACCDATE to enable and disable the writing of access and creation date/time stamps in order to avoid potential problems with alternative uses and for performance reasons. By default, they don't write them to superfloppies and removable disks. IIRC, you use some bitflags per volume already, perhaps SAVENAME and ACCDATE should be made configurable on a drive-by-drive basis as well.)

Quote:These bugs you found so far are not actual bugs, but minor incompatibilities with a particular variant of FAT that's not widely in use today (unless you tell me Linux and Windows have incorporated these changes lately, then I'll be forced to do it).

The SAVENAME thing above is clearly an extension - I never called it a bug. I mentioned it merely because I ran into it looking at the source code and because it is so easy to implement at virtually no costs.

However, treating a variable as a 32-bit value of which only 16-bits are actually defined (as in the cluster example) is the same as using an uninitialized variable...
Anyway, my intention was not to count bugs, but simply to help improve an implemention so that it becomes more reliable.

In general, IMHO the reason to use FAT is because it is a "universal exchange format" requiring only minimal resources to implement and still give reasonable performance at least when used as a storage and exchange medium only. I like the fact that it is supported by virtually all systems and devices, big and small, new and old. This is quite an achievement, and we shouldn't give up on this lightheartly by introducing FAT implementations which are no longer compatible with existing older systems.

I mean, if you only care about compatibility with modern versions of Windows, why not implement exFAT instead of FAT?
To me, the specification that actually makes up FAT is the combination of all existing (and reasonably well coded) implementations, in particular those in desktop operating systems.

Quote:Now these code changes seem simple and doable, so I might incorporate them just for good measures to bullet-proof the code in case of corrupted data.

Not only corrupted data, but also data related to unsupported features. Utmost reliability is paramount in a filesystem implementation, IMO.

Quote:Now if you volunteer to improve and maintain newRPL's file system... that's a different story, then you can do all these changes and more while I work on RPL :-)

Unfortunately, I don't have the time for this in the foreseeable future. What I can do is analyze the code and point out weak spots where I see them, and in some cases I may also provide (pseudo) source code snippets as (more or less) drop-in replacements.

Greetings,

Matthias

PS. Perhaps all these filesystem related discussions should be split out to a new thread in order not to bore the other readers?

matthiaspaul · 08-12-2016, 06:47 PM

(06-13-2016 07:05 PM)Claudio L. Wrote:
(06-10-2016 08:42 AM)emece67 Wrote: That's what I mean, the ability to display 1.234k or 56.345G (or even 1k123 and 56G345).
I couldn't find any reference to this way of writing being used or endorsed by any group or organization.

I have seen this convention to replace the decimal dot only in schematics and BOMs, and I always wondered were it originated. This Wikipedia article discusses its usage in conjunction with the currency symbol cifrão ("2$50")

https://en.wikipedia.org/wiki/cifrão

Perhaps this hint will help someone to track down its origin.

Greetings,

Matthias

Claudio L. · (This post was last modified: 08-13-2016 01:06 AM by Claudio L..)

(08-08-2016 06:28 PM)matthiaspaul Wrote: PS. Perhaps all these filesystem related discussions should be split out to a new thread in order not to bore the other readers?

Perhaps we should. For the time being I'm quietly working on implementing all these things, trying hard not to break anything. I implemented the new partial FAT scan feature, so far so good: much faster mount, I read and scan only 3 sectors at a time. The 3 sectors is so I don't have to deal with cluster info being "cut" between sectors in FAT12. Now I need to make it detect and use the hint in the BPB for FAT32, as well as update it when it exists.
3 sectors = 1024 clusters in FAT12, 768 in FAT16, or 384 in FAT32. With 384 free clusters, you can store 384 variables with SDSTO, or write 1.5 MB of data (assuming 4k clusters) before needing a second 3-sector scan so the user should not feel the slowdown of normal operations.

Vtile · 08-13-2016, 01:38 AM

(08-12-2016 06:47 PM)matthiaspaul Wrote:
(06-13-2016 07:05 PM)Claudio L. Wrote: I couldn't find any reference to this way of writing being used or endorsed by any group or organization.
I have seen this convention to replace the decimal dot only in schematics and BOMs, and I always wondered were it originated. This Wikipedia article discusses its usage in conjunction with the currency symbol cifrão ("2$50")

https://en.wikipedia.org/wiki/cifrão

Perhaps this hint will help someone to track down its origin.

Greetings,

Matthias

Apparently it is written in the British BS-1852 (70s? This would somewhat fit to the first appearances of the marking style to old schematics (according more google)) that specifies the coding used for Resistor and Capacitor values. I have no copy of it at my disposal.
https://en.m.wikipedia.org/wiki/BS_1852

There were reply that did point out this BS-1852.
http://electronics.stackexchange.com/que...r-resistor

Here is it "more clearly" written
http://www.matrixtsl.com/courses/ecc/ind...storCoding

matthiaspaul · 08-13-2016, 04:28 PM

(08-13-2016 01:38 AM)Vtile Wrote: Apparently it is written in the British BS-1852 (70s? This would somewhat fit to the first appearances of the marking style to old schematics (according more google)) that specifies the coding used for Resistor and Capacitor values. I have no copy of it at my disposal.

Thanks for the links and the BS 1852 hint!

Not owning a copy of it either, it would be interesting to know what the standard actually prescribes for capacitors -- I have seen "F" being used for "factor 1" with capacitors (but in one of the posts someone was talking about "C" being used as well) and "H" with inductors (although the standard does not appear to cover inductors at all).

Quite interesting, one of the posts also mentions the usage of E instead of R/F/H. I have never seen this in practice, except for when it was actually meant as shorthand E notation, like in 1E = 1E0 = 1R. Now, is 3E3 meant to be a 3k3 or a 3R3 resistor? ;-) So, something better to be avoided, but still good to know when running into some schematic using it...

Thinking about it some more, I have seen old ads using this notation with currency symbols. In particular I remember a camera equipment ad with a double-stroked dollar-like symbol (at that time, however, I was assuming it would in fact be a dollar, not a cifrão sign).

Some NLS systems even have a facility to define a special "monetary decimal separator" different from the normal "numeric decimal separator". So, there might be more to it, including a possible usage of this convention before BS 1852 and outside the area of electronics...

Greetings,

Matthias

Vtile · (This post was last modified: 08-13-2016 05:32 PM by Vtile.)

Hmm...

I think ( or "I quess" depending which is less affirmative) if someone is using the F for capacitor or H for inductor are not familiar with the system.

As that british standard ( If we keep the hypothesis that the notation did come in wider use in electronics from there ) indicates that R (resistance) is user for Resistors and C (capacitance) for Capacitors. Applying similar logic for inductor the only possible decimal marking for factor 1 would be L (inductance), suprise not I as inductace, but L as it is used in electrical calculus.

Something I just realised that it is not I, but L .. where on earth these come from a ~~latin word for 'loop' IDK~~ to honor Heinrich Lenz ( http://electronics.stackexchange.com/que...9542#29542 ).. Because I is already used for current.

Now the BS 1852 use K for kilo and M for mega. New schematics use non-capital letter k for kilo and all other kinds of markings for other magnitudes not found on that standard I assume. Some of them are atleast:

m for milli
u for mikro
n for nano
p for pico

Now the system doesn't identify the type of component for other magnitudes than 1, so they only work when used in place where environment gives the type R,L,C ie. schematics with the drawing symbols or physical device (which used to be more different in form as these days with tiny surface mount granules)

matthiaspaul · 08-13-2016, 11:35 PM

(08-13-2016 05:28 PM)Vtile Wrote: I think ( or "I quess" depending which is less affirmative) if someone is using the F for capacitor or H for inductor are not familiar with the system.

Not sure about that... Similar to "u"/"U" and "µ", I assume one reason to use "R" instead of "Ω" is that the glyphs look similar and that "Ω" is often difficult to type or not available at all (in CAD software even less so than in text processors). "R" expanding to "resistor" is certainly a nice (and influential) coincidence as well, but if that would have been the primary reason for the choice of that character, it would indicate that someone mixed up quantities with units. So, there are good arguments for both. ;-)

Quote:As that british standard [...] indicates that R (resistance) is user for Resistors and C (capacitance) for Capacitors.

Well, that's just the question. ;-) Which character is used in BS 1852 as "factor 1" decimal separator in capacitance values? If I understood you correctly, you don't have the actual standard in front of you either, or could you look it up in the meanwhile? Searching the net, I could not find that being answered with explicit reference to that standard as the source...

Greetings,

Matthias

matthiaspaul · 08-14-2016, 02:14 AM

(08-02-2016 07:14 PM)Claudio L. Wrote:
(08-01-2016 01:31 AM)matthiaspaul Wrote: // mainentry[12] = file->NTRes;
mainentry[13] = file->CrtTmTenth;
WriteInt32(mainentry+14, file->CreatTimeDate);
WriteInt16(mainentry+18, file->LastAccDate);
[...]
For some reasons, restoring the original value of the NTRes byte was commented out here. This byte is used for various purposes. It is important that the implementation does not change the contents of bits 7-5 and 2-0. It may change bits 3 and 4 when dealing with LFNs, and it may clear all bits when creating a new file. However, in an already existing file, the bits must not be changed.
That's exactly the reason why it's commented out: the bits must not be changed. This function does read-modify-write on an existing entry, only to update the size, date, etc. when you close the file, and it only modifies what needs to be modified, then writes back.

I have another question regarding this section: If NTRes is commented out because it doesn't change (except for possibly bits 4-3 during a file rename), does this imply that CreatTimeDate and CrtTmTenth do change here (they shouldn't unless during file creation)?

I could probably answer that question myself by digging deeper into the call hierarchy of your code, but as I haven't found the time for that so far and since you wrote that this piece of code is just used to modify existing entries (not to initialize new ones), setting the create date/time seems unnecessary as well here. Reinitializing with the same values read when opening the file would not cause any problems (just be redundant), but if the create date/time would be calculated afresh and applied to an already existing entry, this would not only undermine the very purpose of a create date/time stamp, but also overwrite some alternative data possibly residing at this location - which could cause problems elsewhere. So, this might be worth another close look.

Greetings,

Matthias

Vtile · (This post was last modified: 08-15-2016 12:09 AM by Vtile.)

(08-13-2016 11:35 PM)matthiaspaul Wrote:
(08-13-2016 05:28 PM)Vtile Wrote: I think ( or "I quess" depending which is less affirmative) if someone is using the F for capacitor or H for inductor are not familiar with the system.
Not sure about that... Similar to "u"/"U" and "µ", I assume one reason to use "R" instead of "Ω" is that the glyphs look similar and that "Ω" is often difficult to type or not available at all (in CAD software even less so than in text processors). "R" expanding to "resistor" is certainly a nice (and influential) coincidence as well, but if that would have been the primary reason for the choice of that character, it would indicate that someone mixed up quantities with units. So, there are good arguments for both. ;-)

Your explanation of similarities between glypths of R and omega are indeed interesting and now when you pointed it out I can see the similarities. You are correct there is a good argument for both Big Grin

This would need more digging to the history of notation in electric calculus itself.

(08-13-2016 11:35 PM)matthiaspaul Wrote:
Quote:As that british standard [...] indicates that R (resistance) is user for Resistors and C (capacitance) for Capacitors.
Well, that's just the question. ;-) Which character is used in BS 1852 as "factor 1" decimal separator in capacitance values? If I understood you correctly, you don't have the actual standard in front of you either, or could you look it up in the meanwhile? Searching the net, I could not find that being answered with explicit reference to that standard as the source...

Greetings,

Matthias

You understood my gibberish correctly, indeed I do not have the standard here (or anywhere else) with me, so that is based on those wikipedia and other internet finds at that time. I might made a too big assumption about the factor 1 marking for C, but on the other hand I can not see the unit explanation as a truely solid explanation. That assumption is made because the L.R.C markings are so widely used in electronic engineering, ie. LCR-meters (no RFH-meters), LC-circuits (no FH circuit) and so on. How it were approx. 1900 .. 1950s before Giorgi system aka mksA system, remains still a questionmark.

This starts to go way too much offtopic for a newRPL topic so maybe it should be branched out to its own.

Colour Code for Fixed Resistors for Telecommunication Purposes (B.S. 1852: 1952).
BS 1852:1975, IEC 60062:1974 Specification for marking codes for resistors and capacitors

http://ieeexplore.ieee.org/stamp/stamp.j...er=5320454
http://shop.bsigroup.com/ProductDetail/?...0010037100

EDIT: I created a new spinoff thread for this subject: http://www.hpmuseum.org/forum/thread-6685.html
-LV

Claudio L. · 08-15-2016, 03:10 PM

(08-14-2016 02:14 AM)matthiaspaul Wrote: I have another question regarding this section: If NTRes is commented out because it doesn't change (except for possibly bits 4-3 during a file rename), does this imply that CreatTimeDate and CrtTmTenth do change here (they shouldn't unless during file creation)?

I could probably answer that question myself by digging deeper into the call hierarchy of your code, but as I haven't found the time for that so far and since you wrote that this piece of code is just used to modify existing entries (not to initialize new ones), setting the create date/time seems unnecessary as well here. Reinitializing with the same values read when opening the file would not cause any problems (just be redundant), but if the create date/time would be calculated afresh and applied to an already existing entry, this would not only undermine the very purpose of a create date/time stamp, but also overwrite some alternative data possibly residing at this location - which could cause problems elsewhere. So, this might be worth another close look.

Greetings,

Matthias

I'm not sure why I didn't comment that line out. There's no need to refresh that information at all.

Nigel (UK) · 09-12-2016, 04:19 PM

(08-08-2016 01:04 PM)Claudio L. Wrote:
(08-08-2016 06:41 AM)RMollov Wrote: No good, another set of fresh batteries dead after 4 days without the SD card...

Only 4 days? That's a massive current leak. The good news is we ruled out the SD card pins as the problem, the bad news is that it doesn't solve the problem.

I've managed to obtain a second-hand HP-50g in decent condition to run newRPL on. I've flashed it and my HP-49g+ with the latest firmware.

The 49g+ power consumption is unchanged from my previous measurements - 4mA when turned off; about 42mA when the calculator is on.

The 50g draws $29\,\mu\rm A$ when turned off. However, to my great surprise it draws 48 mA when turned on and doing nothing. Is this the expected power consumption? Has the latest firmware caused a problem, or do I have an "odd" machine?

Nigel (UK)