05-31-2023, 08:48 PM
Unlike the HP 32SII, which used exactly 1.5 bytes for every program step (except for literal numbers and equations), the DM32 uses only 1 byte for most program steps, but occasionally uses 3 or 4 bytes for some programmable operations. Here's the complete list (as of v2.02; subject to change in future firmware updates):
BYTES PER DM32 PROGRAM STEP
All programmable functions and commands use 1 byte
except all STO and RCL commands which use 4 bytes each,
and all of the following which use 3 bytes each:
∫FN d var or (i)
CF n
DSE var or (i)
ENG n
FIX n
FN= label or (i)
FS? n
GTO label or (i)
INPUT var or (i)
ISG var or (i)
LBL label
SCI n
SF n
SOLVE var or (i)
VIEW var or (i)
XEQ label or (i)
x<> var or (i)
LITERAL NUMBERS
Unlike in the HP 32SII, literal numbers in DM32 program memory occupy 2 bytes plus 1 byte per digit, decimal point (if keyed in), EEX, sign, fraction mark. If numeric entry is begun by pressing the decimal point key, a leading zero ("0.") is automatically entered. Fraction-notation numbers are stored in program memory as such, e.g. 1.2.3 is stored as 1.2.3, not as its decimal equivalent. The internal format can be seen by pressing SHOW. Example: 2.6.3 is fraction notation for 2+6/3 which equals 4. Keying 2.6.3 into a program is displayed in the program listing as 4, and when run it puts 4 into X, but SHOW reveals that it's stored in program memory as 2.6.3 which occupies 7 bytes.
Some non-obvious consequences of the above rules:
BYTES PER DM32 PROGRAM STEP
All programmable functions and commands use 1 byte
except all STO and RCL commands which use 4 bytes each,
and all of the following which use 3 bytes each:
∫FN d var or (i)
CF n
DSE var or (i)
ENG n
FIX n
FN= label or (i)
FS? n
GTO label or (i)
INPUT var or (i)
ISG var or (i)
LBL label
SCI n
SF n
SOLVE var or (i)
VIEW var or (i)
XEQ label or (i)
x<> var or (i)
LITERAL NUMBERS
Unlike in the HP 32SII, literal numbers in DM32 program memory occupy 2 bytes plus 1 byte per digit, decimal point (if keyed in), EEX, sign, fraction mark. If numeric entry is begun by pressing the decimal point key, a leading zero ("0.") is automatically entered. Fraction-notation numbers are stored in program memory as such, e.g. 1.2.3 is stored as 1.2.3, not as its decimal equivalent. The internal format can be seen by pressing SHOW. Example: 2.6.3 is fraction notation for 2+6/3 which equals 4. Keying 2.6.3 into a program is displayed in the program listing as 4, and when run it puts 4 into X, but SHOW reveals that it's stored in program memory as 2.6.3 which occupies 7 bytes.
Some non-obvious consequences of the above rules:
- Don't key 4.E37 into a program; just key 4E37 (one less byte and faster)
- Both .1.3 and 1..3 evaluate as 1/3, but 1..3 uses one less byte and runs faster due to the automatic leading zero rule.
- 1..3 takes two more bytes than 3 1/x but it runs faster.