A629
===
Subject: Re: tds ram card

Does this mean that it is possible to create, say, a ROM card that is
larger than 128KB but is usable in card slot one?
Han
===
Subject: Re: tds ram card
Hi Han,
Yes, if that card either reacts to the TDS (or a similar) bank switching
mechanism,
which has mechanical switches to enable exactly one out of four 128K banks
Raymond
===
Subject: oops! ON-D on a 49g+
I did an ON-D test mode and put it into autotest by pressing A.
Well, it goes into an endless loop and I could not stop it, so I pulled out

a
AAA cell.
Now it will not turn on even after a hard reset. What can I do???
===
Subject: Re: oops! ON-D on a 49g+
Well, you can try to discharge the capacitor. For that you'll need to
take out ALL the batteries (even the little CR2032 3V backup battery)
and short-circuit the batteries contact. Them put the batteries back
and try again.
P.S.: The correct way to get out a loop self-test is pressing ON+F3
(ON+C).
Hope It Helps
===
Subject: Re: oops! ON-D on a 49g+
the battery contacts with paper clips. And it does work.
===
Subject: Assembly problem
My first Assem program is acting funny.
The program takes one real from the stack, puts the characters into a string

on stack level one. The next time I run the program the old characters are
in the resulting string.
Running this program with: 312.1821
4:
3:
2:
1: +312A18'21.0'
Run it a second time with 1.4567
4:
3:
2:
1: +311A45'67.0'
Notice the 31 is still there
recalling the program from the var it is stored in and you will see
+311A45'67.0'
instead of +000A00'00.0' Why???
RPL
*D1 is pointing into the string
*C[W] holds the number
::
$ +000A00'00.0'
SWAP
CODE ( Begin assembly language)
GOSBVL =POP1% * A[W] HAS THE NUMBER
R0=A * save in R0
* Get pointer to the string
SETHEX
A=DAT1 A * A[A] contains pointer to object in stk1
the string
R4=A.F A * store address R4[A]
C=R4.F A * recall address of object
D1=C * D1 pointing to prolog of object
D1=D1+ 5 * point past prolog
A=DAT1 A * read the length into A[A]
CD1EX * get address that D1 was pointing at
C=C+A A * add address and length
D1=C * D1 now pointing to last character + 1
D1=D1- 2 * D1 pointing back to last character
D1=D1- 12
D1=D1- 12 * D1 pointing to first char
* ready to get the number
SETDEC
C=R0
?C=0 S * IS IT A positive NUMBER
GOYES Pos
* Load the neg sign
SETHEX
LA(2) #2D * load char -
DAT1=A B * write character to string
Pos
* Check the mantissa exp sign
SETDEC
C=R0
?C=0 XS * IS IT A positive NUMBER
GOYES ExPos
* Mantissa Exp is neg only work right of decimal point
SETHEX
D1=D1+ 10
Decimal SETDEC
CSLC
DAT1=C S
D1=D1+ 2
CSLC
DAT1=C S
D1=D1+ 4
CSLC
DAT1=C S
D1=D1+ 2
CSLC
DAT1=C S
D1=D1+ 4
CSLC
DAT1=C S
?P= 10
GOYES End
ExPos
* Working with a positive exp
P=C 0
CSLC
?P= 2
GOYES Three
?P= 1
GOYES Two
?P= 0
GOYES One
One
D1=D1+ 6
DAT1=C S
D1=D1+ 4
P= 10
GOTO Decimal
Two
D1=D1+ 4
DAT1=C S
D1=D1+ 2
CSLC
DAT1=C S
D1=D1+ 4
P= 10
GOTO Decimal
Three
D1=D1+ 2
DAT1=C S
CSLC
D1=D1+ 2
DAT1=C S
CSLC
D1=D1+ 2
DAT1=C S
D1=D1+ 4
P= 10
GOTO Decimal
End
SETHEX
P= 0
GOVLNG =GETPTRLOOP * restore pointers
ENDCODE ( End assembly language )
;
===
Subject: Re: Assembly problem
this is normal,
because you're using the *same* string for both program runs;-)
More than that, the string is embedded in your program.
You first have to create an independent copy of the string in your prog.
This can be done via TOTEMBOB .
An alternative is to create a new tempob string from inside your assembly
code.
For this use the supported entry =MAKE$ .
HTH
Raymond
===
Subject: Re: Assembly problem
online.com:
I am guessing you meant
to-temp-ob TOTEMPOB
rather than totem-bob TOTEMBOB
:)
--
bz
please pardon my infinite ignorance, the set-of-things-I-do-not-know is an
infinite set.
bz+csh@ch100-5.chem.lsu.edu (remove ch100-5 to email)
===
Subject: Bug? Using KEYEVAL to toggle last stack corrupts local variables?
What I was trying to accomplish would be sort of a long story, but
with the following example program on either the 49G or 49g+:
%%HP: T(3)F(.);
<<
<<
69. MENU @ Old MODES MISC menu.
-14.1 KEYEVAL @ [F4] key (toggle last stack saves).
n @ Put the local variable's contents on the
@ stack.
If I start with last stack saves disabled, then it enables them
and puts the 0. on the stack, as expected.
But if I start with last stack saves enabled, then it disables
them, and then errors out with KEYEVAL Error: Undefined Local
Name. Whether -14.1 is returned to the stack as the last argument
depends on the state of flag -55 (as expected).
What happened to my local variable? The system still knew that n
was a local name, but now undefined. Why?
Toggling last stack saves doesn't normally have any effect on
local variables, and although I don't have much experience with
KEYEVAL, it normally doesn't either, as far as I know.
Maybe this is related to previous reports (Google for them) of
strange things happening when KEYEVAL was used in a FOR loop,
which also uses a local variable for its index?
Any ideas?
Yeah, I know: Don't do that! ;-)
--
Regard,
James
===
Subject: Re: Bug? Using KEYEVAL to toggle last stack corrupts local
variables?
The toggle menu was purely designed to be called by hand, not in a program.
LAST STACK is actually a block of nullname local variable, when you
enable it it will create the variable. Unfortunately when doing so it
assumes that you have no other local variables existing. So when it
creates the new block, it erases any other that may be existing
yes
This is the same problems that have been reported several times when
using the new choose menu. It took a while to identify all instances of
code creating local variables and also saving the last stack, as each
time other variables were deleted making the code crash sooner or later.
it's a bad thing (c) TM
JY
===
Subject: Re: Bug? Using KEYEVAL to toggle last stack corrupts local
variables?
program.
Well, actually the problem that I noticed seemed to be only when
disabling last stack, not when enabling it, but I see what you
mean.
Okay, so it's not a bug; I'm glad that I asked here instead of
reporting it on Bugzilla.
It seems that there are indeed possible pitfalls to using
KEYEVAL, yet the documentation doesn't include any suggestion of
this for the unwary user. Perhaps we should consider it to be a
hacker's command -- okay for the user who really knows what
he's doing, but potentially dangerous.
--
James
===
Subject: Re: Bug? Using KEYEVAL to toggle last stack corrupts local
variables?
Where do you suppose the stack is saved when you have enabled saving?
in an environment, and apparently that environment (or yours) is deleted
when you disable Last Stack; the following thread might be interesting,
which emerges when some programs are run with Last Stack disabled:
You are not, of course, getting a KEYEVAL error; what happens
is that the last saved user command name was KEYEVAL,
There was also no corruption of local variables,
but simply a deleted entire environment,
due to taking too much liberty by invoking in a program
a function not intended to be programmable.
I think it's best to enable/disable Last Stack only from the keyboard.
Some other KEYEVALs are also very problematic (e.g. may hang)
if performed in the command line (this isn't what you did,
but might as well be mentioned, as another caution).
Incidentally, have you noticed that every HALT level has its own
Last Stack enable/disable ability, and an independent save location
when enabled?
===
Subject: Re: Bug? Using KEYEVAL to toggle last stack corrupts local
variables?
Umm, some special place in memory?
And SAVESTACK and undo.
Good to know about.
Well yes, at least that much was obvious to me.
Probably so, although it does seem to work okay as long as I don't
have any local variables when I disable last stack.
Yes, I often use such suspended environments. Note that neither
the last stack nor any local variables in a suspended environment
is affected by disabling last stack, as long as last stack is
enabled again when CONT is pressed.
--
James
===
Subject: Re: Bug? Using KEYEVAL to toggle last stack corrupts local
variables?
X
I use -55 CF/SF or toggle it with IFTE or similar
===
Subject: Re: Bug? Using KEYEVAL to toggle last stack corrupts local
variables?
On Tue, 04 Apr 2006 04:36:35 -0500:
keyboard.
That's the Last *Args* flag (there is no Last Stack flag).
By the way, when you toggle Last Args off then back on,
it wipes out any existing references,
which is a neat way (along with things like ERR0
and clearing the stack) of removing any obstacles
to purging libraries because of object in use.
===
Subject: Re: Bug? Using KEYEVAL to toggle last stack corrupts local
variables?
CASCFG - ah, that helped!
It will be fixed in VPN 2.05 (and it will introduce 2 new features)
Last Args Off/On & ERR0 - what else is needed?
===
Subject: Re: Bug? Using KEYEVAL to toggle last stack corrupts local
variables?
Plagiarizing from Bill Wickes's HP 48 Insights Part I: Principles
and Programming HP 48G/GX Edition:
6.4.2.2 Altering Port Variables
Port variables are intended for object storage that is somewhat more
permanent
than that offered by global variables. For this reason, the contents of

port
variables can not be changed once they are created, short of deleting
them
with PURGE. STO returns the Object In Use error if you attempt to
overwrite
the contents of an existing port variable, Furthermore, you can't delete

a
port variable if the stored object is referenced, in which case PURGE
returns
the same error message as STO. Referenced means that a stored object (or

part
of it) has been recalled by one means or another, and the recalled copy

is
still present--on the stack, in argument recovery or stack recovery
memory, on
the program return stack, or in a local variable. Specifically, this
means
that there is a pointer to the port variable object in any of these
areas--see
section 5.7. On a HP 48GX, this can only happen for port 0 or port 1,
since
objects in higher ports are copied to temporary memory when they are
recalled.
To succeed in purging a port 0 or port 1 variable, you must first remove

all
such references to the object, either individually, or collectively by
executing a system halt [ON}-[C]). Some references may be very subtle;

for
example, if a program enters an object that is left on the stack or in a

local
variable, the program will be referenced until the object is removed. Or,

if
a program uses DOERR (section 9.6.2) with a string argument defined in
the
program, the program will be referenced for the sake of the ERRM command

until
ERR0 is executed or some subsequent error generates a new error message.
If you want to delete a port variable while keeping a copy of its stored
object, you must recall the object and either store it in a global
variable or
another port variable, or execute NEWOB (section 11.6) with the object in
level 1. This creates a new copy of the object and unreferences the port
variable. Then you can use PURGE to delete the variable.
and about libraries specifically:
PURGE. To remove a library from a port, execute :n:ID PURGE. As in the

case
of port variables, you will be unable to purge a library if it is
referenced
in any way (Object In Use). In addition to the other ways that an object

can
be referenced, a library is referenced when it is attached to the home
directory; you must detach it (see below) before purging.
When you purge a library, you may see the display jump briefly. This is
caused by the movement of display memory arising from the removal of an

entry
in the HP 48's internal table of libraries; it is quite harmless.
And from the original edition of HP 48 Insights Part I:
(In HP 48SX versions 1A - 1D, even a system halt does not clear the ERRM
reference.)
It occurs to me that an object could be referenced in a suspended
environment created by HALT and so on, so (unless dereferencing
by a warmstart) a CONT or KILL might be needed.
Of course what he's referring to by referenced is that, in many
cases, a recalled object hasn't really been copied, but a
pointer to it that's still in use has been created. Changing
what's at the location pointed to would be a bad thing to do.
directory would apply to a library attached to any of its
subdirectories as well, but I haven't experimented with this.
48SX port 2. As for how all of this applies to the 49 series
ports, you're on your own there.
It seems obvious, but of course you can't STO or PURGE in a ROM
Available error.
I consider the Insights series indispensable for RPL users, even
users of the 49 series; in case you don't have the books, scans of
them are available on The Museum of HP Calculators CD set / DVD.
See:
http://www.hpmuseum.org/cd/cddesc.htm
--
James
===
Subject: Re: Bug? Using KEYEVAL to toggle last stack corrupts local
variables?
For any readers wondering:
Last Args is what enables you to use the LASTARG command,
or the keyboard ANS (on 49 series) or [last]ARG (on 48 series),
to recover to the stack the arguments of the last
User command which required stack arguments; E.g.
4 8 * (get answer 32); ANS or ARG then recalls 4 and 8 to stack
(while answer 32 remains).
Last Stack is what enables you to use UNDO
(which restores the stack as it was before the last keyboard command,
but does not undo any other effects), E.g. 4 8 ENTER *
(get answer 32); UNDO then puts back 4 and 8 but 32 is gone;
note that if you don't press ENTER then you also don't get back
4 and 8 either, because then they weren't already on the stack
just before pressing *
One unusual special recovery action is that keyboard STO
(with either STO or left-shifted VAR menu key) into an
existing variable (oops!) can be undone via *immediately* doing
LASTARG (ANS or ARG on keyboard), STO, LASTARG (again),
provided that Last Args was enabled
(especially clever key definitions make this possible);
note that this has nothing to do with UNDO.
===
Subject: Re: Bug? Using KEYEVAL to toggle last stack corrupts local
variables?
have you examined what the KEYEVAL code does?
Or have you tried toggling last stack by a direct call?
Regarding the local variables:
Apart from that, I don't see much practical use for KEYEVAL at all;-)
Raymond
===
Subject: Re: Bug? Using KEYEVAL to toggle last stack corrupts local
variables?
Well, I did look at it briefly with Nosy, but didn't follow every
branch or attempt to decipher the code objects.
Well actually, I have a SysRPL last stack toggler that seems to
work very nicely:
::
CK0NOLASTWD
# 137
JstGETTHEMSG
UNDO_ON?
ITE
::
UNDO_OFF
Off
;
::
UNDO_ON
On
;
&$
xMSGBOX
;
Maybe they shouldn't, but in this particular case they obviously
do.
things can be accomplished well enough without it. Where I see a
possible use for KEYEVAL is for executing non-programmable
operations. But it seems that some such operations don't work out
very well within a program; I suppose that maybe that's why they
aren't commands.
Anyway, the last stack toggler was just something that I was
fooling around with, and was surprised when it don't work as I'd
expected.
--
James
===
Subject: Re: Bug? Using KEYEVAL to toggle last stack corrupts local
variables?
On Mon, 03 Apr 2006 15:36:19 -0500:
To assign the functions of some keys to other keys
(I use it to swap some key functions in my calcs, for example).
There are, of course, other keys that have no user equivalent,
like the cursor keys, but there again, IIRC,
it may prove unsatisfactory to try to use some keys via KEYEVAL,
just as it sometimes was for the (still-existing) *libraries*
A1 thru A6 (each corresponding to one entire keyplane of the keyboard,
with keys numbered from zero in the top left corner),
which were introduced in the first 48G.
For example, #A2018h LIBEVAL gives you ACOS on your 49-series calc,
the same as -54.2 KEYEVAL; on the 48G/GX/G+ you have only these
LIBEVALs to rely on, since KEYEVAL was introduced in the 49 series.
Note that the key numbering is different on the 48G/GX/G+ keyboard
(but counting is easier, since every row is straight :)
===
Subject: Re: Calling ROM routines in SysRPL
the
be
stores
When ML calls ML (and only in this case),
it usually uses the shortest of GOTO, GOLONG, GOVLNG
which can reach the desired address, but the greater problem
is that the desired internal program is *unsupported*
(it evidently moves from version to version); therefore,
any port that you make in this fashion will be version-dependent,
will work only on particular ROM version(s),
and otherwise may crash, corrupt or wipe memory,
in which case it will provide an unsatisfactory experience
to the user.
It is frustrating when an internal function that was
unsupported but stable in HP48 (and which will forever remain so
in that series, simply because those are out of production)
turns out to be a moving target in the HP49 series,
but when that happens, one must be very cautious
in issuing a port relying on such functions.
At the very least, unless you reproduce the function
with all new code in the ported system, relying on
nothing still unsupported, it can be risky for the user,
and ought to be accompanied by clear warnings
(which even then you can't force anyone to read).
Of course, if you are the only user, and you will not
be distributing it, then you can throw caution to the winds :)
Sometimes we can dodge the issue by relying on some other
supported function which in turn invokes the one we really want
(that's why we have to resort to EvalNoCK invoking user commands
when the dispatched addresses that we'd like to use directly
happen to be unsupported), or sometimes we hope that an unsupported
address that we need will always remain at a fixed offset
from some supported address; if we can't find anything like this
to hook onto, then we are sure to end up with version dependency,
particularly when we have already seen the target move around in the past,
guaranteeing that anything we now produce will go wrong on already existing
versions (including on any 49G which thus far can not generally be updated
to match a more recent 49G+ version).
===
Subject: Re: Calling ROM routines in SysRPL
hello,
Well, that is what supported means: it is supported.
unsupported means NO WARANTY...
if we ment to support or guaranty that unsupported entry point were never to

move... we would call them supported (well actually, we would not need to
call anything supported cause all the ROM would be supported)... but in this

case, guess what :-) they are unsupported because.... they are not supported

and can move anytime! (we need to create a self modifying ROM to move things

around all the time, just for fun :-)...
the other alternative is to never provide ROM upgrade so things don't move
:-) (yes, I know: If HP created a bug free ROM, they would not be any need
for upgrade....)
hpcalc.org)
past,
updated
===
Subject: Re: Calling ROM routines in SysRPL
I first thought that this might have been originally an HP48 series
program, but looking on www.hpcalc.org, I see that it was written
in May 2001 for the HP49G (http://www.hpcalc.org/details.php?id=4666)
So, has it already ceased to work in 49G+ ?
If so, at what version number did it start to fail
(did it, for example, work with version 1.24 for the HP49G?)
If we find this happening in programs that are all in the
same calc series, I guess we have to be ever more cautious,
perhaps have some additional rating system, program submission
characteristic or symbol (to use on hpcalc.org) to identify any programs
using unsupported entry points, which always carry this risk,
and then identify which ROM version every such program
is written and tested for!
===
Subject: Re: Calling ROM routines in SysRPL
John H Meyers ha scritto:
It has never worked reliably on anything greater than ROM 1.18: ROM
1.19-6 drew the graph correctly but crashed when using softkeys, and on
subsequent versions it crashed since the beginning.
I'll ask permission to Jurjen before distributing my version (if I ever
get to port it!!!) - since the code relies heavily on fast ML routines,
the best I can do is to document as much as I can about the unsupported
entry points that have been used.
If Jurjen decided that the program is meant only for those who live
dangerously, all I can say is 'Caveat Utens' ;)
Anyway, IMHO is better to have HLDRAW than not...
===
Subject: Re: Calling ROM routines in SysRPL
a
it depends what kind of entry it is.
SysRPL, ML, jumps etc...
JY
===
Subject: Re: Calling ROM routines in SysRPL
Machine language
--
Stefano Priore | Debian Sarge 3.1r0
--------------------------------+--------------------------------
Video meliora proboque, | Linux Registered User #210152
autem deteriora sequor... | Linux Registered Machine #97752
===
Subject: Re: Calling ROM routines in SysRPL
if it's plain ML, a GOVLNG address
will be sufficient
OTherwise something like:
LA(5) address
PC=(A)
JY
===
Subject: Re: Older 49G ROMs on EMU48
You have to upgrade your ROM image with the program UPD49ROM.EXE. This
program update a emulator ROM image with the flash file for the calculator
update.
A downgrade from 1.19-5 or later has the problem that these ROM's use a FS
(File System) which is a normal user block on 1.18. The only way to kill
the
FS block is overwriting the block header. This can be done by calling
UPD49ROM with the -f option. But this option does _not_ delete the
ramainder
data of the FS, only change the block header to user data. I don't know
what's really happen in this situation, I normally go the way of real
updgrade from an old emulator file version or from a file containing the
boot block only.
Christoph
the
===
Subject: Re: hp49g+ and ROM codes like SWAP
It is really *after* the garbled ARM instruction,
even though listed first among the assembler errors
(I think the assembler usually lists things in reverse order).
I believe that the built-in decompiler has simply lost its place,
and has started re-interpreting instructions
at a wrong point (at 0323E), which will never be reached.
There are different instructions at this point in the 49G version;
the instructions which the ARM code replaces are in that area instead,
and none of those is this phantom instruction, nor is at address 0323E
Instead, the HP49G would have:
0323A A=DAT0 A
0323D D0+5 ( 0323E would be in the middle of this instruction )
03240 PC=(A)
If the decompiler garbles the source,
it is to be expected that this erroneous source
might not recompile again; no doubt HP's original source
compiles just fine, but they just don't release it to us :)
You might be much happier trying an older 49G ROM on Emu48,
unless and until the on-board MASD decompiler gets adjusted
for some new 49G+ ARM instructions (or perhaps if some
earlier 49G+ ever didn't have this particular ARM instruction,
then you could go all the way back to that ROM, if any).
Firstly, SysRPL doesn't have any asm code within it,
because SysRPL is *interpreted* -- however, every time
that the SysRPL runstream pointer addresses a CODE object
(or a primitive code object - PCO - in ROM),
*then* the processor instructions embedded therein
get executed directly instead, until that code
returns to interpreting SysRPL.
Such a library splitter (that can even split internal libraries)
does exist, but I think you will be disappointed when what you
finally get is essentially exactly the same as you already see
with Nosy. But here it is, anyway, so you can try for yourself:
http://www.hpcalc.org/details.php?id=6024
I keep suggesting getting a 49G ROM and using Emu48 (which also
saves wear and tear on that infamously delicate 49G+ keyboard),
but who's listening?
===
Subject: Re: HP49G+ do you recommend it ? hear my case.
Why is a raven like a writing desk?
[I don't know the solution, but ask Rev. Charles Lutwidge Dodgson,
author of Pillow Problems and a Tangled Tale (math puzzles),
a/k/a Lewis Carroll -- probably reborn as JKH :]
http://www.amazon.com/gp/product/0486204936
===
Subject: Re: HP49G+ do you recommend it ? hear my case.
On Sat, 01 Apr 2006 10:42:19 -0600:
Whose real world?
The student world which likely buys most of the product?
Maybe the real world of economics, mass marketing and bottom line
takes precedence to the desires and demands of the shrinking proportion
of engineers and scientists in the customer base.
A few words dropped occasionally in this forum suggest
that HP is still working on things,
but I would not myself expect anything that will satisfy you,
except as an outlet for letting off steam, which is of course
yet another significant, though indirect, use of the product.
Maybe a good hunt, with real ammo (or just paintballs if necessary
among human comrades) might also serve the purpose,
or something really restful to the entire mind and physiology,
or maybe a good sermon from Joe would do the trick
(go ahead, let's have one, and see how much it does for our spirit,
even by comparison with a good long rest).
===
Subject: Re: HP49G+ do you recommend it ? hear my case.
(Google bought Deja in February 2001,
and merged its archives into the competing service
which they had already been programming).
still work, but some broke, perhaps when Google
decided to drop certain old indexes.
If we could have a little deja at Google,
we might want to go back to an earlier,
less cluttered interface (but more ads
and ever less useful extra features
always displace what once was optimum for the user,
just as it did at Deja, which had by its demise
turned into ads on all sides of the screen,
with a tiny text window in the middle :)
===
Subject: Re: HP49G+ do you recommend it ? hear my case.
Can the hp49G+ solve the example difeq on page 19-6 of the hp48 users guide

edition 7?
I posted this near the beginning of last month.
===
Subject: Re: HP49G+ do you recommend it ? hear my case.
Yes it can and the answer is the same.
I entered it *excatly* as in the book
and in the 48-mode, eg. Approx. mode (instead of exact)
I was also careful to enter the vector correctly
Is there a problem or were you just asking if it can?
I was going to mention this on bugzilla but I didn't want to create an
account.
Anyway, this bus is irritating me, so please HP gods, fix it on a
future revision.
When display is set to FIXED it puts a comma for the place holder in
the string. It didn't do this on the 48 series.
(and acting as did the latter on 48 series,
inserting thousands separators for both functions)
After more research:
This uses ^FSTR7 instead of ^FSTR9 (and there won't be any commas);
this solution is also backward-compatible to HP48G series.
Could this not be fixed in Extable alone,
(or leave the latter as it is now, wasting a few bytes of ROM :)
a controlling flag?
(after CK1 to ensure that the stack isn't empty),
Of course there are flags influencing the result;
these include the number display mode (STD vs. FIX/SCI/ENG,
and how many places for the latter group).
then produces the string 12,345,678.12 (to which
produces the comma-free string 12345678.12 (isn't that
Unless, of course, you also have flag -51 set, in which case
the roles of the comma and decimal point are exchanged.
What else could we guess you might mean,
in the complete lack of any example yet -- let's see,
what did you mean by place holder, say?
There are other inherent minor display differences, of course,
such as the fact that all reals on HP49G (even integer-valued)
display with a decimal point, and that is to distinguish
them from the fundamentally different integer objects,
which didn't exist in the HP48, so that's just how it is.
Could you give an example of an argument,
your flags (say what number display command you last set,
and what different result were you expecting?
That's the only way we're likely to ever find out what you really mean.
Oh, what you mean is for thousands separators!
in that the former is used for program decompiling
(as for editing), and partly ignores number display mode
(except it still rounds off to the given # of places),
while the latter is used for stack decompiling,
and is supposed to obey number display mode
(thus in STD mode, both give the same result,
while in FIX display mode they may differ by some commas,
if the number magnitude is 1000 or greater).
Extable (original version) gives these entry points
as the same address, so of course they will always
give the same result, always obeying the number display mode.
Well, that's either an error in Extable (not likely), or a mistake
in not quite correctly supporting a supported entry point
(the chances of rectifying which might be small).
It looks as though you will have to change the number display mode
(flags) if you do not want the commas, or else simply
remove them via the equivalent of , SREPL DROP
(to be completely general, the first of those two strings
should be . if flag -51 is set).
To show that everything in the universe has an exact opposite,
there was someone else who *wanted* the commas, even in STD mode,
for which a weird HP48 semi-solution was posted
(needs adjustment for HP49 series, however,
because real integers have decimal points in STD mode on 49 series):
A little extra,
for people who want thousands separators on *integer* objects
(however large they may be):
Any example?
Is flag -51 cleared? Otherwise the fraction mark
(a/k/a decimal point) is *supposed* to be a comma.
(which doesn't mean add a comma :)
are the same address (#25F0Fh) in Extable,
but this simply does DecompStd1Line,
which decompiles any old object whatsoever,
and looks fine to me.
There was a post about these entry points (on 48 series)
way back when, but Google doesn't index on symbols,
so I can't find it.
Waiting to see the example... [with flag settings from RCLF]
===
Subject: Re: Full-screen CHOOSE for any calculator
Below is a simplified program for all HP48G/49G/???
which implements a multi-level (unlimited) CHOOSE
using the built-in CHOOSE,
by recursively calling itself
whenever any selection returns a list.
A sample program is also included, to illustrate
(showing that you can even have a differing number
of levels in different branches, if you like).
You could even add some fancy touches to this;
for example, at the expense of a bit more complexity,
whenever you need to invoke a lower-level CHOOSE,
you could give it the title of the most recently chosen item,
and/or if canceled you could re-highlight the choice just made,
but in most cases you will not be backing out anyway,
so why even bother?
You may of course also use any full-screen CHOOSE with this,
like the (now built back in) original HP48 Equation Library, E.g.
<< DROP DO DUP2 1. CHOOSE {
DUP TYPE 5. ==
{ 3. PICK SWAP 1. MCHOOS @ must be its own name
{ ROT ROT DROP2 1. 1. } 0. IFTE
} { ROT ROT DROP2 1. 1. } IFTE
} { DROP2 0. 1. } IFTE
<< Sample
{ { TopMenu1 { { MidMenu { 55 66 } } 44 } }
{ TopMenu2 { 22 33 } }
There are other circumstances where we would rather
not have to create an entire static menu up front; for example,
in a user equation library application having a sub-directory tree,
we might simply repeat CHOOSE whenever a selection is a directory,
showing new selections for the chosen sub-directory,
and use the sub-directory name as the new title;
we could back out one directory level at a time on Cancel
until reaching the top level, which could instead exit, E.g.:
===
Subject: Multi-level CHOOSE for any G calculator
Using the built-in CHOOSE in a trivial manner:
%%HP: T(3)F(.); << @ Header for file transfer only
@ Multi-level CHOOSE program:
<< DROP DO DUP2 1. CHOOSE {
DUP TYPE 5. ==
{ 3. PICK SWAP 1. MCHOOS @ must be its own name
{ ROT ROT DROP2 1. 1. } 0. IFTE
} { ROT ROT DROP2 1. 1. } IFTE
} { DROP2 0. 1. } IFTE
@ Example of use:
<< Functions {
SIN COS TAN ASIN ACOS ATAN } }
@ Principle:
@ Same arguments (and return values) as CHOOSE.
@ MCHOOS repeats itself if a selection returns another list,
@ returns a final selection if not a list,
@ or returns to the previous level if canceled.
@ End
===
Subject: New replacement HP49g+
HP sent me a new 49g+ to replace my 1 with breaking keys and I a m setting
it up, But it wont connect with the HP Connectivity kit, my old will connect

so I dont think its a problem with the computer, but will the software allow

2 49s on one computer. the only thing that happens is I get a variable
called '$$$t' in my Home Dir that contains a string - { 0.000000 0.000000

Revision #2.06 }Version HP49-C Revision 2.06 Has anybody seen that
before.
Maybe HP figures if I cant use it I wont break the keys hehe
===
Subject: Re: New replacement HP49g+
0.000000
'$$$t'
This happens early during the connection process.
Commands are sent to the calc to build an information string which is then
sent back to the PC.
I would guess that the calc. is still busy when the command is sent and the
command gets missed.
The timing of these exchanges is very critical and difficult to control.
But, of course, this should all be old history with Conn4x.
You did not mention your PC OS. I assume Windows XP.
Windows 98 does work but frequently has problems with various USB
configurations.
Here are some things to try:
Make sure you have Conn4x build 2353 or later.
Make sure flag -33 is clear.
Set flag -34 and then try a screen capture. Screen capture can be done
without a connection.
Plug in usb, select HPx9G+ in Conn4x box
Select File / Capture Calculator String
on the calc, hold ON press and release UP_Arrow, release ON
If all that works, then put in fresh batteries.
Try a USB port without going through any hubs. i.e. back of the PC.
-- - - - - - - - - - - - - - - - -
Bill Graves RKBA!
bgraves@ix.netcom.com
===
Subject: Re: New replacement HP49g+
[got string variable '$$$t' in Home Directory using Conn4x]
Sounds as if it connected great -- for a moment, anyway.
Did this happen before attempting any transfer,
or after trying to transfer (transfer what? in which direction?)
Let's see whether Mr. Conn4x (via email Bcc) can help.
===
Subject: Re: New replacement HP49g+
0.000000
'$$$t'
This happens early during the connection process.
Commands are sent to the calc to build an information string which is then
sent back to the PC.
I would guess that the calc. is still busy when the command is sent and the

command gets missed.
The timing of these exchanges is very critical and difficult to control.
But, of course, this should all be old history with Conn4x.
You did not mention your PC OS. I assume Windows XP.
Windows 98 does work but frequently has problems with various USB
configurations.
Here are some things to try:
Make sure you have Conn4x build 2353 or later.
Make sure flag -33 is clear.
Set flag -34 and then try a screen capture. Screen capture can be done
without a connection.
Plug in usb, select HPx9G+ in Conn4x box
Select File / Capture Calculator String
on the calc, hold ON press and release UP_Arrow, release ON
If all that works, then put in fresh batteries.
Try a USB port without going through any hubs. i.e. back of the PC.
-- - - - - - - - - - - - - - - - -
Bill Graves RKBA!
bgraves@ix.netcom.com
===
Subject: Re: New replacement HP49g+
Well it happens when its 1st connecting and eventually I get a message on
conn4x that Error (unable to connect to open comunication to: HPx49G+) if
Its defective I will build a collection of bad 49g+s, they didnt want my
old one back. I kinda remember having the same problem with my original
calc although it eventually started working, dont know what I did though and

dont remember seeing the '$$$t' file.
===
Subject: Re: New replacement HP49g+
and
The same thing happened to me. However, I was using a USB to Serial
connector on my laptop to transfer from my HP-48GX, not the HP-49G+.
The transfer was interrupted, then I got the blue screen of death (I'd
guess the USB-Serial driver for the connector I was using on my WinXP
machine was not fully compliant). I thought it was a combination of my
using this cable with Conn4x. I got a different ROM version string, of
course, but it did leave a '$$$t' variable in HOME and the resulting
string format was similar.
When using the USB port directly with my 49G+ cable, I didn't have any
problem (knock on wood).
John
===
Subject: Re: Chess for 49g+?
I seem to remember a program called MLChess or something like that
that was quite good
...Don't quote me on it, though
Mike
===
Subject: Second order DiffEq
Hi.
I have some questions about (graphically) solving second order
differential equations with the 49G+. On the user's guide (the 10MB
one) the only example provided uses a 2x2 matrix saved by the user in a
variable called A. The solution is then plotted writing A*X in the plot
setup window.
What I think is strange is that this is the only way I can make it
work. If I try a non-matricial transform of Y, both the numerical
solver and the plotter complain about invalid data. For example, Y and
A*Y do work, BUT a constant vector [ 1 2 ] does not work; even [[2 3]
[5 7]]*Y given directly does not work.
For example, I would like to plot/solve the classical
X'' = -sin(X)
the way it has always been solved, i.e. with
X' = Y
Y' = -sin(X)
But I wasn't able to find any way to do it.
Another (less important) thing I would like to ask is: why do the
numerical solver and the plotter always save the X,Y,t,... variables? I
find it unhandy, because after that I continuously need deleting them
to avoid substitution in general formulas. Any hint?
A final question: is there a way to plot phase portraits? Any nice
program on the Internet to download?
===
Subject: Re: Remote Display for HP48GX
Ooops, that should have been pins 33-36. Pins 31 and 32 are address
pins.
48GX
a