(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?

(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 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!

(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?

(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?

(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.

(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.

(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.

(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.)

(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.

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

(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.

(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.

(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.

(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.

(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"

(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..