MIDI-OX User Forum - Print Page


    
      
        MIDI-OX User Forum
        (http://www.midiox.com/cgi-bin/yabb/YaBB.pl)
      

        HP16C Emulator >> HP16C Bug Reports >> Annoyances, Requests, Bugs
        
(Message started by: Jamie OConnell on Mar 28^th, 2005, 5:49pm)

Title: Annoyances, Requests, Bugs
Post by Jamie OConnell on Mar 28^th, 2005, 5:49pm

Please add related items to this HP16C thread.

Already on the table are:
1) Stray Pixels
2) Keyboard annoyances (support more than just KeyPad)

[Later...] The above items are fixed in the latest BETA (just released).

Title: Re: Annoyances, Requests, Bugs
Post by Chris_L on May 14^th, 2005, 5:14pm

Small bug:
CHS (change Sign) does not set the G flag when you use this function on the largest negative number in 2's complement mode.
To reproduce this error:

Set WSIZE = 6.
Set Negative mode to 2's complement.
Enter binary mode.
Enter 100000 (-32 in decimal).
Press the CHS button.

The emulator will continue to show 100000, but it will not set the G flag like my original HP16C does.

By the way, this is the best hp16c emulator I have seen. I have been working on my own java Applet based emulator for a school project, and it is very convenient to use yours to test against mine (along with my original hp16c calculator to settle any discrepencies :) )

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on May 16^th, 2005, 10:41pm

I appreciate the report -- thanks!

Title: Re: Annoyances, Requests, Bugs
Post by Chris_L on May 17^th, 2005, 12:30am

A few more bugs:

1. Decimal entry is not correct for negative numbers.
To reproduce:
A. Set negMode = 2's complement.
B. Set wordSize = 4.
C. Set base mode to Decimal.
D. Enter 8. Emulator will not allow you to enter this. Original Hp16c will allow it and immediately converts the display to show -8 (because 8 in binary is 1000, same as -8 with base 4).

2. Hex mode entry overwrites digits for 64 bit words.
A. Set negMode = 2's complement.
B. Set wordSize = 64.
C. Set base mode to Hex.
D. Enter 7FFFFFFFFFFFFFFFFFF (7 followed by 16Fs).
E. This will be stored in register X as:
FFFFFFFFFFFFFFFFFF, rather than
7FFFFFFFFFFFFFFFFF. The leading 7 gets overwritten.

3. Multiplying large numbers does not always set G flag properly.
A. Set negMode = 2's complement.
B. Set wordSize = 64.
C. Set base mode to Hex.
D. Enter largest possible number: 7FFFFFFFFFFFFFFFFF (7 followed by 15Fs).
E. Press enter once.
F. Press multiply key.
G. Emulator gives correct sum of 1, but the overflow (G) flag is not set.

4. 1's complement multiplication is not correct.
In this mode, -2 * 4 = -9 on emulator.
Multiplying by 0 or -0 can produce even stranger results.

Title: Re: Annoyances, Requests, Bugs
Post by Chinpokomon on May 17^th, 2005, 8:52pm

I was going to reply to Shalkey in the other thread, but it seems as though you've locked it. When I want to clear the Carry and Range flags (C and G) I just add 0. Seems to give me the same effect and easier to remember than which the numbered flag to clear. (You can't just flip the calculator over when it's a picture on the screen)

Is there a case that I'm unaware of that adding 0 fouls the result and doesn't clear the flags?

/Ryan

Btw, nice app (I was actually making one of my own when I stumbled upon yours) but Chris_L is spot on for those bugs. -2 * 4 was actually returning -11 for me. Oops. I won't even print what multiplying by -0 got me. Hmmmm, on second thought, perhaps clearing the flags by adding 0 isn't safe. :D

Title: Re: Annoyances, Requests, Bugs
Post by Chris_L on May 20^th, 2005, 2:21pm

Chinpokomon -
I don't think there is any risk adding 0 to clear Carry and overflow (flag 4 and flag 5).
However, whenever you do this, you are losing the value in two of the registers (RegT and Reg Last X).
For instance, suppose stack is:
RegT = 23
RegZ = 12
RegY = 8
RegX = 11
RegLastX = 30

You enter 0, now the stack is:
RegT = 12
RegZ = 8
RegY = 11
RegX = 0
RegLastX = 30

You press +, now the stack is:
RegT = 12
RegZ = 12
RegY = 8
RegX = 11
RegLastX = 0

This works, but you just lost the original LastX and RegT values.
Pressing "g" then "5" then "4" will clear the carry flag.
Pressing "g" then "5" then "5" will clear the overflow flag.
These steps will clear the flags without overwriting any values.

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on May 30^th, 2005, 12:29am

Chris_L: Many thanks for the bug reports. I believe each of the issues you raised is now fixed in the latest Beta.

Some Notes:

Quote:

This quirky data entry 'feature' is particularly difficult to emulate, but I believe we have now copied it satisfactorily. While investigating your report, I also noticed that entering '9' would result in '-7', '10' in '-6' ... '15' in '-1'. I also copied those modes. The emulator result is not identical to the Calculator, as it's initial display shows '-06' when '10' (etc.) is entered, however after pressing [Enter] both results are the same.

Quote:

2. Hex mode entry overwrites digits for 64 bit words.
A. Set negMode = 2's complement.
B. Set wordSize = 64.
C. Set base mode to Hex.
D. Enter 7FFFFFFFFFFFFFFFFFF (7 followed by 16Fs).
E. This will be stored in register X as:
FFFFFFFFFFFFFFFFFF, rather than
7FFFFFFFFFFFFFFFFF. The leading 7 gets overwritten.

This was a definitely a problem as the PC silently overflowed the result. Now fixed.

Quote:

3. Multiplying large numbers does not always set G flag properly.
A. Set negMode = 2's complement.
B. Set wordSize = 64.
C. Set base mode to Hex.
D. Enter largest possible number: 7FFFFFFFFFFFFFFFFF (7 followed by 15Fs).
E. Press enter once.
F. Press multiply key.
G. Emulator gives correct sum of 1, but the overflow (G) flag is not set.

Similar bug as above.

Quote:

4. 1's complement multiplication is not correct.
In this mode, -2 * 4 = -9 on emulator.
Multiplying by 0 or -0 can produce even stranger results.

Admittedly, 1's complement arithmetic has had less testing and scrutiny than other modes, as it's less used in practice, but thanks to the reports I think it is much better now.

A new beta is available for download.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Jun 1^st, 2005, 2:36am

HP-16C Emulator version 1.3.0.8, unsigned 56-bit math, z = 0xeef430a939058a, y = 0x277cf2a79, x = 0xbe, DBL/. Gives Error 0 instead of the correct answer.

I wrote an HP-16C program in 1982 to approximate e (2.718...) to 400 decimal places. It takes about 4 hours to run. I will keep running it on new emulator versions until it works.

Rick

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Jun 1^st, 2005, 11:01am

When running the "e to 400 digits" program, I noticed the execution speed of the emulator running on a 1.7 GHz P4 is about the same as the calculator! Can anything be done easily to speed it up?

The blue-shift legends on the keys are hard to read. I tried saving and adjusting brightness on the keyboard image. Making it a little brighter makes a big improvement in readability.

I really like your project! I am a computer science engineer with 28 years HP/Agilent experience. Nothing to do with their calculators though.

Rick
Liberty Lake, WA

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Jun 1^st, 2005, 5:57pm

Quote:

When running the "e to 400 digits" program, I noticed the execution speed of the emulator running on a 1.7 GHz P4 is about the same as the calculator! Can anything be done easily to speed it up?

Probably so. The current emulation is designed to run as close to the original calculator in every way possible (so that you get the blinking "running" effect -- as well as an artificial blink when functions are pressed). Maybe we could add an option to allow it to run at a faster rate -- I'll evaluate it.

Thanks for the feedback on the visual UI. There is certainly room for improvement, and I will see what I can do.

Title: Re: Annoyances, Requests, Bugs
Post by Chris_L on Jun 2^nd, 2005, 1:30am

A few float bugs in the newest version (I downloaded June 1):

All bugs are in floating point mode.

1. Enter 9.999999999 and then press the EEX button (f - CHS).
This button will not work on the emulator.
The eex button should not work only if the decimal point is to the right of the 8th digit or greater.
So: 9.999999999 should work, and 99999999.99 should not.

2. Sqrt is slightly incorrect in floating point mode.
enter 1.000000001 and then press sqrt (g - oct).
This will result in 1.000000001, when it should result in 1.000000000. Also, but if you do the sqrt again, it will result in the correct number. I think this might be due to you storing the floating point number in a different way than the original hp16c.

3. This one might not be something that you want to fix, but:
It looks like you are not storing floating point numbers in the same way as the hp16c does. Here is how you can test this:
Enter into float mode on your emulator. Enter some random floating point number. Store the results to a register (STO 4).
Return to integer mode by pressing the HEX button.
Retrieve your floating point number in int mode by pressing RCL 4. Perform the same steps on the original hp16c (make sure you enter the same random floating point number). You will notice that your emulator is storing the floating point number differently than the original. If you need some additional information on how the original hp16c stores floating point numbers, let me know. I had to figure that out for part of my school project.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Jun 4^th, 2005, 1:23pm

A few posts back I mentioned a bug found by running a program to calculate e to 400 decimal places. Let me know if you want the program, to either use in testing the emulator or for posting so others can see it. It is 2 scans of 8.5x11 handwritten pages. Instructions are included. In summary, enter 28 steps to find e in binary to 1344 bits, run 3 hours, clear program, enter 28 steps to convert to base 10, run and record results.

HP released "xhpcalc" on its HP-UX (Unix) workstations, and it simulates the 16C as well as scientific and financial calculators. But the 16C part doesn't support the DBL functions. Emmet Gray released "WRPN" that simulates the 16C, but without programming or word sizes greater than 32 bits. So far I know of no *complete* HP-16C simulator and hope you will take on the challenge.

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Jun 7^th, 2005, 2:23pm

RickN: Sure, I'd appreciate a copy of the program. It could be very helpful for debugging.

Chris_L: I would definitely appreciate information about the original internal number representation. I have implemented a homebrew fixed decimal representation for the emulator. In most cases it gets identical results, but there is always a possibility for discrepency. Especially in the display of the numbers (as opposed to the internal representation).

Any documents can be sent to "jamieoconnell (at) midiox (dot)com".

Title: Re: Annoyances, Requests, Bugs
Post by Chris_L on Jun 7^th, 2005, 5:06pm

Floating point format details:
It is a 56 bit format, but it is easiest to think about it as 14 hex digits (although as you will be able to tell in the details below, all of these hex digits will end up between 0-9. This format that the hp16c used is obviously not the most efficient one, but it does make it easy for you to tell what the floating point value is just by looking at its hex value).

Hex digit 1: Sign, 0 if positive, 9 if negative.

Hex digit 2-11: This is the 10 digit mantissa.

Hex digit 12-14: Exponent, expressed as 3 digit decimal. If exponent is negative, add that negative number to 1000 to get your 3 digit decimal. Here are some exponent examples: 0=000, 1=001, 95=095, -1=999, -45=955. Note that -0 does not ever get stored.

Putting it all together here are some examples of floating point numbers and how they would be stored by the hp16c:

1.0242476 * 10^18 Float = 01024247600018 hex
-.9541112121 Float = 99541112121999 hex
5.2 * 10^-50 = 05200000000950 hex

Once you get your 14 digit hex, you should be able to easily convert that to the 56 bit binary value for storage.

Let me know if any part of that didn't make sense.

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Jun 10^th, 2005, 3:23pm

Thanks for that information. So they store each digit in a nybble, 2 per byte...14 of those packed digits takes 7 bytes (56 bits). It's not clear that they are using hex though: in all your examples decimal digits are shown, but I think I understand what you mean as 2 hex digits CAN be stored in a single byte. In the early days of computing they called this format Packed Decimal, although the exponent coding seems unique. In fact, this is similar in concept (but not identical) to my internal representation.

It might be possible to store values in storage registers this format, but there is another difference between the emulator and the calculator: the emulator does not change the width of the storage registers when the word size changes. The calculator does change the width of the storage registers because the amount of available storage was so scarce.

[Later... I now see why you referred to HEX, as converting the calculator from float to HEX allows inspection of the float representation. I appreciate the hints ;)]

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Jun 10^th, 2005, 10:52pm

on 06/01/05 at 02:36:14, RickN wrote:

HP-16C Emulator version 1.3.0.8, unsigned 56-bit math, z = 0xeef430a939058a, y = 0x277cf2a79, x = 0xbe, DBL/. Gives Error 0 instead of the correct answer.

I finally got some time to look into this. My real HP-16C calculator gets the same result (Error 0). I presume that this is because the answer does not fit inside a 56 bit result (or even 64 bit). From the HP-16C manual:

http://www.midiox.com/forumpix/dbldiv.gif

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Jun 13^th, 2005, 12:32am

on 06/02/05 at 01:30:42, Chris_L wrote:

This was an eye opener. Fixing it required changing a good bit of the internal buffer and display logic. It should be working as expected in the next beta.

Quote:

2. Sqrt is slightly incorrect in floating point mode.
enter 1.000000001 and then press sqrt (g - oct).
This will result in 1.000000001, when it should result in 1.000000000. Also, but if you do the sqrt again, it will result in the correct number. I think this might be due to you storing the floating point number in a different way than the original hp16c.

This was due to differences in rounding behavior. I now truncate any portion of the answer tha can't fit inside a 10 digit mantissa, and round from there.

Quote:

3. This one might not be something that you want to fix, but:
It looks like you are not storing floating point numbers in the same way as the hp16c does...

I haven't yet done anything about this, but I agree that it would be nice to have the storage registers (in 56 bit widths) use the original float format when switching back to HEX. So I may implement this in the future.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Jun 16^th, 2005, 2:31am

Let me try to redeem myself after my DBL/ red herring earlier. (You are right, what I described is not a defect.)

1) Enter this program in the HP-16C and emulator: LBL F, GTO F. From Run mode, press and release GTO, F, SST, SST, SST... Notice the HP-16C indicates the LBL F as a step and the emulator skips over it. This messed up my debugging efforts, counting SST presses on the emulator and 16C to pace and compare the two. Every GTO, the emulator skips a step relative to the 16C.

2) I count on CLx disabling stack lift in my program and the emulator doesn't do it. From the keyboard: 1, ENTER, 2, ENTER, 3, ENTER, 4, CLx (blue shift, BSP), 5. Compare the emulator and 16C stacks to see the difference. See the owners manual pages 25 and 99. (This took me 3 hours to find, as the root cause of a problem in my e program. An emulator workaround is to replace CLx, RCL (i) in my program with CLx, ROLLDOWN, RCL (i).)

3) I could really use a "run at full speed" option when using my 4-hour program to help debug the emulator...

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Jun 17^th, 2005, 10:49am

Enhancement suggestion: I would like some way to get a text file listing of the program contents (and registers, stack, LastX... too) of the emulator, with both row/column keystroke notation and command name columns side by side. This could be by making the .16c files plain text or providing another menu option to export this information. It is time consuming to use the emulator for debugging programs that work on a real HP-16C. This option would allow a quick way to make sure what is in the emulator is what is intended. It also provides a good way to share programs with either emulator OR real calculator users.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Jun 17^th, 2005, 10:56am

Enhancement suggestion: Finer mouse-click recognition so f or g shifts can be clicked directly instead of requiring 2-key sequences. (This was a feature of the HP program xhpcalc that ran on UNIX workstations. A useful example: Either g SST or BST in one click would do a BST operation.)

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Jun 18^th, 2005, 5:45pm

DBL/ and DBLR bugs: 56-bit word size, unsigned math, HEX, 5F7Ed0AE425dF1, ENTER, 3A, ENTER, bE, DBL/. An HP-16C returns 4EA664Cdb79766 but the emulator returns 4EA664CA644FC4. Try the same arguments with DBLR. The HP-16C returns 3d but the emulator returns 277CF2A79. (These took me several hours of degugging effort to find using my e program, an HP-16C, and Derive software on a PC.)

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Jun 19^th, 2005, 10:58am

Nice, thanks. I think we both got to roughly the same place (LastX = 190). What does the Derive software do?

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Jun 19^th, 2005, 6:02pm

on 06/17/05 at 10:49:29, RickN wrote:

This is a good idea, and one I have toyed with; however it may be beyond what can be accomplished for a version 1 program. The program did not even get released to Beta until the version 1 features were complete.

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Jun 19^th, 2005, 6:06pm

on 06/17/05 at 10:56:07, RickN wrote:

This is a very good idea. I think we could add an option for this type of behavior. It needs to be an option because there will be a certain set of folks who will desire an accurate simulation, without shortcuts.

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Jun 19^th, 2005, 6:42pm

on 06/16/05 at 02:31:18, RickN wrote:

Confirmed and repaired.

Quote:

2) I count on CLx disabling stack lift in my program and the emulator doesn't do it. From the keyboard: 1, ENTER, 2, ENTER, 3, ENTER, 4, CLx (blue shift, BSP), 5. Compare the emulator and 16C stacks to see the difference. See the owners manual pages 25 and 99. (This took me 3 hours to find, as the root cause of a problem in my e program. An emulator workaround is to replace CLx, RCL (i) in my program with CLx, ROLLDOWN, RCL (i).)

I cannot reproduce your particular example:

1, ENTER, 2, ENTER, 3, ENTER, 4, CLx (blue shift, BSP), 5
This sequence results in a stack of (T) 1, (Z) 2, (Y) 3, (X) 5 on both calculators. However, I did find a problem where rolling the stack up or down sometimes did not Enable stack lift. I fixed the latter one.

I'm not sure why this was the Root Cause of the problem in your e program, as I haven't yet got the first program to run to completion? And that one doesn't have a CLx instruction.

[Later... I also see that: CLx followed by RCL n does not behave as expected...]

Quote:

3) I could really use a "run at full speed" option when using my 4-hour program to help debug the emulator...

I'm still working on this. As the program instructions are interpreted, and there is large overhead in certain operations, it will never be incredibly fast. Of course, the goal is to emulate the HP-16C, not a P4, but I think we can offer some speed-up.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Jun 19^th, 2005, 7:55pm

Quote: I cannot reproduce your particular example: 1, ENTER, 2, ENTER, 3, ENTER, 4, CLx (blue shift, BSP), 5. ... However, I did find a problem where rolling the stack up or down sometimes did not Enable stack lift. I fixed the latter one. ... I also see that: CLx followed by RCL [i] does not behave as expected... I'm not sure why this was the Root Cause of the problem in your e program, as I haven't yet got the first program to run to completion? And that one doesn't have a CLx instruction.

Explanations: I couldn't make the "find e in binary" program to work on the emulator, so to continue making progress I made a separate program to find e to only 32 decimal places. It worked (in hindsight, by not encountering the DBL/ and DBLR bugs) and allowed running the 2nd "convert to base 10" program, that failed, due to the CLx RCL(i) sequence not behaving as expected. I think I then tried the manual 1 ENTER 2 ENTER 3 ENTER 4 Clx 5 sequence just after finding the Clx RCL(i) bug and it failed. I was doing RollDown at various points to check the stack. But I can't replicate it now either. (Fortunately I did mention the core CLx RCL(i) problem.) AFTER finding the CLx RCL(i) bug, I did the CLx RollDown RCL(i) workaround and went back to the full "find e in binary" program, to find the DBL/ and DBLR bugs. (Whew!)

Bottom line: I will email separately my .16c file that can be used as a test program via Factory Reset, load program, GSB A. Since the emulator has more register + program memory than the 16C, both halves of the program and all manual setup can be done in the emulator program. Currently it would take about 4 hours to run.

Rick

Title: A few programming bugs
Post by Chris_L on Jun 30^th, 2005, 3:58pm

1. The clear program command (F-Rdown) should only delete programmed instructions when you are in program edit mode. In regular calc mode, this command should still reset the current instruction to 0, but should not delete any instructions.

2. The pause command (g-X<>Y) does not work exactly the same as the original hp16c. I ran into a similar problem with my academic project, and I had to choose not to execute show-base commands from inside of programs.

Here is a short program that highlights the differences:
001 - HEX
002 - 9
003 - 8
004 - 7
005 - f-BIN (show binary)
006 - f-DEC (show decimal)
007 - g-X<>Y (pause)

Original calculator will show 100110000111 b for 1 second,
2439 d for 1 second, 987 h for 1 second, and then finish executing the program and show the final result permanently (987 h).

Your emulator will just show 2439 d for 1 second, and then it will finish executing and show the final (wrong) result of 100110000111 b. The calculator should be in hex mode here, not binary.

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Aug 9^th, 2005, 2:01am

You're right. The Clear Program operation was backward. I think I now have the Show Number Mode stuff working in program run mode.

Many thanks to Chris_L and RickN as well as everybody else for helping out with bug reports. A new Beta has been released tonight.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Aug 9^th, 2005, 11:12pm

Jamie,

The new rev 1.3.2.10 is great! I especially like the "Execute at Max Speed" and "Tri-Section button" features. The "e to 400 places" program, re-written to be one long program with no setup needed, executes and gives correct results in about a minute instead of 5 hours.

I noticed on the tri-section buttons that the f-shifts have very little vertical mouse distance allocated to them -- having the mouse in the middle of the yellow text is already outside the allowed mouse space.

Rick

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Aug 10^th, 2005, 9:56am

Quote:

I noticed on the tri-section buttons that the f-shifts have very little vertical mouse distance allocated to them -- having the mouse in the middle of the yellow text is already outside the allowed mouse space.

That's true, but I can't make it test outside of the button itself, and I didn't want it to be easy to accidently hit f+func or g+func.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Aug 29^th, 2005, 1:57am

Regarding the HP-16C Emulator version 1.3.6.15 (8/27/05),

I really like it!

Enhancement: Remember the on/off state and location of the stack, reg, and program windows so I can quit the program and restart where I left off.

Enhancement: Allow resizing of the stack, reg, and program windows. (The real desire here is to get all 3 of these and the calculator window on-screen at the same time, not overlapping. Maybe leave them a fixed size, but with non-overlapping layout a goal. The register window seems to stay at the widest size ever needed which usually includes lots of white space.)

Bug: Clicking on the calculator window will not raise it above the stack, reg, or program windows. I tried "Keep on top" but figured out this keeps the whole set of windows on top of other applications, not what I wanted.

Rick

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Aug 29^th, 2005, 11:30am

on 08/29/05 at 01:57:01, RickN wrote:

Enhancement: Remember the on/off state and location of the stack, reg, and program windows so I can quit the program and restart where I left off.

We already do save stack contents, regs, program, and IP. I agree that saving the state of the stack would allow restarting so I'll add that.

Quote:

Enhancement: Allow resizing of the stack, reg, and program windows. (The real desire here is to get all 3 of these and the calculator window on-screen at the same time, not overlapping. Maybe leave them a fixed size, but with non-overlapping layout a goal. The register window seems to stay at the widest size ever needed which usually includes lots of white space.)

This is a bunch of extra work, but maybe necessary at this point. I hadn't noticed because I run at 1280 x 960 minimum, but not everybody does.

Quote:

Bug: Clicking on the calculator window will not raise it above the stack, reg, or program windows. I tried "Keep on top" but figured out this keeps the whole set of windows on top of other applications, not what I wanted.

That's a Windows limitation for child windows and can't be changed, but maybe resizing child windows will make this moot.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Aug 29^th, 2005, 8:58pm

Jamie quote: We already do save stack contents, regs, program, and IP. I agree that saving the state of the stack would allow restarting so I'll add that.

Jamie: I mentioned the on/off state and location of the *windows* involved. I would like to start the application and have all 4 (or fewer) windows onscreen where I last left them, the same size as I last left them.

Another thing about resizable windows -- The current Registers window isn't big enough to show a 64-bit register in binary.

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Aug 30^th, 2005, 2:21am

Quote:

Another thing about resizable windows -- The current Registers window isn't big enough to show a 64-bit register in binary.

True. It would have to be huge by default to satisfy that, however you CAN resize the columns and use a horizontal scroll bar to get to all of the data.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Sep 6^th, 2005, 10:35pm

1) I compared the checksum example on page 90-93 of the owners manual with the emulator and got different results. I did this:

- Factory Preset
- Load your provided chksum.16c program
- Initialize registers 1 through A to a 7 b 1 3 d a 2 d 6.
- GSB D (I get "6" which agrees with the manual.)
- x~y (I get "B" which disagrees with the manual's "1".)

I didn't check my real 16C, but assume it agrees with the manual.

2) Enhancement: Flag 3 displays leading 0s in the calculator display, but not in the Registers window. (I wanted to see leading 0s in the Register window and this was the way I assumed would do it.)

3) Enhancement: Display numbers in the Stack and Registers windows using a fixed-width font so the digit positions line up. (With 64-bit wordsize, compare 1111111111111111 to CCCCCCCCCCCCCCCC and see the latter appears several digits longer.)

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Sep 8^th, 2005, 12:58pm

In Program mode with a program in memory so the current IP is shown in the calculator display, right-click on a different step in the Program window and select Move IP to Cursor. The calculator display stays on the old IP location instead of indicating the new IP location. (The IP did actually move, as can be seen with SST, BST.)

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Sep 9^th, 2005, 9:55pm

Thanks for the reports. As a general rule, there aren't any more enhancements planned for the initial release. The emulator is feature complete. I only plan to fix bugs from now to release, which I hope is very soon if all goes well.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Sep 9^th, 2005, 11:54pm

Defect (emulator version 1.3.7.16 2005-09-02): Sometimes adding a program step *overwrites* an existing step instead of being *inserted* after the IP. Do this -- Factory Settings, BSP (to clear Pr Error), P/R, 1, 2, 3 (so you have a program of 3 steps), open the Program window, left-click on step 2 to highlight it, right-click on step 2 and Move IP to Cursor, BSP (to delete step 2 -- so far so good, step 1 ("1") and 2 ("3") remain, and IP appears to be on step 1), 8. The new step ("8") correctly becomes step 2, but step 3 ("3") is gone.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Sep 26^th, 2005, 11:19am

Jamie: Current comments on www.hp16c.net for the 2005-09-24 version say "Many bug fixes." Could you list all changes and defects fixed? It will help those of us doing testing know where to focus our efforts. If you want to be more private about the defects, please consider posting them only here in the forum instead of on the download website. - Rick

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Sep 26^th, 2005, 12:17pm

I WILL detail them soon, but didn't have time Saturday night -- stay tuned. FWIW, everything reported has been fixed, I believe.

[A summary of the bug fixes has been added. You can view it here: [url]http://www.midiox.com/hp16c/details050924.htm[/url]

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Sep 27^th, 2005, 10:57am

Version 1.3.8.017 (2005-09-24):

While in Program Mode, do Factory Settings, Yes. See "PGRM" in display (wrong). SST SST. Really are still in PGRM mode. (Factory Settings doesn't clear all calculator history, making it hard to be sure of a known starting point in any testing effort.)

Maybe related, and intermittent: Factory Settings, Yes, BSP, g P/R. Display showed "1 h" instead of the "000 -" display. (This happened twice, and then I couldn't replicate it.)

Intentional? With my keyboard Num Lock on, the emulator doesn't recognize any Num Pad digits, and the Num Pad Enter key closes the application.

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Sep 27^th, 2005, 12:19pm

on 09/27/05 at 10:57:57, RickN wrote:

Yeah, good catch. I suppose that option should not be available in Program mode.

Quote:

Maybe related, and intermittent: Factory Settings, Yes, BSP, g P/R. Display showed "1 h" instead of the "000 -" display. (This happened twice, and then I couldn't replicate it.)

Right. I imagine we need to clear the display backup.

Quote:

Intentional? With my keyboard Num Lock on, the emulator doesn't recognize any Num Pad digits, and the Num Pad Enter key closes the application.

What Keymap to you have loaded? If it is the default one, then you're right: Numpad is not enabled (intentional). To see the current assignments choose (right-click: Keyboard Map...). ENTER closing the App IS a bug.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Sep 27^th, 2005, 5:56pm

In Windows Explorer, double-click on C:\Program Files\HP16C\Programs\ReverseDec.16c. This opens the emulator, but not with the intended program loaded. (I assume the file type association is created during setup, but seems of little use without allowing the emulator to load a program this way.) Similarly, "Open" on the file opens the emulator, but not the file.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Sep 29^th, 2005, 7:24pm

Provided program BigMath-pg78.16c starts at LBL A, but the manual uses LBL 1 in the program and usage instructions.

Not an emulator issue, but maybe good to publish in Programs Readme.txt, the manual has several errors in the above example: pg 80, after f WINDOW 1, "f WINDOW 0 19326320 .d" is missing. After f WINDOW 2, "73" is correct but misleading, being the *3* MS decimal digits of the word. It should be interpreted as "073" but there is no way to make leading 0s display in DEC mode. The "Exact answer is ...320,731..." is incorrect due to the missing "0" before "73". The correct exact answer is 12,193,263,200,731,267,636,031,035,818.

Factory Settings, Yes, BSP, f FLOAT . 1 EEX 50 ENTER * (overflow, G flag set). Bug 1: f PREFIX shows 9999999990 and should show 9999999999. Bug 2: Formatting of the stack window X value is different than the calculator display, showing "1e+100". 0 ENTER +. Bug 3: The G flag is still displayed and should have been cleared.

FYI, my manual says "April 1982" on the first page. I wonder if future versions fixed HP manual defects. It might be good to mention in Programs Readme.txt what version of the manual is being used.

Regarding Factory Settings not being allowed in PGRM mode, it seems to me it should be allowed from any state including off. A related defect: Off, Factory Settings, Yes. "Pr Error" is in the display, but the emulator is still off so BSP/whatever won't clear it. (Seems to me it should turn on, similar to the real calculator "ON/-" reset.)

Future enhancement: Allow mapping multiple keyboard keys to one emulator key. For example, either "1" or "Number Pad 1" pressing the emulator "1" key.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Oct 1^st, 2005, 6:17pm

Big Defect I think: The emulator does not provide float-to-BCD conversion like the calculator does. Starting in floating point mode, enter -1.234567890e-16, STO 0, HEX, RCL 0. The calculator gives 91234567890984, the BCD conversion of the input, 56 bits, Sign Mantissa Exponent SMMMMMMMMMMEEE, see p56 Owner's Handbook. The emulator gives A1CAC067A85A7b.

Big Defect I think: The emulator does not allow "register splitting" like the calculator does. Continuing the above steps, 4 WSIZE, RCL D, RCL C, RCL B... RCL 0. The calculator provides each of the 14 BCD digits. The emulator does not.

Programs making use of either of the above two documented features would not run correctly on the emulator.

Defect: 0-64-0000 status, HEX 1 CHS SQRT. Calculator shows 0xffffffff + G + C but the emulator gives Error 0. Assumed related: 0xffffffff ENTER * SQRT. Calculator gives 0xffffffff (no G no C) but the emulator gives Error 0.

Defect: 0-64-0000 status, HEX 1 CHS FLOAT . and see the G flag is still set, but it should be cleared.

Defect: In floating point mode, enter -2.468013579e-98. PREFIX shows 2468013578 (the last digit should be 9).

Defect: On the "Pre-Release" text, "Release" had a gray box around it, the same color as the top of the window when the application is not highlighted. I did Alt-PrintScrn to save the image, went to Paint to paste it in, and there was nothing to Paste. I had been doing various operations for about 30 minutes, so don't know how to replicate it.

Defect/Enhancement: Enter -2.468013579e-98 and look at the Stack window. It shows "-2.46801e-098", a format showing fewer mantissa digits than the calculator, and an extra exponent digit. It seems the formatting of the Stack and Register windows should either follow the calculator (for HEX, DEC, OCT, BIN, SF/CF 3, and Float), or be fixed at something that gives all information available, like "-2.468013579e-98" in this example.

Defect/Enhancement: 2-64-0000 status, 1 CHS STO 0 FLOAT . and look at the Register View of R0. "-1.#QNAN" is unclear. The intent is unclear -- Is the desire to show "wrong format" in *all* cases, or show the actual floating point number if the bit pattern happens to be valid BCD (my preference, same as recalling it to Rx would show), or something else?

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Oct 2^nd, 2005, 3:51pm

on 10/01/05 at 18:17:48, RickN wrote:

This has been known from day 1, and disclosed. Programs that switch modes between Float and Binary would be few and far between because they rely on the particular quirks of the HP-16C implementation. Those quirks have little relationship to any other math system. A future version might deal with this, but not currently.

The manual states on p56:
"Numbers in Floating Point mode and Integer mode are represented in two different, incompatible formats. Therefore, any values stored in the storage registers in one format are not meaningfully converted when the calculator switches to the other format. Their integrity is retained, however when the calculator is restored to the original mode."
The emulator follows this concept also.

Quote:

Big Defect I think: The emulator does not allow "register splitting" like the calculator does. Continuing the above steps, 4 WSIZE, RCL D, RCL C, RCL B... RCL 0. The calculator provides each of the 14 BCD digits. The emulator does not.

Intentional. This has been known from day 1, and disclosed right in the first readme parapraph. Registers and memory on the emulator DO NOT share the same 203 bytes of storage. A future version might address this, but not now.

Quote:

Programs making use of either of the above two documented features would not run correctly on the emulator.

No kidding. Things taking advantage of these features would also not work on any other calculator or computer. I expect this to be a distinct minority of useful applications.

Regarding ALL cases of the Stack and Register views being slightly different from the emulator: it is expected. These views use a different method of formatting and displaying numbers (particularly float, but no leading 0's in binary modes either). These views are designed for additional useful aids and hints about what is going on inside the emulator, but not for exact representation. I don't consider it a problem.

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Oct 2^nd, 2005, 6:17pm

on 09/29/05 at 19:24:09, RickN wrote:

Provided program BigMath-pg78.16c starts at LBL A, but the manual uses LBL 1 in the program and usage instructions.

Thanks. I'll change it to match the manual.

Quote:

Not an emulator issue, but maybe good to publish in Programs Readme.txt, the manual has several errors in the above example: pg 80, after f WINDOW 1, "f WINDOW 0 19326320 .d" is missing.

That is not really true. The result of running the program shows Window 0.

The manual actually says:
"[GSB 1] 19326320 .d Executes program"
"[f][WINDOW] 1 12 .d labeled "1";..."

Quote:

After f WINDOW 2, "73" is correct but misleading, being the *3* MS decimal digits of the word. It should be interpreted as "073" but there is no way to make leading 0s display in DEC mode. The "Exact answer is ...320,731..." is incorrect due to the missing "0" before "73". The correct exact answer is 12,193,263,200,731,267,636,031,035,818.

True in the April 1982 manual. The May 1983 manual corrects this error.

Quote:

Factory Settings, Yes, BSP, f FLOAT . 1 EEX 50 ENTER * (overflow, G flag set). Bug 1: f PREFIX shows 9999999990 and should show 9999999999.

OK, although I think the discrepancy is less than epsilon.

Quote:

Bug 2: Formatting of the stack window X value is different than the calculator display, showing "1e+100".

Yes, but see message above (this rounding is expected).

Quote:

0 ENTER +.
Bug 3: The G flag is still displayed and should have been cleared.

True.

Quote:

FYI, my manual says "April 1982" on the first page. I wonder if future versions fixed HP manual defects. It might be good to mention in Programs Readme.txt what version of the manual is being used.

Yes. See above.

Quote:

Regarding Factory Settings not being allowed in PGRM mode, it seems to me it should be allowed from any state including off. A related defect: Off, Factory Settings, Yes. "Pr Error" is in the display, but the emulator is still off so BSP/whatever won't clear it. (Seems to me it should turn on, similar to the real calculator "ON/-" reset.)

I'm willing to bend somewhat on this one, except it will not be available from OFF. Use the keystroke equivalents if you want to set it from OFF ([ON][-][ON]).

Quote:

Future enhancement: Allow mapping multiple keyboard keys to one emulator key. For example, either "1" or "Number Pad 1" pressing the emulator "1" key.

Not likely. We answered the former problem with this by making the facility completely configurable. Still, I don't see anyone needing two different keys doing the same action. Adding this would be too big an effort for little payoff. It takes all of 5 seconds to switch keymaps.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Oct 4^th, 2005, 1:44am

Jamie,

I really intend the following to help, not just be argumentative. I think your program is great, and will continue trying to find problems. As always I won't be hurt if you ignore change suggestions. I do hope the "known differences" list in the Readme file is kept complete and correct. I bring these things up here in the forum in case anyone else is still monitoring it and wants to chime in. (It doesn't appear anyone else is...)

Regarding float to BCD conversion missing from the emulator: You said "This has been known from day 1, and disclosed." I couldn't find any mention of it in your end-user documentation. Where is it disclosed? When you quoted page 56 of the HP manual you left out the referred to footnote: "Floating Point mode in BCD (Binary Coded Decimal) form". You called this "the particular quirks of the HP-16C implementation" and "Those quirks have little relationship to any other math system." A Google search on Binary Coded Decimal returns 118,000 hits. HP calculators (all, I think) use BCD internally for good reason, as documented in 1970s issues of the HP Journal. BCD is supported in many CPU assembly language instruction sets. It has good reason being in a Computer Scientist calculator. It is used all over the place.

Regarding register splitting missing from the emulator: You said "This has been known from day 1, and disclosed right in the first readme parapraph." I don't see it. The first paragraph addresses program/register memory not being traded off, and always having 406 storage registers. What happens to register contents when WSIZE changes is a different issue. It is definitely different behavior than the calculator, and the example on page 67 won't work on the emulator. Related defect: 2-32-0000 status HEX 12345678 STO 0 4 WSIZE. The Register display shows 12345678 in R0, which doesn't make sense with 4-bit WSIZE.

Regarding differences in the emulator's 10th significant floating point digit from the calculator: This is a big deal. Further chain calculations can make the difference dominate a final result. HP goes to great pains to not let this happen.

You said "Things taking advantage of these 'features' would also not work on any other calculator or computer." I don't understand. The only comparison that matters is the HP-16C. *Any* difference from it could lead to different program results. I agree most users don't use lots of the calculator features, but it is important to know all differences exactly.

The Readme file says "In all other operations and displays there are no known differences between the hardware and software versions of the calculator." If you choose to not fix the above, I hope you at least list them as differences from the real HP-16C.

Regarding not providing both top-row and number pad entry of 0 through 9, you said "I don't see anyone needing two different keys doing the same action." All computer keyboards do this. Maybe don't make it user configurable, but it seems by default that the number pad keys should do 0 1 2 3 4 5 6 7 8 9 + - * / . ENTER, in addition to the user-configurables in the main "qwerty" part of the keyboard. Why *not* do this? Many people go back and forth between the two sections of the computer keyboard.

New issue: Why not make the Index register 68 bits like the calculator instead of 64? You documented this one in the Readme file, but it seems like an unnecessary difference. (I think you use 128-bit libraries internally.) For example, in the calculator, storing 0xffffffffffffffff into the index register stores different bit patterns in 0-64-0000 (64 1-bits, or 2^64-1) and 2-64-0000 (68 1-bits, or -1). The *value* is stored, not the contents of Rx.

Hope this helps,
Rick

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Oct 15^th, 2005, 12:42pm

Quote:

Regarding float to BCD conversion missing from the emulator: You said "This has been known from day 1, and disclosed." I couldn't find any mention of it in your end-user documentation. Where is it disclosed?

My error. I should have said 'Will be disclosed', as the latest user manual has not been posted. I intend to document all known differences -- the readme is horribly out of date.

Quote:

When you quoted page 56 of the HP manual you left out the referred to footnote: "Floating Point mode in BCD (Binary Coded Decimal) form". You called this "the particular quirks of the HP-16C implementation" and "Those quirks have little relationship to any other math system." A Google search on Binary Coded Decimal returns 118,000 hits. HP calculators (all, I think) use BCD internally for good reason, as documented in 1970s issues of the HP Journal. BCD is supported in many CPU assembly language instruction sets. It has good reason being in a Computer Scientist calculator. It is used all over the place.

I was speaking of the conversion between numbering systems as being unusual and unique, not BCD itself. Although, I believe HP's form of BCD is unique as well -- using '9's as the sign indicator. I may be able to emulate it in a future version, but currently the emulator uses IEEE floating point, which is native in MS C++ implementation.

Quote:

New issue: Why not make the Index register 68 bits like the calculator instead of 64? You documented this one in the Readme file, but it seems like an unnecessary difference. (I think you use 128-bit libraries internally.) For example, in the calculator, storing 0xffffffffffffffff into the index register stores different bit patterns in 0-64-0000 (64 1-bits, or 2^64-1) and 2-64-0000 (68 1-bits, or -1). The *value* is stored, not the contents of Rx.

Actually it would be quite a lot of effort to do this, with little payoff, although a future version might address it. Using "back of the envelope" calculations, it indicates that it would take hundreds of years for the emulator to cycle though 64 bits of counting before a wrap around occurred, even at maximum speed. Values larger than 64 bits cannot be stored in a single variable on the PC, and I believe that the HP implementation is arbitrary -- that they happened to use a hardware index register chip that was 68 bits wide. You can never actually see the index value when it is larger than 64 bits anyway: it will always be truncated when moved to the stack.

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Oct 16^th, 2005, 5:53pm

on 09/27/05 at 17:56:09, RickN wrote:

Actually we don't associate any files with the application, although a user (like yourself) can do this manually. Because of that I'll add support for opening programs from the command line.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Oct 16^th, 2005, 10:24pm

Quote:

I believe HP's form of BCD is unique as well -- using '9's as the sign indicator.

FYI: The exponent is 3-digit 10's complement (999, 000, 001 correspond to values of -1, 0, 1) and the sign is one-digit 10's complement (9, 0 correspond to values of -1, 0 -- like a sign bit/digit).

Quote:

Using "back of the envelope" calculations, it indicates that it would take hundreds of years for the emulator to cycle though 64 bits of counting before a wrap around occurred, even at maximum speed. ... You can never actually see the index value when it is larger than 64 bits anyway: it will always be truncated when moved to the stack.

The time comment assumes starting at 0. The value can't easily be seen but the effect can. What follows is contrived, but gives an easy way to see the difference between the HP-16C's 68-bit I register and the emulator's 64-bit. Program to increment RegI and return 0|1 if it is 0|non-0: LBL A, 0, ISZ, 1, RTN. Do these keystrokes: HEX, 0, WSIZE, UNSGN, 40, MASKL, STO I, GSB A. The calculator gives 1 because its RegI has value 1<then 64 0 bits> and the emulator gives 0 because its RegI has value 0.

I will look at the new 2005-10-16 version soon. Thanks again for your work!

Rick

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Oct 18^th, 2005, 10:47am

2005-10-16 1.3.9.019 version: After associating file type .16c with the emulator, close the emulator. In Windows Explorer, double-click file a.16c and see the application with the program loaded as expected. Close the app. Double-click b.16c and see it opened as expected. Close the app. Double-click on a.16c again and get a file sharing violation. I am closing the app with the upper-right "X". Files aren't properly closed when exiting the application? I think I associated .16c with the emulator like I normally do file type extensions. If you have problems replicating it let me know.

Title: Re: Annoyances, Requests, Bugs
Post by Jamie OConnell on Oct 20^th, 2005, 1:47am

Thanks. I just issued another update to deal with this issue. The installer will now actively associate the file type as well.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Oct 21^st, 2005, 11:17am

In the Brief Users Guide, Keyboard Mapping, CHS=End and ENTER=Enter are missing. Also, the columns are reversed and rows in a different order relative to the program keyboard mapping window.

Using default mappings, these don't work on my keyboard: -, + (shift-=), . (dot), /. All other mappings work fine. My keyboard is a 2-year old Dell with 12 function keys along the top -- standard, nothing fancy.

Title: Re: Annoyances, Requests, Bugs
Post by RickN on Oct 21^st, 2005, 8:20pm

Floating point number entry is different than the emulator: FLOAT . .0000001 EEX 1 ENTER enters 1.1e-7 on the calculator because EEX is a no-op as per the owner's handbook p58 footnote, but enters 1.0e-6 on the emulator.