Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mephisto!prism!gt1246c From: gt1246c@prism.gatech.EDU (Warren Furlow) Newsgroups: comp.sys.handhelds Subject: Re: HP-48 Emulator Message-ID: <6724@hydra.gatech.EDU> Date: 6 Mar 90 20:47:39 GMT Reply-To: gt1246c@prism.gatech.EDU (Warren Furlow) Distribution: comp.sys.handhelds Organization: Georgia Institute of Technology Lines: 75 Alonzo Gariepy writes: >You could build a Saturn emulator that would blow the socks off the >HP28. They call it a 1MHz machine, but that doesn't say much about >the instruction timing. Someone recently claimed that the 28 has a >one bit memory bus, which I am inclined to believe. At best, it has >a 4 bit memory bus and a 4 bit register bus. With a 16 bit 286 running >at 16 MHz, you would have 64 times the speed. That is easily enough >to emulate the Saturn at several times the speed of the 28. The emulator I wrote for the HP-41 actually runs slightly slower than the real thing on a 12Mhz AT. It is all written in Microsoft C and well optimized. I think it could be sped up by rewriting critical routines in assembly, but I don't see anything near 64 times the speed. (The HP-41 runs much slower than the Saturn, I forget exactly how much) The real problem seems to be that the Saturn and HP-41 processors use nybble field arithmetic and this must be emulated by using loops. For instance the following instruction adds the value of the A register to the C from the pointer (PT) through the end of the 56 bit word in the HP-41: C=C+A WPT translates to something like: for (i=PT;i<14;i++) { C_reg[i] += A_reg[i]; } Where: char C_reg[14],A_reg[14]; //HP-41 C reg is 56 bits int PT; //0..13 This is a simplification and does not consider the carry but it is easy to see how slow it is. Another way to do this that Ross Cooling of Canada implemented in an HP-41 emulator he wrote is to use double (64 bit) variables: double C_reg,A_reg; which requires only several masking operations and one addition. This is definitly faster but a seperate routine must be written for EVERY TEF case for EVERY arithemtic instruction and this takes ALOT of code. I can't think of any other way or accectible combination that would be worthwile to implement. This all relates to the HP-48 since it uses the Saturn processor and now Alonzo is interested in writing a Saturn emulator. Peter Holzer writes: >The main reason for not writing a CPU emulator (I considered it before >I started) is that either every user would have to load the entire ROM >of the HP28 (128k!) into his PC (not everybody has an IR receiver on >his PC) or the ROM had to be distributed with the emulator (I am not >sure if HP would like this). I don't think HP would like that at all and now they have expliclicitly said so in the HP-48 copyright notice. But with the HP-48, it is now very easy for each individual to download the ROMs to a PC. I don't think HP can or will say anything about the downloading of their ROMs. Futhermore, the can't say anything if someone writes a disassembler that produces listings from the ROM images as long as those listing are not distributed. (I think HP does have the right to prevent that). If I am wrong, HP speak up now... This disassembler could be smart and even include comments and labels. I interested in seeing if Peter is going to change to the HP-48. I think an RPL emulator for the HP-48 would be a big success since it would allow RPL program development on a large screen with a real keyboard. I have been planning for some time to write development tools for the first new HP calculator with I/O. This would include a disassembler, assembler, linker and ultimately a Saturn emulator and be very much like the ASDT package I did for the HP-41. The speed of the emulator and the usage of the ROMs are major concerns so maybe someone else has some ideas. Also, I am interested to know how much interest there will be in HP-48 machine code. Warren Furlow