Kind of late to the party, but, as another new DM16L owner, I was intrigued by post about adding this type of commonly used but unsupported feature on this calc. I like your implementation (using ABS to force the base into LASTX is pretty sneaky), but there were a few things I noticed:
1.) There's a typo on line -005-, the mnemonics should be STO I. The codes are right, but the [f] prefix key doesn't match.
2.) There's an edge case at an exponent of 0 that will break everything. I'm guessing it would subtract 1 from 0 and then keep decrementing and never finish.
3.) The [DEC] step is unnecessary. It would have no effect if you were already in binary mode (other than changing the displayed representation) and would cause a corruption of the X and Y registers if you had entered the base and exponent in floating-point mode.
Using what you had done, I started about setting up another implementation with some modifications:
Code: Select all
001 LBL E | 43 22 E
002 x#0 | 43 48
003 GTO 0 | 22 0
004 1 | 1
005 RTN | 43 21
006 LBL 0 | 43 22 0
007 CF 0 | 43 5 0
008 x<0 | 43 2
009 SF 0 | 43 4 0
010 ABS | 43 8
011 1 | 1
012 - | 30
013 STO I | 44 32
014 CLX | 43 35
015 x<>y | 34
016 + | 40
017 LBL 1 | 43 22 1
018 LST X | 43 36
019 * | 20
020 DSZ | 43 23
021 GTO 1 | 22 1
022 F? 0 | 43 6 0
023 1/x | 43 26
024 RTN | 43 21
Code: Select all
DM16
04 00000000000000 00000000f00000 c02f0008fff000 eae00000000000
08 00000000000000 2faf8befbe2280 bef20200bcaf80 00000000000000
f8 00000000000000 00000000d4a430 41a1cea601ccca c0d6cdf1d810d2
fc 2000d4f140a90e 00000000000000 000000000003f9 00000000000000
A: 00000000000000 B: 00000000000eae C: eae00000000000
S: 00011100000000
M: 00000000000000 N: 00000000000000 G: 0a
This method assumes that you have already set the word size and are already in binary mode OR that you are in floating-point mode and planning to stay there. It will work with negative bases in either mode (set 2's COMP for binary mode) and will work with both negative bases and negative exponents in floating-point mode. Bases must be integers in binary mode; exponents must be integers in either mode. If the exponent is 0, the result is 1. What's neat is that in binary mode, you can do exact math as long as you only need integers and its within the range that can be represented. Floating-point mode can represent a larger range, but that comes with the loss of precision, so you have to decide which is best for the case you're working in. One snag is that since 1/X is ignored in binary mode, negative exponents when in binary mode will be treated as positive exponents.
Some additional improvements I was thinking about would be to check for even or odd exponent, the do half as many steps, then duplicate and multiply X and Y (and multiply that by the base once more if the exponent was odd). That would cut it in half. If you could figure out the highest power of two that's less than your exponent, you could maybe make use of some of the DM16L-specifc bit manipulation features, but there isn't (AFAIK) any way to programmatically know whether you are in binary or floating-point mode or what your word size is, etc....
Anyway, thanks for inspiration...this is a much more interesting way to spend my lunch hour than reading articles on the internet....
P.