9 Sep
2016
9 Sep
'16
9:42 a.m.
On Fri, Sep 9, 2016 at 10:07 AM, Klemens Krause <
krause at informatik.uni-stuttgart.de> wrote:
I tried both versions with the emulator, and both gave identical
results. So I tested another "BSW"-replacement, simply:
BSWEMU, 0000
RTR
RTR
RTR
JMP I BSWEMU
This also worked. ;-) I didn't look in the code, but evidently the
BSWs are only used, to get the higher 6 bits of a word.
I'm pleasantly surprised this worked, as I see several cases in my code
where I'm using BSW to shift 6 times to the left, which isn't the same as
shifting 6 times to the right since there's that pesky link bit, unless I'm
missing something obvious here. Hmm. I'm updating the code to selectively
use three RTRs or three RTLs instead of BSW with the single field option
enabled.
And now another question came up. What does a hp-calculator answer,
if you ask fot tan(90)?
Answer:
hp35_emu: 90 t gives 9.9999999999 E99
hp35_real: didn't find the power supply :-(
hp9100: 90 tan gives 9.9999999999 E99
hp9810: 90 tan gives 9.9999999999 E98 (yes, E98!)
hp9820: 90 tan gives "NOTE 01"
Huh. E98...that's pretty odd. Wonder what the algorithm looks like for the
9810. The real HP-35 gives E99 like the emulator.
I'll push the changes soon; please give it a try on your 4K machine and let
me know how it does!
Thanks,
Kyle