Can someone fill me in...?
Han
features and the CAS. While the machine is a wonderful "tinkering"
tool, I find that it still falls short as a reliable calculator. The
erratic / inconsistent behavior of the CAS and related flags coupled
with the slowdown resulting from the 12MHz <-> 75MHz swap (I read
about this here on comp.sys.hp48), it seems that even after 3
generations (HP 49G, HP 49G+, and now HP 50G), HP still does not have
it quite together. =(
Can anyone shed some light on the history of the HP 49 -> HP 49G+ ->
HP 50G series in terms of hardware changes as well as operating
systems? Every now and then I would read a post that mentions Kenpo
OS... are there now several operating systems, and not just the
software emulating the Saturn CPU?
Getting back to the CAS, I find it odd that there is nothing in ROM
that essentially saves a user's settings, does calculations with
whatever necessary flags set/unset, and then restores the user's
settings. For example, when I evaluate a limit, flag -115 is cleared.
There is nothing that indicates this until I later use the square root
operation. Then there's the auto-prompting for complex mode; some
operations require it be turned off, and others require it be turned
on. Otherwise I get an error... I often think: why not just "do what
you have to do" and return the original state (flagwise)?
Other inconsistencies include special placement of inputs for sigma in
the equation writer, but the limit operator essentially uses algebraic
notation regarding inputs. The outputs of various calculations are
also inconsistent. For example:
4 5 XROOT
produces e^( 2ln(2) / 5 )... while mathematically correct, it is
completely inconsistent with other inputs. Anyway, that's all for now.
Virgil
<b10815d5-3124-4b32...@k17g2000yqb.googlegroups.com>,
Han <handuo...@gmail.com> wrote:
> I got my HP 50G about a week ago, and have been playing with its
> features and the CAS. While the machine is a wonderful "tinkering"
> tool, I find that it still falls short as a reliable calculator. The
> erratic / inconsistent behavior of the CAS and related flags coupled
> with the slowdown resulting from the 12MHz <-> 75MHz swap (I read
> about this here on comp.sys.hp48), it seems that even after 3
> generations (HP 49G, HP 49G+, and now HP 50G), HP still does not have
> it quite together. =(
>
> Can anyone shed some light on the history of the HP 49 -> HP 49G+ ->
> HP 50G series in terms of hardware changes as well as operating
> systems? Every now and then I would read a post that mentions Kenpo
> OS... are there now several operating systems, and not just the
> software emulating the Saturn CPU?
>
> Getting back to the CAS, I find it odd that there is nothing in ROM
> that essentially saves a user's settings, does calculations with
> whatever necessary flags set/unset, and then restores the user's
> settings. For example, when I evaluate a limit, flag -115 is cleared.
> There is nothing that indicates this until I later use the square root
> operation. Then there's the auto-prompting for complex mode; some
> operations require it be turned off, and others require it be turned
> on. Otherwise I get an error... I often think: why not just "do what
> you have to do" and return the original state (flagwise)?
If you want a program, or a series of commands, to end with all the same
flag settings and in the same directory as when it began, merely start
it with a PUSH command and end it with a POP command.
John H Meyers
> Every now and then I would read a post that mentions Kinpo OS...
> are there now several operating systems,
> and not just the software emulating the Saturn CPU?
My mental image (which may be too low-resolution to be accurate :) is
Kinpo: Hardware (incl tester and flash updater) and emulator, in separate bank of ROM.
HP: Saturn ROM banks (slightly doctored to employ some emulator-level things)
> Getting back to the CAS, I find it odd that there is nothing in ROM
> that essentially saves a user's settings, does calculations with
> whatever necessary flags set/unset, and then restores the user's settings.
Just like leaving the eggs to be added at home to a cake mix,
which Betty Crocker knew would make the home cook feel more involved,
HP knows that you will feel more involved if you do this yourself :)
You can, for example, use
PUSH [then do anything] POP
or you can use an automatic 'BetaENTER' program,
such as mentioned in some old postings
(which are older now than I am, which means that
I can't possibly have made them myself :)
http://groups.google.com/group/comp.sys.hp48/msg/a5716f4bf1cca011
(towards the end)
http://groups.google.com/group/comp.sys.hp48/msg/9eb78e7553ecc545
> Then there's the auto-prompting...
See flag -120 (automatically handled in above 'BetaENTER' program)
> 4 5 XROOT
What answer do you want?
[r->] [OFF]
Han
>
> Kinpo: Hardware (incl tester and flash updater) and emulator, in separate bank of ROM.
>
If this is really the case, that's just sad...
> Just like leaving the eggs to be added at home to a cake mix,
> which Betty Crocker knew would make the home cook feel more involved,
> HP knows that you will feel more involved if you do this yourself :)
Only I feel like I bought the latest and greatest blender, and am
finding out that making a smoothie followed by making a slushy could
potentially cause future smoothies to be have a different texture --
maybe even end up with a "roughie."
>
> You can, for example, use
>
> PUSH [then do anything] POP
>
Thank you for this fix. Is there any reason why this IS NOT the
default behavior? I am starting to feel like I have to write all these
small utilities to "fix" what should never even be "broken." I am
starting to feel sorry for any new user of the HP 50G.
> > 4 5 XROOT
>
> What answer do you want?
The same output that I would get for any other set of inputs such as 5
6 XROOT. If you enter 4 5 XROOT, you get e^(2ln(2) / 5) whereas 5 6
XROOT you get XROOT(6,5). Why is there this inconsistency? Either keep
them both at XROOT(X,Y) or both in the form e(LN(Y)/X).
Here's an example of what I encounter often -- something working in
"most" cases but fails in a general case:
'2*LN(3)+5*LN(7)' LNCOLLECT results in: LN(3^2*7^5)
'2*LN(X)+5*LN(Y)' LNCOLLECT results in: LN(X^2*Y^5)
but
'A*LN(X)+B*LN(Y)' LNCOLLECT does nothing... (I am aware that this is
the same behavior in Erable as well).
Another example:
'X*(X+1)' EXPAND produces 'X^2+X'
and
'A*(B+C)' EXPAND produces A*B+A*C'
whereas
'X*(Y+1)' EXPAND does nothing on the HP 50G but works as expect on the
HP 48G. (BTW, replacing EXPAND with EXPAN gives me the same results).
Well, it turns out that the CAS actually treats 'X*(Y+1)' as a
polynomial, so that EXPAND (or EXPAN) doesn't actually do anything
except to reorder the expression as '(Y+1)*X'. Except when you look at
the AUR it explains that EXPAND and EXPAN expand products and has a
misleading example showing '(X+Y)^2' expanding as 'X^2+2*Y*X+Y^2'.
And yes, I am aware of the command DISTRIB (which apparently is what I
really want). I just wish the documentation was a bit more clear on
how algebraic objects are handled. As far as I know, there is no
documentation on this behavior in any of the manuals.
As for flag -120... this is just sad. Whatever happened to being able
to work with complex numbers and yet still expect "real" results. As
an example:
'X^2/(X^4+1)' INTVX results will vary depending on the complex mode.
This itself is fine. But it is impossible to specify no simplification
over the complex reals and still be able to work w/ complex numbers.
That is, I cannot work with complex numbers and expect 'X^2/(X^4+1)'
INTVX to give me a result over R[X] at the same time. This would not
be a problem on the HP48 and Erable installed.
I could go on and on about what a "normal" user (regardless of prior
experience with TI and/or HP calculators) might expect and how they
could get frustrated by this calculator. I am just glad I have the
patience to keep pushing forward in learning the ins and outs of this
thing.
Virgil
<cc50ca3e-3b55-48bc...@a18g2000yqc.googlegroups.com>,
Han <handuo...@gmail.com> wrote:
> > My mental image (which may be too low-resolution to be accurate :) is
> >
> > Kinpo: Hardware (incl tester and flash updater) and emulator, in separate
> > bank of ROM.
> >
>
> If this is really the case, that's just sad...
>
> > Just like leaving the eggs to be added at home to a cake mix,
> > which Betty Crocker knew would make the home cook feel more involved,
> > HP knows that you will feel more involved if you do this yourself :)
>
> Only I feel like I bought the latest and greatest blender, and am
> finding out that making a smoothie followed by making a slushy could
> potentially cause future smoothies to be have a different texture --
> maybe even end up with a "roughie."
>
> >
> > You can, for example, use
> >
> > PUSH [then do anything] POP
> >
>
> Thank you for this fix. Is there any reason why this IS NOT the
> default behavior?
Yes! If it were the default, there would be no way for a program to
modify the system or user flags for use by other programs.
I, for one, would find that "cure" much worse than the disease.
Han
>
> > > PUSH [then do anything] POP
>
> > Thank you for this fix. Is there any reason why this IS NOT the
> > default behavior?
>
> Yes! If it were the default, there would be no way for a program to
> modify the system or user flags for use by other programs.
>
> I, for one, would find that "cure" much worse than the disease.
What I meant was, why doesn't the default ENTER function not have this
already built-in? Or at least have a flag that effectively enables
this PUSH/POP effect?
Han
Actually, changing ENTER doesn't help. Commands accessed from the
keyboard would not be effected. A better approach would be to have
each CAS command should respect the flags before it is run. This would
not effect user programs that alter the system flags, since only the
CAS commands are contained within the PUSH/POP environment.
John H Meyers
>> Kinpo: Hardware (incl tester and flash updater) and emulator, in separate bank of ROM.
> If this is really the case, that's just sad...
They design and produce electronics of all sorts,
including cheaper calculators, even for HP's rival Texas Instruments,
now that the only products made in USA are burgers, fries, Coke,
entertainment featuring continual explosions,
and gigantic financial structures made of material lighter than air :)
http://wrightreports.ecnext.com/coms2/reportdesc_COMPANY_C76072400
http://www.rskey.org/~mwsebastian/selftest/kinpo_test.htm
http://en.wikipedia.org/wiki/HP_calculators (search for Kinpo)
http://www.hpmuseum.org/therest.htm (search for Kinpo)
http://www.engadget.com/2009/06/07/kinpo-shows-off-7-inch-android-thin-client-tablet/
http://www.kinpo.com.tw/English/ "Last Update:2007/10/2"
At one time, we may recall,
U.S. manufacturing had already moved entirely to Japan,
but now "The Simpsons" is the only thing still made there :)
> Is there any reason why [PUSH...POP] IS NOT the default [CAS] behavior?
Not ideal for some commands which are supposed to set flags? (e.g. XQ)
It is a tall order to squeeze a lot of CAS into the little room available,
under the constraints of the internal OS, and all by one independent contractor
who gave much more support than HP may even have paid for, some say.
"You get what you pay for" (or HP paid for, in this case)
However, consider all that we have come to know about how
having machines do all our work has made us less physically healthy;
will it turn out, then, that CAS "answer machines"
also turn students' brains to mush, and that the HP49/50 series
is the only hope for developing future engineers and scientists,
since you still have to think a little?
I shouldn't talk, however, since I don't even use it :)
A parting thought:
"As you travel on through life, Brother,
Whatever be your goal,
Keep your eye upon the donut,
and not upon the hole."
[r->] [Off]
Bart
>
> Getting back to the CAS, I find it odd that there is nothing in ROM
> that essentially saves a user's settings, does calculations with
> whatever necessary flags set/unset, and then restores the user's
> settings. For example, when I evaluate a limit, flag -115 is cleared.
> There is nothing that indicates this until I later use the square root
> operation. Then there's the auto-prompting for complex mode; some
> operations require it be turned off, and others require it be turned
> on. Otherwise I get an error... I often think: why not just "do what
> you have to do" and return the original state (flagwise)?
>
When I reached a point where I was happy with my chosen flag settings,
I used RCLF to get the hex stings of all the falg settings, and stored
it to a variable. Now I can recall this and use STOF to set the flags
back to my own preferences whenever I need. I can even store different
settings, and easily swap between them.
-B
Veli-Pekka.Nousiainen
If you use googkle groups and google for that CAS problem you will
finally find thgat that behaviuor has been asked for decade ago.
It seems that you really have to set up the User Mode flag and the
Vectored ENTER Flag and then use the AlphaENTER and BetaENTER variable
to store brograms that do PUSH and POP and maybe check for XQ plus
simiklar cases for special treatment if you think uit's absolutely needed.
Naturally in your programs you should remember to do PUSH & POP and set
the "Silent Mode Change" flag. Yeah! A kiot of extra work, but it is
also up to HP not to pay for Bernard Parisse to do somne aditional
maintainance work for the CAS. I think that mayb
e also Jean-Yves Avenard shoukld be hired fior a moment.
What I'm now waiting for is that HPGCC 3.0 compoatible RON 3.0 is released.
Yes! That is thge ROMN version I would expect
Why? You mnay ask and Cyrilkle de Brebisson as weklkl.
It's a really big change - to accommodate the HPGCC 3.0 into the ROM
that the ROM version number should reflect this acordingly.
IMHO
VPN
TW
> What I'm now waiting for is that HPGCC 3.0 compoatible RON 3.0 is released.
HPGCC is a dead project at the moment, and v3 will likely never be
released.
Any code from HPGCC will never be incorporated into the official HP
rom. Maybe a launcher could be added at some point, but it isn't a
priority at the moment.
TW
Bruce Horrocks
> Can anyone shed some light on the history of the HP 49 -> HP 49G+ ->
> HP 50G series in terms of hardware changes as well as operating
> systems?
If only I could write as well as Verity Stob.[1] Oh well, here goes...
In the beginning there was the HP28C. It 'only' had a 4 line display and
2KB of RAM but it introduced RPL, nearly as we know and love today. It
was a marvel: it could do symbolic algebra which was unique for the
time. It could symbolically integrate and differentiate. And it was
really fast: it would really quickly tell you that it had run out of
memory. Still it was quite a big hit, setting the standard for the
models to come.
Next came its big brother the HP-28S. (Funny how, in the calculator
world, big brothers are younger than little brothers.) It had 32Kbytes
of RAM. And in those days, 32Kbytes was so enormously big that it needed
to be *managed*. So out went the single line of variables in the 28C and
in came 'directories'. Ta da! Yes, you could organise variables into
directories and subdirectories. Directories were really useful - when
you lost the entire memory of the calculator trying to change batteries,
you could now exclaim 'Gosh darn, I've just lost five entire directory's
worth of work!' Which sounds as though you've been so much more productive.
The 28S was very popular. People loved its clamshell design with two
keyboards, meaning that the keys could be clearly labelled without
clutter. They didn't love the battery door though, which broke quite
often, even if you weren't a clumsy oaf with the finesse of an elephant
wearing boxing gloves. So along came the HP48SX.
SX stood for Scientific Expandable, but it was all too easy to think
'Expendable' instead. Except that it wasn't really expendable since
things still cost 'too much' in those days. However, it solved the
'losing data when changing batteries' problem by having a serial port
which allowed it to be backed-up to a PC. Hallelujah! It had 32KBytes of
RAM but you could add memory cards of either 32 or 128Kbytes. One of the
cards could be merged with main memory to give unheard of amounts of
working RAM. (Actually I use the phrase 'unheard of' metaphorically - if
someone actually had one of these cards then, boy, did you hear about it.)
The other major change was to drop the clamshell case. Apparently
'marketing' (those people in the back office who don't get out much
except when they've run out of coke) did some 'research' and discovered
that 'students' expect a calculator to look like a rectangular block
with a big screen at the top (as big as possible, irrespective of the
actual resolution) and lots and lots of buttons underneath. Preferably
with about 5 or 6 labels on each. Any calculator designer who produced
designs that did not follow this model exactly was sent off to the
Siberian salt mines. (As an aside, I have some wonderful prototype case
designs carved in solid rock salt.) The HP48SX was as near perfection as
there has ever been in the RPL line. But perfection can be improved upon
by applying the 'less is more' philosophy.
The HP48S was the result. It had identical software to the HP48SX but
less hardware - specifically only 32KBytes of RAM and no expansion
ports, so you couldn't add memory cards. It retained the serial port but
so slavish was the adherence to the 'less is more' philosophy that even
the model name had a letter removed.
The 48S was actually a remarkable product - remarkable because it sold
in large numbers - much more than expected. But even more remarkably, it
caused sales of the HP48SX to increase as well. So much so that HP felt
they could afford to introduce an updated version, the HP48GX.
The GX was even more student oriented (aka in the absence of critical
thought, we'll try and be as TI like as possible). So it introduced
drop-down menus for everything. These were slow. Really slow. Really,
really slow. But they could at least be turned off. So that was good.
Best thought of as 'shop demo mode' i.e. looks good and really easy to
use when dad is shown it by the bloke in the store. (Dad being the buyer
of HP calculators and so has to 'approve' the purchase even though he
doesn't really have a clue and it is the son who's going to college and
will actually use it.) Also those menus make it really easy for the
bloke in the store to look like he knows what he is doing. (At this
point I feel I should diverge into an honourable mention for Richard
Nelson who was one of those blokes in a store. In fact he was the bloke
in his *own* store. And he did know what he was doing, even if he didn't
look like it.)
The GX wasn't well received. The colour scheme on the keyboard was
changed from nice clear orange and something (I forget and I don't have
mine with me at the moment) on the SX to green and purple on the GX.
These were hard to tell apart under anything less than bright lighting
and, for those with the wrong type of colour blindness, they were all
but impossible to tell apart under any lighting.
Naturally the GX needed some more features so list processing was added
to RPL. An attempt was made to allow more or less any command to work on
either its traditional single arguments or lists of arguments. This
mostly worked as expected but there were some surprises. Also some
explicit list processing commands were added. These turned out to have
been rather poorly coded and faster, more robust community derived
versions in userRPL were quickly developed.
The GX came with 128KBytes of main memory and is expandable with two
memory card slots like the SX. There were some electrical changes (IIRC)
which enable larger cards to be used. At the expense of compatibility
with the SX ROM cards. But that wasn't too big a problem since SX ROM
cards were fantastically expensive and only corporate types could afford
them. The GX was soon followed by a cheaper, HP48G model released with
only 32KB of main memory and no expansion card slots. By now (1998),
32KB was looking rather miserly and HP quickly came out with the HP48G+
with 128KB instead. (This actually makes a very nice calculator and well
worth getting if you find a cheap one on you know where.)
Here endeth the 'old testament' namely the old certainties of one true
religion - RPN - and a large enter key. What followed can only be
described as 'new testament' because ever increasing amounts of
forgiveness were demanded from HP fans.
The HP49G was the first model to drop the Saturn CPU (a custom design
from HP that had been in use for decades) and use an ARM to emulate it.
The interface was revamped by incorporating the MetaKernel. This
wizardry was achieved by employing Cyrille de Brebisson and Jean-Yves
Avenard, two French students who had developed and were selling an
alternate interface for the 48GX. HP then nullified this stroke of
genius by saddling them with the worst rubber-key keyboard design since
the Sinclair Spectrum. They were also forced by the 'marketing' people
to implement an algebraic mode and, rubbing salt into the wound, it was
the default mode. This was, apparently, so that 'students' would be more
'comfortable' with it. All it probably did was contribute to an increase
in bullying - previously the one HP user in a class of TI sheep could at
least claim he was being different and thinking for himself; now it just
looked like his dad had gone to store *on his own* and bought the wrong
one because it looked vaguely like a TI.
What should have been a great machine was let down by an awful keyboard
and it is now fondly remembered as 'the frozen Hamster-butt blue one'.
It did also introduce flash ROM and so the ability to eradicate bugs by
loading a newer ROM into the machine.
Next was the HP49G+. This was so good that eBay prices for HP41s in
virtually any condition went through the roof. The 49G+ replaced an
awful rubber keyboard with an awful plastic keyboard. So not really an
advance. HP were really, really struggling with keyboards at this time
as the other models in their range at the time were just as bad or
worse. No doubt the true story will emerge at some point in the future
when a Chinese multi-gazillionaire writes his memoirs explaining how he
got rich by screwing HP.
Finally, (skipping some oddities like the HP48GII) we come to the HP50G
which is still on sale today, has a quite passable keyboard and which
you all know and love, so I'll shut up. If they update it with the
keyboard technology used on the new 30B then we'll almost be back to
where we were in 1982. ;-)
Here endeth the history of the HP48/49/50 series.
[1] http://www.theregister.co.uk/odds/stob/
--
Bruce Horrocks
Surrey
England
(bruce at scorecrow dot com)
Jacob Wall
Nice write-up Bruce! I found that enjoyable to read. A lot of what
you mentioned was new to me actually, so even though I was hoping to
go all day without learning something new today...
I became a HP calc user in 2005 when I bought a 49g+, which has a
perfectly working keyboard still, must be the later model, now quite
happy with the 50g which I prefer slightly although my 49g+ sees
regular use still. Never owned or used a 48 series, and definitely
not a 28S, so I can't compare the quality of the 'old testament'
calculators to the 'new' ones.
Also I've had only positive experience with the new ones so no reason
to spend more for older technology, IMO.
Jacob
Al Borowski
This is kind of depressing. I remember multiple people wanting to
release patches or updates to the released version, only to be told
"don't bother, it's fixed in 3.0".
Is the source code for 3.0 online anywhere?
Cheers,
Al
TW
> release patches or updates to the released version, only to be told
> "don't bother, it's fixed in 3.0".
>
> Is the source code for 3.0 online anywhere?
I think Egan Ford has it, but I don't know if the authors ever gave
permission for it to be released publicly and I don't know which
license it was under.
I, and several others, were quite annoyed at the HPGCC team for that
reason. It is one thing to say "it's open source, do it yourself" or
something to that effect, but individuals were actively discouraged
from participating which really killed interest overall in C for the
calculators . . . :-(
I can understand why the team would want to release a nice, finished
project, but I don't like what happened as a result. It is probably
time to take the v2 code and start from there.
TW
TW
Just a quick edit here - it still ran a 4mhz saturn. It wasn't until
the 49g+ when it became emulated.
> from HP that had been in use for decades) and use an ARM to emulate it.
> The interface was revamped by incorporating the MetaKernel. This
> wizardry was achieved by employing Cyrille de Brebisson and Jean-Yves
There were a few more of those 'french wizards' besides those two. By
working 20 hour days, living at the HP facility, and the fact that one
could simply say "I need a choose box engine" and that took the place
of a 300 page specification document, they were able to get it done.
Nothing short of a miracle in many ways. . .
TW
Bruce Horrocks
>> The HP49G was the first model to drop the Saturn CPU (a custom design
>
> Just a quick edit here - it still ran a 4mhz saturn. It wasn't until
> the 49g+ when it became emulated.
>
>> from HP that had been in use for decades) and use an ARM to emulate it.
>> The interface was revamped by incorporating the MetaKernel. This
>> wizardry was achieved by employing Cyrille de Brebisson and Jean-Yves
>
> There were a few more of those 'french wizards' besides those two. By
> working 20 hour days, living at the HP facility, and the fact that one
> could simply say "I need a choose box engine" and that took the place
> of a 300 page specification document, they were able to get it done.
> Nothing short of a miracle in many ways. . .
There's always space in Datafile for a warts 'n' all exposé...
Han
and then. Are they at all part of the problem? Or were there hands
tied by the folks from HP who wanted to "dumb down" the calculator. I
seriously believe that the ALG mode is a complete waste of ROM,
especially when in the quick start guide they mention just how much
better RPN is.
TW
> and then. Are they at all part of the problem?
Somewhat. The code they made is the low level OS that runs the
saturnator (the arm saturn emulator written by Hydrix). A lot of it
was not very good. For example, the kinpo C fseek command is a POS.
> especially when in the quick start guide they mention just how much
> better RPN is.
That's because I wrote it. :-)
TW