HP Articles Forum
[Return to the Index ]
[ Previous | Next ]
Some thoughts about possibilities uploading High-End Pioneer and Clamshell ROM images
Posted by Christoph Giesselink on 20 Feb 2006, 3:27 p.m.
One of the biggest problems of using calculator emulators is the need of having a ROM image. Because of copyright reasons it's not possible to publish them as file. The good luck is that the calculators have an infrared transmitter LED and most of them are able to execute self written binary code.
1.1 The first approach getting a HP42S ROM image was made by Jean-Francois Garnier using the internal memory scanner by manual transmitting the ROM image, eight bytes each, over the transmitter LED in the redeye format used by the HP82240A/B printer. The bad point is, you need a special receiver to capture the data and be able to transfer the data to a PC. The best common receiver is a HP48 calculator so far. The most worst thing is, that the process is very very slow, we are talking about ~4 hours! More about this in JFG's article HP-42S: New Facts.
1.2 The 2nd approach done by me, based on Jean-Francois one. The only difference is, that a used a machine program transmitting the data in binary and as a whole with no user interaction after starting. The transfer time was reduced to 16 min. plus the time to enter the machine program (10 - 15 min.). But it's still necessary to have the special receiver for the redeye format and in difference to the first approach with enough RAM to hold the complete ROM image. More about this at http://privat.swol.de/ChristophGiesselink/Emu28/CPROMUPL.ZIP.
1.3 My 3rd approach is now changing the transfer protocol. Instead of using the redeye format I tried to implement the RS232C protocol with 2400 baud 8,N,1. First without success. The problem in general is that you have to do all timing by software. First the effective CPU speed is not constant, it depend on various factors. Therefore the redeye implementation in the calculators itself are measuring the CPU speed. To keep my implementation simple I don't care about this at the moment. The bigger problem brought me some sleepless nights is, that code running in RAM differs very much from the one running in ROM from timing aspects. Furthermore, all commands executed in RAM have a different timing when they are executed on an even or odd address. My solution for this problem is executing the timing critical parts in the display RAM. Display RAM is directly connected to the Saturn bus like the ROM and has exactly the same timing. This implementation is now independent if the code begins on an even or odd address.
But has the receiver problem being solved? Sorry I can't really say. Because I'm doing a simple binary transfer only receivers and operating systems supporting native Ir transfer working. Most of the actual IrDA receivers accept only data with IrDA protocol, they don't work in connection with native Ir transfer. So I tried to use a Pocket PC as receiver. It works fine with my Jornada 565 (distance from some up to 300 millimeters), only sometimes with my Axim X50v (only successful with a distance ~220 millimeter) and never with a HP hx2110 or a Qtech 9100. The process was never such stable like with the 2nd approach. The only good think was, that the transfer time of the HP42S image was reduced to less than 6 min.
Because of the various problems with receivers I quit further development. There's no other common platform in the HP community like the HP48.
This isn't an example for beginners, you must be familiar with the Pioneer integrated memory scanner and you must to know how you can get and save binary data on your receiver. Set your receiver to 2400 baud 8,N,1 please.
If you want to try, here's a "Hello world" example for the HP42S. But it should run on all High-End Pioneers, because only fixed hardware addresses are used. Type in these numbers very carefully with the memory scanner into your HP42S. A good address maybe #52000.
1FF0304D215D0808 F81B43418000CA13 01F0000434A20001 5A01590160170CE5 FE1ED03078108456 C6C6F60277F627C6 46000713614A1619 68A07A0060FFD281 B3FCAA0C4E434000 0481B331B18160EF 215D081CD215D031 41CE5DFFAA4E50E01
After starting the program with the <.> key you should exactly receive 11 bytes containing "Hello world" without the " delimiters. Got it? Congratulations you maybe able to get a ROM image by this way.
1FF0304D215D0808 F81B434A6000CA13 01F0000434A20001 5A01590160170CE5 FE1ED03034FFFF0D 5D213614A1617B00 CD53FD281B3FCAA0 C4E4340000481B33 1B18160EF215D081 CD215D03141CE5DF FAA4E50E01
If it worked you should got an exact binary dump of the ROM image.
"69C200B0008F1805 01FF0FFFD215D080 8F81B43446000CA1 301F82EFF34B2000 8F2FF401FD0FFF34 FFFF1D5D213614A1 617010CD53F80808 DB2B30FCAA0C4E43 482EFF81B331B181 60EF215D081CD215 D03141CE5DFFAA4E 50E010"
These are only a proof of concept programs, especially because of the big problems with the receivers. Sorry I can't and will not give any support to the published serial approach.
c dot giesselink at gmx dot de
[ Return to the Message Index ]
Go back to the main exhibit hall