Firmware birthday ?

[dg1969]

Soon we will celebrate the first anniversary of the latest firmware!
Dear HP team member It's time to upload some teaser &;o)

[StephenG1CMZ]

Perhaps some of these implementation limits could be improved/expanded, now that the the Prime G2 with 8 times more Ram is becoming more widely available.
https://www.hpmuseum.org/forum/thread-13621.html

[rprosperi]

(09-09-2019 10:24 PM)StephenG1CMZ Wrote:  Perhaps some of these implementation limits could be improved/expanded, now that the the Prime G2 with 8 times more Ram is becoming more widely available.
https://www.hpmuseum.org/forum/thread-13621.html

Is 3 posts to say the same thing really the way to go here?

I'd say it would be more compelling to explain some sample application or usage where that many vector operations really makes sense being done on a handheld calculator. I'm not saying there aren't any, only that none come to mind, and the work to implement and test that, even if the RAM is available, might better be used for some of the many other places Prime could be improved.

But maybe, with compelling examples, this is could be wrong...

[StephenG1CMZ]

One use for matrices larger than 141*141 would be in investigating image/video processing - but doing that on a PC would be easier. But having lists and vectors have the same size limits would be more robust.

[toml_12953]

(09-10-2019 04:55 AM)StephenG1CMZ Wrote:  One use for matrices larger than 141*141 would be in investigating image/video processing - but doing that on a PC would be easier. But having lists and vectors have the same size limits would be more robust.

Why limit any function or variable artificially? IMHO, it's best to let the machine use all available RAM. On a PC, the only limit to the nesting of subroutines, the size of arrays, etc. is the available RAM, not some arbitrary limit. Let the programmer decide what to use the RAM for!

[jte]

There’s a bunch of places in the standard Plot views where additional RAM could be put to very good use (even just the 32MB of the G1). Many of the Plot views were designed around the RAM constraints of the 39gII (1/4MB).

Without a background picture enabled, the standard Function Plot view, for example, does not use any backing store (offscreen pixel buffer) to keep track of pixels behind the barberpole / marching ants cursor, the tangent line, or the areas covered by the Signed Area display. In each case, permutations of RGB values are performed per-pixel — permutations so that they can be undone as needed (without knowing what the original RGB value was before the visible “overlay” was applied). This design, while minimizing memory use, does introduce a bunch of complexities. If a single pixel is ever mishandled, that bit of “pixel dust” would remain until the Plot view had to completely refresh — which is not the case when simple panning is done. Panning moves the bulk of the pixels around on the screen and only plots “fresh” pixels — those brought in on the edges. Some of this can be seen quite easily when panning views with the barberpole / marching ants cursor and / or tangent line enabled: those overlays will flicker while the rest of the plot does not. (The implementation is: undo [some of] the overlays, scroll, redo [some of] the overlays. Turning on all three and then panning around should be illuminative to those interested...)

Going from 32MB to 256MB: there are at least a few fun plotting features that this increase makes much easier (/ practical / realistic) to implement. (In Graph 3D, for example.)