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
In article <F6D08.97920$va.45585...@news2.rdc1.mi.home.com>, Eric Wolsing wrote: >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?
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).
In article <F6D08.97920$va.45585...@news2.rdc1.mi.home.com>, Eric
Wolsing wrote: >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.
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!
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?
James Sorenson wrote: > In article <F6D08.97920$va.45585...@news2.rdc1.mi.home.com>, Eric > Wolsing wrote: > >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.
> 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!
-- 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/ ======================================
> 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?
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
| >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).
> "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 > | Wolsing wrote: > | >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).
"HPhreacker 2002\(?\)" wrote in message: > If we can compact the rom [sic] ...
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.
> Or Mathematica, with an [sic] command line and graphing? > Just MuPAD is good for me.
MuPAD on a handheld device would be cool, but I cannot seem to find the source to this 'open' CAS.
> :-((( I would like Maple on Palm OS. Now I use WinCE (Xpander, very good > software and Emu48 CE).
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>
> "HPhreacker 2002\(?\)" wrote in message: > > If we can compact the rom [sic] ...
> 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.
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.
