D-109
===
Subject: Checking for HP calcs files
I'd like to know if it is possible to be sure that a selected file is
for the HP calculators or not?
As binary files for the calc start with the header HPHPxx-x can an
application consider this to be an HP calculator file? Is it a
suffiscient check?
Fred.
NB: if I remember well, text files have also another header that start
also with HPHP... but I don't remember all ;)
===
Subject: Re: Checking for HP calcs files
If you mean to sort out computer files and display
appropriate icons with pretty good likelihood,
(or something like the Unix file command,
which takes good guesses at what files are for,
especially when aided by known binary prefixes), then why not?
If you mean to actually let them be loaded into the calculator,
then more stringent tests are normally performed,
at least by the original Kermit I/O code
and by certain careful object fixers (e.g. objfix, fixob)
which run in the calculator itself.
The reason for such additional tests (at least for
a valid object ROM address, then making sure that SKIPOB
agrees with its apparent length) is that if you let anything
prefixed by HPHP49-x be referenced in HP49 memory, say,
it could easily crash the calc if it were corrupted
or truncated (or even too long),
or produced by or for the wrong model, etc.
This is why the poor man's OBJFIX (simple UserRPL in 49G,
which just bypasses the 26 total nibbles of combined
string header and HPHP4x-y) is slightly risky,
but for something intended to run only on computers,
rather than in the calc itself, go right ahead
(and count those beginning with %%HP: as well :)
===
Subject: Re: Checking for HP calcs files
Hi John,
Actually I simply want my application checking if the file is valid
before uploading it into the calculator. Thus, no matter the
calculator. I just want to check if it's a file for any hp calculator.
Fred.
===
Subject: Re: Checking for HP calcs files
You can do a cursory check for HPHP49-x or HPHP48-x or %%HP:
at start of file; calculator will check further when it gets file.
Some text files are legitimate ascii text or UserRPL program text
yet may not start with %%HP: if created on the computer,
rather than by export from the calculator itself.
Actually, any file whatsoever is legitimate for binary mode
transfer to calculator, if all you want is to be able
to store any computer file verbatim on the calculator!
(as a string)
The %%HP: (if present at all) needn't be the very first characters;
ROM-based Kermit was happy to find it anywhere in the first packet,
but what today's binary transfer software (E.g. Conn4x) does with
text files depends on what helper program it first sends to the calc
(unless it's built into the Xmodem Server XSERV command itself).
However, HPHP4m-x must be the very first characters of binary files;
4m tells you with which series it is compatible (48 or 49).
So that's my long story, once again
(All the news which fits, we print :)
Bonjour!
===
Subject: Re: Checking for HP calcs files
Well,
As I'm lazy, according to Brother-Peter, I'll let the user be sure that
the file is correct :P
The calculator will do the rest.
I'm upgrading my HPConn project to .NET 2.0 with a more simple user
interface :)
But I'm stucked because we still can't communicate with USB drivers in
.NET 2 without doing ugly stub classes. So, for the moment, I'm just
playing with RS-232 and HP-48 by doing an N-th XModem and Kermit ;)
===
Subject: Re: Checking for HP calcs files
Did I say so? Word 4 word? I apologize then!
Nice to know
Soon the Windows Vista to a Kill will arrive
Are you prepared for some new driver technology?
Just asking...
===
Subject: Re: Checking for HP calcs files
I'll check for driver technology when the final release of vista will
be available. I NEVER use MS betas. One day at a time :)
For now I'm just playin' with .NET 2 and I have strange behaviours with
the reception. lol
Some packets are sent twice by the calc while the CRC is correct and I
sent a CHACK. I'm debuging that :)
===
Subject: Re: Checking for HP calcs files
Use the PC emulators as a testing environment
rather than (possibly) corrupting your calc
===
Subject: Re: Transferring programs from card
Scurvy Marauder?
I'm a Buckaneer!
===
Subject: Re: Transferring programs from card
A buck an ear is way too much to pay for corn.
===
Subject: Re: Using the HMS functions in a user RPL program.
[didn't see the whole thread, wants an HMSRND function]
So look back; I didn't parameterize it with an argument
for how many decimal digits to keep, say,
but you can proceed to do that for yourself,
as I am taking a short break from writing calc programs :)
Actually, the following cheap shot has some chance of working,
but I leave testing (and any fixing) to you:
Args: HMS_value(real) #places(real_or_zint)
It works even with improper input like .995999999999 11
or .999999999999 11 (that's what the first HMS+ is for),
but no warranty is expressed or implied :)
Values of 1 or 3 for number of places are not very reasonable,
but try anyway and see what happens :)
===
Subject: Re: Some questions before buying HP49g+
Sorry that this thread turned to a bit of flame.
Anyway, I am going to state again what I would expect HP49G+ should do
for me:
-Quickly find the odd intergral/derivative that is too time consuming
to find manually
-Test ideas, quickly check graphs and examine numerical results
-Store set of calculations for later reference
-Speed up parts of calculations that I know how to do them but are too
much time consuming.
In general, as an AID to pen and paper, when I do not want to fire up
Matlab or Mathematica (so I do not have to lug a computer around).
I just want it to be a underpowered maths-oriented computer (without
forgetting its limitations of course), so it can help me through some
tiresome calculations and be able to develop and test algorithms on it.
The question is if I can use it this way.
===
Subject: Re: Some questions before buying HP49g+
That's the way I see it, a sort of glorified paper napkin, for roughing
ideas, for quick experimentation. I think that's the niche beyond the
classroom.
MK
===
Subject: Re: Some questions before buying HP49g+
The original goals of HP in creating the HP48
were stated in the System RPL manual RPLMAN.DOC:
| The HP 48 calculator was designed to be
| a customizable mathematical scratchpad
| for use by students and professionals in technical fields.
In the intervening years, however,
it has also found ever expanding uses, such as:
o an emulator of more antique HP calculators
o a surveyor's data collection tool
o a telephone directory and PDA
(well, why did HP supply alarms? :)
o to play games on (minehunt, tetris, even chess)
o a music player (primitive though it be)
o a TV remote control
o a way to send text messages to nearby classmates
(before they all had cell phones :)
o to display photos of famous sexy models
So what kind of throwback is this,
that someone actually wants to use it now
for the original intended purpose?
Where do they dig up people like that, anyway? ;-)
===
Subject: Re: Some questions before buying HP49g+
What is still missing
is the Complex Number Solver directly in the EQW
using Units in Polar Mode (no mode switch for user, please)
X is initally 1_V
( X <) 45_o ) + ( 3.5_V <) pi/6_r )=( -14_V <) 125_o )
One could also solve for the angle alpha, initially 0.5_2pirad
which is introducing a new unit
where full circle is 1_2pirad instead of 2pi_r
notice the use of algebraic symbolic pi
inside a Polar Complex Number representation
which naturally is done using a list
in a very similar way the new symbolic matrices are done internally
Brother-Peter
PS: EE-Engineers have been asking for this in two different millenia
that is: already thousands of years :-)
===
Subject: Re: Transfer error between HP49G+ and HP49G-Files
Looking up TNT at hpcalc.org:
http://www.hpcalc.org/search.php?query=tnt
Finding this statement about 49G version:
Easy-to-use, but not completely stable, file compressor.
Hopefully compatible, then.
What are they when recalled to the stack -- still look like strings?
If so, what does the string start with?
Is it HPHP49-x? (once, or more than once consecutively?)
If it is some other, seemingly completely unintelligible string,
remember that TNT itself outputs its compressed objects
as strings -- even the self extracting or self extracting
and executable objects look like garbled strings in the stack display,
although DUP TYPE will for those actually show type 8 (program).
The TNT? command tests whether objects are recognized by TNT,
and the TNT command then unpacks them;
self-extracting or self-executing objects are programs
which call TNT to unpack themselves,
unless they were compressed with an option
to include a self-contained unpacker program
(like SFX for Zip on computers).
BTW, have you installed TNT into your 49G+?
If you used Kermit (or other Ascii mode transfer software in PC)
to transfer compressed strings out of the original calculator,
that could potentially be a problem, because the compressed
output of TNT may include all characters, including binary zeros
(nulls), which may later be problematic as to properly
transferring back to a calculator, so we should always
use binary mode to transfer anything other than plain text
or pure UserRPL (which can be completely expressed in plain text).
Again, see what DUP TYPE says (strings are type 2,
programs are type 8), and if it's not a string
beginning with HPHP49-x then try TNT? or TNT command on it
(TNT? outputs the value 1 if it's recognized as valid).
If OBJFIX/FIXOB doesn't accept a string beginning with
HPHP49-x, then it's quite likely a corrupted string;
even if you can hack it to pass as a valid calc object,
the next hurdle would be to pass TNT's own CRC check,
which is another layer of protection, absent from BZ etc.
===
Subject: Re: Transfer error between HP49G+ and HP49G-Files
X
X
What?
TNT  *only* does a crc check on a compressed object?
Seems like a good product to me
especially if it can make self-extracting objects
===
Subject: Re: Transfer error between HP49G+ and HP49G-Files
I'm just quoting the included TNT.doc:
* Compressed files are CRC protected
so that if the compressed file is altered for any reason,
TNT-Packer won't try to uncompress it
and thus won't corrupt your memory
as BZ would do in the same situation.
Do you mean that you are alarmed that the CRC check
may be applied after compression, rather than before?
This is a very practical way to avoid having to crash
the unpacker before ever being able to check the unpacked CRC :)
I had to do something similar for ASCI and ASCO
Any compressor can be used to make self-extracting objects
via a small wrapper program, as did BZM using BZ;
in the TNT case the same author supplies both, which is nice,
though if BZM came with a copy of BZ, then it didn't much matter.
Note that the lower-overhead style of self-extractor relies on
the decompressor being already installed at self-extraction time,
while the independent, higher-overhead style
copies the [constant] decompressor program right into every object.
===
Subject: Re: Transfer error between HP49G+ and HP49G-Files
X
I just hope that a CRC check and decompressor could be part of OS
===
Subject: Disp5x7 and DISPN on 49G+
This program distills the method by which my ancient
@ Write on every available line of HP49G/49G+ full screen
@ (according to current font size):
<< 7. FREEZE :TURNMENUOFF:#2F034h SYSEVAL CLLCD
1. VERSION DROP #1. POS 64. 80. IFTE @ 49G vs. 49G+
:GetFontHeight:#2623Dh SYSEVAL R~SB / FLOOR @ how many text lines
i 1. :COERCE2:#3F481h SYSEVAL :Disp5x7:#25EBCh SYSEVAL
Result:
o It works perfectly as always in the 49G, but:
o The additional screen lines at the bottom of the 49G+ screen
*remain*blank* (the range left on the stack shows, however,
that we attempted to write to them as well)
The following version replaces Disp5x7 with DISPN;
it also works fine on the 49G, but on the 49G+:
o It works fine with font height 8 (it does now show all lines!)
o But it *warmstarts* (crashes) with font heights 7 or 6 (why?)
<< 7. FREEZE :TURNMENUOFF:#2F034h SYSEVAL CLLCD
1. VERSION DROP #1. POS 64. 80. IFTE @ 49G vs. 49G+
:GetFontHeight:#2623Dh SYSEVAL R~SB / FLOOR @ how many text lines
i :COERCE:#262F1h SYSEVAL :DISPN:#25FB3h SYSEVAL
Am I doing something wrong?
Or is it the 49G+
(do both Disp5x7 and DISPN need adjustment for the larger screen?)
===
Subject: Re: 49G+ recent versions' keyboard fixed now or not?
No, it doesn't. The best ROM for my HP49G+ is still the very first
one. The keyboard misses some keys, but this is less annoying than the
auto-repeat function some of the keys show with build 50, build 80 or
build 83.
Frank.
===
Subject: Re: 49G+ recent versions' keyboard fixed now or not?
Surely not v1.22? It had severe power drain issues.
Steen
===
Subject: Re: 49G+ recent versions' keyboard fixed now or not?
Perhaps his best was Build 50 ?
===
Subject: Re: 49G+ recent versions' keyboard fixed now or not?
The worst case is the hp49g+, which often has 1-key failures! BWAH Hah
you know of any?
-jkh-
===
Subject: Re: 49G+ recent versions' keyboard fixed now or not?
As a very simple example,
if you are making a crossbar keyboard array
with direct connections (no diodes, resistors, etc.)
and if there are any two horizontal lines
and any two vertical lines which have actual keys
at each of the four crossings, and if you press and
keep holding down any two of these four keys already
and then press a third key down, you will at that moment
have all four lines simultaneously connected together,
making it impossible to discern which of the two remaining keys
was just added to the already-down set.
So you have to introduce some other element if you want to resolve
such ambiguities, such as adding more crossbar lines
until you can avoid any four-way situations like that,
or using diodes or resistors to help distinguish
which connections were actually made, etc.
Another poster sounds like a real keyboard engineer;
I didn't study his post, but pardon if this has
already been more than covered.
===
Subject: Re: 49G+ recent versions' keyboard fixed now or not?
X
I hope that HPW hires such a real keyboard engineer
with one job in mind: a new perfect calculator keyboard
that will last 10 years, 10 hours a week usage pattern
===
Subject: Re: 49G+ recent versions' keyboard fixed now or not?
hello,
Note, your PC keyboard is the same! it's a matrix and they are 3 keys
combinaisions on your PC keyboard (different in each brand of keyboard) that

will cause the same issue...
for example ESC F1 F6 does not wok on my PC keyboard (which makes it hard to

do a ON A F on EMU48, which is why I need to do ESC F1 F instead)....
note that the HP48 series had the same problem, but starting on the HP49,
the algorithm changed.
on the 48, the calculator would not register any key after the 2nd key,
while on the HP49, you can press much more keys at the same time, provided
that they do not cause a keyboard matrix square as described above. For
example, if you are in alpha mode, try Q R S T U simultaneously, they will
all register.
so, the HP49 series is an improvement above previous HP calculators in this

respect!
===
Subject: Re: 49G+ recent versions' keyboard fixed now or not?
no sh*t, Cyrille!
BUT
the broken hinges is one problem: a different construct is needed
AND
the missed keys/douplepresses is also because of the design
There are only a few HW flaws:
1) keyboard durability & keypresses
2) clock
both of which are also a SW problem
I really hope that in the future
you will also have a real RS-232C controller in each top-model
Using bigger AA batteries could be a bonus
as they put more weight and thus give a sturdier feel
1*AA = 3*AAA in energy density and NiMH AA's are much cheaper
SW: Please, please make the CAS save the User flags
the change the modes internally then Restore the User Flags
ALSO
the solver etc.. should not demand to purge a user variable first
Clock/Alarms are not working
etc...
You have a lot of work to do
BUT
I'm still hoping for a new 49g++, 39g++, 48GIII
with RS-232 & big batteries and...a totally new keyboard
===
Subject: Lost items from Port 2 (flash) in 49G+ (again)
Well, it's done it again --
lost not only my most recent memory backup,
but also my Nosy library vanished as well from Port 2,
immediately after I did a RESTORE (I also got Invalid
Card Data again on every warmstart since that RESTORE;
doing PINIT cured the Invalid Card Data
at the expense of the instant disappearance
of my both last backup and my Nosy library.
and 368K free in flash; it also just occurred
with very fresh batteries installed,
although they became freshened only after
an earlier low batt warning.
So it's acting like a sieve which can't hold water.
Any thoughts on what's happening under my hood?
Some other little observations about which I'm curious:
The backup which I'm restoring to 49G+ was actually made
then recalled to emulator stack, save object to PC disk,
and finally transfer via Conn4x to 49G+
Naturally this produces a directory object (not a backup object)
in the 49G user area. After copying this directory
on the user variable, and I noticed that it took a very long
time to purge -- yes, I thought, that's because the RPL system
has to be very careful about any referenced items, and has to
recurse through the entire subdirectory structure to be sure
that it doesn't cause a TTRM by keeping a reference
to something which is about to be purged.
Then I copied that whole directory back into user memory,
and this time I asked the *Filer* to delete it for me,
rather than using PGDIR -- well, I think that the Filer
deleted that entire directory so fast that it was gone
even before I could release the PURGE menu key :)
How does the Filer manage to do that without worrying at all,
while PGDIR still plows through the slow but sure procedure
which we once thought to be necessary?
Getting back to my first issue,
based on my repetitive experiences with backups and libraries
vanishing from Port 2, I recommend using that SD card slot
all the time -- don't leave HOME without it :)
===
Subject: Re: Repairing damaged HP48's
Would you be willing to sell acouple of them for a good alternative ?