Detecting presence of SD-card on HP-50g

[cahlucas]

Hi all,
For a program, I am making it is important to detect if there is an SD card in the HP-50g. How can I best do this in system RPL? As far as I can tell there is no special command for it. Something must be possible here because the built-in filer would not be able to work with an SD card if that function were not present. The program must therefore be able to detect with a flag (TRUE/FALSE) whether an SD card is present or not. I would like to use this function in my program. Sincerely, Karel.

[DavidM]

(07-14-2021 04:38 AM)cahlucas Wrote:  For a program, I am making it is important to detect if there is an SD card in the HP-50g. How can I best do this in system RPL?

The following Saturn code object will leave TRUE on the stack if a card is present or FALSE if no formatted card is available. It can be used within a SysRPL program compiled on the 50g as needed. Full disclosure: this is not my code, it was contributed by Claudio Lapilli in the comp.sys.hp48 newsgroup long ago. All credit is due to him for this quick and efficient implementation.

Code:

CODE
   P=8
   ACCESSSD
   P=7
   A+1 P
   P=0
   GOVLNG "PushF/TLoop"
ENDCODE

[Note: always turn the calculator off before inserting or removing the SD card!] EDIT: this stipulation may not actually be needed, since it appears that the Kinpo O/S still seems to know about the card status changing without a power-on cycle.

An example of its use within a SysRPL program:

Code:

!NO CODE
!RPL
::
   "SD Card is "
   
   CODE
      P=8
      ACCESSSD
      P=7
      A+1 P
      P=0
      GOVLNG "PushF/TLoop"
   ENDCODE
   
   NOT_IT ::
      "NOT " &$
   ;
   
   "present." &$
;
@

[BINUBALL]

Hello, I have a question. I've wrote that code and executed. But result is not expected. If I have SD card on 50g, it gives FALSE. And if SD card is not present, it gives TRUE.

[Joe Horn]

(07-15-2021 02:10 AM)BINUBALL Wrote:  Hello, I have a question. I've wrote that code and executed. But result is not expected. If I have SD card on 50g, it gives FALSE. And if SD card is not present, it gives TRUE.

It works on my 50g. Are you sure that you typed PushF/TLoop and not PushT/FLoop?

[cahlucas]

(07-15-2021 12:35 AM)DavidM Wrote:  The following Saturn code object will leave TRUE on the stack if a card is present or FALSE if no formatted card is available. It can be used within a SysRPL program compiled on the 50g as needed. Full disclosure: this is not my code, it was contributed by Claudio Lapilli in the comp.sys.hp48 newsgroup long ago. All credit is due to him for this quick and efficient implementation.

Code:

CODE
   P=8
   ACCESSSD
   P=7
   A+1 P
   P=0
   GOVLNG "PushF/TLoop"
ENDCODE

Note: always turn the calculator off before inserting or removing the SD card!

Dear David,
Thank you very much for your response! I've entered the code and tested it, and it works as expected. That means I can continue with my program. Thank you very much for this! Another question: Why is it important to turn off the calculator before inserting or removing the SD card? Sincerely, Karel.

[BINUBALL]

(07-15-2021 04:51 AM)Joe Horn Wrote:  

(07-15-2021 02:10 AM)BINUBALL Wrote:  Hello, I have a question. I've wrote that code and executed. But result is not expected. If I have SD card on 50g, it gives FALSE. And if SD card is not present, it gives TRUE.

It works on my 50g. Are you sure that you typed PushF/TLoop and not PushT/FLoop?

Yes, I typed PushF/TLoop. It made me confused.

[DavidM]

(07-15-2021 04:53 AM)cahlucas Wrote:  Another question: Why is it important to turn off the calculator before inserting or removing the SD card?

Two reasons here:

1) It's generally best to make sure that the card is seated properly in any device before power is applied to the card. There's always the chance that the act of inserting the card will apply power before all of the pads are making full contact, which may not allow the card to start up properly.

2) In this specific case, the 50g's operating system checks for the presence of the card and reads directory information from it during the power on sequence. This step needs to have already been completed before using this Saturn code object, so trying to use this code if the sd card has been changed without giving the O/S a chance to detect the change will give meaningless results.

[DavidM]

(07-15-2021 02:10 AM)BINUBALL Wrote:  Hello, I have a question. I've wrote that code and executed. But result is not expected. If I have SD card on 50g, it gives FALSE. And if SD card is not present, it gives TRUE.

(07-15-2021 05:32 AM)BINUBALL Wrote:  Yes, I typed PushF/TLoop. It made me confused.

So now I'm confused. Are you saying that you typed it in as written, and that you still got the incorrect results? Or did you mean to say that you originally typed in "PushT/FLoop"?

If you meant the latter, then the typo correction should fix things. If you meant the former, then I'm not sure why your calculator would respond incorrectly to this code. It implies that the O/S is reporting an error code in response to the ACCESSSD command instead of the expected result, which could mean that there's a problem with the contents of the card. If you have another card to try, see if you encounter the same results when using the alternate card.

[BINUBALL]

(07-15-2021 10:56 AM)DavidM Wrote:  

(07-15-2021 02:10 AM)BINUBALL Wrote:  Hello, I have a question. I've wrote that code and executed. But result is not expected. If I have SD card on 50g, it gives FALSE. And if SD card is not present, it gives TRUE.

(07-15-2021 05:32 AM)BINUBALL Wrote:  Yes, I typed PushF/TLoop. It made me confused.

So now I'm confused. Are you saying that you typed it in as written, and that you still got the incorrect results? Or did you mean to say that you originally typed in "PushT/FLoop"?

If you meant the latter, then the typo correction should fix things. If you meant the former, then I'm not sure why your calculator would respond incorrectly to this code. It implies that the O/S is reporting an error code in response to the ACCESSSD command instead of the expected result, which could mean that there's a problem with the contents of the card. If you have another card to try, see if you encounter the same results when using the alternate card.

Sorry for confusing you. I change PushF/TLoop into PushT/FLoop and program now working well.

PushF/TLoop and PushT/FLoop seemed to be easy to confuse, so I said so (It made me confused).

[ijabbott]

(07-15-2021 10:37 AM)DavidM Wrote:  

(07-15-2021 04:53 AM)cahlucas Wrote:  Another question: Why is it important to turn off the calculator before inserting or removing the SD card?

Two reasons here:

1) It's generally best to make sure that the card is seated properly in any device before power is applied to the card. There's always the chance that the act of inserting the card will apply power before all of the pads are making full contact, which may not allow the card to start up properly.

The SD card power and ground pins are designed to make connection before other pins on insertion, and to break connection after other pins on removal, so indeed power will be applied before the other pads are making contact if the calculator is on during insertion. (I don't know if that is actually a problem for the calculator.)

[DavidM]

(07-15-2021 08:28 PM)ijabbott Wrote:  The SD card power and ground pins are designed to make connection before other pins on insertion, and to break connection after other pins on removal, so indeed power will be applied before the other pads are making contact if the calculator is on during insertion. (I don't know if that is actually a problem for the calculator.)

I was sure that I had read somewhere that the 49g+/50g should be turned off before inserting or removing the SD card. A quick look through the User's Manual for both of those devices doesn't seem to mention that, though. I still may have read it somewhere else, but that's where I thought I had gotten the info. So my memory is less accurate on this topic than the card currently inserted into my calculator...

Furthermore, after testing the above program with the card being inserted/removed without an intervening power cycle, it seems to still work as designed. Apparently the Kinpo O/S still knows when the card status has changed, even without a power cycle. So I'll amend the post to mention that stipulation may not apply after all.

[Claudio L.]

(07-15-2021 11:53 PM)DavidM Wrote:  

(07-15-2021 08:28 PM)ijabbott Wrote:  The SD card power and ground pins are designed to make connection before other pins on insertion, and to break connection after other pins on removal, so indeed power will be applied before the other pads are making contact if the calculator is on during insertion. (I don't know if that is actually a problem for the calculator.)

I was sure that I had read somewhere that the 49g+/50g should be turned off before inserting or removing the SD card. A quick look through the User's Manual for both of those devices doesn't seem to mention that, though. I still may have read it somewhere else, but that's where I thought I had gotten the info. So my memory is less accurate on this topic than the card currently inserted into my calculator...

Furthermore, after testing the above program with the card being inserted/removed without an intervening power cycle, it seems to still work as designed. Apparently the Kinpo O/S still knows when the card status has changed, even without a power cycle. So I'll amend the post to mention that stipulation may not apply after all.

The Kinpo OS has no caching of any kind, does not delay writes or keep any state in RAM that could be compromised if you pull the card.
Having said that, if you pull the card WHILE it's still writing on the card you will end up with a damaged file system.
In addition, some SD cards have INTERNAL caching and delayed writing, so turning off the calculator or pulling the card quickly after writing to it also risks ending up with a damaged file system.
So while you don't need to turn the calculator off, you do need to be patient and wait several seconds after you write to the card before you cut power to it. Cutting power means: turning the calculator off, pressing the reset button, pulling batteries, pulling the card out.

[DavidM]

(07-15-2021 11:48 AM)BINUBALL Wrote:  ...I change PushF/TLoop into PushT/FLoop and program now working well.

But it shouldn't, so something odd is happening with your calculator or sd card. Making that change would provide the opposite boolean value to what is intended (no card inserted -> TRUE, card is present -> FALSE).

Would you mind compiling this code on your calculator and post the results for two test cases:

1) run with card inserted
2) run with no card inserted

Thanks!

Code:

!NO CODE
!RPL
::
   CK0NOLASTWD
   RunSafeFlags ::
      64 dostws
      DOHEX
      CODE
         SAVE
         A=0 W
         P=8
         ACCESSSD
         P=15
         GOVLNG "PUSHhxsLoop"
      ENDCODE
      hxs>$
      BINT3 LAST$
   ;
;
@

The above code object performs the same basic SD operation as the original program ( P=8 ACCESSSD ), but instead of returning a boolean value, it leaves the contents of the A register on the stack as a hex string. The A register is where the ACCESSSD command leaves its results in this situation, so this program simply shows the full result of the command instead of doing something with it.

[DavidM]

(07-16-2021 01:51 PM)Claudio L. Wrote:  Having said that, if you pull the card WHILE it's still writing on the card you will end up with a damaged file system.
In addition, some SD cards have INTERNAL caching and delayed writing, so turning off the calculator or pulling the card quickly after writing to it also risks ending up with a damaged file system.
So while you don't need to turn the calculator off, you do need to be patient and wait several seconds after you write to the card before you cut power to it. Cutting power means: turning the calculator off, pressing the reset button, pulling batteries, pulling the card out.

Thanks, Claudio. That makes a lot of sense, and I think it explains why it's so easy to corrupt the file system on SD cards when used with a 49g+/50g.

[cahlucas]

(07-17-2021 12:29 PM)DavidM Wrote:  Would you mind compiling this code on your calculator and post the results for two test cases:

1) run with card inserted
2) run with no card inserted

Code:

!NO CODE
!RPL
::
   CK0NOLASTWD
   RunSafeFlags ::
      64 dostws
      DOHEX
      CODE
         SAVE
         A=0 W
         P=8
         ACCESSSD
         P=15
         GOVLNG "PUSHhxsLoop"
      ENDCODE
      hxs>$
      BINT3 LAST$
   ;
;
@

The above code object performs the same basic SD operation as the original program ( P=8 ACCESSSD ), but instead of returning a boolean value, it leaves the contents of the A register on the stack as a hex string. The A register is where the ACCESSSD command leaves its results in this situation, so this program simply shows the full result of the command instead of doing something with it.

Dear David,
The code you entered returns a string ("0") in both cases. Since it is a "0" in both cases, I wonder what the use of your program is. In any case, I can't detect if there is an SD card in my HP. Therefore, the original program discussed earlier in this thread is useful, and yours is not. Sincerely, Karel.

[DavidM]

(07-17-2021 05:07 PM)cahlucas Wrote:  The code you entered returns a string ("0") in both cases. Since it is a "0" in both cases, I wonder what the use of your program is. In any case, I can't detect if there is an SD card in my HP. Therefore, the original program discussed earlier in this thread is useful, and yours is not.

The second program is not intended to replace the original one, but rather to gather information in understanding why BINUBALL can't use the original one as posted. I'm asking BINUBALL to run this in an attempt to see why he has to use an altered version of the original program on his calculator. I never intended the program to be used for any other purpose.

If you attempt to run the second program on an emulator, the result will be meaningless (and likely "0" in all cases). I've tested it on a real 50g and 49g+ (both firmware v2.15), and it works as it should when running with and without a card present (it always gives non-zero results on my calculators).

All it does is to execute the same ACCESSSD command as the original program, and then converts the contents of the A register to a string (hex notation) and leaves it on the stack. The A register is where the ACCESSSD command leaves its results in this case, so the purpose here is simply to see what's there after the command completes.

According to the only information I've been able to find, executing the P=8 ACCESSSD sequence will leave one of two things in the lower 8 nibbles of the A register:
- the amount of free space remaining on the card, or
- an error code (as a negative number)

Claudio's program works by assuming that a negative result left in the lower 8 nibbles of A implies that a card is not present (and thus leaves FALSE on the stack). A positive number implies that a card is present (TRUE). I'd like to see BINUBALL's results to better understand why he seems to need the opposite logic with his calculator. I considered sending it as a private message instead of a post, but thought others might like to see what was going on as well.

[BINUBALL]

(07-17-2021 12:29 PM)DavidM Wrote:  

(07-15-2021 11:48 AM)BINUBALL Wrote:  ...I change PushF/TLoop into PushT/FLoop and program now working well.

But it shouldn't, so something odd is happening with your calculator or sd card. Making that change would provide the opposite boolean value to what is intended (no card inserted -> TRUE, card is present -> FALSE).

Would you mind compiling this code on your calculator and post the results for two test cases:

1) run with card inserted
2) run with no card inserted

Thanks!

Code:

!NO CODE
!RPL
::
   CK0NOLASTWD
   RunSafeFlags ::
      64 dostws
      DOHEX
      CODE
         SAVE
         A=0 W
         P=8
         ACCESSSD
         P=15
         GOVLNG "PUSHhxsLoop"
      ENDCODE
      hxs>$
      BINT3 LAST$
   ;
;
@

The above code object performs the same basic SD operation as the original program ( P=8 ACCESSSD ), but instead of returning a boolean value, it leaves the contents of the A register on the stack as a hex string. The A register is where the ACCESSSD command leaves its results in this situation, so this program simply shows the full result of the command instead of doing something with it.

It's very interesting. I've tested.

Edited) My typed code had a typo. Sorry.
P=5 -> P=15

1) run with card inserted : "395A8000"
2) run with no card inserted : "FFFFFF38"

After almost 10 times warmstart, it became like this.
1) run with card inserted : "39580000"
2) run with no card inserted : "FFFFFF38"

Edited) And recently I warmstart 50g, it gives invalid card data. Claudio's program now working with PushF/TLoop. Strange behavior, for yesterday I remembered it worked with PushT/FLoop.

Edited) After warmstart 50g, on port 0, has strange external files which 2 bytes. I can list some of strange file. Sometimes if I tried to go port 0, insufficient memory happens.

ROMPTR 0 12
ROMPTR 336 44E
PTR 894E7
PTR 9B083
PTR 9B6B6
PTR 89531
PTR BAD22
ROMPTR 177 1C1
ROMPTR FAA 180
PTR 51A02
PTR D2261
ROMPTR 4D6 56E
PTR F77E6
And so on..

[DavidM]

(07-17-2021 10:36 PM)BINUBALL Wrote:  It's very interesting. I've tested.
...
1) run with card inserted : "395A8000"
2) run with no card inserted : "FFFFFF38"

Those look like normal results. Your result for "no card inserted" is the exact same thing that I see when I have no card inserted.

With these results, I see no reason that you would have to change PushF/TLoop to PushT/FLoop for the original program to work properly. It's a mystery.

[DavidM]

(07-17-2021 10:36 PM)BINUBALL Wrote:  Edited) And recently I warmstart 50g, it gives invalid card data. Claudio's program now working with PushF/TLoop. Strange behavior, for yesterday I remembered it worked with PushT/FLoop.

Edited) After warmstart 50g, on port 0, has strange external files which 2 bytes. I can list some of strange file. Sometimes if I tried to go port 0, insufficient memory happens.

ROMPTR 0 12
...
PTR F77E6
And so on..

You were editing this about the same time I was typing my last response.

It looks like your card's filesystem may be corrupted. See Claudio's post above for some potential causes for how this may have happened.

It's probably a good time to backup the contents of the card and attempt a format/restore sequence.

[BINUBALL]

I formatted the card and backup 50g's content. Now it looks quite clean, and invalid card data not shown while warmstart.

Thanks DavidM!