How in the world are these connected?
Wes
(Set Word Size) related?
When I use the CATalog, I usually type the first few letters of the
command to jump to that command. Typing "TM" moves me to the TMENU as
expected. Recently, I noticed the behavior had changed, so that now
when I type "TM" it moves to the first T command, TABVAL, and then to
the first M command, MAD, no matter how quickly I type the two letters
in succession.
I also noticed a few days ago that the TEVAL command was giving
nonsense timings. RPL programs that were taking several seconds in
real time were reported as having taken only thousands of a second.
After trying a gazillion things to figure out the first problem, I
finally tracked it down to a flag setting: the word size for Binary
Integer (type 10, Hex Strings in SysRPL). If the word size is 14 or
higher, then CATalog searching works as expected. But if the word size
is 13 or less, it does not.
Can somebody please try this to confirm: Do << 14. STWS >> then try to
search for something in the catalog, such as "TM" for TMENU. Then do
<< 13. STWS >> and try to search again.
I'm using the lastest ROM (2.01 build 83), but EMU48 with the 49g+ ROM
gives the same behavior.
To add to the mystery, I noticed that setting the word size to at least
14 also fixed the TEVAL problem. If I set the word size to 13 or less,
I get garbage timings. But with 14 or more, the timings are correct?
Can anybody confirm this behavior or shed some light on it?
Thanks,
Wes Loewer
Jean-Yves Avenard
> To add to the mystery, I noticed that setting the word size to at least
> 14 also fixed the TEVAL problem. If I set the word size to 13 or less,
> I get garbage timings. But with 14 or more, the timings are correct?
>
bugs.hpcalc.org to see the status
For the MENU shortcut i'm not aware of any issues.
JY
John H Meyers
> When I use the CATalog, I usually type the first few letters of the
> command to jump to that command. Typing "TM" moves me to the TMENU as
> expected. Recently, I noticed the behavior had changed, so that now
> when I type "TM" it moves to the first T command, TABVAL, and then to
> the first M command, MAD, no matter how quickly I type the two letters
> in succession.
> After trying a gazillion things to figure out the first problem, I
> finally tracked it down to a flag setting: the word size for Binary
> Integer (type 10, Hex Strings in SysRPL). If the word size is 14 or
> higher, then CATalog searching works as expected. But if the word size
> is 13 or less, it does not.
> Can somebody please try this to confirm: Do 14. STWS then try to
> search for something in the catalog, such as "TM" for TMENU. Then do
> 13. STWS and try to search again.
> I'm using the lastest ROM (2.01 build 83), but EMU48 with the 49g+ ROM
> gives the same behavior.
Exactly the same on HP49G version 1.19-6,
so it is evidently a very old bug indeed.
Could add to bugs.hpcalc.org and see whether anyone ever takes a byte :)
[r->] [OFF]
Steve Sousa
"John H Meyers" <jhme...@miu.edu> wrote in message
news:op.s2grr...@news.cis.dfn.de...
Hello:
Is bugs.hpcalc.org used for the 49g+ too? only 49g is listed in the
platforms.
Also version (2.01 83) is not listed.
I have something that i wouldn't call a bug to report, just a minor
aestetic flaw:
The "empty stack" error box is smaller than other error boxes, so if you
have an empty stack and press *down* or "right" followed by *up*, parts
of the large box are visible behind the "empty stack" one.
Maybe i'm just picky ;-)
Just a note, i'm using version 83, since 80 had some problem with the
arrow keys (playing minehunt was dangerous :-) )and i love the calc,
it's fast, the eqw is at last usable, the matrix writer and the whole
user interface has no delays, it solves my ocasional indefinite
integrals, i like it so much i've put my 48GX aside, the plastic on the
back is like a ti, the front has a better appearance, so i grade it
above ti, thank you and keep up the good work guys!
Best Regards
Steve Sousa
Wes
> bugs.hpcalc.org to see the status
Ok. I tried searching bugs.hpcalc.org before I posted, but I searched
from the first page instead of clicking "Search existing bug reports"
first.
> For the MENU shortcut i'm not aware of any issues.
Do you not have the same problem with searching the catalog? I also
notice the same problem with HLP49.
-Wes Loewer
John H Meyers
> Is bugs.hpcalc.org used for the 49g+ too?
> only 49g is listed in the platforms.
49G versions after 1.19-6 would seem to refer to the 49G+
> Also version (2.01 83) is not listed.
News travels slowly :)
In http://groups.google.com/group/comp.sys.hp48/msg/4b34c53b89939395
JYA has declared that:
> Build 80 and 83 are identical with those differences:-build 80: 75ms anti keybounce, 83 150ms-build 80: shows as a beta ROM, 83 shows as Cthat's it.
[r->] [OFF]
James M. Prange
Confirmed, and as John noted, the strange behaviour with the
catalogue goes back to at least the 49G revision 1.19-6 ROM. I
recommend that you report this on Bugzilla.
What the wordsize has to do with searching the catalogue, I don't
know.
For TEVAL, the system times (in ticks; 1 second = 8192 ticks) are
binary integers (well "hex strings" is probably the correct SysRPL
term) (52 bit, if I recall correctly), so a small word size
truncates the difference of system times, thus giving nonsense
evaluation times. Exactly how large the wordsize has to be for
correct times depends on how long the evaluation takes. See
http://bugs.hpcalc.org/show_bug.cgi?id=128, and note in particular
"fixed in 2.04", so there is indeed reason to hope for another
updated 49g+ ROM.
With TEVAL, there's also an issue that TEVAL doesn't attempt to
compensate for the time to execute the SysRPL CLKTICKS and OBJ>R_
commands, so the resulting time is slightly high.
For UserRPL timing programs that force and restore the wordsize
and compensate for the execution time for TICKS and storing the
initial time, see:
http://www.hpcalc.org/search.php?query=%22EVAL+TIMER%22
These programs can be modified to work with any RPL model.
With both the built-in TEVAL command and my programs, the result
in seconds is rounded to four decimal places, which is pushing it
a bit, as 1 tick is about .00012 second.
--
Regards,
James
Wes
think I understand how the catalog (and 49HLP lib, any others?) would
be affected by wordsize. This is just an educated guess, mind you, but
I think it will fly...
When you enter letters in the catalog, if you type, say "TL", without
much time between the "T" and "L" the catalog goes to TLIN, but if you
wait too long it goes to LABEL. Based on trial and error, the wait
time limit seems to be about 1 second. If it is 1 second, that would
be 8192 ticks, which is 2^13. This is consistent with the fact that
when the wordsize is 13 or less, the catalog search doesn't work, and
when it's 14 or more, it does work. My guess is that when it reads the
ticks between keystrokes, it will get garbage values when the word size
is too small for the same reason that TEVAL gets garbage values.
Someone with inner knowledge of the ROM may want to confirm this, but
if this is true, it all makes sense.
-wes loewer