HP50g SD Card -- 2 Questions
in [HP48]
|
Prev: XCELL
Next: HP Calculator Book at Samson Cables
From: not4mail on 13 Nov 2006 01:20 I installed a 1G SD card in a 50g w/2.09 ROM. Mostly OK, but a couple of questions: (1) When a directory from {HOME} is copied to both ERAM and SD, the resulting item (marked DIR) in ERAM is traversable via the arrow keys. The SD item (marked HPDIR) is not traversable. Is this normal? (2) After STO'ing an object in :3:"TEST/ITEM" RCL, EVAL and PURGE all work. However, after PURGEing :3:"TEST/ITEM" I've found no way to delete the empty directory :3:"TEST". This can't be right! What have I missed? I've re-formated to clear my tests, but once the card's in-use, re-formatting's probably not an option. --
From: TW on 13 Nov 2006 11:30 > (1) When a directory from {HOME} is copied to both ERAM and SD, the > resulting item (marked DIR) in ERAM is traversable via the arrow keys. > The SD item (marked HPDIR) is not traversable. Is this normal? Yes. You can only browse DOS directories on the SD card. > (2) After STO'ing an object in :3:"TEST/ITEM" RCL, EVAL and PURGE all > work. However, after PURGEing :3:"TEST/ITEM" I've found no way to > delete the empty directory :3:"TEST". This can't be right! What have > I missed? Nothing. The only way to do this is by using the computer or a 3rd party program such as my SDfiler. It wasn't ever finished however since the HPGCC filesystem had some issues with certain cards not adhering to SD standard. This has now been fixed so I hope to finish it shortly and upload the program to the hpcalc.org. TW
From: not4mail on 13 Nov 2006 04:02 On Mon, 13 Nov 2006, TW wrote: > > (1) When a directory from {HOME} is copied to both ERAM and SD, the > > resulting item (marked DIR) in ERAM is traversable via the arrow keys. > > The SD item (marked HPDIR) is not traversable. Is this normal? > > Yes. You can only browse DOS directories on the SD card. I was afraid of that. It certainly makes the SD memory less versatile. > > (2) After STO'ing an object in :3:"TEST/ITEM" RCL, EVAL and PURGE all > > work. However, after PURGEing :3:"TEST/ITEM" I've found no way to > > delete the empty directory :3:"TEST". This can't be right! What have > > I missed? > > Nothing. The only way to do this is by using the computer or a 3rd > party program such as my SDfiler. It wasn't ever finished however > since the HPGCC filesystem had some issues with certain cards not > adhering to SD standard. This has now been fixed so I hope to finish > it shortly and upload the program to the hpcalc.org. I'll be looking forward to that! It seems odd to only partially support a directory-structure. Also -- thanks for the reply. I'd pretty much exhausted sites to search and things to try. -- ..
From: John H Meyers on 13 Nov 2006 17:19 On Mon, 13 Nov 2006 13:02:50 -0600, not4mail: >> You can only browse DOS directories on the SD card >> [i.e. you can't go into a *calc* directory tree >> for a *calc* directory object stored on the card] > It certainly makes the SD memory less versatile. Why? How about if you drop an MS-DOS/Windows directory into a calculator variable -- would you expect it to be browseable in that milieu, just as if it were a directory of calculator objects? (if so, perhaps fish should drive cars and people should live in the seas :) It seems to me that what you can do with an SD card, which is actually a computer mass storage device, corresponds quite closely to what you can do with the built-in "Transfer" application, viewing the directories of "Remote PC files" and transferring those files to or from the integrated RAM-based, non-heierarchical storage system of the calculator, which bears no resemblance to an external mass storage system, and contains only specially structured calculator objects of a few special types (numbers, strings, lists, arrays, programs, symbolic expressions, libraries, etc.) In other words, the SD card acts like the file system of a remote computer, not really a calculator "port" at all, wherein reside all sorts of foreign things that are *not* calculator-compatible objects, thus it is basically available for you to transfer *computer* type files into and out of the calculator's memory system, if and only if they happen to be valid calculator objects, imported/exported into/from the calculator in the same way as any other *external* computer files (e.g. they need "HPHP49-x" headers if they are binary objects, etc.) To expect a remote computer disk to act directly like built-in mappable memory seems a bit of a stretch to me, although of course it is eventually possible to add yet another layer of programming to perform some file transfer for you and then look at the copied file, pretending that it is the original, saving you the extra step of first transferring it yourself into a built-in port or a user variable, where the built-in Filer could then handle it as an internal calculator object anyway. The only thing that the internal ARM OS doesn't provide is to delete or rename Windows (or MS-DOS) directories within the mass-storage system file structure; fortunately this is a minor omission, because those objects are both rather small and also tend to be left alone (we usually create or change them using our computer anyway, although you can at least *create* them in the calculator, just as you can even format your SD card in the calculator). So I can see why the current ARM OS was not expected to be called upon to do any more about computer file systems, because this product is still thought of as a traditional graphing calculator, based on its original platform, and not as something evolving on its own to become a computer OS, enough of which have already been developed that new products will probably be designed from the ground up to run within an existing computer OS, instead of having to build yet another computer OS on top of itself. [r->] [OFF]
From: Marcus von Cube on 13 Nov 2006 18:21
On Mon, 13 Nov 2006 16:19:57 -0600, John H Meyers wrote: >thus it is basically >available for you to transfer *computer* type files >into and out of the calculator's memory system, >if and only if they happen to be valid calculator objects, >imported/exported into/from the calculator in the same way >as any other *external* computer files (e.g. they need >"HPHP49-x" headers if they are binary objects, etc.) What's missing here is support for ASCII encoded objects. I know that it is possible to transfer them as strings, cut off the header and convert them to objects, but it's still an omission. The feature whould greatly simplify the management of calculator objects on a PC with card reader. Marcus von Cube Wehrheim, Germany -------------------------------------------------------------- http://www.mvcsys.de Cruising with eComStation and PMINEWS/2 -------------------------------------------------------------- |