Prev: XCELL
Next: HP Calculator Book at Samson Cables
From: John H Meyers on 14 Nov 2006 13:57
On Mon, 13 Nov 2006 17:21:13 -0600, Marcus von Cube wrote:

> 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]
From: not4mail on 14 Nov 2006 05:54

On Tue, 14 Nov 2006, Gene wrote:

> 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

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! ;)


--
..
From: John H Meyers on 14 Nov 2006 17:15
I think we can make an analogy that storing to
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]
From: arturo on 14 Nov 2006 17:47
most of what you folks are talking about is
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

From: John H Meyers on 14 Nov 2006 20:47
On Tue, 14 Nov 2006 16:47:59 -0600, Arturo wrote:

> 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]
First  |  Prev  | 
Pages: 1 2 3
Prev: XCELL
Next: HP Calculator Book at Samson Cables