HP50g SD Card -- 2 Questions
not4mail
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.
--
TW
> 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
not4mail
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.
--
..
John H Meyers
>> 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]
Marcus von Cube
>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
--------------------------------------------------------------
Veli-Pekka Nousiainen
news:op.tiy6z...@w2kjhm.ia.mum.edu...
X
> 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;
I would love to see rename everywhere - also in the internal Flash
Why?
At least I can then [COPY] the name and [PASTE] to command line
so that after [ENTER] i have ti on stack and can much easier perform stuff
No even the internal Flash doesn't allow [RENAME] to even start
I don't care if it says after misspressed [ENTER] or | OK |
"Error:
Can not rename"
while I only need to copy the name and then [CANCEL]
not4mail
On Mon, 13 Nov 2006, John H Meyers wrote:
> >> 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...
> ...
Your assessment is, of course, correct.
Lacking documentation to the contrary, I'd simply expected :3: items
to be the same as :1: and :2: items. I'll adapt.
> ...
> 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).
Strictly within the 50g environment this is more than a "minor
omission." Without an external reader, card management is difficult.
--
..
not4mail
On Tue, 14 Nov 2006, Marcus von Cube wrote:
> 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.
When my 48sx died (unexpectedly in it's sleep), I downloaded emu48 and
used it to recover a PC-saved backup. I then used "emu48asc.bin" to
translate the emulator's user-rpl-binaries to ascii files with the
"%%HP: T(3)A(D)F(.);" header. Then, I transfered the ASCII files to
the 50g -- generally worked pretty well.
Point being -- would something like "emu48asc.bin" help with ASCII
object support? It appears that "asciibin.49" is the same program
(from asciibin.zip; hpcalc.org).
--
..
Gene
not4mail wrote:
> Your assessment is, of course, correct.
>
> Lacking documentation to the contrary, I'd simply expected :3: items
> to be the same as :1: and :2: items. I'll adapt.
Gene: Some documentation is available from HP that certainly indicates
several differences with how the SD card works. You can find it here:
http://h20331.www2.hp.com/Hpsub/downloads/50gUsing_an_SD_Card.pdf
John H Meyers
> the internal Flash doesn't allow [RENAME]
Because it's physically impossible, as you know;
the only way is to *copy* the file (to the same port,
then select "rename" from the menu which comes up,
if you are using the Filer).
[r->] [OFF]
John H Meyers
> What's missing here is support for ASCII encoded objects.
As always, support has come from various contributed programs,
including:
Extremely simple ascii import/export for all HP48/49/50:
http://groups.google.com/group/comp.sys.hp48/msg/78ccdda2a7e971a6
Character translation only (8-bit characters via 7-bit encoding):
http://groups.google.com/group/comp.sys.hp48/msg/d15a030ff1917086
With complete ascii header analysis & generation
(scroll way down to find the programs):
http://groups.google.com/group/comp.sys.hp48/msg/46b8bc3f34d9dfe0?dmode=source
The last of these postings includes completely safe transfer,
which means never *evaluating* what's transferred,
as even the Conn4x connection kits do
(and so do most other contributed programs).
I once suggested building this in, via UserRPL IMPORT/EXPORT commands,
but it has thus far never materialized.
[r->] [OFF]
not4mail
OK!!! Jeeze, you folks are tough!
Perhaps I should have said instead: ... expected :3: items to be more
of a *super-set* of :1: and :2: items.
Then again, if I'd used only the above cited pdf, I wouldn't have
tried the filer with the SD card, wouldn't have noticed the directory
non-traversability, wouldn't have noticed directories weren't really
purged, wouldn't have had any questions! ;)
--
..
John H Meyers
and recalling from the SD card (or copying
to or from the SD card using the Filer)
is just like cable transfer in binary mode,
which is also like "Save object" and "Load object"
in the Emu48 (or Debug4x) emulators.
In any case, it's always just like a binary transfer
to/from an external hard disk on a remote computer;
although the Filer presents it using its own
common display style, one should remember
that it's really like an external remote computer disk,
not like internal "user" object storage memory,
not an internal RAM port like port 0 or port 1,
and not like internal flash port 2 either.
[r->] [OFF]
arturo
over my head and i know that by the time i
could figure it out, it would be out-dated
( or i would ).
but overall am i correct that the sd card is
mainly for program or data storage that is
not directly accessable for use by the calc-
ulator but can be loaded into calculator for
direct use ? and is a valid use of the card
to backup everything in the calculator in case
of crash ? by valid i mean will an sd card
retain it's own data thru most of the events
that mite cause all data to be lost in the calc-
ulator itself ?
thanks, Arturo
John H Meyers
> most of what you folks are talking about
> would [become] out-dated
As soon as this calc series is out-dated, I guess.
> but overall am i correct that the sd card is
> mainly for program or data storage that is
> not directly accessable for use by the calc-
> ulator but can be loaded into calculator for
> direct use ?
The only practical difference which you would
likely notice about the SD card, which is otherwise
disguised almost like a "port 3" on 48GX,
is that calc libraries can't be attached from it
(but you can keep backups of libraries,
for re-copying back to the calc);
otherwise you can use it pretty much the same
as you can use the other numbered ports,
even though it's really an external computer disk
(having slightly different file naming rules,
containing other foreign objects which you can't use
in the calculator, etc.), which is to say
that you can only store and recall named things,
or even do :3:myprog EVAL, just as in the HP48 series.
> and is a valid use of the card
> to backup everything in the calculator in case
> of crash ? by valid i mean will an sd card
> retain it's own data thru most of the events
> that mite cause all data to be lost in the calc-
> ulator itself ?
Yes, I think that :3:mybackup ARCHIVE/RESTORE
works the same, and I've never yet heard of SD trashing
during common calc hangs or even TTRMs
(in which all "user" memory is wiped out).
Both port 2 of the 49-50 and the "port 3" SD card
are "flash" memory, which means that they retain data
without any power supply; the extra battery backup
in the 49G+/50G also helps avoid RAM loss, but of course
some RAM may get trashed by OS crashes anyway.
The nicest "extra" about SD cards, however,
is that you can slip them out of the calc
and into your computer's card reader (as a disk),
thus providing an extremely neat way to transfer files
(and backups), which it seems is generally preferred
to bothering with the cable and its extra software.
[r->] [OFF]