Join us on Discord!
You can help CodeWalrus stay online by donating here.

WARNING: HP Prime OS 10077 calc bricking & ICON command to be discontinued soon?

Started by Dream of Omnimaga, April 26, 2016, 06:00:29 PM

Previous topic - Next topic

0 Members and 9 Guests are viewing this topic.

Dream of Omnimaga

The new HP Prime firmware revision 10077 was said to improve RAM usage and fix various stability issues that were present in previous firmwares. In previous firmwares, sending large program files caused the calculator to become unstable and quickly run out of RAM.

However, it seems that the new firmware have made it even worse: When the calculator RAM is saturated, it now ends up corrupting various files stored in your flash memory. Not only this can result into data loss, but it seems like this is not limited to programs and applications, but possibly the OS, boot code and NAND as well. In other words: you could brick your calculator, with no way to get it working again, meaning $150 flushed down the toilet right before your school finals.

Unfortunately, HP workers who are active posting on TI-Planet and HP Museum initially tried to shift the entire blame on TI-Planet's PDF to picture converter, even though it was not used before Critor's calculator died for good. And even if the image tool was in use beforehand, the generated images are written in pure HP PPL, the language that is built into the calculator firmware. In other words, the cause of the calculator bricking is firmware-related (maybe a lack of amount of RAM checking during file transfers?), whether was the image tool involved or not. So we can only recommend waiting before upgrading for now. A downgrade tutorial is available here

Also, Tim Wessman announced that the ICON format will be discontinued in the next firmware update or the one after, so we recommend HP game programmers to either switch back to DIMGROB or to applications as soon as possible.

Source:
https://tiplanet.org/forum/viewtopic.php?f=55&t=18294
http://www.hpmuseum.org/forum/thread-6082-post-54475.html#pid54475

UPDATE (June 10): The old firmware has been put back online ftp://ftp.hp.com/pub/calculators/Prime/
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

utz

welp... there goes my newly found appreciation for HP :o From the thread at hpmuseum I would guess HP is being a bit more cooperative now. So let's see how the saga continues.
  • Calculators owned: TI-82, TI-83, TI-83+, TI-85, TI-86, TI-92+, Sharp PC-1403

Dream of Omnimaga

Yeah I am glad they cooperate more now. They needed to realize the bugs are triggered with only transfers of HP PPL programs and code, not Ndless-like hacks. In the last two years they often had the tendency to shift the blame on the user whenever bugs were reported.

Also @timwessman complains that ICON is being abused and have said that it will be discontinued soon. But the problem is that .hpapp transfer and editing is not even close to functional and there is no included documentation to make apps. I can't test in 10077 becauze I'm afraid of bricking my calc, but in 8151, if I edit the content of an application inside the connectivity kit such as the code, saving will crash the emulator. Also many app transfers will fail until after about 3 tries. Not to mention it takes about 3 reboots before custom apps can run properly (a spreadsheet will appear otherwise)

People still stick to ICON simply because the newer alternative is not functional enough to be viable. Not even close in fact.

As a result, I'm sticking to programs for now and if HP ever dares removing DIMGROB-based image storing support instead of just ICON storage in the next firmwares to force everyone to switch to apps and do that before the hpapp format is even close to functional, then I'm done with HP Prime programming.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

alexgt

Quote from: DJ Omnimaga on April 28, 2016, 03:41:21 PM
Yeah I am glad they cooperate more now. They needed to realize the bugs are triggered with only transfers of HP PPL programs and code, not Ndless-like hacks. In the last two years they often had the tendency to shift the blame on the user whenever bugs were reported.

Also @timwessman complains that ICON is being abused and have said that it will be discontinued soon. But the problem is that .hpapp transfer and editing is not even close to functional and there is no included documentation to make apps. I can't test in 10077 becauze I'm afraid of bricking my calc, but in 8151, if I edit the content of an application inside the connectivity kit such as the code, saving will crash the emulator. Also many app transfers will fail until after about 3 tries. Not to mention it takes about 3 reboots before custom apps can run properly (a spreadsheet will appear otherwise)

People still stick to ICON simply because the newer alternative is not functional enough to be viable. Not even close in fact.

As a result, I'm sticking to programs for now and if HP ever dares removing DIMGROB-based image storing support instead of just ICON storage in the next firmwares to force everyone to switch to apps and do that before the hpapp format is even close to functional, then I'm done with HP Prime programming.

I have no problems with data transfer or anything of the such after I figured out how to send apps.

I highly doubt that HP will take out GROBs, or DIMGROB since that is what you put files on, ex:

G1:=AFiles("catphoto.png");
//or to store stuff back into files:
AFiles("catphoto.png"):=G1;


I, luckily have not upgraded yet but I hope they release a new update that allows alpha overlays...
  • Calculators owned: Ti-84+, Ti-Nspire, Hp Prime, Broken HP Prime, HP 48SX

Dream of Omnimaga

Yeah I doubt they will either, but maybe eventually they'll take out the ability to store sprites directly into a GROB and only keep the ability to DIM a GROB with a single color?

As for app transfer, with your trick it eventually works, but often only after about three tries. During the first and second attempt, either the app won't send or the image files won't (usually the icon).
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

timwessman

QuoteHowever, it seems that the new firmware have made it even worse: When the calculator RAM is saturated, it now ends up corrupting various files stored in your flash memory. Not only this can result into data loss, but it seems like this is not limited to programs and applications, but possibly the OS, boot code and NAND as well.

So here is the thing - nobody can say what happened here at this point . No other units of the many units that have been tested on my end using critor's same files and process have show similar behavior or failures. No other person has reported a corruption or failure with a boot loader in a similar way. The only slightly similar item has been a unit that had the firmware update stop during mid-running and they had to redo the update again. To my knowledge, nobody else has seen this happen like critor reported.

Does this read to you like the sky is falling?  :w00t: <--person running around with the sky falling

Something happened - true. Until I get the unit back and someone can pull the flash chip though, there is absolutely no way to know what is going on here. The only report and demonstration of this failure is a single individual with a single unit - that later appears to have died in a mysterious way.  Is it an isolated incident? I don't know. Nobody can know anything apart from speculating at the moment unfortunately.  ???

Working with modern electronics is difficult for many reasons, and one of the most annoying things is my experience is that there *is* an acceptable rate of failure with modern components. You in fact pay higher money for items that have been more thoroughly validated, tested, and so on. That is what the whole CPU processor binning is about. Certain processors that have been tested as being able to run higher get sold for more cost. Others get traces clipped and sold for cheaper. Nothing can be absolutely perfect and things can potentially happen to components later.

Did the update do something to his unit? Definitely possible, but I feel it is unlikely. The boot loader resides in a protected area of flash. Writing to it isn't possible without first sending a very specific sequence of commands to unlock those blocks. Could that happen due to corrupted memory? Possible. However, it is just as likely that some blocks in his flash chip has some bad sectors that have functioned ok up until now, but just now failed when the most strenuous activity flash chips can possibly have (writing data) was busy ongoing.

Note I am not trying to blame him, or diminish the possibility of a problem here. Rather, I am just explaining another possibility.

QuoteUnfortunately, HP workers who are active posting on TI-Planet and HP Museum initially tried to shift the entire blame on TI-Planet's PDF to picture converter, even though it was not used before Critor's calculator died for good.

I'm sorry you seem to feel this way. My intent with the discussion of the picture converter was not to shift blame nor trivialize anything, but to point out that the way it has been implemented is extremely memory inefficient (due to the use of the ICON keyword which was intended for permanent "stay in ram continually" items) and that has exacerbated the memory problems in the past. People then complain that the memory is "leaking" which is just not true. The program asks to keep the bitmap loaded permanently and so the software complied.

In many ways this is like using bitmaps for a complete webpage. True, it works - however, users on mobile/dialup won't be happy that instead of a 500kb page you managed to make one that takes 20MB.

QuoteAlso, Tim Wessman announced that the ICON format will be discontinued in the next firmware update or the one after, so we recommend HP game programmers to either switch back to DIMGROB or to applications as soon as possible.

I believe that I said I *anticipate* it may happen. The reason is rather simple - ICON and the text to loading for DIMGROB are very non-portable. They are tied very specifically to one color encoding on a single platform. Maybe you haven't noticed that the HP Prime is now available on many more platforms, and that will potentially grow to more over time. In order to ensure that you can share programs and files directly everywhere, you have to take into account many different factors. Colors on the rgb 565 format have proven problematic elsewhere and it is probably time to change that to eliminate another source of potential problems.

It might be possible to do some tricks to convert the programs on the fly, but I honestly don't know at this point.

You now have support for extremely portable graphic objects - jpg and png - directly. They are about as standard as you can possibly get and are very easy to work with. Granted, we only support files packaged in apps at this point in time and that is a valid complaint (as is the lack of documentation about more complicated app creation).We hope to be able to extend that support into plain program files at some point, but that has some challenges of its own.

QuoteSo let's see how the saga continues.

Really? Saga?  :D

Quoteif I edit the content of an application inside the connectivity kit such as the code, saving will crash the emulator. Also many app transfers will fail until after about 3 tries. Not to mention it takes about 3 reboots before custom apps can run properly (a spreadsheet will appear otherwise)

The issue here is that we just are not getting this feedback. The overall feedback we hear matches what alexgt is reporting (works pretty well) and so therefore we have nothing to test that *isn't* working well to try and fix. Please communicate examples, example programs/apps, and/or steps (calchelp at hp.com will go to me) directly to get some attention at looking at a problem.

Frankly, I and others try our best but we can't perfectly catch every discussion or comment on the internet. I have a hard time reading this site for example due to the format it uses... something about it just makes it hard for me to find stuff. Maybe I'm just too old.  (-_(//));

QuoteI, luckily have not upgraded yet but I hope they release a new update that allows alpha overlays...

What is it you are wanting when you say "alpha overlays". PNG files do support transparency for sprites directly. We don't have alpha blending for aliases edged or anything - true. That is pretty much impossible unless we move away from the rgb565.... hmm, maybe another reason???  ;)




TW

Although I work for the HP calculator group, the comments and opinions I post here are my own.

alexgt

@DJ Omnimaga try reinstalling or renaming the app file and all files with an extension that starts with .hpapp the same new name. That might fix it because there is some residual data that gets left behind when you replace the file or delete it I think. It will eventually go away though and you can use the old name. I haven't looked into it except it happens to me when I am deleting old apps.

Quote from: timwessman on April 28, 2016, 07:20:31 PM
QuoteI, luckily have not upgraded yet but I hope they release a new update that allows alpha overlays...

What is it you are wanting when you say "alpha overlays". PNG files do support transparency for sprites directly. We don't have alpha blending for aliases edged or anything - true. That is pretty much impossible unless we move away from the rgb565.... hmm, maybe another reason???  ;)

but in the latest update  it says it has alpha blending...

any ways since reading more into the update list I can't wait to at least give it a try!
  • Calculators owned: Ti-84+, Ti-Nspire, Hp Prime, Broken HP Prime, HP 48SX

Dream of Omnimaga

@timwessman Regarding your first point, I seem to recall on TI-Planet Critor mentioning that at least another calculator was bricked and it also had that firmware installed, but I couldn't find the HP Museum topic about it. But it's entirely possible that the bricking was caused by previous firmwares. I hope someone can figure out what went wrong.

I forgot if the bricking happened on his prototype unit or the HWC unit, though. If it was the prototype then maybe it had different hardware than HWA and C that didn't support the new firmware 100%? But yeah I understand your concerns. THe issue is that on HP Museum, apparently HP developers have jumped several times on MViewer GX, falsely accusing the software of using hacks that can brick calcs even when it's not the case. The so-called hack is basically that HP team forgot to put an error check to detect if you try to open a ICON with less RAM than required (such as an error message saying Insufficient memory to continue this operation). Kinda like how on the TI-84 Plus CE, when you try to make a matrix that is larger than 400 elements, you get an error (although such low hard limit can get annoying).


Anyway the reason why I felt that HP devs shifted blames on the users when bugs were reported is because ever since bugs started being reported in 2013, users are told it's not a bug, but rather the user not using a feature properly. And sometimes when we provide examples of stuff that doesn't work (which we shouldn't even need to do in some cases, and is probably enough to deter some busy users from sending example files), it seems that they are not received, since I reported the application transfer issues with a link to Mineprime or SIFS before on MoHPC, to no avail.

As for the forum layout, do you have any suggestions of layout that you prefer? (Eg forum softwares, site names, etc) We are looking to switch in the next few years, but perhaps it's something that can be fixed earlier?
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

alexgt

I haven't had any problems with the new firmware update so far, and I have been coding very heavily. And using apps, and also I uploaded an app to my calculator with absolutely no problems. I don't know if it is the firmware or something else for you @DJ Omnimaga.
  • Calculators owned: Ti-84+, Ti-Nspire, Hp Prime, Broken HP Prime, HP 48SX

Dream of Omnimaga

@alexgt I think my issue is just that I got a lot of programs on my calc and often run many of them. I think it's a matter of rebooting the calc after every USB transfer, after disconnecting the cable. But most prime issues seems to be on a case by case basis.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

alexgt

Yeah it could be different for you then since I only have 14 programs xD
  • Calculators owned: Ti-84+, Ti-Nspire, Hp Prime, Broken HP Prime, HP 48SX

Dream of Omnimaga

I think I got about 30 and a few apps, but some programs are several hundreds KB each.

On a side note @alexgt did you upgrade yet? I am curious about if you noticed a significant performance drop with BLIT_P as a result of alpha blending addition? (Unless they didn't add it, but if that's the case then their changelog is misleading). On my older firmware I just tested with a quick program that drew a 320x240 rectangle that was originally 319x239, while also drawing the value of A (for loop) and it drew about 35 times every second. But if I displayed a 320x240 rectangle at original size, it drew about 250 times a second or maybe more.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

alexgt

I have upgraded. But I don't know if the change log is misleading or I used poor word choices when I made these posts.
Quote from: alexgt on April 28, 2016, 07:37:02 PM
Quote from: timwessman on April 28, 2016, 07:20:31 PM
QuoteI, luckily have not upgraded yet but I hope they release a new update that allows alpha overlays...

What is it you are wanting when you say "alpha overlays". PNG files do support transparency for sprites directly. We don't have alpha blending for aliases edged or anything - true. That is pretty much impossible unless we move away from the rgb565.... hmm, maybe another reason???  ;)

but in the latest update  it says it has alpha blending...

any ways since reading more into the update list I can't wait to at least give it a try!

But I will test the BLIT with this program:


EXPORT LineTimer()
A:=TICKS;
BLIT(G1); //Displays G1 on the screen (the fastest it can go)
B:=TICKS;
C:=B-A;
MSGBOX(C);
END;

and then you would replace that with the other levels of zoom.
  • Calculators owned: Ti-84+, Ti-Nspire, Hp Prime, Broken HP Prime, HP 48SX

Dream of Omnimaga

I edited my post by the way with benchmarks from a program that drew a 320x240 squares and text. But it was a different program and I lost it when I rebooted my calc.

But I just tried a modified version of your program that is more accurate I think:

EXPORT LineTimer()
BEGIN
DIMGROB_P(G1,320,240,#990000);
A:=TICKS;
BLIT_P(0,0,320,240,G1,0,0,320,240);
B:=TICKS;
C:=B-A;
MSGBOX(C);
END;

This gives me between 3 and 10 milliseconds (since it's so fast it's less accurate since the prime always had minor speed drops at times).


Here is what I get with zoom now:
EXPORT LineTimer()
BEGIN
DIMGROB_P(G1,320,240,#990000);
A:=TICKS;
BLIT_P(0,0,320,240,G1,0,0,319,239);
B:=TICKS;
C:=B-A;
MSGBOX(C);
END;

Now I get between 28 and 36.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

alexgt

Quote from: DJ Omnimaga on May 05, 2016, 02:12:31 AM
I edited my post by the way with benchmarks from a program that drew a 320x240 squares and text. But it was a different program and I lost it when I rebooted my calc.

But I just tried a modified version of your program that is more accurate I think:

EXPORT LineTimer()
BEGIN
DIMGROB_P(G1,320,240,#990000);
A:=TICKS;
BLIT_P(0,0,320,240,G1,0,0,320,240);
B:=TICKS;
C:=B-A;
MSGBOX(C);
END;

This gives me between 3 and 10 seconds (since it's so fast it's less accurate since the prime always had minor speed drops at times).


Here is what I get with zoom now:
EXPORT LineTimer()
BEGIN
DIMGROB_P(G1,320,240,#990000);
A:=TICKS;
BLIT_P(0,0,320,240,G1,0,0,319,239);
B:=TICKS;
C:=B-A;
MSGBOX(C);
END;

Now I get between 28 and 36.
Ok, and yeah I forgot to add the DIMGROB_P() xD but you meant milliseconds right?
  • Calculators owned: Ti-84+, Ti-Nspire, Hp Prime, Broken HP Prime, HP 48SX

Powered by EzPortal