HP 50g & SD Cards: Performance, Format, Notes

[rprosperi]

(09-03-2016 10:33 PM)Vtile Wrote:  

(09-03-2016 10:08 PM)JDW Wrote:  You mention 17:50 in my video, but that is the point at which I showed my continuity check between R68 and the SD card metal frame. Please explain what specific "interesting text on the PCB" that you were talking about.

That didn't actually relate to the current problem at all. The board have markings that indicates that same PCB is used for 50g, 39g and 40g from "current" production.

I've looked at the photos (and video) that JDW posted but I don't see this. Maybe I'm blind, but where do you see this?

[Vtile]

Really neat that you got your calculator working satisfactory. It were indeed the card socket that were broken.

@rprosperi
SG49A/48A/
39A/40 -11

[Claudio L.]

(09-03-2016 11:39 AM)matthiaspaul Wrote:  Tracing the WP signal to the controller would also help Claudio to implement the WP feature in newRPL.

I just found it: it's at GPD3. newRPL will support it on the next update.

[JDW]

I added the second half to my video, showing the jumper wire repair and how to clean and properly close up the unit. I edited the Youtube URL I previous posted earlier in this thread, but here is that new video again:





Thanks again to Vtile for your frame of reference checking and suggestions, and thanks also to Claudio for your guidance, and thanks to everyone else who contributed to this discussion.

The only issue now is relating to what we talked about earlier in this thread: Partitioning of SD Cards. On the other SD card that I have, which is 2GB, I partitioned it so the first partition is only 32MB so as to make the calc turn on faster. The issue is that I can only see that first 32MB partition in the 50g's File Manager, and I cannot see the larger second partition. Is this normal?

[TravisE]

I could be mistaken (haven't tried it myself), but I would assume the 50g OS only supports one partition per card, given that several other aspects of the implementation in the official 50g ROM (such as FAT long file name support) are also incomplete.

[Claudio L.]

(09-07-2016 12:25 AM)TravisE Wrote:  I could be mistaken (haven't tried it myself), but I would assume the 50g OS only supports one partition per card, given that several other aspects of the implementation in the official 50g ROM (such as FAT long file name support) are also incomplete.

You are not mistaken, that's exactly what happens. It reads the partition table, but only uses the first partition.

EDIT: BTW, so does Windows.

[JDW]

Which makes it all the more silly to partition an SD card intended for use with a 50g.

The only reason I partitioned the card was to get a faster ON time when I first turn ON the calc. But if I cannot access all the space of the SD Card via the 50g, I might as well just use a smaller SD card that is not partitioned.

[TravisE]

I have to admit that I have kept SD cards in my 50g's for so long I never even realized they caused a turn-on delay until I read this thread. Both the 1GB card my first 50g came with and the 2GB Kingston card I use with the 50g I bought a few years later (which didn't come with a card, unlike the first one) seem to yield an almost exactly 1-second power-on delay. But I'm so used to it I never really notice.

For the record, I have a TI-89 Titanium that takes nearly two seconds to become responsive when turned on, and it doesn't even support SD cards.

[JDW]

Regarding the Turn On DELAY, my 256MB SD Card, formatted inside my 50g, now causes the 50g to take 1sec. for the display to appear after pressing ON. To confirm why I put the SD back in my iMac and ran the following command in the Terminal:

diskutil info /Volumes/NO\ NAME

("NO\ NAME" because I formatted it inside the 50g.)

The Terminal then displayed the following:

Device Block Size: 512 Bytes
Allocation Block Size: 2048 Bytes

So the 50g is slow to turn ON because the Allocation Block Size is too small for this 256MB card.

To reduce the slowness I reformatted the 256MB card via the Terminal using the following command line:

diskutil partitiondisk /dev/disk3 1 MBR "MS-DOS FAT16" "SD256MB" 0B

Then I ran the following line to confirm the Allocation Block size:

diskutil info /Volumes/SD256MB

The Terminal responded:

Device Block Size: 512 Bytes
Allocation Block Size: 4096 Bytes

With that larger allocation block size, the 50g now takes 700ms to display the screen contents after pressing ON. (To time it, I Googled "Timer" and used that timer, clicking Start at the same time I press ON, and then pressing stop immediately when the screen displays. I repeated the timer test 3 times to get an accurate measurement.)

Wanting a still faster turn-on time, I launched the Disk Utility app to UNMOUNT my SD Card (but kept it inserted in my iMac), and then I used the following Terminal command line to format the SD card with a larger Allocation Block Size:

sudo newfs_msdos -F 16 -v SD256MB -c 32 /dev/disk3

(Where the "-c" sets 32 clusters of 512 bytes each, 16k total.)

And then the Terminal reported:

Device Block Size: 512 Bytes
Allocation Block Size: 16384 Bytes

Using the Google timer, I now get an ON-time of 550ms. Hmmm...


New Topic...

For the very first time, I decided to try to copy User RPL code out of a forum post here and then Paste that code directly into TextWrangler on my iMac. I then saved the text file without a file extension to my SD card using these settings:

Line Breaks: Windows (CRLF)
Encoding: Unicode (UTF-8)

I then inserted the SD card into my 50 and viewed the content of my file with the File Manager. Here's a PHOTO of what I saw on the 50g's screen:

Garbled User RPL Code

And here is the code that I copied and pasted into TextWranger:

Code:

<<
   #21d #8d BLANK "" 2 →LIST
   DUP DUP DUP DUP DUP
   6 →LIST
   TMENU
>>

I then repeated the above but this time using the following "escaped" code instead:

Code:

\<<
   #21d #8d BLANK "" 2 \->LIST
   DUP DUP DUP DUP DUP
   6 \->LIST
   TMENU
\>>

But when I view the file on the 50g in File Manager, it looks pretty similar, except that I see the "\" characters. I still see the black squares. The only thing that's fixed is that I now see "->" instead of the 3 garbled characters.

What specifically am I supposed to do when saving User RPL programs using a text editor on a computer, saving the file to the SD card?

[rprosperi]

(09-09-2016 10:33 AM)JDW Wrote:  What specifically am I supposed to do when saving User RPL programs using a text editor on a computer, saving the file to the SD card?

RPL programs (UserRPL and SysRPL) aren't actually stored internally as text (strings) they are converted to binary format during download from Conn4x. Alternately, you can create UserRPL source in SysRPL and save them to the card as strings (text files) and then on the 50g compile them using the built-in MASD compiler (ASM) in the tools menu.

To do this, you will have to learn how UserRPL is represented in SysRPL (typically, the statement FOO would appear as "xFOO"); a simple way to start exploring this is to make simple UserRPL programs, recall them to the stack and use (->S2) to convert it to a string (decompile).

[Vtile]

If you do not have already, then get it (there is also english version): http://www.hpcalc.org/details/7587

Also please note that → in example is unicode glypth (IIRC), while calculator uses custom 8-bit? character map for math and special programming characters. So it is only partially compatible with the old 8-bit ascii codepages and unicode character sets. The /<< etc. notation is some odd archaic and long time forgotten HP48 legacy notation (...that is supposed to know, since every hp50g owner have had 48sx, HP35 and HP41, sorry there is really pita blackholes in the documentation and connectivity of this product still sold new with bold statements. *HP Fail*) that is listed at the end of Advanced User Manual.

So while you often see << it actually is just graphical substitute for 50g double angle iron symbol and is not suitable of computerised copy&paste.

[DavidM]

(09-09-2016 10:33 AM)JDW Wrote:  ...I then repeated the above but this time using the following "escaped" code instead:

Code:

\<<
   #21d #8d BLANK "" 2 \->LIST
   DUP DUP DUP DUP DUP
   6 \->LIST
   TMENU
\>>

I, uhm, recognize that code for some reason...

I believe the "blocks" you are seeing in the string are actually carriage returns, which aren't typically used on RPL calcs to separate lines (line feeds are used instead).

The escaped characters in the above code are called "digraphs". If you use the HP Calculator Connectivity Kit to transfer this type of file to your 50g over a cable, it can automatically handle the conversion of those escaped characters into their RPL equivalents. I probably should have also included the header line when I originally posted that block of code, because that removes any ambiguity about the translation settings that are appropriate for its conversion. This is how the code block would look with the header:

Code:

%%HP: T(3)A(R)F(.);
\<<
   #21d #8d BLANK "" 2 \->LIST
   DUP DUP DUP DUP DUP
   6 \->LIST
   TMENU
\>>

The codes in the header signify the following:
T(3): translate all digraphs to their single character equivalents
A(R): radian mode is active (which doesn't matter for this, obviously)
F(.): the current fraction mark setting is "." (which also doesn't apply here, but is typically important)

If the string object already has the header (or if you add it), you can use James Prange's utilities to translate the program accordingly.

If you've already got the text object on the calculator (or the SD card) without the header, there is a fairly easy way to translate the digraphs using a SYSEVAL on the 50g. <INSERT STANDARD SCARY WARNING ABOUT USING SYSEVAL HERE>. Here's the required steps:

1) Set the appropriate translation mode on the calculator to 3. Easiest way:
3 TRANSIO
2) With the string on the stack (note: without the header), execute #2F34Dh SYSEVAL. You should now see the translated string in SL2 and an empty string in SL1. Carriage returns are automatically removed if you do this.
3) Drop the empty string, then execute OBJ→ (menu path: PRG - TYPE - OBJ→) on the translated string. You should now have a compiled code object on the stack.

Hope this helps!

[JDW]

Bob,

Thank you for the info.

(09-09-2016 02:45 PM)Vtile Wrote:  If you do not have already, then get it (there is also english version): http://www.hpcalc.org/details/7587

I actually downloaded that some weeks ago but experienced problems with it on my Mac. When switching the UI to English, the text in the UI becomes blocks (unreadable). I exchanged emails with the author of the English translation and we determined that I did everthing correctly but that the blocks must simply be an incompatibility with WINE/Crossover (what my Mac needs to run Windoze apps). And so, I am unable to use that particular app on my Mac and long for a native Mac app instead.


David,

Thank you again for your menu-hiding code and for your detailed reply. But I have some comments and questions.

First, the utility you pointed me to appears to be a COMM transfer tool that has nothing to do with my desired means of transferring User RPL programs from a computer to the 50g via SD card. What I want to do is be able to easily copy any System RPL code, say out of a forum post, with or without those backslashes, and with or without a header line, and then wave my magic wand to have it encoded properly such that I can save that to an SD card and then easily put it in the stack using the 50g.

So with regard to your previous post, I have the following two questions:

1. Are you saying that I can copy your posted code with header into my Mac's text editor and then save that as an extentionless text file to an SD card and then be able to insert that SD into the 50g and use it? If so, what text encoding must I use in the text editor on my Mac to properly save it to the SD card?

2. Your 3 steps involving TRANSIO and SYSEVAL work on what, exactly? For example, so long as I do NOT have a header line, and so long as the code is backslash-escaped (or does that matter?), I can paste such User RPL code into a Mac text editor and then save that as a single extentionless file to my SD card (but again, saving with what text encoding? UTF-8?) and then follow your 3 steps with success?

My apologies for the many questions, but with a little more hand-holding by you gentlemen I believe I will eventually see the light.

Thank you.

[DavidM]

(09-09-2016 11:53 PM)JDW Wrote:  First, the utility you pointed me to appears to be a COMM transfer tool that has nothing to do with my desired means of transferring User RPL programs from a computer to the 50g via SD card.

I wasn't so much trying to get you to use it as I was simply pointing out that if the transfer tool is used, you can have it manage the translation to and from "mode 3" objects (the type that have individual characters replaced by digraphs).

The digraphs may be somewhat crude, but it's about the most transportable way of expressing the special RPL characters on a wide variety of platforms that we can use. That's why you'll see them cropping up in posts from time to time.

(09-09-2016 11:53 PM)JDW Wrote:  What I want to do is be able to easily copy any System RPL code, say out of a forum post, with or without those backslashes, and with or without a header line, and then wave my magic wand to have it encoded properly such that I can save that to an SD card and then easily put it in the stack using the 50g.

Let me know when you get that wand. A lot of people would love to have one! You stated System RPL above, but for purposes of this discussion there is a distinct difference between User RPL and System RPL. In native form on the calculator, User RPL source code will have special characters scattered throughout that aren't part of the ANSI standard codepage. At the very minimum, the opening and closing brackets (each of which is a single character). Most User RPL programs will have others as well, and some commands (such as square root) have no standard ANSI in them at all.

System RPL source code on the calculator is simply standard ANSI text. Once compiled, it's a binary object, of course. But the source code character set is actually simpler than User RPL.

(09-09-2016 11:53 PM)JDW Wrote:  So with regard to your previous post, I have the following two questions:

1. Are you saying that I can copy your posted code with header into my Mac's text editor and then save that as an extentionless text file to an SD card and then be able to insert that SD into the 50g and use it? If so, what text encoding must I use in the text editor on my Mac to properly save it to the SD card?

I am, provided that you are referring to the version with the digraphs. But it will require the use of a supplemental program (James Prange's "TxtToObj") that can be found in the link that I provided in the previous post. The text encoding should be ANSI/UTF-8. I no longer use Macs on a regular basis, so there's probably other ways to do similar things that I'm sure folks here will volunteer.

(09-09-2016 11:53 PM)JDW Wrote:  2. Your 3 steps involving TRANSIO and SYSEVAL work on what, exactly? For example, so long as I do NOT have a header line, and so long as the code is backslash-escaped (or does that matter?), I can paste such User RPL code into a Mac text editor and then save that as a single extentionless file to my SD card (but again, saving with what text encoding? UTF-8?) and then follow your 3 steps with success?

They work on a string placed on the stack that starts with "\<<" and ends with "\>>". And everything in the string has to be valid, as in regular ANSI characters and all "escaped" combinations must be valid digraphs. Otherwise the parser will give up. Note that the output of the SYSEVAL step is still simply a string; it doesn't become compiled code until you execute the last step. Yes, the same method of saving the text file to the SD card as above should work. The primary difference in this second method is that source code DOES NOT have the header line. If you have that line, just use TxtToObj.

If I were in your situation, I would simply add any missing headers before saving the text file to the SD card. It's not that hard to do, and keeps you from having to mess with SYSEVALs and other extra steps.

Many moons ago when I was still using a Mac with my HP calculators (it was well before OS/X), I had a special "HP48" font that properly mapped the HP character set to the ascii codes used natively on the calculator. Using that, I could transfer files back and forth without needing to using digraphs, due to the special font allowing me to see all the proper characters. But that was a "closed system", and I wasn't in a position to share code online at the time. The landscape is quite different now. The widespread use of Unicode and a variety of code pages for character mapping has made it difficult to deal with all the possible variants of text encoding in common use. As archaic as it is, the use of digraphs is still the best way I know of to share User RPL code on a wide variety of platforms.

Note that all of this is focused solely on moving text TO the calculator. Going in the opposite direction is similar (there's an ObjToTxt command to complement TxtToObj), but there's one extra consideration: the O/S on the calculator will prepend a special series of byte codes to whatever you save on the SD card -- even a text string. You can usually delete those characters with a text editor on your computer, but there's also a library (SDFiler) that provides a command to save to the card without the header prepended.

[Claudio L.]

The hp48 code page is actually more Unicode than it seems. Except for 34 characters, the conversion is 1:1. Of course, those high characters need to be encoded in UTF-8. It shouldn't be too hard to write a userRPL program to search and replace those 34 characters, and properly encode all others in UTF-8.

Here's a useful link:

http://www.drehersoft.com/mapping-hp48-text-to-unicode/

[Vtile]

Well it is more unicode since the 7-bit legacy part is intact and what I understood the tricode also uses only the standard 7-bit ascii table. utf8/16/Unicode is a mess from eyes of average joe like me, too much diversity and "same symbols with different seasoning". </rant>

[matthiaspaul]

(09-06-2016 06:15 PM)Claudio L. Wrote:  

(09-03-2016 11:39 AM)matthiaspaul Wrote:  Tracing the WP signal to the controller would also help Claudio to implement the WP feature in newRPL.

I just found it: it's at GPD3. newRPL will support it on the next update.

Great, good news!

Matthias

[franz.b]

It has been a long time since i took the sd card out of my 50g, since win7 i suppose (last year for me).
The card is 2Gb, works fine, formatted in fat16.
After inserting it into the pc with win10 I found the "System Volume Information" folder which is practically irremovable from the card both from windows and from the calculator. I found a way by connecting it via OTG to the mobile and Android deleted the folder (and this is meant as a suggestion).
Is there a more practical way to do this cleaning? Any file manager on the calculator? any tools on win10?
Thanks

[rprosperi]

(01-04-2021 11:56 PM)franz.b Wrote:  It has been a long time since i took the sd card out of my 50g, since win7 i suppose (last year for me).
The card is 2Gb, works fine, formatted in fat16.
After inserting it into the pc with win10 I found the "System Volume Information" folder which is practically irremovable from the card both from windows and from the calculator. I found a way by connecting it via OTG to the mobile and Android deleted the folder (and this is meant as a suggestion).
Is there a more practical way to do this cleaning? Any file manager on the calculator? any tools on win10?
Thanks

In Win10, open a command window (WinKey-R, CMD, [Enter]), change to the subject drive (in my case G: ) and then:

G:> rmdir /S "system volume information" (or whatever the exact name is, and do use the quotes) and as soon as that is done (do wait to get the prompt back) remove the card, then close the cmd window.

[Massimo Gnerucci]

That folder is normally protected by casual tampering. You should get control on it by editing Access Control Lists via icacls from an elevated command prompt.

Watch this short video.