Problem whit EQSTK & TED
Kjetil
I have a problem whit those programs. When i have both installed at the
same time I loose all my memory when i am using cont to end the EQSTK.
I have been using EQSTK v5.3 for a long time whit no problem, it is a
realy nice program, but when i uppgraded to v9.0 and installed TED v3.1
and UFL 101 my calc crashes. I have a HP48SX whit an 128 K ram card. I
have also installed ALG48 and Algb, but the problem first came when i
installed TED.I Now i have lost my memory three times in tree days.
Is ther anyone who know what to do.
I need help.I have also tried whit EQSTK v5.3 but it didnt help.I realy
like the programs and I need them for my exam.
Mika Heiskanen
Kjetil <el9...@lhg.hib.no> writes:
This is probably the bug which most stack replacements have in common, namely
executing an alternate environment by typing the name instead pressing the
respective menu key may or may not cause trouble depending on the current
settings in the stack save.
Here's a report I got from Joe Horn on the BLIND program:
> When launched from a menu key, all's well. But when launched by typing
> its name into a command line, it does not exit (via CONT) properly. It
> usually warmstarts, but I'll bet two cents that if the phase of the moon is
> right it'll get a Memory Clear.
And my answer was:
----------------------------------------------------------------------
This bug is due to the annoying use of LAM's when the editline is terminated.
When this happens the keyhandler saves the last KeyOb to 1LAM and evaluates
the editline as is - then recalls the 1LAM to evaluate the actual key
which terminated the editline. In the simple case of enter key the 1LAM
would actually only contain NOP.
What makes it annoying is that one cannot easily obtain information on how
a program was started. For SOL's the difference is that they also have to
handle stack saves, and this of course happens by creating a new lambda
environment. The keyhandler itself of course still expects 1LAM to contain
the KeyOb which terminated the editline, thus when the SOL exits it must
o Either leave the saved stack as it is for the SOL below
o Abandonn it so that 1LAM becomes visible
In this particular SOL I have now finally made an exit which should always
work - even UNDO immediately after the exit. This probably is not the case
with all SOL's - including those by me..
For your benefit I have included the source code of BLIND since the program
is not disassemblable due to assembly language jumps. However I do use a
personalized entry table which probably would make assembling the source
a bit hard for other people.
The crucial part is after the BEGIN-UNTIL loop
UNDO_TOP? IT ABND ( Abandon saved stack from this SOL )
TEN GETLAMPAIR ( Recall first lambda variable )
casedrop CacheStack ( Handle the possibility of no 1st lam )
UNROT2DROP ( Leave lambda name on stack only )
EQ: PTR 5A777 ?SEMI ( Abort if it is the KeyOb save )
CacheStack ( Else save stack again if necessary )
;
Note that an exit like this is only necessary when stack saves complicate
things - it is not necessary in regular programs.
I should note though that if the SOL is started by typing the name then
a subsequent UNDO after exit will restore the stack which one had right
before the SOL whereas UNDO after exiting a directly executed SOL will
do nothing since the stack is saved at exit. Changing the behaviour to
be uniform does not seem worth the extra code.
----------------------------------------------------------------------
Environments like EQSTK which bind their own local variables should also add
an extra ABND:
UNDO_TOP? IT ABND ( Abandon saved stack from this SOL )
ABND
TEN GETLAMPAIR ( Recall first lambda variable )
...
I am planning to fix this today, and also implement some checks on system
flags to trace any changes in system flags which affect display modes so
that the cache is cleared automatically. Version 9.1 should be available
from http://www.hut.fi/~mheiskan fairly soon.
--
---
--> Mika Heiskanen mhei...@gamma.hut.fi http://www.hut.fi/~mheiskan
Mika Heiskanen
I wrote:
>The crucial part is after the BEGIN-UNTIL loop
>
> UNDO_TOP? IT ABND ( Abandon saved stack from this SOL )
> TEN GETLAMPAIR ( Recall first lambda variable )
> casedrop CacheStack ( Handle the possibility of no 1st lam )
> UNROT2DROP ( Leave lambda name on stack only )
> EQ: PTR 5A777 ?SEMI ( Abort if it is the KeyOb save )
> CacheStack ( Else save stack again if necessary )
>;
Well, this exit too neglects the following case:
o Turn off stack save
o Start EQSTK by typing ASTK
o Turn on stack save
o Exit EQSTK by pressing CONT
o Try UNDO to recover last stack
I have put available EQSTK v9.1 which extends the exit to cover that case
too. For the benefit of SOL writers out there the required code is:
* Unsupported entries:
=UNDO_TOP? EQU #14E6D
=KeyObLam EQU #5A777
* The code at the exit:
UNTIL ( SOL main loop exit )
* Local exit preparations
' ID agrob PuHiddenVar ( Specific to EQSTK )
* This exit avoids problems with stack save modes when EQSTK
* was entered by typing the command ASTK.
UNDO_TOP? IT ABND ( Abandon possible saved stack )
ABND ( Abandon EQSTK local variables )
TEN GETLAMPAIR ( Fetch first local variable with name )
casedrop CacheStack ( Unlikely possibility of no 1st lam )
UNROT2DROP ( Leave only the name on stack )
EQ: KeyObLam ( Is it KeyOb lam? )
NOTcase CacheStack ( No - just update stack save )
* The stack save mode may have been changed from OFF to ON during EQSTK,
* thus there may not be a stack save below KeyOb and thus an immediate
* UNDO after exit may cause a crash. Thus we explicitly fix the situation.
1GETABND KeyOb! ( This is what the system would do anyway )
CacheStack ( Fix stack save condition - this is enough )
KeyOb@ ' KeyObLam ONE DOBIND ( And bind the KeyOb back in )
; ( And fall through to ROM code )
Those interested can trace the problematic ROM code with HACK WKEY and ED
[DOB] key as follows:
WKEY [press enter] DROP
ED
[DOB]: PTR 40BB5 = standard code for enter
[DOB]: PTR 408F0 = standard code for enter & eval ob
[DOB]: PTR 4091D = the case of existing editline
[DOB]: PTR 4098A = standard mode (not custom)
[DOB]: PTR 23439 = safe editline eval with keyob save
The idea is that the keypress which terminated editline is saved, the
editline itself is evaluated, the keypress is recovered and evaluated.
A fool proof save of the keypress requires using a lambda variable, thus
all the extra trouble since any stack saves by the internal system have
been done earlier in PTR 408F0, while the SOL executed by typing the name
(the editline being executed) may require doing new bindings. The problem is
restoring things to a state where the above case as well as any other
'easier' execution method works fine, in particular pressing the UNDO key
afterwards.
A good test to see the bug (typically a jam occurs):
o Disable stack save
o Start SOL by typing the command name
o Enable stack save
o Exit SOL
o Press the UNDO key
It should be noted that in many early SOL's starting the SOL by typing is
already sufficient to cause problems:
o Start SOL by typing the command name
o Exit SOL
o Press the UNDO key