Funny HP-16C quirk
|
11-06-2024, 04:33 PM
Post: #1
|
|||
|
|||
Funny HP-16C quirk
Try this simple 16C program in either float or integer mode:
Code: 001- 21 A GSB A Run it with [RTN] [R/S] then switch to program mode. You will see the step 0 as: 000- F Was it already known? Or other similar quirks? J-F |
|||
11-06-2024, 08:02 PM
(This post was last modified: 11-06-2024 08:03 PM by ThomasF.)
Post: #2
|
|||
|
|||
RE: Funny HP-16C quirk
(11-06-2024 04:33 PM)J-F Garnier Wrote: Was it already known? Or other similar quirks? Hi J-F, Never seen that before! It works the same if you end a program with similar steps, SST to the GSB line, then SST in run mode until R/S. Seems to be related to a pending return (i.e. must end with R/S and not RTN). Same on the go16 Android app, so ROM related, and maybe would be possible to track down if the code is disassembled ... Cheers, Thomas [35/45/55/65/67/97/80 21/25/29C 31E/32E/33E|C/34C/38E 41C|CV|CX 71B 10C/11C/12C/15C|CE/16C 32S|SII/42S 28C|S 48GX/49G/50G 35S 41X] |
|||
11-08-2024, 09:08 AM
Post: #3
|
|||
|
|||
RE: Funny HP-16C quirk
(11-06-2024 08:02 PM)ThomasF Wrote: Same on the go16 Android app, so ROM related, and maybe would be possible to track down if the code is disassembled ... Interesting quirk. It's the same on a 15C CE thrown into 16C mode. Current daily drivers: HP-41CL, HP-15C, HP-16C |
|||
11-08-2024, 02:42 PM
Post: #4
|
|||
|
|||
RE: Funny HP-16C quirk
We can check how the program lines are represented internally:
000- 0xf000bffffff000 001- 21 A ; GSB A 0xf001bff21fa000 002-4322 A ; LBL A 0xd002b4322fa000 003- 31 ; R/S 0xf003bffff31000 000- F 0xf000bffffff000 We can see that the line 000 is represented identically in both cases. This is an excerpt from the comparison (side-by-side of the differences) when running P/R in both cases: Code: 0-bf8 038 c = data reg['C'] = 0x00000000000000 addr = 255 | 0-bf8 038 c = data reg['C'] = 0x000000003fc000 addr = 255 Since F can be used as a label with the HP-16C, it can appear in the last position. Therefore, there must be another way to distinguish the usual interpretation of f as a space in this case. I assume this is related to the value 3fc read from the address 255. Later, it is converted to 74 and written to reg[010]. It is probably written when subroutine A is executed, but as ThomasF already mentioned, it is not reset anymore. I've attached the full diff in a zip-file. |
|||
11-08-2024, 02:55 PM
Post: #5
|
|||
|
|||
RE: Funny HP-16C quirk
(11-08-2024 09:08 AM)RPNerd Wrote: It's the same on a 15C CE thrown into 16C mode. Hardly shocking since that is a emulation of real 16C firmware. Any bugs/quirks would therefore be present. A1 HP-15C (2234A02xxx), HP-16C (2403A02xxx), HP-15C CE (9CJ323-03xxx), HP-20S (2844A16xxx), HP-12C+ (9CJ251) |
|||
11-09-2024, 03:44 AM
Post: #6
|
|||
|
|||
RE: Funny HP-16C quirk
(11-08-2024 02:42 PM)Thomas Klemm Wrote: I assume this is related to the value 3fc read from the address 255. Yes, reg 0xff contains the current program position in the lowest three digits, 0x000 for line 0. The next three digits to the left of the progran position are the first return level, with 0x3fc being to line 3. At 0x0a14, a subtroutine is called to read that register, which of course gets all 56 bits of it. However, the microcode programmer apparently assumed that all of the digits 13..3 would be zero. At 0x0a1a, the entire C register is checked for zero, where the check should only be for the exponent and exponent sign digits. When there's no pending return, it jumps ahead to L0a2a. Because of the pending return, the code falls through into 0x0a1c, which formats one digiit of the display, then falls into the comnon path at 0x0a2a. The code from 0x0a1c to 0x0a29 is what would usually format the base indicator in integer modes, or the least significant display digit (of mantissa, exponent, or blank) in FLOAT. It shouldn't be executed in PRGM mode on line 0. It is being executed with wrong flag settings, so a 0xf in one of the display formatting temporary registers is being formatted in hexadecimal mode as "F", rather than in decimal and special mode where it would be a blank. Replacing the "? c#0 w" instruction (0x2ee) at 0x0a1a with "? c#0 x" (0x2e6) should fix it. HP used that to test for line 0 in other places in the code, such as 0x0c25. That works because the program pointer register number can never be 0x00, which is in the status registers, so if it is 0x00, it doesn't matter what digit 2 contains (1-7 for byte), though that should always be zero when the register is 0x00. Are there any other known bugs in the ORIGINAL 16C firmware? At least this one is only cosmetic, and won't lose or corrupt any data. |
|||
11-09-2024, 09:15 AM
(This post was last modified: 11-09-2024 12:54 PM by J-F Garnier.)
Post: #7
|
|||
|
|||
RE: Funny HP-16C quirk
(11-09-2024 03:44 AM)brouhaha Wrote: Are there any other known bugs in the ORIGINAL 16C firmware? At least this one is only cosmetic, and won't lose or corrupt any data. There are two bugs shared with the 15C: - in float mode, CHS doesn't enable the stack lift when the X-register is 0. - If a program ends with a conditional test that is evaluated false, program pointer skips to line 1 and continue from there, instead of stopping at line 0. There is no "GSB I with I<0" bug as in the 15C because the I<0 case doesn't exist (the absolute value of I is used as described in the manual). I can also mention another quirk (can't really call it a bug) found by Mike (Stgt) years ago who just reminded me about it: > Clear Prefix in integer mode does not end digit entry, in floating mode it does This is likely because Clear Prefix is a nop in integer mode. In the same way, integer-only functions are nop in float mode and don't end digit entry either. J-F [edit: stack lift bug in float mode only] |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)