glenk@llama.rtech.UUCP (Glen Kilpatrick) (12/28/89)
Please put on your thinking caps, 28S_chums, and tell me if anyone's
had a glimmer of an idea re these two modest problems:
* What about a "fuel gauge" for the 28? I'd like a function that
would return a real number between 0 & 1 indicating battery voltage,
where 1 = new batteries, & 0 means the low-battery indicator was
just triggered. If it could report hours of continuous computation
left, it would be a googol times GREATER (but that's too much to
hope for!)!
* I keep a "catalog" of ~150 objects of the form << param1 param2
pgm >> 'name1' STO. I'd like pgm to report "Output for name1" when
it executes, but cannot afford the MEM to encode name1 INSIDE name1.
So, is there a way for an executing program to know its own name,
and the names of its "shell" programs? Of course, programs executed
from the stack could not have a name (unless it was "1", since they
could only be executed from level 1, a la 1_visit), but there MIGHT
be a way for global/local variables.
Please be cautious re SYSEVALs in your answers. I crashed my sys
last week, and took over a day to type all back in, so I'd prefer
rugged/tested implementations. Thanks!
Glen Kilpatrick
(916)756-9321homebradb@cs.toronto.edu (Brad Brown) (12/30/89)
glenk@llama.rtech.UUCP (Glen Kilpatrick) writes: >* What about a "fuel gauge" for the 28? I'd like a function that >would return a real number between 0 & 1 indicating battery voltage, >where 1 = new batteries, & 0 means the low-battery indicator was >just triggered. If it could report hours of continuous computation >left, it would be a googol times GREATER (but that's too much to >hope for!)! This would be really hard to do. Alkaline batteries tend to have fairly constant output for most of their life then they drop off quickly. This is similar to what happens with NiCad batteries, except NiCads drop off much more rapidly... Consiquently, it would be hard to accurately measure remaining charge from battery voltage. On IBM-PC compatable laptop computers you can get a utility that loads as a background program and monitors system use to keep track of battery drain. That approach doesn't seem practical for the HP-28 :-) (-: Brad Brown :-) bradb@ai.utoronto.ca
alonzo@microsoft.UUCP (Alonzo GARIEPY) (12/30/89)
In article <4374@rtech.rtech.com> glenk@llama.UUCP (Glen Kilpatrick) writes: > * I keep a "catalog" of ~150 objects of the form << param1 param2 > pgm >> 'name1' STO. I'd like pgm to report "Output for name1" when > it executes, but cannot afford the MEM to encode name1 INSIDE name1. There is a way to do this, but it seems like a lot of unnecessary work. You can write a machine code object that will determine what variable it is stored in and put the name on the stack. This will use up more memory in your program than the name itself. Alternatively, you can write a machine code subroutine (in another variable) that figures out where it was called from and determines the name of the calling program. Both of these approaches are extremely risky, which you did not want. The best way is to avoid this complexity and simply call your program from another program that prints the name for you. The basic idea is: INVOKE << DUP ->STR "Output for " SWAP + 1 DISP EVAL >> 'pgmname' INVOKE Alonzo Gariepy alonzo@microsoft
daver@guille.ece.orst.edu (Dave Rabinowitz) (12/30/89)
In article <4374@rtech.rtech.com> glenk@llama.UUCP (Glen Kilpatrick) writes: >* What about a "fuel gauge" for the 28? I'd like a function that >would return a real number between 0 & 1 indicating battery voltage, >where 1 = new batteries, & 0 means the low-battery indicator was >just triggered. If it could report hours of continuous computation >left, it would be a googol times GREATER (but that's too much to >hope for!)! The hardware in the 28S uses a simple comparator to compare the battery voltage to an internally-generated reference value, so it cannot arbitrarily measure battery voltage. There are two such comparators in the calculator. The first tells the software to turn on the low battery indicator and the second, at a lower voltage, tells the software to shut down the calculator completely to avoid the chance of some incorrect operation messing up memory. The calculator speed was set to assure correct operation down to this lowest battery voltage; processor speed varies with battery voltage and if the voltage gets too low some logic might not reach the correct state before its output is sampled. If the calculator has been sped up using one of the programs which have been posted here it is possible that memory will be messed up or lost as the battery voltage drops with age.