Some HP-50G Questions

[John Keith]

Older MicroSD cards are slow just like old SD cards. Newer ones claim to be fast enough to record 4K video.

[cdmackay]

(12-09-2018 06:41 PM)HP67 Wrote:  It seems to me there should be no technical difference of cards based on physical format alone. If you compare specs on both you should find the difference.

yup, sorry, my comment wasn't clear: micro SD and SD should be of equivalent performance, and using an adaptor shouldn't affect that at all.

But I thought I'd noticed that a similarly branded card in micro SD format often had a lower performance rating than the same branded SD. But perhaps I was imagining that.

And counterfeit, as you say…

[Claudio L.]

(12-09-2018 11:31 PM)cdmackay Wrote:  

(12-09-2018 06:41 PM)HP67 Wrote:  It seems to me there should be no technical difference of cards based on physical format alone. If you compare specs on both you should find the difference.

yup, sorry, my comment wasn't clear: micro SD and SD should be of equivalent performance, and using an adaptor shouldn't affect that at all.

But I thought I'd noticed that a similarly branded card in micro SD format often had a lower performance rating than the same branded SD. But perhaps I was imagining that.

And counterfeit, as you say…

Here are some quick facts, that may or may not clarify anything at all

* microSD and SD are electrically identical, the adapter is just tracks to put each pin to the right place.
* SD standard has a negotiation in voltage and there's a maximum current too. The faster the card, the more current it draws, and the hotter it gets.
* Faster cards use newer protocols, they aren't any faster if an older host doesn't support the high speed protocol (the 50g being SD 1.1 compatible falls into this category, quite slow).
* microSD cards in older generations were meant for low-powered devices, therefore they were usually slower to limit power consumption. Back then, big SD cards were thought for PCs and camcorders, so performance to record video without skipping was more important.
* The previous statement is 100% untrue nowadays. microSD became the standard for phones, which have a lot of power AND demand a lot of performance. There's virtually no difference between new microSD and big SD cards.
* I had microSD cards that were very fast, but they would shut down due to overheating after less than a minute working at full blast (copying large files). I don't know if to blame the card or the host's socket poor heat dissipation. In other devices the same card would work without any issues.

Regarding boot delays:
* SD cards have a power-up delay that varies from manufacturer to manufacturer. Some cards are ready to receive commands in a few milliseconds, I had others that take 300 ms before they accept the first command. The 50g cuts down power to the card after every single operation, making it unbearably slow on those cards. I had a case of a fast card that tested on a PC was more than twice the speed of another one, but on the 50g it was 4x slower. Investigating the issue I discovered it had 190 ms startup time, ruining the performance on the 50g.
* The above statement is not true when using SDFiler, hpgcc 2.0, hpgcc3 or newRPL, all of which don't power off the card (merely stop its clock, meaning instant wake-up at the expense of a tiny current draw).
* The boot delay on the 50g is due to the ROM computing the free space, for which it needs to read the entire FAT table. The amount of data to read is therefore proportional to the number of clusters, just lower the number of clusters and your 50g boots faster.
* The recommendation to use FAT16 is only because FAT16 is limited to 65536 clusters.
* Since most objects in the 50g are small, using a large cluster size is also a waste, so it's best to use a smaller partition if possible. Now that Windows finally mounts all partitions, I think it's wise to create a first partition with 128 MB (FAT16) and the rest in a FAT32 volume for bigger files.

I hope it saves you some reading from other old threads.

[edryer]

Wow, thank you Claudio!

Would you happen to know if we used a 4GB SD (the non HC rare ones that follow the SD spec) would it work? These are difficult to find I know. I did have one a long time ago in a camera that could only take 2GB max and it worked fine.

I can see them on eBay for around 20 Euros for a non name brand (may not even be real). I expect a decent named brand 4GB SD non HC to reach quite a bit more... probably more than a 128GB or even 256GB card. Crazy.

[rprosperi]

(12-10-2018 08:20 PM)edryer Wrote:  Wow, thank you Claudio!

Would you happen to know if we used a 4GB SD (the non HC rare ones that follow the SD spec) would it work? These are difficult to find I know. I did have one a long time ago in a camera that could only take 2GB max and it worked fine.

I can see them on eBay for around 20 Euros for a non name brand (may not even be real). I expect a decent named brand 4GB SD non HC to reach quite a bit more... probably more than a 128GB or even 256GB card. Crazy.

Here's a 2GB Transcend card for < $9.00 from Amazon. Known to work fine with the 50g, I've used many of these. If you need more than 2GB of storage in your 50g, then you're quite probably doing something very wrong...

[Claudio L.]

(12-10-2018 08:20 PM)edryer Wrote:  Wow, thank you Claudio!

Would you happen to know if we used a 4GB SD (the non HC rare ones that follow the SD spec) would it work? These are difficult to find I know. I did have one a long time ago in a camera that could only take 2GB max and it worked fine.

I can see them on eBay for around 20 Euros for a non name brand (may not even be real). I expect a decent named brand 4GB SD non HC to reach quite a bit more... probably more than a 128GB or even 256GB card. Crazy.

Unfortunately, while the SD specification allowed a lot of freedom to card manufacturers, software developers didn't care to implement all possible cases.
Large SD cards use larger sectors (this Wikipedia article might interest you), and developers simply reused their old code from DOS era with 512-byte hard-coded sector size.
The thing is, the SD card specification allows partial sector read/write, so you could have a card with 2048 byte sectors and still allow the host to read or write 512-byte chunks and so far so good. But the specification didn't make that part mandatory! The manufacturers went completely wild and they supported whatever bits and pieces were convenient to them.
Developers on the other hand, went completely conservative and never touched their 512-byte sector size in their code. After all, why bother supporting a feature if it will be available in only certain cards from certain manufacturers? You want your device to read all of them. As a result, the more "special" the card was, the more chances for trouble.
By the time SD 2.0 came out, the specification for SDHC made 512-byte sector support mandatory and discarded all the partial reads/writes support to keep it simple and universal.

Back to your 4GB cards: it will be hit and miss. 4 GB cards use larger sectors, if you get it from a responsible manufacturer that supported partial read/writes at 512-bytes, your poorly programmed device will be able to read it. Keep in mind that the SD card specification says 2GB is the maximum capacity for SD cards, so 4GB cards are non-standard (but unless there's a hard-coded limit, a proper driver should be able to read them). The bad part is that poorly programmed devices also had trouble doing math so close to the limit of the 32-bit integers, hence some 4GB cards are seen as 2GB cards by some devices.

I'd say stay away from the 4 GB cards, they are most likely trouble. 2 GB and lower are fine for the 50g. Unfortunately HP never updated the firmware of the 50g to support SDHC.

[DavidM]

Claudio, any plans to release an updated SDLIB that could be used in an updated SDFiler? I seem to recall you mentioning in another thread that you had updated the library after it was included with SDFiler 1.3.

I know, I know... oldRPL isn't exactly on your radar screen these days. But it never hurts to ask!

[cdmackay]

thanks very much Claudio, very helpful!

(12-10-2018 04:42 PM)Claudio L. Wrote:  * Since most objects in the 50g are small, using a large cluster size is also a waste, so it's best to use a smaller partition if possible. Now that Windows finally mounts all partitions, I think it's wise to create a first partition with 128 MB (FAT16) and the rest in a FAT32 volume for bigger files.

I don't quite get the above; the 50g would only see the first partition, wouldn't it? So why would you do that?

thanks.

[edryer]

Quote:Here's a 2GB Transcend card for < $9.00 from Amazon. Known to work fine with the 50g, I've used many of these. If you need more than 2GB of storage in your 50g, then you're quite probably doing something very wrong...

I guess I'd never use the 4GB capacity in the 50G !! However I was thinking of getting a few of these cards for some old electronics I have (2004-2006 era) and was curious about the 50G.

Claudio's note on how the spec is implemented was interesting, so I would prefer to try and find some old 4GB SD non HC cards from a reputable manufacturer.

Actually looking I can see they are quite cheap (Transcend on eBay) I very much doubt though they are genuine cards - my experience of eBay and SD Cards is that perhaps over 50% are fakes, whether manufacturer or even reported capacity in some cases.

[Claudio L.]

(12-10-2018 11:13 PM)cdmackay Wrote:  thanks very much Claudio, very helpful!

(12-10-2018 04:42 PM)Claudio L. Wrote:  * Since most objects in the 50g are small, using a large cluster size is also a waste, so it's best to use a smaller partition if possible. Now that Windows finally mounts all partitions, I think it's wise to create a first partition with 128 MB (FAT16) and the rest in a FAT32 volume for bigger files.

I don't quite get the above; the 50g would only see the first partition, wouldn't it? So why would you do that?

thanks.

Assume you want to limit the number of clusters to 65535. If you do that with a 2G partition , you end up with huge cluster size to store thy files. As a result you'll waste 99% of the space. If you create a small partition, you can store the same amount of small files, and you still have the rest of the card for other uses in the second partition, just not for the calculator or I should say only when using SDFiler.

[cdmackay]

(12-12-2018 07:40 PM)Claudio L. Wrote:  Assume you want to limit the number of clusters to 65535. If you do that with a 2G partition , you end up with huge cluster size to store thy files. As a result you'll waste 99% of the space. If you create a small partition, you can store the same amount of small files, and you still have the rest of the card for other uses in the second partition, just not for the calculator or I should say only when using SDFiler.

thanks!

[pier4r]

(12-10-2018 10:54 PM)DavidM Wrote:  Claudio, any plans to release an updated SDLIB that could be used in an updated SDFiler? I seem to recall you mentioning in another thread that you had updated the library after it was included with SDFiler 1.3.

I know, I know... oldRPL isn't exactly on your radar screen these days. But it never hurts to ask!

I second the question and I thank Claudio L. for the info about the SD cards. Finding such detailed recaps nowadays is quite tricky.

[Claudio L.]

(12-10-2018 10:54 PM)DavidM Wrote:  Claudio, any plans to release an updated SDLIB that could be used in an updated SDFiler? I seem to recall you mentioning in another thread that you had updated the library after it was included with SDFiler 1.3.

I know, I know... oldRPL isn't exactly on your radar screen these days. But it never hurts to ask!

That was a loooong time ago. I don't know if I can build SDLIB anymore. I'm not setup to build hpgcc 2.0 programs, and to be honest I don't even know if hpgcc 2.0 would build using a new gcc version.
The answer is: if you like SDLIB, it's actually included in newRPL! (you saw that one coming from a mile away, but at least pretend to be surprised ), do you have any plans to write a Filer for newRPL? (you didn't see THAT one coming, didn't you? )

[DavidM]

Touché, Claudio

Well, I wasn't sure if you still had a compiled SDLIB somewhere that was newer than the one included with SDFiler but still compatible with the ancient O/S.

I imagine (some)one could write a Filer-like app using standard newRPL instead of having to resort to C, and its performance would still be quite good! Maybe after I finish a few other non-calculator projects I'll give newRPL some more brain cycles.