I think my HP48 GX, complete with all of the cards I've purchased for it for
use in my engineering work, is the greatest thing ever.

With the demise of the HP calculator line and the use of handhelds on the
rise, it only makes sense to create a full-featured emulator for Palm OS.
While I already utilize an RPN pop-up calculator on my Visor, the
functionality of the HP 48 is sorely missed.  The Palm platform could offer
a great deal of benefits to the current HP 48 user -- an infrared port, a
serial port, a faster processor, larger screen with superior resolution
complete with color, and, in the case of the Visor, an expansion slot where
HP ROM cards could be used.  Finally, it would allow those of us who would
like to retain the HP's quality in an all-in-one handheld option.

I couldn't help but notice that EMU48, an excellent HP 48 emulator for the
Windows Platform, comes complete with source code (in C++, I believe).  Has
anyone considered porting it to Palm OS?  Has it already been done, and if
so, where can I find it?

Thoughts, anyone?

Eric Wolsing
Mechanical Engineer
Precision Systems Laboratory
University of Kentucky
eawol...@engr.uky.edu

Interesting concept... may be theoretically possible, though perhaps
with some functionality missing (e.g., card support sounds especially
questionable).

However, despite the faster processor and larger screen, Palm OS has
some serious restrictions of its own - 256 KB heap, regardless of total
memory; 4 KB stack, and 16-bit integers.  Some of the heap space is
used by the system so the full amount is in fact never available.

Palm development tools like CodeWarrior and prc-tools are capable of
compiling C++, but the C library is severely crippled and some functions
just don't work the same on Palm OS (e.g., sprintf).

Would definitely require a great deal of work.

--
Andre Schoorl <ascho...@engr.uvic.ca>   http://www.engr.uvic.ca/~aschoorl/

In article <F6D08.97920$va.45585...@news2.rdc1.mi.home.com>, Eric
OS.
<<SNIP>>

I too own both an HP48GX and a Visor Platinum.  I would love to merge
these into one device, and I've researched a lot of software to to see
the feasibility of this.  Sadly, the most powerful RPN program I can
find is RPN.  There are other powerful calculators (Power One and
CplxCalc), but none can remotely touch the power of my HP48 with the
Erable libraries.  The HP emulator can not be ported to the existing
PalmOS because the ROM is so much larger than the Palm's stack space.
Much as I dislike the interface of the PocketPCs, they do have the
hardware and memory-addressing to handle the usual bloat-ware that
accompanies it.  So, there is an HP48 emulator for the PocketPC.

Oddly enough, there seems to be more requests for a Matlab emulator
than an HP48 emulator.  The text interface eats less of the stack
memory, and the cut&paste abilities of the PalmOS make this easy to
use.  Lyme (www.calerga.com) has the best rendition of this, complete
with user-defined functions and plotting.

In the meantime, perhaps we'll be able to look again at the HP
emulator when the new PalmOS5 comes out with the new Arm processor.
Until then, my HP is faithfully pushing me through my Master's degree!

Hi

Please excuse my ignorance if I'm making an obvious mistake here as I've
never programmed in Java.  But my understanding is that Java is supposed
to be able to run on any machine with minimal software modification - so
why has no-one ever written the emulator in Java and solved the problem of
platforms for it once and for all?

--
Colin Croft

"Old mathematicians never die; they just lose some of their functions. "

======================================
Applications in Mathematics
ccr...@iinet.net.au
http://members.iinet.net.au/~ccroft/
======================================

        Hello,

        You are quite correct in theory; however, in my opinion, the
main issue in a Java emulator would be performance.

        From my personal experience with the saturn emulator I wrote
(Unix OS, RISC CPU), the overhead of an emulator written in C roughly
slows down the CPU clock speed by an order of magnitude.

        For example, my emulator runs a saturn CPU at an apparent
speed of 8-10MHz on a 100MHz Alpha CPU, assuming there is no paging;
things get worse on CISC CPUs, partly because I wrote the code with a
RISC CPU in mind.

        Simple, interpreted implementations of the Java virtual
machine like the ones to be found on portable devices are likely to
slow down the emulation process by an additional order of magnitude;
at least, these are the figures I obtained when I attempted to
implement the main CPU ISA execution loop using JDK 1.0.2, Digital
Unix platform.

        Things should be better if the Java VM supports advanced
execution techniqus, like code mutation, just-in-time compilation, and
so on, but I have never checked this, so I cannot estimate how much
speed could be gained and I don't know if these optimizations are
feasible on a portable device.  Does anyone have any clue on this?

        With my best regards,
        Ivan

--
------------------------------------------------------------------------
Ivan Cibrario Bertolotti            /     phone: +39-011-3919246
IRITI - National Research Council  /      fax:   +39-011-341882
Turin (Italy)                     /       mailto:cibra...@iriti.cnr.it

"James Sorenson" <james_soren...@yahoo.com> escreveu na mensagem
news:88fc1a21.0201152256.35a260cb@posting.google.com...
| In article <F6D08.97920$va.45585...@news2.rdc1.mi.home.com>, Eric

| >I think my HP48 GX, complete with all of the cards I've purchased for
| it for
| > use in my engineering work, is the greatest thing ever.
| >
| >With the demise of the HP calculator line and the use of handhelds on
| the
| >rise, it only makes sense to create a full-featured emulator for Palm
| OS.
| <<SNIP>>
|
| I too own both an HP48GX and a Visor Platinum.  I would love to merge
| these into one device, and I've researched a lot of software to to see
| the feasibility of this.  Sadly, the most powerful RPN program I can
| find is RPN.  There are other powerful calculators (Power One and
| CplxCalc), but none can remotely touch the power of my HP48 with the
| Erable libraries.  The HP emulator can not be ported to the existing
| PalmOS because the ROM is so much larger than the Palm's stack space.
| Much as I dislike the interface of the PocketPCs, they do have the
| hardware and memory-addressing to handle the usual bloat-ware that
| accompanies it.  So, there is an HP48 emulator for the PocketPC.
If we can compact the rom ...
| Oddly enough, there seems to be more requests for a Matlab emulator
| than an HP48 emulator.  The text interface eats less of the stack
| memory, and the cut&paste abilities of the PalmOS make this easy to
| use.  Lyme (www.calerga.com) has the best rendition of this, complete
| with user-defined functions and plotting.
Or Mathematica, with an command line and graphing?
Just MuPAD is good for me.
| In the meantime, perhaps we'll be able to look again at the HP
| emulator when the new PalmOS5 comes out with the new Arm processor.
| Until then, my HP is faithfully pushing me through my Master's degree!

:-((( I would like Maple on Palm OS. Now I use WinCE(Xpander, very good
software and Emu48 CE).

See also Coconut, HP41CX emulator for Palm OS :
http://www.berndabel.de/products/coconut/
Best regards
VG

HPhreacker 2002(®) <hphreac...@email.com> a écrit dans le message :
aapvtf$covo...@ID-88878.news.dfncis.de...

This would be fairly hard to do.  Apparently, you are limited to 256kB
of heap, and I am guessing that the ROM of a 48 is more than 512kB.
It would be nearly impossible to get 50% compression for something
that is not very redundant.  You could use a sort of paging system,
but that would be excessively annoying.

I am guessing that the biggest part of the OS, other than the normal
math operations, is the UI, so it could be contained in one image and
the other stuff in the other image.  You do not exactly need most of
the UI to be running when you are running a program (ex. filer, y=
editor, etc.).  If you page between the UI and the rest of the ROM,
there should be little overlap.  A better idea might be to make the
math part of it as a data file.  The emulator could lookup what to do
as it encounters various math operations.  This would make the
emulator slower, but it would not require paging as much.

Is the 256kB limit there is asm?  If not, an emulator could be written
in it and the entire ROM could be used.

MuPAD on a handheld device would be cool, but I cannot seem to find
the source to this 'open' CAS.

I think that it would be very cool if Math Xpander was ported to the
Apple Newton 2X00/eMate.  They use StrongARM processors, so it should
only take a recompile for it to work.

<rant>
I believe that WinCE cripples devices that could have the power of a
desktop computer.  The OS is huge and slow.  For the most part this is
because it was written to be used on all sorts of hardware.  If they
would just write a different version of the OS for different hardware
setups, it would be far more efficient, there would be less OS
bloating, and the entire device would run faster.
</rant>

Dylan

In article <460a25b9.0205081451.5b394...@posting.google.com>,
 rgd...@aol.com (Dylan Stewart) wrote:

PalmOS divides RAM into two sorts, dynamic and storage.  The dynamic
heap is used for program stack, global variables and anything the
program allocates on the fly.  It's 256KB on an 4 or 8MB device (128KB
on a 2MB device), though, the OS takes around 64KB of that.  The storage
heap is used to store databases and is write-protected by the hardware.  
To write to the storage heap, you have to go through OS functions which
check you're not overwriting anything you shouldn't be.  Whilst you
couldn't allocate enough dynamic heap space to emulate more than a 48G+,
you can store the ROM image in a database and have full read only access
to it.  In fact, i have 48G and 38G rom images stored on my TRGpro (8MB
PalmOS device with CF slot, see http://handera.com) and wrote a program
to check the CRCs.  It takes about 20s to check one, but i'm sure it
could be speed up with some assembly language.  (The C code uses about 3
dereferences, a test and a shift/mask per nibble.)

Email me at (jon AT purvis DOT co DOT nz) if you'd like a copy of the
source.

Later...

        Jon