Conversion from CASIO-basic to RPL

[brickviking]

I've got some questions that are particularly new-user style questions, so please bear with me as this is the first time I've really dug in deeper to RPL programming. It may help if you've got a little experience with the Casio fx-9860GII (or 9750GII) but it's not needed.

Introduction
I'm the author of a Casio grocery program (link) on the Casio FX-9750GII and I'm trying to convert it into RPL on the HP-50G.

Funnily enough, the bit I thought was going to be the hardest, was actually the easiest; duplicating (roughly) the Casio screen below as a graphical screen on the 50G. I managed to create a routine for creating the PICT I need, though I should probably leave the bottom 8 pixels free to set up a menu.



This screen (taken from the Casio) describes the pieces I want to present:



Q1. Multiple var initialisation
I want to do a wholesale initialisation of variables, but so far all I've been able to come up with is the usual (for me):

\<< 0 'VEGE' STO 0 'MEAT' STO 0 'MISC' STO ... \>>

Now I'm jolly sure there's a far more efficient way of doing multiple variable assignment. Have I missed something in the UM/UG? I even had a look in the AUR, and didn't see what I wanted there either. Basically I want to either set all the categories to zero on initial start (and set the tax to a set rate), or set all the categories from previously stored data (ditto tax).

Q2. Running with a graphical screen and menu (i.e. no stack display)
This is trickier for me, as I had to use a loop and GetKey() on Casio, making the calculator cycle constantly through the loop and hence use more battery. The reason is because Casio's GetKey() returns immediately, regardless of whether a key was pressed or not. I'm looking for a better option on HP-50g, where I can display the graphical screen above, plus a menu, and then the calculator waits (without spinning its wheels like crazy) until I press a menu key. Each menu key fires up a sub-program to request a value from the user, set the relevant variable, then pass back to the main program, which updates the displayed variables, shows a grand total, and waits until I press a menu key (or Exit).

Q2a. Can I display INPUT on top of a graphics screen?
This would be the least visually disturbing, as otherwise I'd be jumping between a cleared out text screen requester, then back to the graphics screen, then a cleared out text screen requester, etc. Yuck. Still, if I have to do it that way, I have to do it that way.

Q3. Speed of GUI vs text
Can I run a graphical interface at nearly the same speed as a stack-based text interface? So far, to write onto the graphics screen, I do PICT RCL, create a tiny GROB with changed data, and use GOR at a specific location, save the PICT back and display it again ({} PVIEW). I can't think of a faster way to do this, and I'm sure it'll be slow. One other thing I haven't yet worked out (though this should be easy) is how to blank-out then write figures anew on the PICT.

Conclusion, at least for now
I think I can probably do most of the other functionality I think I need, it's just tying it all together that may be the issue, at least for RPL. I was thinking the main control could be a DO ...(run main loop) UNTIL (some-end-condition) END but I'll get that done once I've got most of the subprograms written.

If y'all need further explanations (i.e. more detailed workflow for the program), shout out here and I'll see what I can do. I wrote the initial Casio program after all .

(Post 71)