49g+/50 G Backup to SD Card



#21

Below is a listing of a backup routine I use on my 49g+ to back up everything to a directory on an SD card. The directory used is \bkup\YYYYMMDD.hhm, so every backup is in a unique directory. I've assigned this to an alarm that runs at 1:00 am daily so I have daily full backups. Since I have a 256 MByte card, I'm not worried about running out of storage. Every couple of weeks I go and delete the older directories.

I used a routine posted here that I'm unable to relocate, to copy everything in a port to a directory on an SD card. There is 1 syseval used to convert from a string to a global name. The backup is wrapped in a program that stores it in the variable 'bkup'.

I hope people find this useful.

Dave

%%HP: T(3)A(R)F(.);
@ Personal Backup Routine.
@
@ 5/4/2007 Started.
@ Backup User Keys to 'MyKEYS'
@ Backup Flags to 'MyFLAGS'

@ Wrap this in another wrapper to store the program into the variable "bkup"
\<<
@
@ Start of Executable
@
\<<
@ Change Directory to Home
PATH { HOME } EVAL

@ Backup User keys and flags to variables in home directory
RCLKEYS 'MyKEYS' STO
RCLF 'MyFLAGS' STO
@ Change to Std Display to generate Base Folder Name
-49 CF -50 CF
@ Generate a base folder name for the backups
@ in the format YYYYMMDD.HHM
"bkup/"
@ generate YYYY0000
DATE 100 * FP 100000000 *
@ Generate MMDD and add to YYYY0000
DATE 100 * IP 100 / DUP FP 10000 * + IP +
@ Generate .HHM. Want to keep the directory in 8.3 format
TIME 10 * IP 1000 / + \->STR +
@ Done with Base, archive Home.
@ Save latest backup name to a variable
DUP 'BackupPath' STO
@ Generate global name for backup.
DUP "/Home.bck" +
#05B15h SYSEVAL
3. \->TAG @ Generate :3:\Backup\YYYYMMDD.HHM\Home.bck
@ 06/01/2007 At this point, ARCHIVE is puking because the :3:\Backup\.. Is
@ a string instead of global name.
@ Fixed with a syseval. Doing it in user rpl didn't work because of the slashes.
ARCHIVE
@ Now I have home backed up, I can move to the ports. Use a routine from
@ hpmuseum to write port variables to a backup.

\<< @ Begin program.
"/" + @ Append to path.
SWAP PVARS DROP @ List of port variable names.
1. @ Loop index initial value.
OVER SIZE @ Loop index final value.
FOR n @
DUP n GET @ Tagged port variable name.
DUP RCL @ Port variable object.
SWAP DTAG @ Untagged port variable name.
IF @
DUP TYPE 28. == @ Library number?
THEN @
"L" SWAP + @ Prepend "L".
ELSE @
\->STR @ Quoted name within string.
2. OVER SIZE 1. - SUB @ Remove "'" name delimiters.
END @
4. PICK SWAP + @ Prepend path string.
3. \->TAG @ Tag with port number for memory card.
DUP PURGE @ Purge file if it exists.
STO @ Store object as file on memory card.
NEXT @
DROP2 @ Discard path and list.
\>> @ End program.

@ Write subroutine to a local variable.
\-> bkuppath sub

\<<
@ Check to see if there is anything in the port.
@ Check to see if SIZE == 0, if it is, then there isn't anything in the port.
0 PVARS DROP SIZE 0. IF > THEN
0 bkuppath "/Port0" + sub EVAL @ backup Port 0
END
1 PVARS DROP SIZE 0. IF > THEN
1 bkuppath "/Port1" + sub EVAL @ Backup Port 1
END
2 PVARS DROP SIZE 0. IF > THEN
2 bkuppath "/Port2" + sub EVAL @ Backup Port 2
END
"Backed up to: " bkuppath +
@ Back to the correct flag settings.
'MyFLAGS' RCL STOF
@ Go back to the original Path.
SWAP EVAL

\>>

\>>

@
@ End of Executable, start of store routine.
@
'bkup' STO
\>>


#22

Hi David.

First of all, thank you for sharing your program here.

I immediately put in onto my 50G to try it, but it errored out with a:

ARCHIVE Error:
Invalid DOS Name
message.

Seems like the ARCHIVE puking you mention in the comments is not cleared... Or - most probably - I missed something :-)

May you please help?

Thanks in advance.

Best regards.

Giancarlo

#23

You're probably using a comma instead of a decimal point, so when I create the directory name from the time, there is a comma instead of a period. Give me a couple of days and I'll fix it. I'll change the flag to be a decimal point, and then change it back at the end.

Dave


#24

Hi David.

Don't know if I got your point, but I tried several times to SST through your program in DBUG mode,

and I could see that TIME generated the number with a period.

For instance, trying it right now (it's about 8:18 AM GMT+1) it gives:

8.1826960083
and no comma is used :-?

Hope this is meaningful to you - in any case, thank you for your feedback & support.

Best regards.

Giancarlo

#25

Hi David and Giancarlo,

Giancarlo:
David's program, exactly as posted, works for me.

Quote:
Don't know if I got your point, but I tried several times to SST through your program in DBUG mode,

and I could see that TIME generated the number with a period.

For instance, trying it right now (it's about 8:18 AM GMT+1) it gives:
8.1826960083
and no comma is used :-?

I think that the concern was that if you had your "fraction mark"
mode set to use a comma instead of a period, then a valid name
wouldn't be generated. However, David's use of SysRPL command $>ID
via the SYSEVAL sequence allows any characters to be used in a
global name. The only problem is that using the comma means that
the subdirectory will be stored as a "long filename" on the card,
as well as a generated "short filename", and the filer shows only
the generated short filename, which isn't as useful. For example (on
2007-10-16, about 06:33), with the comma, the subdirectory will be
stored as both 20071610,063 and 200716~1 (or similar), but only
200716~1 will be shown in the filer. Using the period, the
subdirectory will be stored only as 20071610.063 (a "short filename"), and will be
shown as such in the filer. Note that the format of the date
portion depends on the state of flag -42.

Anyway, I think that the cause of your "Invalid DOS Name" error
lies elsewhere. In case you keyed in the program manually, perhaps
you used "\" where you should've used "/"?

Note that for a relatively long program nicely posted as David's
is, with an ASCII transfer header and proper translation
sequences, the easiest way to get it into your calculator is to
start an Edit of his post, copy and paste everything between his
[pre] and [/pre] codes to a plain text file, and transfer the
file to the calculator.

For the file as posted (including the "wrapper" program with the
'bkup' STO sequence), the BYTES command returns #BA3h and 721.5,
and after running that, BYTES on the bkup program returns #B6AFh
and 694.

David:
Your program is good as posted, and I hope you won't
mind my pointing out a few posssible improvements.

  • The { HOME } EVAL sequence can be replaced by the command HOME.
  • The -49 CF -50 CF sequence can be replaced by the command STD.
  • "Meaningful" local names are nice during development, but you can
    save a few bytes by replacing them with 1-character local names
    for the finished program.
  • After running the program, the global variables MyKEYS, MyFLAGS,
    and BackupPath are left in the home directory. Perhaps purge
    MyKEYS and MyFLAGS after their last uses in the program?

    Now that I think of it, the user keys (and alarms) are stored in
    the hidden subdirectory, which is backed up as part of the home
    directory by the ARCHIVE command and restored by the RESTORE
    command, so it isn't necessary to back them up in a global
    variable separately.

    Why bother storing BackupPath at all?

    Of course, if you really do want these variables to be left in the
    home directory when the program finishes, then suit yourself.

  • If you really want to get fancy, you could include a FixUp program
    (stored as a global variable) to be run after a RESTORE, that
    would restore the saved flags, move any libraries and port
    variables ("backup objects") back to theirs original ports, and
    delete the archived MyFLAG variable and the FixUp program itself.
    For some ideas on how to accomplish this, see Bill Wickes's
    XARCHIVE program in either of his HP 48 Insights Part I:
    Principles and Programming
    books, available in the Museum
    CD/DVD-ROM set.
  • As you've already noted, flag -51 should be forced to clear
    ("Fraction mark: .") to ensure a nice file name.
  • Regarding your #05B15h SYSEVAL sequence, this of course invokes
    the SysRPL command $>ID. A possible alternative would be to use
    the S~N command from the built-in development library, but this would have
    the disadvantage that library 256 would have to be attached when
    the program is compiled.
  • When posting programs, it's helpful to others to include the
    results from the BYTES command, perhaps as a program comment.
  • Using the wrapper program with the 'bkup' STO sequence may be
    useful for a recursive program that calls itself by name, but in
    general, it just means that the originally downloaded program will
    be left in the home directory, as well as the 'bkup' program, and
    the user will want to purge it. I think it better to just let the
    user decide the name, except in the case of those recursive
    programs, where the required name can be stated in a comment.

A basic problem with using subdirectories on the flash card is
that they can't be deleted by the calculator itself (at least with
built-in tools; some HPGCC tools may be able to); you have to use
a PC (or possibly, added on tools) to do so.

Regards,
James


Edited: 16 Oct 2007, 9:08 a.m.


#26

Hi James.

First of all, thank you for your kind support and feedback :-)

Quote:
I think that the concern was that if you had your "fraction mark" mode set to use a comma instead of a period, then a valid name wouldn't be generated

No, as far as I can remember (I'm not with my 50G at hand right now...) the calc uses a period as fraction mark (i.e. flag -51 clear).

Quote:
In case you keyed in the program manually, perhaps you used "\" where you should've used "/"?

Note that for a relatively long program nicely posted as David's is, with an ASCII transfer header and proper translation sequences, the easiest way to get it into your calculator is to start an Edit of his post, copy and paste everything between his

 and 
codes to a plain text file, and transfer the file to the calculator.

Well, actually I copied and pasted the text from David's e-mail into a plain text file on my laptop,

then copied it onto the SD and then RCL'ed it on the stack of the 50G.

Then, I run the 'IN' utility by John H. Meyers:

Quote:
\<< \->STR 3 TRANSIO RCLF SIZE 3 < #3016Bh #2F34Dh
IFTE SYSEVAL + STR\-> \>>

to translate the text into a program (forgive me for the simplification).

Subsequently, I stored it into a var named 'BKUP' and run it.

All in all, I think I didn't change a comma ;-) of the whole listing...

I get the error I quoted in my first reply when the ARCHIVE command was issued;

when I used the SST utility, I could see that the #05B15h SYSEVAL command "transformed" the double-quote delimitator into a single one - I mean something like this:

":3:\Backup\YYYYMMDD.HHM\Home.bck"

#05B15h SYSEVAL

':3:\Backup\YYYYMMDD.HHM\Home.bck'

then the ARCHIVE errored out....

OTOH, your hint about the date format gets me doubtful

Quote:
Note that the format of the date portion depends on the state of flag -42.

I'll double check as soon as I can - do you think that could be a root cause for my issue?

Please let me know if and how can I help you to help me by providing you more (detailed) information.

In the meanwhile, thank you very much for your assistance.

Best regards.

Giancarlo

#27

Hi Giancarlo,

Quote:
First of all, thank you for your kind support and feedback :-)


You're quite welcome.
Quote:
Quote:
I think that the concern was that if you had your "fraction mark" mode set to
use a comma instead of a period, then a valid name wouldn't be generated

No, as far as I can remember (I'm not with my 50G at hand right now...) the calc uses a period as fraction mark (i.e. flag -51 clear).

Quote:
In case you keyed in the program manually, perhaps you used "\" where you
should've used "/"?

Note that for a relatively long program nicely posted as David's is, with an
ASCII transfer header and proper translation sequences, the easiest way to get
it into your calculator is to start an Edit of his post, copy and paste
everything between his [pre] and [/pre] codes to a plain text file, and
transfer the file to the calculator.


Well, actually I copied and pasted the text from David's e-mail into a plain text file on my laptop,

then copied it onto the SD and then RCL'ed it on the stack of the 50G.

Then, I run the 'IN' utility by John H. Meyers:
Quote:
\<< \->STR 3 TRANSIO RCLF SIZE 3 < #3016Bh #2F34Dh
IFTE SYSEVAL + STR\-> \>>

to translate the text into a program (forgive me for the simplification).

Since no angular components are used, your calculator is using the period for
the fraction mark, and apparently you didn't include the
%%HP: T(3)A(R)F(.);
transfer header, that would work correctly.

What about the results from the BYTES command? Are your results the same as
mine?

Note that John's RCLF SIZE 3 < sequence is a clever way of distinguishing
between the 48 and 49 series, so that the correct entry point can be selected
to invoke the SysRPL command KINVISLF, which does the ASCII translations.

Quote:
Subsequently, I stored it into a var named 'BKUP' and run it.

Right, which would've created a new variable 'bkup', with the "unwrapped"
program stored in it. Or if you really stored the downloaded program as
'bkup', then the contents of 'bkup' would've been replaced by the unwrapped
program instead of creating a new variable.
Quote:
All in all, I think I didn't change a comma ;-) of the whole listing...

I get the error I quoted in my first reply when the ARCHIVE command was issued;

when I used the SST utility, I could see that the #05B15h SYSEVAL command "transformed" the double-quote delimitator into a single one - I mean something like this:

":3:\Backup\YYYYMMDD.HHM\Home.bck"

#05B15h SYSEVAL

':3:\Backup\YYYYMMDD.HHM\Home.bck'


As it should've done, except that it should be 'bkup/YYYYMMDD.HHM/Home.bck' or
'bkup/YYYYDDMM/Home.bck', depending on the state of flag -42. Note the
forward slashes ("/") instead of backslashes ("\"), and the tag (:3:)
shouldn't be within the name.
Quote:
then the ARCHIVE errored out....

Well, I'm rather at a loss as to why it works for me but not for you.

Single-stepping through the program, just before executing the ARCHIVE
command, you should have a tagged path name similar to

3.:
bkup/20071610.121/Home.bck
or
3.:
bckup/20071016.121/Home.bck
on stack level 1.
Quote:
OTOH, your hint about the date format gets me doubtful

Quote:
Note that the format of the date portion depends on the state of flag -42.

I'll double check as soon as I can - do you think that could be a root cause for my issue?

No. With flag -42 clear, the subdirectory name should be in a YYYYDDMM.HHM format,
and with flag -42 set, it should be in a YYYYMMDD.HHM format. Either way, it
shouldn't cause an error.
Quote:
Please let me know if and how can I help you to help me by providing you more (detailed) information.


Offhand, the results from the BYTES command run on your program would probably
be the most helpful.

I doubt that this has anything to do with the problem, but which ROM revision
is your 50g using?

Quote:
In the meanwhile, thank you very much for your assistance.

Again, you're welcome.

Regards,
James


#28

Hi James.

Quote:
[...] and apparently you didn't include the
%%HP: T(3)A(R)F(.);
transfer header, that would work correctly

Correct. I did not include the transfer header 'cause there was no real "transfer" but the copy'n'paste into a text file then its recalling on the stack by means of the built-in filer.

Quote:
What about the results from the BYTES command? Are your results the same as mine?

This is a major puzzling clue - in fact I get:

'BKUP'
BYTES
#7188h
702.5
and this is not the same as yours - Hmmmm....

Quote:
I doubt that this has anything to do with the problem, but which ROM revision is your 50g using?

I doubt that as well, but however here's the output of the VERSION command:

"Version HP50-C
Revision #2.09"
By the way, the SD card I used (SanDisk 512 Mb) is the "usual" one I've been currently using for any other file transfer betweeen 50G and laptop, with no major issues so far...

In case you think it might prove helpful and you're willing to take a look, here follows what I can see on stack level 1 (right column) when single-stepping through the program in DBUG mode (left column):

"bkup/"		"bkup/"
DATE 10.162007
100. 100.
* 1016.2007
FP .2007
100000000. 100000000.
* 20070000.
DATE 10.162007
100. 100.
* 1016.2007
IP 1016.
100. 100.
/ 10.16
DUP 10.16
FP .16
10000. 10000.
* 1600.
+ 1610.16
IP 1610.
+ 20071610.
TIME 22.091216809
10. 10.
* 220.91216809
IP 220.
1000. 1000.
/ .22
+ 20071610.22
\->STR "20071610.22"
+ "bkup/20071610.22"
DUP "bkup/20071610.22"
'BackupPath' 'BackupPath'
STO
DUP "bkup/20071610.22"
"/Home.bck" "/Home.bck"
+ "bkup/20071610.22/Home.bck"
#05B15h # 5B15h
SYSEVAL 'bkup/20071610.22/Home.bck'
3. 3.
\->TAG 3.: bkup/20071610.22/Home.bck
ARCHIVE ARCHIVE Error: Invalid DOS name
Recalling that checksum different from yours, would you advise to go through each single line/command of the listing to check whether some misspelling slipped in?


===[EDIT]===

I made a spell check and the only differences between David's listing and my 50G program are:

1) all the numbers are reals - i.e. I have:

-49. CF

-50. CF

and

100.

100000000. and so on

2) the argument for SYSEVAL is shown as # 5B15h with no leading zero before the "5"

..Still pointless differences, to me....

===[/EDIT]===


Thanks in advance for your precious feedbacks.

Warmest regards.

Giancarlo

Edited: 16 Oct 2007, 5:06 p.m.


#29

Hi Giancarlo,

Quote:
Correct. I did not include the transfer header 'cause there was no
real "transfer" but the copy'n'paste into a text file then its
recalling on the stack by means of the built-in filer.

And just to be certain, I did that and tried John's IN program,
and got exactly the same results as with my own program to convert
a source code string to an object.
Quote:
Quote:
What about the results from the BYTES command? Are your results the same as mine?

This is a major puzzling clue - in fact I get:
'BKUP'
BYTES
#7188h
702.5
and this is not the same as yours - Hmmmm....

Part of that may be explained by my recalling the stored object
itself to the stack (as in 'bkup' RCL BYTES) instead of using the
quoted global name (as in 'bkup' BYTES). My reasoning is that
(except for a recursive program that calls itself by name), the
name could be any valid global name that the user happens to
choose, without affecting the object's execution, and if the
quoted name is used, then its size plus 1 byte for the variable
structure is included in the size that BYTES returns; that is, it
returns the amount of memory actually used to store the variable,
but I'm more interested in the size of the program itself. But
using the name doesn't affect the BYTES command's checksum result;
that's calculated using the stored object only.

Anyway, doing 'bkup' BYTES (with the program compiled in exact
mode) returns:

# B6AFh
702.5
That's the same size that you got (an extra 8.5 bytes because of
the 4-character name), but the same checksum that I got before,
which indicates a real difference between my program and yours.
Quote:
I doubt that as well, but however here's the output of the VERSION command:
"Version HP50-C
Revision #2.09"

Okay, I was using 2.10-7, so I re-flashed to 2.09, but, as I
expected, that didn't make any difference for this program.
Quote:
By the way, the SD card I used (SanDisk 512 Mb) is the "usual" one
I've been currently using for any other file transfer betweeen 50G
and laptop, with no major issues so far...

Okay, I very much doubt that there's any problem with the card.
Quote:
In case you think it might prove helpful and you're willing to
take a look, here follows what I can see on stack level 1 (right
column) when single-stepping through the program in DBUG mode
(left column):
"bkup/"		"bkup/"
DATE 10.162007
100. 100.
* 1016.2007
FP .2007
100000000. 100000000.
* 20070000.
DATE 10.162007
100. 100.
* 1016.2007
IP 1016.
100. 100.
/ 10.16
DUP 10.16
FP .16
10000. 10000.
* 1600.
+ 1610.16
IP 1610.
+ 20071610.
TIME 22.091216809
10. 10.
* 220.91216809
IP 220.
1000. 1000.
/ .22
+ 20071610.22
\->STR "20071610.22"
+ "bkup/20071610.22"
DUP "bkup/20071610.22"
'BackupPath' 'BackupPath'
STO
DUP "bkup/20071610.22"
"/Home.bck" "/Home.bck"
+ "bkup/20071610.22/Home.bck"
#05B15h # 5B15h
SYSEVAL 'bkup/20071610.22/Home.bck'
3. 3.
\->TAG 3.: bkup/20071610.22/Home.bck

Up to here, with the program compiled in approximate mode, the
only differences that I noticed are due to the different times.
Okay, your 20071610.22 subdirectory name is an "8.2 name" (due to
being in STD mode instead of 3 FIX mode when \->STR runs) instead
of an "8.3 name", but that won't cause the ARCHIVE command to
error out; any name with only characters valid for a filename
should work as well, as long as there are no more than 8
characters before the "dot" and no more than 3 characters
following it. Even extra characters won't cause an error, they'll
simply cause it to be treated as a "long filename".
Quote:
ARCHIVE		ARCHIVE Error: Invalid DOS name

But here, my ARCHIVE command doesn't error out, and I can continue
the program to completion. Why does it error out for you but not
for me? I don't know; that doesn't make any sense to me. I note
that ARCHIVE isn't erroring out with a "Bad Argument Type", so it
isn't objecting to having a tagged name for its argument. And
since it's causing an "Invalid DOS name" error, it seems to me
that it must be recognizing the tag correctly and trying to
archive to the card. To me, it seems to act as if one (or more) of
the characters in the name isn't valid for a filename, but why?
Quote:
I made a spell check and the only differences between David's listing and my 50G program are:

1) all the numbers are reals - i.e. I have:

-49. CF

-50. CF

and

100.

100000000. and so on


Okay, I surmise that your calculator was in approximate mode when
you compiled the program with John's IN program. I edited my
program in approximate mode to recompile the zints to reals.
Quote:
2) the argument for SYSEVAL is shown as # 5B15h with no leading zero before the "5"


That's normal; although the calculator will accept leading zeros
in the source code (command line or other editor, string to be
compiled by the STR\-> command, source code file, etc.), after
compiling to an object, it will never decompile (for stack
display, editing, printing, transfer, etc.) with leading zeros.
Quote:
..Still pointless differences, to me....

I agree, and whether I compile in exact mode (so that zints are
compiled as zints) or in approximate mode (so that zints are
compiled as reals), the program works for me.

But with the program compiled in approximate mode, both the
checksum and size change. For 'bkup' RCL BYTES, I now get:

# F3A2h
722.5
This problem is really starting to bug me.

This is clutching at straws, but try this: Purge your current
program, and then, with the calculator in exact mode, run John's
IN program on the source code string again, store the resulting
"wrapper" program in a variable, and run the wrapper program to
create (or replace) the 'bkup' variable. Then do 'bkup' RCL BYTES
and see if it returns the same results that I get:

# B6AF4h
694.
I'd just like to be certain that we're both using exactly the same
program.

And of course, try out the newly compiled program.

Regards,
James


#30

Hi James.

Quote:
try this: Purge your current program, and then, with the calculator in exact mode, run John's IN program on the source code string again, store the resulting "wrapper" program in a variable, and run the wrapper program to create (or replace) the 'bkup' variable. Then do 'bkup' RCL BYTES and see if it returns the same results that I get:
# B6AF4h
694.
I'd just like to be certain that we're both using exactly the same program.

I tried exactly what you suggested, and I got:

'bkup'
RCL
BYTES

# B6AFh
694.

The newly compiled program errors out exactly as before....

Then, I started to experiment... :->

Inserting the SD into my laptop card reader and trying to rearrange the files on it, I attempted to delete a "20070717" folder but I couldn't do that!

Win2k kept on maintaining that it was "Impossible to delete" that object.

So I moved all the files but that single folder from the SD to a backing folder, then *formatted* (FAT16) the SD, then copied back onto it the files.

Guess what? Now everything went smooth with David's routine!

What I suppose is that - for unknown reasons - some bytes of the SD had been "screwed up", preventing any other instance of David's routine to operate correctly.

By the way, I had also made a cross-check using a
similar routine by Jorge Cevallos M. and it had proved successful

(I think that routine by Jorge is fine as well).


OK, the nightmare seems over now :-)

Let me thank you once again for your support and your always helpful and instructive support.

Best regards.

Giancarlo

#31

Hi Giancarlo,

I'm certainly glad to read that you found and fixed the problem.

So it was a problem with the card itself after all. I suppose that I should've guessed that; after all, I couldn't come up with any reasonable explanation for why it should work for David and me, but not for you. I was considering a possible problem with a different boot ROM version, but that seemed very unlikely.

It seems very strange to me that a problem with the card would cause an "Invalid DOS Name" error. I'd expect something like "Object In Use" or some other one of the messages that added with the 49g+ that seem to be related to the card:

"Invalid DOS Name"
"File already opened"
"Invalid File Handle"
"Invalid File Index"
"Invalid File Mode"
"Disk Full"
"Disk Format Error"
"Disk Change"
"No SD card inserted"
"Not enough ARM memory"
"DOS call unsupported"
"DOS unknown error"
"Disk Protected"
So it's all your fault, for using a corrupted SD card! ;-)

Well, seriously, it was educational; I learned a few things during this exercise.

Regards,
James

#32

Giancarlo, the other day, I was transferring some files from one SD card to another, via card readers connected to my PC. I noticed that there were some that were not on my hard drive, so I attempted to simply drag and drop it to the appropriate directory on my hard disk. But one set of files just wouldn't copy or paste or delete, as in your case, and they happened to be all stuff relating to HP calculators.

I was fairly upset at the prospect of having to lose the material through reformatting or some such operation (though probably, I could find it again on the various HP calc sites) when I decided to try to transfer them one directory at a time. That worked! Well, it did until I got to one folder. Now that I got smart, I tried now to move them one file at a time, and that worked! That is, until I got to the one offending file. It was one of the programs for a HP calc communicating with a PC.

I suspect that as new a piece of technology as flash memory devices are, no one really knows all the ways they can screw up, yet. It's hard for me to imagine that a collection of transistors can develop "bad sectors" like a piece of iron oxide coated plastic or aluminum, but there may be times or circumstances in which they might "misfire" and corrupt the data stored at that location... so badly that it becomes not only an unreadable file, but an undeletable one at that.

Oh, how did I get out of this predicament? I found myself getting a bit depressed and getting wistful and nostalgic about the old DOS days of 8088 and 80x86 computers and that wonderful set of software, the OLD Norton Utilities. Then it hit me that WinXP's got a little of that and I had the offending SD card "error-checked" (I guess it might be like the old Norton Utilities' Norton Disk Doctor) and not only did it find errors, it essentially fixed them! The bad file became a set of useless files, but now they were deletable! My SD card got saved... and the all the data (except for that one stupid file) got saved!

(I had a copy of that program on a Zip disk, which I promptly copied back onto the now working SD card.)


#33

Hi Ed.

Hey, thank you for your interesting piece of information - at least I feel a bit less dumb by now! ;-)

Best regards.

Giancarlo

#34

James:

THanks for your helpful comments.

I've saved flags, keys and the backup path for a couple of reasons. I find it useful to have my flags backed up in a variable just in case, and I was unaware the the user keys are archived. I save the backup path because the next thing to do with this is to write a restore routine, and having the backup path seems convenient.

I use the wrapper program because of the way I develop programs. I use a text editor on a PC, and copy and paste into emu49 and use emu49asc to convert it to an executable. This leave the executable on the stack, and using the wrapper let's me just press eval and I get it stored into a variable. . Once it's debugged, I save it to a sd card and retrieve it to the stack, where I repeat the process. I find that this wrapper is convenient for me, but you are correct, it's a item of confusion.

I hadn't gotten to deleting directories on the calculator yet, I'll have to ponder how to do that. This approach is easy, but has the potential error of running out of space on a small sd card. This call's for some thought.

Dave


#35

Quote:
I hadn't gotten to deleting directories on the calculator yet, I'll have to ponder how to do that. This approach is easy, but has the potential error of running out of space on a small sd card. This call's for some thought.

I believe that there's an HPGCC application, SDfiler, that can do it, but as for as I know, short of using ARM code, no one's found a way to get the calculator to delete subdirectories on the card. Let us know if you find one.

Regards,
James

#36

Quote:
I used a routine posted here that I'm unable to relocate,

I don't understand what you mean by that.
Quote:
The backup is wrapped in a program that stores it in the variable 'bkup'.

Why?

Regards,
James


#37

Hi James.

Quote:
Quote:
I used a routine posted here that I'm unable to relocate,
I don't understand what you mean by that.

I guess David means that he uses:


" [...] a routine from
@ hpmuseum to write port variables to a backup."


he was not able to retrieve from MoHPC Forum archives...

Best regards.

Giancarlo

#38

James:

It was your original routine I copied. I dug around and found your posting, in this thread

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=112771#112771

Many thanks

Dave

#39

Thank you for what looks like a fantastic backup utility.


One quick question ... What if I can't get the calculator to see the SD card? I was able to use the card to install the 2.09 update on an HP50g, but after resetting the calculator, it won't see the card.


If this is a hardware problem in the calculator (instead of operator error) I'd like to figure it out during the warranty period.


#40

Quote:
What if I can't get the calculator to see the SD card? I was able
to use the card to install the 2.09 update on an HP50g, but after
resetting the calculator, it won't see the card. If this is a
hardware problem in the calculator (instead of operator error) I'd
like to figure it out during the warranty period.

Well, of course it could be a hardware problem with the
calculator, but do try some other things first.

Do the card's contacts look clean and undamaged? Maybe try
cleaning and lightly burnishing them, with, for example, an "ink"
or "typewriter" eraser, just enough so that they look nice and
shiny. Be sure to dust off any "eraser crumbs" before trying to
use the card.

Can the card be read by a card reader on a PC? If not, then
obviously something's wrong with it; try formatting it.

Note that various disk testing utilities, such as Microsoft
ScanDisk and Norton Disk Doctor, can be used to test the card in a
card reader.

Forgive me for asking about something so basic, but are you
certain that the card is properly inserted? Label side toward the
back of the calculator, and pushed in until it's almost flush with
the bottom?

I doubt that this would help, but maybe at least temporarily try a
fresh set of AAA cells? If it doesn't help, you can set them aside
for later use.

Did the problem start immediately after flashing the ROM to 2.09?
If that's the case, then perhaps the ROM didn't really get flashed
properly. Maybe try flashing it to 2.09 again. Of course, if it
won't recognize the card, then you'll have to use Conn4x to flash
it, which really isn't all that much more difficult. But to use
Conn4x, you'll have to be using an MS Windows OS.

I suppose that it's possible that RAM somehow got corrupted, and
that that's somehow causing the calculator to fail to recognize
the card. To check for this possibility, first do a RCLF and STO
the flag list to a global variable, then use the ARCHIVE command
to back up user memory to port 2, or use Conn4x's "Backup..."
function to back it up to a PC. If you have anything in port 0
(which I don't recommend when any other port is available), also
back this up to some safe place. After you're certain that the
home directory and anything in port 0 is safely backed up, do a
memory clear by holding down the ON, A, and F keys together, and
then releasing F, A, and ON in that order. This gets you to the
TTRM ("Try To Recover Memory?") display. Press NO to clear user
memory and port 0, and also to restore the RAM reserved for system
use to its default state. Now try the card. Later, recall the
backup object created by ARCHIVE to the stack, and do a RESTORE
command, then RCL your flag list, and do a STOF. If you had
anything in port 0, then decide what to do with it; preferably, it
should be stored in port 1 or 2.

It could be that the card's file system somehow got corrupted.

Maybe try formatting the card with the calculator: Hold down ON,
press and release F, and then release ON; this should give you a
self-tests display. With the card inserted, press the - key for
the CARD utilities. If you get a "PLEASE INSERT CARD" message,
then try formatting the card with a PC instead. If you get a
"1.TEST" "2.FORMAT" message, then the calculator has detected the
card; press the 2 key for the FORMAT utility, then press the 1 key
to actually start formatting. If the "WAITING......" message is
displayed for more than a few seconds, then try formatting the
card with a PC instead. Wait for the "FORMAT FINISH" message and
then press ENTER to exit to the card utility display. Now press
the 1 key to run a card test (which, if the card is good, will
return a "TEST OK" message, but apparently, a "TEST OK" message
doesn't necessarily mean that the card really is "good"; see
below), and then follow the prompts to back out and do a reboot.

And yes, I do realize that the filer includes a FORMAT operation
if a card is detected, but I've had occasions when that failed but
the self-test FORMAT operation worked. Maybe the filer's FORMAT
operation does only a "quick" format instead of a "full" format?
That's something that I've never checked on.

If the above doesn't work, then try formatting the card in a card
reader on a PC.

If you still can't get the card to work, then try a different
card; they're reasonably low-cost these days, and even the lowest
capacity cards ever made are plenty big enough for typical uses
with the calculator.

If a "known-good" card, correctly formatted to a FAT12, FAT16, or
FAT32 file system (especially if tested in a different 50g or a
49g+), won't work in the calculator after a memory clear, then I'd
conclude that the calculator very likely has a hardware problem.

For what it's worth, I was given a couple of Samsung 32MB RS-MMC
cards. If I insert either one of these cards with the calculator turned
off, then there's usually no apparent response to the ON key, and
no response to an ON&C or an ON&A&F either, even if I remove the
card and try again. A "paper-clip reset" to invoke a warmstart is
required to get it running again. The paper-clip reset also works
if the card is still inserted. If I do a warmstart with the card
inserted to get the calculator running, or I insert the card after
the calculator is already ON, then everything seems okay unless I
try to start the filer, in which case the calculator usually
"hangs" with the busy annunciator on, and won't respond to the
keyboard at all; another paper-clip reset is required to get it
running again. With the card inserted and the calculator running,
the card self-test usually returns "TEST OK", and the self-test's
FORMAT operation will usually format the card. These cards usually
seem to work okay with various card-readers on PCs. So there can
be "borderline" cards that sometimes seem to work okay in some
situations.

Formatting a card with a PC may (depending on your operating
system or formatting utility) give you more flexibility in how
it's formatted, such as file system type, cluster size, and so on.

If the calculator is turned on with a card inserted, then there
will be a delay (sometimes not really noticeable) before anything
appears in the display. Of course slower cards cause a longer
delay, but also, it seems that the larger the FATs are, or perhaps
the more clusters are in the file system (larger capacity or
smaller cluster size), the longer the delay is. If this delay
seems annoyingly long, then (for a card larger that 32MB) maybe
format it to a FAT16 file system instead of FAT32, which results
in smaller FATs and fewer (but larger) clusters. The trade-offs
are that larger clusters typically result in more slack space, the
root directory for FAT16 is limited to 512 entries (at most, when
only "short filenames" are used), and fewer files can be stored,
but these usually aren't significant problems; if you use the card
only for the calculator, then you'll probably never use up all of
the card's capacity or maximum number of files anyway, and having
many entries in the root directory can cause an annoying delay
when starting the filer.

If the filer takes an annoyingly long time to start, then make
some subdirectories and move your files from the root directory to
somewhere else in the directory "tree", or delete unwanted files
that have accumulated. The idea is to reduce the number of entries
in the root directory.

For those really "into" formatting and partitioning, the
calculator can use a card that has an MBR (Master Boot Record),
like a hard disk (cards are often supplied this way), but an MBR
isn't required on the card for it to be used with the calculator
(or a card reader); it can start out with just a "boot record"
(like an ordinary floppy disk, except that a FAT32 file system can
be used on larger cards). In the case of a card that has more than
one partition, the calculator can "see" only one partition.

Regards,
James


Edited: 19 Oct 2007, 4:27 a.m.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime... NOT meant to replace HP48,49,50 ? Chris Pem10 21 2,836 11-18-2013, 03:30 PM
Last Post: Chris Smith
  ANN: A MacOSX Kermit program for HP48/49/50 calculators Paul Onions 2 785 09-08-2013, 04:55 AM
Last Post: Paul Onions
  HP-50 on Raspberry Pi? The HP-67 come true? Matti Övermark 10 1,623 07-30-2013, 09:40 PM
Last Post: Matti Övermark
  Precision DC-50 Mic 3 840 05-26-2013, 01:27 PM
Last Post: DavidM
  downloading HO 229 v. 2,0 from HP 49/50 Astronomy Programs list Al 10 1,362 11-26-2012, 05:38 PM
Last Post: Al
  PCMCIA SD adapter for 200 LX? wildpig 4 838 08-27-2012, 08:20 AM
Last Post: Bill (Smithville, NJ)
  Symbolic limit of a function of 2 variables, HP49/50 Gilles Carpentier 0 426 08-26-2012, 10:28 AM
Last Post: Gilles Carpentier
  HP41 Card Reader not Pulling Card Colin Verrilli 14 1,888 07-29-2012, 05:53 PM
Last Post: Randy
  Best Keyboard of the HP 28/48/49/50 Series Eddie W. Shore 9 1,542 07-12-2012, 07:21 AM
Last Post: Dave Britten
  Formatting 28/48/50 programs Matt Agajanian 9 1,437 06-06-2012, 06:01 PM
Last Post: Gilles Carpentier

Forum Jump: