Poll: What additional software would you like to see for the HP 50G ?
Andreas Möller
I have a little spare time that I’d like to spend on programming the
HP 50G.
So what kind of programs would the group like to appear for the HP
50G ?
What do you think is missing that should be available ?
Best regards,
Andreas
http://www.software49g.gmxhome.de
Damir
Good DFT FFT software for processing data from SD card.
[Damir]
Full Name
How about porting Xcell (Spreadsheet package) to the 49g/50g to take
advantage of the larger display?
Dave
Yann
Wait, is that not what "Kompression Aid" is doing already ?
Yes, it is !
So I suggest to you an improved version to help long-time HP users.
The main idea behind this proposal :
*safely* compress *very-large* libraries from the HP48 area (such as
those beyond 100KB).
There is no such tool today up to the task.
Therefore, although the program may only run on HP50g,
it should be able to compress HP48 libraries too (on top of regular
HP49/50 ones).
I guess the object structure is the same, so this requirement might be
the easy one.
Specific interest points :
- multiple pointers into the same program ==> detection, compression
exclusion
- unreferenced area (baaad programming, this in essence means no
possibility to work outside Port0, and forbidden compression)
- extreme care for memory consumption, at each step. This program
shall be able to compress 128KB libraries too !
- capability to select compression program at run time (on top of
already provided ones)
In the end, it looks like a fair improvement to Kompression Aid, which
btw already does a good job, within the limits already underlined.
As for usage perspectives, I believe a lot of already developped
libraries would greatly benefit from such a program.
Large libraries are typically compression-friendly, resulting in very
sensible memory savings.
For your liking
supergems
Bruce Horrocks
> What do you think is missing that should be available ?
How about a new programming language? :-)
Specifically, something similar to HP-41 FOCAL with LBLs and GTOs. The
idea is not to replace userRPL but provide something simple that
beginners can start with for small macro type programs.
--
Bruce Horrocks
Surrey
England
(bruce at scorecrow dot com)
Teuvo Yrjömäki
> Good DFT FFT software for processing data from SD card.
Bumping for FFT! Might be doing that myself, too... doesn't the 50g have
a built-in FFT as does the 48GX?
writing code to do windowing etc shouldn't be too difficult, could be
done in user rpl as well?
Bart
I support supergems idea of a circuit4 equivalent for the 50G.
br
Bart
Gustavo Portales
wrote:
> So what kind of programs would the group like to appear for the HP
> 50G ?
- Gaak -
Veli-Pekka.Nousiainen
> Hello Group,
>
> HP 50G.
>
> So what kind of programs would the group like to appear for the HP
> 50G ?
>
> What do you think is missing that should be available ?
>
> Best regards,
> Andreas
> http://www.software49g.gmxhome.de
Anything ported from Saturn to ARM
Where is HPGCC 3.0 & the ROM 3.0 supporting it?
Cyrille? Are you still with HP?
I would love to see a new HP iPaq 50G
Could be Maemo, Android, iPhone, Symbian, Series 60
or Microsoft Mobile 7.0 Phone Edition
All it needs is 3G phone etc normal software
HP 50G emulator on ARM (just like now)
but the screen would be a touch screen where you can press the "keys"
then
you could still have RPL/2 and Parisse's xCAS system directly on Phone
Edition
running on about 1GHz (or 600MHz)
and having almost 1/4GB of RAM available
It's time to skip to a faster CPU now
that even ARM (or Texas OMAP which is based on ARM)
has dual CPU's on a die and some have 3D hw
Think about it
As a student I would sign up for a 2 year 3G contract on a phone
witch includes a master calculator software like 50G or Xcas
(which are quite similar)
Tanguy Briançon
> Andreas Möller wrote:
>> Hello Group,
>>
I am disagree with that: for a calculator I like real keys (much better)
than a touch screen. I also like to have batteries for a few months.
For students a calculator must be different with a cell phone (for
exams...).
What will be great are new graph tools for HP50: fast drawing
for functions (zoom in and out, scrolling in real time), dynamical
geometries. It could be done (I made a bad version of those tings
in HPGCC: but it works...). For surfaces works could be done...
http://briancontanguy.free.fr/hp/
Sorry, geohp, and its documentation, are in french...
Veli-Pekka.Nousiainen
a) some phones have full QWERTY KB - I suppose you could have both:
1) qwerty
2) calculator kb
B) You can always take the SIM out...
bernd
I would propose a consistency checker for databases for the
Treebrowser. I like to use the treebrowser, because it's fast and
comfortable to use. The only thing is that editing the database manually
is very prone to errors and in the end I end up with inconsistent
database.
I know there is a tool for building a database, but since I have to use
an existing database for the EQL+, I have to convert it by hand.
Best regards
Bernd
(Please remove "-removeMe-" when replying directly.)
hpextreme
<velipekka.nousiai...@saunalahti.fi> wrote:
> Andreas M ller wrote:
> > Hello Group,
>
> > HP 50G.
>
> > So what kind of programs would the group like to appear for the HP
> > 50G ?
>
> > What do you think is missing that should be available ?
>
> > Best regards,
> > Andreas
> >http://www.software49g.gmxhome.de
>
> Anything ported from Saturn to ARM
>
> Where is HPGCC 3.0 & the ROM 3.0 supporting it?
> Cyrille? Are you still with HP?
>
> I would love to see a new HP iPaq 50G
> Could be Maemo, Android, iPhone, Symbian, Series 60
> or Microsoft Mobile 7.0 Phone Edition
> All it needs is 3G phone etc normal software
> HP 50G emulator on ARM (just like now)
> but the screen would be a touch screen where you can press the "keys"
> then
> you could still have RPL/2 and Parisse's xCAS system directly on Phone
> Edition
> running on about 1GHz (or 600MHz)
> and having almost 1/4GB of RAM available
>
> It's time to skip to a faster CPU now
> that even ARM (or Texas OMAP which is based on ARM)
> has dual CPU's on a die and some have 3D hw
> Think about it
> As a student I would sign up for a 2 year 3G contract on a phone
> witch includes a master calculator software like 50G or Xcas
> (which are quite similar)
were slim and ran on coin cells. Coin cells last for ever.
Bring out a graphing calc built like a HP 35S, a vga oled screen, a
keyboard with 1/4 inch oled screens under 60 clear keys, and rewrite
all the saturn code in rom to arm code with 512mb ram 512mb rom 4gb
storage and sdhd card slot.
USB client/host ports, digital compass, accelorameter, gforce sencer,
temp, altimeter, borometer, distance.
You know, a maching we can use, strait out the box.
TW
> were slim and ran on coin cells. Coin cells last for ever.
All of that and running on coin cells. . . will run for a minimum 2
years before needing a battery change.
TW
Andreas Möller
> All of that and running on coin cells. . . will run for a minimum 2
> years before needing a battery change.
What you forgot was development time for HW and SW in less than 3
month.
Too bad that there is something called "reality" even if this is
completly ignored by VPN and hpextreme ;-)
Regards,
Andreas
http://www.software49g.gmxhome.de
Andreas Möller
@ Damir:
Interesting math challenge to do this but might be easier to do this
in C now to unleash the power of the ARM.
@ Yann:
I might consider this for a next release of a Compression Aid. If you
want to do it just drop me a private mail so that I can send you the
current sources of Compression Aid.
@ supergems
What do you think about how many copies of a program like this could
be sold for $ 20 ?
Developing a program like this for the 50G is going to be a huge task
and take a lot of efforts.
If HP wants to gain back market shares against TI why haven´t they
already developed a program like this ?
What happend to EEPro for the 49/50 ?
@ Bruce
Desirable but also a quite huge task.
@ Gaak
As free as my beer last night at the pub.
@ comp.sys.hp48
Any more thoughts/proposals ?
Regards,
Andreas
http://www.software49g.gmxhome.de
Damir
<farris...@hotmail.com> wrote:
>I like the way Casio graphing calcs were bult back in the 70s. They
>were slim and ran on coin cells. Coin cells last for ever.
>Bring out a graphing calc built like a HP 35S, a vga oled screen, a
>keyboard with 1/4 inch oled screens under 60 clear keys, and rewrite
>all the saturn code in rom to arm code with 512mb ram 512mb rom 4gb
>storage and sdhd card slot.
>USB client/host ports, digital compass, accelorameter, gforce sencer,
>temp, altimeter, borometer, distance.....
And dildo for your wife!
[Damir]
supergems
> @ supergems
> What do you think about how many copies of a program like this could
> be sold for $ 20 ?
> Developing a program like this for the 50G is going to be a huge task
> and take a lot of efforts.
> If HP wants to gain back market shares against TI why haven´t they
> already developed a program like this ?
> What happend to EEPro for the 49/50 ?
A circuit simulator is a very challenging project, but this program is
really necessary. I would be willing to pay € 50 :) !
EEpro has not been completed :( , looking on the internet there is
still the latest testing version: http://gustavoavellar.googlepages.com/eepro_beta5a.zip
> @ comp.sys.hp48
> Any more thoughts/proposals ?
Another useful program especially when free, less challenging ;) , is
the symbolic continuous-time Fourier transform, available for a fee in
MATH-PACK from http://www.heuson-software.de/heusoneng.htm.
A related discussion: http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/e09d316596dd84/
.
Regards,
supergems
Andreas Möller
> Another useful program especially when free, less challenging ;) , is
> the symbolic continuous-time Fourier transform, available for a fee in
> MATH-PACK fromhttp://www.heuson-software.de/heusoneng.htm.
I would assume that the copyright on this routine is by Heuson.
As I do not have it I can not take a look at this.
Regards,
Andreas
http://www.software49g.gmxhome.de
Gustavo Portales
wrote:
> What happend to EEPro for the 49/50 ?
@ supergems
> EEpro, I would be willing to pay € 50 :) !
Thanks, do you need my paypal account ?
- Gaak -
Andreas Möller
Bart
> @ supergems
> What do you think about how many copies of a program like this could
> be sold for $ 20 ?
>
compared to TI users.
>> Another useful program especially when free, less challenging ;) , is
>> the symbolic continuous-time Fourier transform, available for a fee in
>> MATH-PACK fromhttp://www.heuson-software.de/heusoneng.htm.
>I would assume that the copyright on this routine is by Heuson.
>As I do not have it I can not take a look at this.
You are probably right and would have to source a routing from free &
royalty-free sources or develop your own.
@Gaak
>@ supergems
>> EEpro, I would be willing to pay € 50 :) !
Nice try, but methinks you are mis-quoting supergems, he was quite
clear about willing to pay that for a circuit4 equivalent, not an
EEPro Beta :)
By the way, thanks for the useful collection on your site.
@supergems
I see EEPro is available as a free download for TI89 users on the TI
calc website
(http://education.ti.com/educationportal/downloadcenter/
SoftwareDetail.do?website=US&tabId=1&appId=247).
Do you perhaps know the difference between that and the circuit4 you
mentioned before (i.e. why would one pay for circuit4 vs the free
EEPro)?
Regards,
Bart
woddo
a debugger like Jazz, that supports the FPTR.
bernd
> did you get my email ?
No, unfortunately not.
Regards
Bernd
Am Mon, 12 Apr 2010 23:24:47 -0700 (PDT)
schrieb Andreas Möller <andreas_mo...@gmx.de>:
Andreas Möller
I sent it today from a different email address (this one without the
NOSPAM).
Did you check your SPAM folder ?
I got your mail at this address (without the NOSPAM and replied) but I
did not think that it would that complicated nowadays to exchanges
emails *inside* Germany.
Regards,
Andreas
http://www.software49g.gmxhome.de
TW
TW
Andreas Möller
> A circuit simulator is a very challenging project, but this program is
> really necessary. I would be willing to pay € 50 :) !
Since EEpro for the 50G is probably never going to be released, I
could produce a dataset of equations (from the TI manual, I do not
think that anybody has a copyright on Ohm´s Law) so that at least the
equation functionallity of EEpro will be back for the 50G. If
translators can be found this database could also be translated to
Spanish, French or whatever. A circuit simulator would be a second
step.
This will be a huge task as there are a *lot* of equations to port
which is cumbersome and time consuming. For reading/using the dataset
you would need the TB which is not free but is not very expensive as
the email version (€ 20 including the translation) and allows a lot of
additional stuff on the 50G.
What do you think ?
Regards,
Andreas
http://www.software49g.gmxhome.de
Andreas Möller
> A proper sysrpl/ML debugger would get my vote.
Probably a lot more than what I would consider "a little spare
time" ...
Regards,
Andreas
http://www.software49g.gmxhome.de
Dave Hayden
> A proper sysrpl/ML debugger would get my vote.
I'm curious why? It seems to me that tools like this are much better
suited for a desktop system that uses an emulator or a cable to
calculator.
Dave
Simone...@gmail.com
I think it's a great idea! :)
supergems
Simone...@gmail.com
> @supergems
> I see EEPro is available as a free download for TI89 users on the TI
> calc website
> (http://education.ti.com/educationportal/downloadcenter/
> SoftwareDetail.do?website=US&tabId=1&appId=247).
> Do you perhaps know the difference between that and the circuit4 you
> mentioned before (i.e. why would one pay for circuit4 vs the free
> EEPro)?
>
> Regards,
> Bart
To understand just read the features of Circuit4 ;) :
http://www.noatechnologies.com/about_circuit4.html
http://www.noatechnologies.com/circuit4_examples.html
supergems
TW
> suited for a desktop system that uses an emulator or a cable to
> calculator.
Yes. Even now though, I will still do stuff on the unit itself,
especially when exploring the ROM and things. I just find it quicker
when experimenting. I also think it is useful for students. . .
I wasn't referring to writing a brand new thing though, but rather
just use the old jazz stuff and figure why it doesn't work anymore.
TW
Han
I, too, would love to see Jazz completely ported over, as well as
updated to support the newer opcodes.
Harold A. Climer
<andreas_mo...@gmx.de> wrote:
>Hello Group,
>
>I have a little spare time that I’d like to spend on programming the
>HP 50G.
>
>So what kind of programs would the group like to appear for the HP
>50G ?
>
>What do you think is missing that should be available ?
>
>Best regards,
>Andreas
>http://www.software49g.gmxhome.de
Applied Geology and Hydrogeology programs. for solving problems
similar to those in "Applied Hydrogeology" by C.W.Fetter.
Many problems having to do with ground water flow and test well
information associated with change of ground water levels with the
draw down of aquifers used for irrigation and water supply are quite
complex and calculation intensive.
There are some hydrology programs for HP calculators available but
seem to me to cover surface flows in channels etc.
The software for Hydrogeology that is available for computers for free
is severely limited and commercial software is IMHO greatly over
priced.
Harold A Climer
Dept. Of Physics Geology, and Astronomy
U.T, Chattanooga
Rm. 406A Engineering, Math & Computer Science Building
615 McCallie Ave. Chattanooga TN 37403
Harold...@utc.edu
bernd
I'm sorry, but I still not received anything from you.
Please try the email-address from this posting. (No anti spam add-on
in it.)
Yesterday, I also replied to your account, the one with your name at
gmx.de. Did you receive something?
> Did you check your SPAM folder ?
Yes.
Regards
Bernd
Am Tue, 13 Apr 2010 13:12:40 -0700 (PDT)
schrieb Andreas Möller <andreas_mo...@gmx.de>:
> Hi Bernd,
Andreas Möller
it would be possible to create a dataset for the TreeBrowser according
to the examples mentioned at http://www.appliedhydrogeology.info by
C.W.Fetter.
But it would require your help to accomplish this as I am not
experienced in Geology/Hydrogeology.
If you are interested contact me by private mail. Remove the NOSPAM
from this email address or use the email address at my website
http://www.software49g.gmxhome.de.
Regards,
Andreas
http://www.software49g.gmxhome.de
Veli-Pekka.Nousiainen
I don't think so
I think I will have a HP 50g emulator on a iPAQ or a smart-phone
HP could easily produce a machine with calc keys and aquire both RPL/2
and xCas
about the coins cells - nobody mentioned that one needs just about 20 of
those...
Dueño de Monte
> > I like the way Casio graphing calcs were bult back in the 70s. They
> > were slim and ran on coin cells. Coin cells last for ever.
>
> years before needing a battery change.
>
I agree on this ...
Daniel
Dave Hayden
wrote:
> So what kind of programs would the group like to appear for the HP
> 50G ?
Something that will indicate what function a key will execute when
you're in USR mode. For example, on the HP41, if you held a key down
for moment, the calculator would display the name of the function
assigned to the key. Keep holding the key for about a second and the
calc would display "NULL" to indicate that it wouldn't perform the
function (in case you pressed the wrong key).
Something like this is crucial to making USR mode useful, IMHO.
Ditto for the soft keys when shifted. I'd love it if pressing a shift
key changed the labels on the soft keys to show what would happen. For
example, in he VAR menu, pressing right-shift and a soft key will
recall the variable to the stack. Pressing left-shift stores the
stack to the variable. But how can a casual user remember whether
they're about to recall their precious program, or blow it away with
the contents of the stack? Pressing left-shift could change a label
for XYZ into ->XYZ. Pressing right-shift would change it to XYZ->.
The devil is in the details here of course. It's isn't always clear
what you should display, but I'd rather have an imperfect solution
than none at all.
Andreas, your just the right sort of guy to write this since you have
lots of knowledge of the internals of the calculator.
Dave
Jacob Wall
> On Apr 5, 3:53 am, Andreas Möller<andreas_moellerNOS...@gmx.de>
> wrote:
>
> Ditto for the soft keys when shifted. I'd love it if pressing a shift
> key changed the labels on the soft keys to show what would happen. For
> example, in he VAR menu, pressing right-shift and a soft key will
> recall the variable to the stack. Pressing left-shift stores the
> stack to the variable. But how can a casual user remember whether
> they're about to recall their precious program, or blow it away with
> the contents of the stack? Pressing left-shift could change a label
> for XYZ into ->XYZ. Pressing right-shift would change it to XYZ->.
>
That is an excellent idea IMO, something like that would have saved me
some headaches when I first started using the 49g+.
Of course after some costly mistakes one learns to be careful, however
there was a few instances when I meant to press the Right Shift but hit
the Left Shift key instead, what a great feeling that was when it happened.
Jacob
Bart
You guys can't be serious, my 7000GB goes through a set of 2032's in a
couple of months (running a rather lengthy program several times a
day). When doing intensive graphing, my 50G is about the same on a set
of AAA's - but they are cheaper.
Andreas Möller
> Ditto for the soft keys when shifted.
This would require to take over of the built-in key libs which can not
easily be accomplished as a bug in the deepest core of the O.S.
prevents this (search for infamous STO bug).
A complete take over of built-in functions requires a lot of overhead,
mainly for circumventing the bug, an example for this are my Multi-
Language-Packs (to my knowledge so far the only example of taking over
built-in functions).
Also long hold for a key is already used by the O.S., so one would
have to introduce something like "holding even longer" or whatever
seems to be useful for this.
This is by no way something easily which can be done in a little spare
time, it would be a major project.
If something like this is desired it would be a lot easier to do it in
the official ROM instead of "fighting" against the O.S. But again I
vote for bug fixing the ROM first before introducing new features and
from my point of a non native speaker allowing further translation of
the O.S. by moving hardcoded messages into message tables.
> The devil is in the details here of course.
As always ;-)
> That is an excellent idea IMO, something like that would have
> saved me some headaches when I first started using the 49g+.
My old SX manuals explain this deeply in detail, that was 20 years
ago.
Regards,
Andreas
http://www.software49g.gmxhome.de
TW
> easily be accomplished as a bug in the deepest core of the O.S.
> prevents this (search for infamous STO bug).
We've been over this many times. :-)
Infamous implies that it is well known, notorious, or something like
that. As far as I can tell, you are the only one who has ever talked
or complained about it. This hardly qualifies as "infamous" by any
stretch of the definition. If I remember properly, it also is only a
"bug" if you try to expect it to do something that it was never
defined to do. In that case it would be a missing feature, not a bug.
TW
Andreas Möller
I am sorry Tim, but I can not let that uncommented.
> If I remember properly, it also is only a
> "bug" if you try to expect it to do something
> that it was never defined to do.
According to Charles Patton the system has been designed for this:
http://groups.google.com/group/comp.sys.hp48/tree/browse_frm/thread/0c6f788d0ede1711/dc89bbd77ec6b03c?rnum=11&q=Library+Trouble&_done=%2Fgroup%2Fcomp.sys.hp48%2Fbrowse_frm%2Fthread%2Fc6f788d0ede1711%2F3384f3a3bc46fbc7%3Flnk%3Dgst%26q%3DLibrary%2BTrouble%26#doc_dc89bbd77ec6b03c
Quoting explicitly from the above
"... these aspects of the machine (Hash tables for converting text to
and from commands, and Message tables for defining standarized
messages) must, at the very least, have "hooks" in RAM."
In the original system (48 series) these "hooks" remain under normal
operations, e.g. storing something into a port which is not a library,
whereas in the 49 series the alternative "hooks" are zeroed out. And
unfortunately there are no "hooks" for FLASHPTRs, so overtaking them
is extremely cumbersome and in this case I agree with you that the
system has not been designed to overtake FLASHPTRs, which is a pity in
my beliefs. So in that case it would be a missing feature, IMHO.
But just because it is not used as much as the designer thought it
would be used is not an excuse for leaving the bug. And maybe it is
not used that much in the 49 series because it is buggy ;-)
> We've been over this many times. :-)
Yes. But that does not fix the bug nor its impact ;-) And it is of
this bug that makes programming system enhancements for the 49 series
so much more difficult than for the 48 series. A good example is
Raymond’s SpeedUI for the 48 series. If someone wants to do something
like this for the 49 series (GUISLV is an attempt) the O.S. treats
this like an organic body would treat a virus.
> Infamous
I get a whole bunch of German meanings when I put this in my
dictionary (notorious, mean, lousy, ill-famed, discredited,
disreputable, dingy, sleazy, dubious, opprobrious, characterless,
dishonoring, unholy, wicked, etc.). Notorious is among them, but that
is not what I meant. From my limited understanding of the English
language both words, "notorious" and "infamous" have a negative
meaning whereas the negative image of the latter one is bigger as it
is the opposite of fame in a positive way.
The best German term for it would be infamous-notorious = berühmt-
berüchtigt, which does not exist as an English word in the
dictionaries I used.
And berühmt-berüchtigt translates to either infamous or notorious, but
that’s not exactly what it means ;-)
Quoting my English teacher: "Language is so limited."
From the Compact Oxford English Dictionary of Current English:
infamous
• adjective
1 well known for some bad quality or deed.
2 morally bad; shocking.
— DERIVATIVES infamously adverb infamy noun (pl. infamies).
> As far as I can tell, you are the only one who has ever
> talked or complained about it.
As far as I know I have also been the only one complaining about the
carry bug in the Saturnator. A bug is not defined/declared by the
number of complains AFAIK, but on the impact it has on the system
When I found this bug I was shocked about it and that there was
nothing to easily circumvent it ;-) Also I call it "infamous" because
the bug has been in there for years and no attempt was ever made to
fix it. But maybe you can give me a better English term for it.
I do however understand, that it is extremely difficult to fix and
that this is not a priority and since it can be fixed from the outer
now it will probably be left as this.
And as you know I’d rather focus on extending the message tables at
the moment. Fixing this bug might be a left over as an intellectual
exercise to find out where a mistake was made while porting the
software from the 48 to the 49.
Happy programming,
Andreas
http://www.software49g.gmxhome.de