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

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

Change it to SIZE(...) rather then length(...) and you will work fine I think. Basically, CAS commands don't have access to local variables yet in your version.

As a general rule, avoid any commands in lowercase. Those will be CAS commands and be much, much slower then the uppercase ones.

Right now the only way on any of the apps is to copy the source from somewhere (like this website, etc) using the built in copy/paste tools in the OS, and then paste as text. You can do it, but it is not super convenient yet.

Ive never gone anywhere, just havent posted here much. Thanks for the sentiments though.

Yes, win8/10 store.

You know better then to ask me regarding "future plans"... 

However, considering we already have an ios version, and the largest number of places it is available, it wouldn't seeme like much of a stretch for one to assume the possibility might exist elsewhere. Also, I would think android and ios would elimate the thought of some sort of Microsoft exclusivity. 

Dont forget also in the windows store for prime. x86 only at the moment, but that is another platform that could be on the list.

The announced cuts were basically exclusively over in the Hewlett Packard Enterprise company. Remember that HP is in the process of splitting into 2 companies. The calculator group stays with the company (HP Inc) that does servers, laptops, desktops, printers, etc. No real change.

Quote from: alexgt on April 24, 2015, 08:45:47 PM
Where could I contact him? And it is mostly I found when you go to the font color menu, change color, then go to the back round color and it doesn't like it very much :-(

timwessman at  hp   com for email.

Would definitely be interested. I have a hard time following here since I just don't understand the layout of things basically. Must be too old at 32.

Anyway, had fun playing your game and showed it to my old boss. She is a huge air hockey aficionado (though I would win about 75% of the time any time we played) :-)


#pragma mode( separator(.,;) integer(h32) )

//Declare function
SIFS_PROG_RUN();

//Local vars
Local ProgNum; //Prog number to display/edit
....
<snip>


You'll want to put this at the top of your source file.

The pragma line is so that anyone who has different internationalization/integer settings won't have issues. It tells: , is the separator for arguments, . is the separator for mantissa, ; terminates your command statements.

The next part is why the program isn't running. There is a error when trying to compile because the compiler has no idea what SIFS_PROG_RUN() is since you are creating it on runtime (not sure why exactly, haven't looked at the code). Hence, you should declare it as a function earlier and it will run fine.

The reason the icon isn't showing is because it isn't being sent. I went through this process: Unzip to the content directory, drag the zip file to the calculator tree and it was all sent fine. I will investigate if coming directly from a zip is having an issue or something.

Quote from: DJ Omnimaga on May 19, 2015, 04:02:16 AM
Yeah it uses compression. I wonder if it's like RLE compression?

You were right. I'd compltetely forgotten there was compression in there. Yes, it was an RLE.

Sorry for the wrong info. Either way, don't use ICON. :-)

Quote from: DJ Omnimaga on May 18, 2015, 07:09:14 PM
I do not have any image editing software that can produce 32768 color PNGs with transparency.

You don't need one. It is a fully compliant png implementation. Conversion to specific colors happens internally on load. Do you have something that will edit and save a png image? Now if you really want to have complete control down to exact colors you'll need an editor or converter that handles it at that color depth, but I seriously doubt that is needed except in possibly the most exacting uses.

Quote from: alexgt on May 18, 2015, 07:28:43 PM
I thought that ICONs were smaller than GROBs?

Exactly the opposite. ICON represents the GROB, but using a plain text hex format - two 16 bit characters to represent the single 16 bit pixel. When parsed, it creates an internal GROB from the text. You thus have used 3x the space needed then just for the GROB alone.

Quote from: Cumred_Snektron on May 18, 2015, 06:32:48 PM
A bit off topic but: What's Ebola2 for kind of library?

It comes from a statistics activity being prepared using data from the recent outbreaks to discuss logistic fits. Just happened to be the one I clicked on when adding the icon...

Quote from: DJ Omnimaga on May 18, 2015, 04:39:46 PM
Ooh that is nifty. I didn't know we could now have applications with custom icons and files this way. I will definitively have to keep this in mind when I make larger games.  Just a question, though: Are application icons and files compressed like PNGs? Because the other HP Prime format seemed extremely large and I would rather have my programs not be 400 KB large again like in 2013.

Any GROB object saved to disk is converted to a PNG. You can also load directly from a PNG file to a GROB object (it uses the headers not extension to determine if it is a PNG - so no need to restrict your filename to .png extension if desired). Note that the calculator screen is 16 bits with 1 bit for transparency on/off. You do *not* have ALPHA support, but you *do* have transparency support. So a png with a completely transparent region will have a transparent region when loaded (think sprites).

Quote
Also I didn't know that on program exit the GROB content was not cleared automatically. That might explain why some games behaved strangely after running several other ones.

Yes. There would be no way to know if the user wanted G1 or similar to be used elsewhere and hence no way to "clean" the memory up.

The act of using an ICON keyword would *also* make an object in memory that would never be freed. The ICON keyword was meant for objects where absolute speed was required and is essentially a hex representation of a bitmap. Not small at all, but absolutely fast. I would recommend not using ICON for anything however unless you really feel you have to do so. The speed difference between decoding a PNG to a G2, then using G2 for your tile copy multiple times will be essentially non-existent. Now if you read and decoded the PNG each time that would be another thing entirely...

See the screenshot where I created an icon.png with a completely transparent region. You'll note the icon has transparency around the edge of the silly little walrus... 

Quote from: Cumred_Snektron on May 18, 2015, 06:03:39 AM
Whats a GROB btw?

It's been the HP parlance for GRaphic OBject since 1989 or so.


As for the problem for which I was summoned - there are a couple of questions to ask here.

Are you really meaning to create a 1600x800 <unit> sized GROB?

If so, are you remembering that the <unit> size comes from the Cartesian grid of the current application? So if the function app is running and the user has zoomed in by 2x on the graph, your GROB size just doubled which would already cause your memory to run out. My recommendation would be to always use the _P options to specify an exact size else you are left at the mercy of what the user has done to the Cartesian grid. If you really want to use the cartesian grid, you'd better make certain you set the values to the desired setting by using the Xmin/Xmax/Ymin/Ymax. However, those only exists for about half of the apps that have graphing. Better to just pick your correct pixel size.

Are you cleaning up after the exit of the game? By this, I'd recommend clearing out your large graphics by setting them to 0 or 1 pixel in size. Else that memory will stay in use until the user either resets, or stores something else in there.

With the new firmware, I'd recommend switching to an application. That will give you access to permanent variables that aren't lost on editing, as well as files and an icon for your program. My recommendation would be:

1. Save a copy of the Quad Explorer app (this will be very tiny).
2. Make your START routine be to launch the game, as well as the Plot, Symb and Num routines.
3. In the code itself, get rid of all the uses of ICON. On the PC, you will see that the applications are now folders of the form "<name>.hpappdir". Put all your graphic assets into that directory as png files (.png on the name is not necessary for use/loading - we check the header to determine type) and they will be sent along with it when sending from the connkit.
4. Give a 38x38pix item a name of "icon.png". That will be what is used for your application icon.
5. When you want to load your png files, use G2:=AFiles("filename") or similar. I'd avoid using the AFiles(1) as that file order could change! It depends on what the underlying file system does with the files in how it lists them. Then once you have G2, you can use that to create your larger GROB. Going directly from the png decode to the blit will definitely increase load time.
6. If you have data you want to save, AFiles("name"):=G1 will store it out. You might even be able to store the PNG as built to disk. Not certain of that though due to the large sizes that appear to be involved.
7. If you have data you want saved (scores, map info, etc), do a AVars("name"):=<list_or_whatever>. Note that the primary difference between using AFiles or AVars is that AVars will allow you to use the object directly as a variable (tying MyVar for example) while AFiles will not. You have to load to a variable from AFiles before use. AVars will consume RAM when the app is loaded. AFiles will not until they are recalled to a variable.

8. To distribute your new application, just package the "name.hpappdir" in a zip file! People just need to drop that zip on the calc in the connkit and it will send the application. No messing with pasting of source. This is the strucutre we like to use for distributing HP developed apps for teacher use for example:

<ZIP>
  |-- appname.hpappdir
  |    |-- stuff
  |-- readme.txt
  |--help.pdf
  \--last file

Provided your stuff is not an hp object type (.txt, .pdf, etc) it will not be sent. Anything in the hpappdir WILL be sent as a file, but it will not recursively add things (aka, no nesting of directories in there).

A post over on the HP museum saying the calcuator was out of memory or something if you feel that was the case and have nothing else to discuss about it.

Didn't know anyone wanted a command to get the memory/flash as reported by the OS.

Any problems with a command named MEMORY() which returns a list containing { RAM, STORAGE, [future stuff if ever any] }

It would be nice to get a code blob with the so called "memory leaks" that you keep running into. As far as we can tell there isn't any relating to programming/graphic use. What does tend to happen though is that people keep making and creating full screen grobs which take 16bits per pixel internally and then *keeping* them around while making more. You just run out of memory quickly.

If I had an example though I could tell you if it is a problem on our side that needs fixing.