On Fri, Sep 9, 2016 at 10:07 AM, Klemens Krause < kra...@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
