on the keyboard of my HP39G?Answer: The difference between the 39G and the 40G is that the 39G has an infra-red port and the 40G doesn't, while the 40G has a CAS system (Computer Algebra System) and the 39G doesn't. Apart from the obvious differences that the CAS system makes (some special extra functions and differences in the way that answers are presented) the user interface and behaviour are functionally identical. The chips are essentially the same. Basically Europe wanted CAS but not IR, while the US and Australia wanted IR but not CAS. You can never satisfy everyone can you? Make sure that you don't buy the wrong sort for your particular exam system as you might find yourself in trouble for using an illegal calculator.
Note: There is NO WAY to turn an HP39G into an HP40G (and get
a CAS) by disabling the infra-red. Snipping a few wires will just get you a dead
calculator not a live 40G.
.
Answer: Most of the aplets that are
written for the HP38/39/40G are written using the calculator's built-in
programming language. This language is flexible and easy to use but it is not
very fast when it executes because the calculator has to translate it into
machine code. If you'd like to know more about it then click
here . When a
programmer really wants speed - such as in a game - then they must write the
program directly in machine code. This is NOT easy to do but far more flexible
and VERY fast. When an aplet is written this way it is often accompanied by a 'library'
containing extra code. This library is automatically downloaded with the aplet
and deleted with it when it is deleted in the APLET view. When one of your
aplets has an attached library then you can view it by pressing the MEMORY
button, scrolling down to the Library entry and pressing VIEW. Generally this
view will be empty. If there is a library there then deleting it will stop the
parent aplet from working so it's best to leave the entries alone.
on the keyboard of my HP39G?Answer: Because there were more keys on the keyboard of the HP39/40G than there were on the HP38G we were able to fit in a few more functions. These functions were also present on the HP38G but you had to go through the MATH menu to find them. Looking at them from the top down & left to right...
Note: Much of this will not apply to the HP40G because of its computer algebra system giving exact answers.
d/dx (appearing as 
in the editline): This is the differentiation operator and is also available
from the MATH - Calculus menu. See the manual, page 10-7.
: This is the
integration operator and is also available from the MATH - Calculus menu.
See the manual, page 10-7 & 10-25.
ABS/ARG: These operators work with complex
numbers or with rectangular to polar conversions and are also available from the
MATH - Complex menu. For a complex number they give the modulus and the
arguement. For rectangular coordinates they give the values of r and 
. For example, see right. Notice the double brackets. The reason for this is
that the function requires brackets: ABS(....) and so does the coordinate
(3,3).
!: This is the factorial operator and is also available from the MATH - Probability menu. For example, 5! would give 120.
: This 'angle' operator can
be used to convert polar to rectangular coordinates. For example, if the HOME
view is in degree mode then you could convert (r,
) = (2, 30o) to rectangular coordinates as shown right. There's an
interesting variation on the use of this operator which will convert to r cis
format. In the example shown below right, what was actually entered is not what
appears on the screen. In the first example, I entered (
8,45)
with the HOME 
view in degree mode. As you can see, what appears in the History is the r cis
form and in rectangular format. I then changed to radian mode and entered (3,
/3).
Again the result was r cis
form and rectangular format.
: This is the summation
operator, also available through the MATH - Loop menu. The syntax is
very similar to the way that a problem is read aloud. For example, "the sum
from j = 1 to 3 of j 2" would be entered as
(J=1,3,J2) and would give an answer of 14 (12 + 2 2
+ 32).
AND: This is mainly used by the
computer algebra system on the HP40G. However it also comes in handy when
entering domains for graphing functions. Go back to the FAQ page and check out
question #47.
Answer: From a programmer's point of view, one of the most frustrating things about the HP38G is that there is no way to write a string (of characters) to the graphics screen. You can use the DISP command, of course, but it wipes everything in a band across the screen and so deletes the very image that you are trying to annotate. The only other way to do it on the HP38G is very laborious: you have to save a copy of the screen, create a graphic image of the string, superimpose the two and then re-display the image. This is slow and tedious.
Consequently I was very keen to see if we could build a better way of doing this into the HP39G and I was overjoyed when I managed to pursuade the programming team to incorporate the DISPXY command. The problem was that we did it so late in the process that the manual had already been finalised and so the command is undocumented. Here's how it works...
The syntax is: DISPXY <x_pos>;<y_pos>;<font>;<object>:
The <x_pos>
and <y_pos> are relative to the values of Xmin, Xmax, Ymin & Ymax as set in the
PLOT SETUP view, and the font number can be either 1 (small) or 2 (large). For
example, the program shown left will produce the result shown right if the axes
are set to the default values of -6.5 to 6.5 and -3.1 to 3.2.
The <x_pos>
and <y_pos> values refer to the top left corner of the text when displayed. The
clipping rules are a bit complicated, probably due to the fact that the command
was done in a bit of a hurry (in a hotel room late one night in Chicago!). If
the <x_pos>, <y_pos> corner is off the top of the screen or off the left edge of
the screen then the string will not be displayed even if part of it is onscreen.
If there is sufficient room vertically for the string but part of it would
display off the right edge of the screen then it will be partially displayed (see
right). On the other hand, if we were to move the text one more pixel downwards
so that it would display partially off the bottom of the screen then it will not
display at all. The best way to satisfy yourself of this is to experiment.
Finally, the value of <object> can include variables of any kind.
For example you could have a command:
DISPXY -6.5;0;1;"After "N" min the list is "L0:
.
Answer: The screen on your calculator is made up of small dots called pixels. On the HP38/39/40G the screen is 131 pixels wide and 64 pixels high and this is the reason for the default settings for the axes in nearly every aplet. On the x axis a setting of -6.5 to 6.5 gives 131 dots of 0.1 each (including zero). Similarly a y axis of -3.1 to 3.2 gives 64 dots of 0.1 each. Now you may be asking yourself "Why this odd size?" and, to be honest, I don't know. I can only suggest that the reasons lie in the manufacturing process.
Anyway, the point is that this affects your graphs and it becomes
particularly obvious with circles because part of the graph does not exist (the
part outside the circle). Let's look at the circle x2+y2=9
as an example. This circle only exists from -3 to 3 on the x axis and is
undefined outside this domain. In order to graph it on the HP you have to
rearrange it into the form y=.... so that it becomes two equations: F1(X)=
(9-X2) for the top half and F2(X)= -
(9-X2) for the bottom half.
If you enter these equations into the SYMB view and then graph them with the
default axes (in PLOT SETUP press SHIFT/BLUE CLEAR) then you get a perfect
circle (see right). However, if you go into PLOT SETUP and change the x axis
from the default setting to -6 to 6 and then re-PLOT then a strange thing
happens! Part of the circle disappears. This is shown in the snapshot at the
start of the question. There's a reason for this, and it lies in the pixels.
When the calculator draws the graph it only calculates y values for the x values which fall on pixels. After all, why bother calculating a value you can't display? It just "joins the dots" for the values in between. For the default scale of -6.5 to 6.5 this is not a problem since the edges of the circle at -3 and 3 fall on a pixel and this means that the last segment of the graph is from 2.9 to 3 and the circle reaches right down to the x axis.
However, for our new scale of -6 to 6 the pixels are no longer 'nice' values
of 0.1. If you try to TRACE the circle you'll see that the pixels fall on 0,
0.0923077, 0.1846154..... In particular, near x=3 the pixel values are 2.953846
and 3.046154. This means that the calculator can't draw anything past 2.953846
because the next value doesn't exist :- remember 
(9-X2) is only defined for values up to 3. This is what causes the
gap in the circle. There's nothing to join to past that last point.
So what's the solution? If possible, just use scales which allow the end points of your circle to fall on a pixel point. If your circle has a nice radius such as an integer then this is easily done by starting with the default axes and then ZOOMing in or out to show the circle. I would suggest using the ZOOM menu to Set Zoom Factors to either 2 or 5. This will tend to give 'nice' pixel points. If your circle is not centred on the origin then just check/tick the box in the Set Zoom Factors box to Recenter. That will allow you to turn off TRACE, move the cursor closer to the point where you'd like the centre of screen to be and then ZOOM.
Unfortunately not all circles have a nice radius! For example the end points
of the semi-circles for x2+y2=10 will not fall exactly on
a pixel point no matter what scale you choose. Judicious choice may allow
rounding to work in your favour but it's not always possible to set this up.
.
Answer: It is occasionally desirable to
be able to create or store an empty list in a program. The problem is that
simply using {}\>/L1 will just give a syntax error. There are a couple of
solutions to this, the simplest of which was contributed by Mark Howell.
He points out that the command:
SUB L1;L1;1;0
will store an empty list into L1. This method can also be used to empty a
statistics column.
.
.
Answer: Because some changes were made
to internal structures in the upgrade from the 38G to the 39G, aplets and lists
cannot be transferred directly from a 38G to a 39G using the infra-red link.
However there is no problem transferring Notes, programs or matrices in either
direction using the IR link.
WarningIf you try to transfer an aplet from the 38G to a 39G the process will appear to succeed. However when you try to run this aplet on the 39G it will simply lock up the calculator and/or cause it to reboot with possible loss of memory. |
If you wish to transfer an aplet or a list from a 38G to a 39G then you will
need to save it from the 38G to a computer, update it using the HP utility
covered below and then transfer to the 39G. This process cannot be used to
transfer backwards from 39G to 38G.
| A free Windows utility has been provided by HP to convert 38G aplets and
other objects to 39G format. This utility can be downloaded from the
‘Utilities’
page on my web site. Using it is very simple, requiring only that you
choose the directory containing the files and then click on the button
labelled ‘Convert Files’.
Once converted, the files are no longer readable by a 38G. For this reason it is advisable to convert a copy rather than the original. As of early 2001 there was a known bug in this utility which causes the conversion process to fail if any of the files are set to be read-only. This is unlikely to be the case for the average user but in case of a failure this may be the reason. To check, right click on each file and select ‘Properties’. |
|
If you are a former HP38G user who regularly used the ADK to edit notes
then you will be pleased to know that a version of the ADK is available for the
HP39G and HP40G. See my
Utilities page.
.
.
Answer: Sorry, you've got all you're going to get! :-) Personally I will be very surprised if you manage to use even the 234K!
The calculator has a ROM chip which contains the BIOS and a 256K RAM chip for
dynamic memory. Part of this dynamic memory is pre-allocated to be taken up by
"environmental variables". These include memories A,B...Z (whose size is known)
and pointers to dynamically allocated memories such as L1,L2..., M1,M2,...etc
whose size is not known in advance. In addition to this, each aplet has certain
environmental vars such as Xmin, Xmax, Ymin & Ymax that may be allocated to this
area..
.
.
Answer: All of the material available on my site, except for a few exceptions (games and Quad Explorer) are written in HP Basic. This is a fairly simple language to use for anyone who is at all experienced in programming.
There is a listing of all syntax and functions that make up HP-Basic in the manual and there are a number of examples of how to use the SETVIEWS command to link programs into a parent aplet. In fact, I wrote most of that section of the manual (and yes, I know there are mistakes in it but I wasn't the only one writing it! :-) However the manual does not cover binary/assembly code programming (sRPL) on the machine because it was never intended to be programmed that way by the average user. The average user will want to use HP-Basic but it has two big disadvantages.
Firstly, it is a bit limited in some areas. For example it has no facility to manipulate strings, which can be very frustrating. It also can't continuously check for key presses which means that games are more difficult to write.
Secondly, the program is stored on the calculator as a text file and compiled when you want to use it. This is why there is a delay the first time you run any program. Subsequent runs are faster because the calculator keeps the assembled copy. Even so, a calculator created assembly code program is seldom as efficient as a human one as it doesn't have any of the optimization that a human can add. This means that programs written in HP-Basic are seldom fast enough for good games.
If you want to produce really fast games and other material such as that then, as I understand it, you must develop your programs on a PC and compile them on the calculator. Unlike the HP48/49 family, the HP38/39/40G family members are not set up to do this directly - you have to develop the app on another platform and transfer. All the really good games available for the HP39/40G are done like this. The assembly level programming of the HP38/39/40G is VERY complex (I am told) and the experts tell me that if you want to learn it then you should first learn how to program the HP48 or HP49 and only then go the the 40G. I do not program at that level - I never had the spare time to devote to learning it. All the really good games available for the HP39/40G are done like this because sRPL is so much faster and more flexible than HP-Basic.
The most knowledgable people I know of who are writing these are:
You should also check out
http://www.hpcalc.org/ for more information and programs.
