Threaded Mode | Linear Mode

Voldemar · 08-09-2023, 10:55 AM

(08-09-2023 09:52 AM)ThomasF Wrote: I think Eric described it quite well above.
I've seen two cases were we get a corrupt result.

1)
If the resulting HEX-value contains 'E' or 'F' the DEC-value is wrong.

2)
Values of the form 60+n*80 or 61+n*80 will also be wrong, the result R will be shown as R-10+0xA or R-11+0xB and the last digit (A or B) will be shown in HEX (except when R contains E or F in HEX mode, then rule 1 above is valid.

Perfect description.

Voldemar · (This post was last modified: 08-09-2023 02:09 PM by Voldemar.)

(08-09-2023 09:52 AM)ThomasF Wrote: 1)
If the resulting HEX-value contains 'E' or 'F' the DEC-value is wrong.

DEC mode if in HEX mode number contains:
One E or F as last digit
E -> 08 = 14 - 6×16^0
F -> 09 = 15 - 6×16^0
1E -> 24 = 30 - 6×16^0
1F -> 25 = 31 - 6×16^0
2E -> 40 = 46 - 6×16^0
2F -> 41 = 47 - 6×16^0
9E -> 152 = 158 - 6×16^0
9F -> 153 = 159 - 6×16^0
10E –> 264 = 270 - 6×16^0
111E -> 4376 = 4382 - 6×16^0
--------------------------------------
One E or F as secodn from end digit
E0 -> 128 = 224 - 6×16^1
24F1 -> 9361 = 9457 - 6×16^1
--------------------------------------
One E or F as second from end digit and one E or F as last digit
4EF -> 1161 = 1263 - 6×16^0 - 6×16^1
--------------------------------------
One E or F as third from end digit
1E14 -> 6164 = 7700 - 6×16^2
.....................................................
etc.

Each E or F in the number causes 6×16^n to be subtracted from the correct result.
n=0 if E or F last digit in number
n=1 if E or F is the second digit from the end in the number
n=2 if E or F is the third digit from the end in the number
and so on

Voldemar · 08-09-2023, 01:43 PM

Perhaps it is possible to write a program for the calculator that fixes this? And HP 16C CE will become usable in DEC mode... Smile

Voldemar · (This post was last modified: 08-09-2023 02:02 PM by Voldemar.)

The problem is only in the representation. Each DEC number should be checked in HEX mode, then the head count by adding 6, 96, 102, 1536...
60 (or 61) + n×80 contains a warning
Big Grin

J-F Garnier · (This post was last modified: 08-09-2023 03:35 PM by J-F Garnier.)

To speak about something else than the 16c bug, that is after all not the main purpose of the CE:

(08-08-2023 05:34 PM)Valentin Albillo Wrote: But now, with the CE/192 extended memory mode you have 3x the memory and thus up to 1,344 program steps. Even if using just 900 steps max (and still having about 66 data registers available) you might be tempted to create a big program and/or include many short ones in that much room, but the subsequent problem is that you'll have to carefully modify them to cater for duplicate labels. In short, having only 25 labels is quite a serious limitation now. And there's a possible additional problem with that much program memory in use, see the questions below.

Quote:But now, with the 192 registers provided by the CE/192 mode, there are practical cases where the limit of max 5 matrices at the same time is exasperatingly restrictive, e.g. you can't have, say, a 4-block partitioned matrix and easily use concise, fast block operations to work with it because of the 5-matrices limit, so you're having to jump through far too many hoops and annoyances to try and succeed.

It seems to me a bit paradoxal that more resources are seen as limitations.
My answer would be: take the CE/192 as an enhanced 15c, or to say it differently a 15c without the memory limitations of the original, but not as a new machine.

With 192 registers, you can, without changing the standard 19 storage registers allocation:
- use two 8x8 matrices (128 registers) and still have the 46 registers of the original 15C for programming,
- or solve a 8x8 system (64+8+8 registers), use the integrate/solve features (23 reg.), the complex mode (5 reg.) all together, and still have 66 registers for programming.
For me it's the key: you can use several (potentially all) 15c features at the same time without being limited by the memory.
This is much more interesting for me than attempting to write long programs, which is not practical anyway (see my last comments below).

Quote:Anyway, I find it sad that HP didn't consider including the instructions BGTO/BGSB (backwards GTO/GSB,) identical to GTO/GSB except that they would search backwards for the label instead of forwards (so code like the following would've been possible,) alleviating or completely voiding the need for additional labels, with minimum microcoding and ROM space needed to implement both:

We can try to revisit the past but HP never did such a thing, indeed.
Machines of that time had limited memory, and such optimization was just not needed.
When the 41C appeared with its potentially larger memory, HP chose to implement compiled GTO, which was more efficient and simpler to the user.

For me, the main limitation of the 15c is the fact that program steps are still recorded as keycodes.
This seems to me absolutely archaic in 2023. I really would welcome a 15c with clear instructions à la 41C: LbL, STO, RCL, ...
It would not break any compatibility and would give a tremendous comfort for programming.
The 41C series introduced this innovative feature in 1979, unfortunately the 1981 Voyager series went back to keycodes.
It was a big step backward at the time, and I remember that I initially didn't like this series for this very reason.

J-F

ThomasF · 08-09-2023, 03:20 PM

It is said that the DEC-bug is only on presentation, ie the internal representation is correct (eg the HEX value is correct).

And, when working in FLOAT-mode, it works ok, no problem there.

So I thought I could use the feature to convert integer values to float, to get the correct value, but alas, that didn't work either ...

Try the following:

HEX
6F (enter 6F)
DEC
105 (105 is shown but is actually 111)
0
FLOAT 2 (should return y * 2^x)
105.00

So, the conversation will fail as well, but entering 111 is no problem in FLOAT-mode, it is only the conversation from integer to float that also fails.

Working on another (simple) solution for displaying the correct decimal value ...

Cheers,
Thomas

Voldemar · (This post was last modified: 08-09-2023 03:34 PM by Voldemar.)

(08-09-2023 03:20 PM)ThomasF Wrote: It is said that the DEC-bug is only on presentation, ie the internal representation is correct (eg the HEX value is correct).

Yes, it is.
It is not possible to display the numbers affected by the bug correctly in DEC mode. It's not worth trying. Switch to FLOAT mode and add the corresponding 6×16^n. If only this could be automated somehow...
A small program that adds the required 6×16^n to the incorrect result that appears in FLOAT mode

ThomasF · 08-09-2023, 03:41 PM

(08-09-2023 03:30 PM)Voldemar Wrote:
(08-09-2023 03:20 PM)ThomasF Wrote: It is said that the DEC-bug is only on presentation, ie the internal representation is correct (eg the HEX value is correct).
Yes, it is.

That's why I thought that converting to float should work, since presentation in FLOAT-mode works.

Ie that the (correct) internal value would be converted to float, but it does not. Even going from HEX-mode to float fails in the same way (or 0x6F is converted to 105.0000), so the value is internally "presented" as decimal and that value is then converted to float ...

Cheers,
Thomas

Voldemar · 08-09-2023, 03:54 PM

(08-09-2023 03:41 PM)ThomasF Wrote: or 0x6F is converted to 105.0000

Tried with 60(61) + 80n
Works

ThomasF · 08-09-2023, 04:06 PM

Interesting finding!
So that means that it is only values (rule 1) that fails when converting to float!

Cheers,
Thomas

EdS2 · 08-09-2023, 04:10 PM

I think one could write a program to convert an integer into BCD, which would then display the decimal value when in HEX mode. It wouldn't quite have the 64 bit range, of course - only 16 digits will fit.

One would surely want another program to convert back from BCD to binary. That would then allow one to enter a decimal number - in hex mode, then convert.

David Hayden · 08-09-2023, 04:23 PM

(08-08-2023 05:34 PM)Valentin Albillo Wrote: I find it sad that HP didn't consider including the instructions BGTO/BGSB (backwards GTO/GSB,) identical to GTO/GSB except that they would search backwards for the label instead of forwards

The problem with searching backwards is you need to parse the instructions, which can be difficult if they are variable length.

Dave

ThomasF · (This post was last modified: 08-09-2023 05:02 PM by ThomasF.)

Maybe this little program can show the correct decimal value:

Code:

001 - 43,22, d LBL D

002 -       23 HEX

003 -    44  0 STO 0

004 -        0 0

005 -    44 32 STO I

006 -       34 X<>Y

007 - 43,22, 0 LBL 0

008 -        A A

009 -    42  9 RMD

010 -    45 32 RCL I

011 -        4 4

012 -       20 *

013 -    43  E RLCn 

014 -    42 40 OR

015 -    43 24 ISZ

016 -    45  0 RCL 0

017 -        A A

018 -       10 /

019 -    44  0 STO 0

020 - 43, 5, 4 CF 4

021 -    43 48 X#0?

022 -    22  0 GTO 0

023 -       33 RDN

It will convert a decimal value to hex BCD digits.
Doesn't handle overflow, and works only for unsigned values.

HEX
enter 6F
DEC
105 d (but is actually 111)
GSB D
111 h (correctly shown, but a HEX-value)

So with a decimal value in x, GSB D will show the same value as decimal but in Hex-mode.

Edit: Added keycodes

Cheers,
Thomas

Voldemar · 08-09-2023, 04:38 PM

[DEC] on screen 0 d
111 on screen 105 d
[ENTER]
[HEX] on screen 6F h
Aha, there is F as last digit, must add 6×16^0, we know Smile

0
[f] FLOAT 0 on screen 105.
6
+
on screen 111.
[BSP]
[DEC]
239 on screen 137 d
[ENTER]
[HEX] on screen EF h
(must add 6×16^0 and 6×16^1)
0
[f] FLOAT 0 on screen 137.
102
+
on screen 239

This way for now Big Grin

brouhaha · 08-09-2023, 06:08 PM

(08-09-2023 04:23 PM)David Hayden Wrote:
(08-08-2023 05:34 PM)Valentin Albillo Wrote: I find it sad that HP didn't consider including the instructions BGTO/BGSB (backwards GTO/GSB,) identical to GTO/GSB except that they would search backwards for the label instead of forwards
The problem with searching backwards is you need to parse the instructions, which can be difficult if they are variable length.

That was a big issue on the 41C etc., but 15C instructions can easily be unambiguously parsed in both directions. This is because a single-byte instruction, or the second byte of a two-byte instruction, always has a least significant digit 0x0 through 0xE, while the first byte of a two-byte instruction always has a least significant digit of 0xF.

Given a pointer to the start of an instruction, the start of a previous instruction can be found by looking two bytes backward. If the byte is of the form xF, it is the start of the previous instruction, which is a two-byte instruction. Otherwise, the byte only one byte back is the previous single-byte instruction.

Obviously if the pointer is to the first byte of program memory, there is no previous instruction, just the nonexistent step 000. Similarly, if the pointer is to the second byte of program memory, then the first byte of program memory is the previous instruction.

brouhaha · 08-09-2023, 07:13 PM

(08-09-2023 10:42 AM)ThomasF Wrote: Another bug/limitation/difference between 16CE and the original 16C is the momentarily showing of other base modes.

If eg in DEC-mode, you can press 'f' then HEX to temporarily see the value in Hex-mode.
On the original the value is shown as long as the key is pressed, but the 16CE only shows the value for some seconds, independent on how long you press the key.

In the 16C microcode, the f SHOW <base> microcode at ROM address 0f49 calls a subroutine at 00b6 that is supposed to wait for key release. This subroutine is also used for f MEM, f STATUS, SST, and BST. Do those functions continue showing their display as long as the key is held?

brouhaha · 08-09-2023, 07:57 PM

(08-09-2023 03:20 PM)ThomasF Wrote: It is said that the DEC-bug is only on presentation, ie the internal representation is correct (eg the HEX value is correct).

And, when working in FLOAT-mode, it works ok, no problem there.

So I thought I could use the feature to convert integer values to float, to get the correct value, but alas, that didn't work either ...

I believe I've found the 16C microcode instruction which, when BCD addition is improperly optimized by the Nut emulator, causes the decimal integer display problem. I think the corresponding problem in integer to float conversion is in a different microcode path, but I haven't yet checked that.

ThomasF · (This post was last modified: 08-09-2023 08:22 PM by ThomasF.)

(08-09-2023 07:13 PM)brouhaha Wrote: In the 16C microcode, the f SHOW <base> microcode at ROM address 0f49 calls a subroutine at 00b6 that is supposed to wait for key release. This subroutine is also used for f MEM, f STATUS, SST, and BST. Do those functions continue showing their display as long as the key is held?

Hi Eric,

f MEM and f STATUS works as the mode, ie in the original 16C shows status as long as the key is pressed, but on the CE only for some seconds.
But SST is even worse, on the original the line number and keycode is shown while the key is pressed, but on the CE nothing is shown. The instruction is executed and the display is updated directly when the key is pressed, no line number or keycode is shown at all ...
Same with BST (except nothing is executed), ie nothing happens in the display (but the PC is decremented (verified by entering PRGM mode)).

Cheers,
Thomas

Voldemar · 08-09-2023, 09:06 PM

(08-09-2023 04:29 PM)ThomasF Wrote: Maybe this little program can show the correct decimal value:

Code:

001 - 43,22, d LBL D 002 - 23 HEX 003 - 44 0 STO 0 004 - 0 0 005 - 44 32 STO I 006 - 34 X<>Y 007 - 43,22, 0 LBL 0 008 - A A 009 - 42 9 RMD 010 - 45 32 RCL I 011 - 4 4 012 - 20 * 013 - 43 E RLCn 014 - 42 40 OR 015 - 43 24 ISZ 016 - 45 0 RCL 0 017 - A A 018 - 10 / 019 - 44 0 STO 0 020 - 43, 5, 4 CF 4 021 - 43 48 X#0? 022 - 22 0 GTO 0 023 - 33 RDN

It will convert a decimal value to hex BCD digits.
Doesn't handle overflow, and works only for unsigned values.

HEX
enter 6F
DEC
105 d (but is actually 111)
GSB D
111 h (correctly shown, but a HEX-value)

So with a decimal value in x, GSB D will show the same value as decimal but in Hex-mode.

Edit: Added keycodes

Cheers,
Thomas

Very good
Thank You
Also works for 60(61)+80n numbers

brouhaha · 08-10-2023, 06:40 PM

(08-09-2023 07:57 PM)brouhaha Wrote: I believe I've found the 16C microcode instruction which, when BCD addition is improperly optimized by the Nut emulator, causes the decimal integer display problem. I think the corresponding problem in integer to float conversion is in a different microcode path, but I haven't yet checked that.

The binary-to-float error does appear to result from the same instruction. It's in a complicated routine that I don't yet understand, but it appears to be a general-purpose binary-to-BCD conversion. The reason the routine is complicated is probably the need to handle 64-bit input.

Anyhow the (sort of) good news is it looks like only one instruction in the 16C microcode will need special handling in the Nut emulator ARM code to fix both the decimal integer display and tge binary-to-float errors.

I haven't yet checked the 60+80n display error, but it's probably the same instruction.

I have two 15C CE un8ts waiting for me in Colorado, but I'm stuck in Florida for at least a few weeks, so I won't be able to try anything on the 15C CE for a while.