Author |
Topic: Annoyances, Requests, Bugs (Read 12688 times) |
|
Jamie OConnell
Administrator
 
Gender: 
Posts: 2027
|
 |
Annoyances, Requests, Bugs
« on: Mar 28th, 2005, 5:49pm » |
 Quote  Modify
|
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).
|
| « Last Edit: May 7th, 2005, 12:18am by Jamie OConnell » |
 IP Logged |
--Jamie
Music is its own reward.
|
|
|
Chris_L
New Member
MIDI-OX Rules!
Posts: 6
|
|
Re: Annoyances, Requests, Bugs
« Reply #1 on: May 14th, 2005, 5:14pm » |
Quote Modify
|
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  )
|
|
IP Logged |
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
|
Re: Annoyances, Requests, Bugs
« Reply #2 on: May 16th, 2005, 10:41pm » |
Quote Modify
|
I appreciate the report -- thanks!
|
|
IP Logged |
--Jamie
Music is its own reward.
|
|
|
Chris_L
New Member
MIDI-OX Rules!
Posts: 6
|
|
Re: Annoyances, Requests, Bugs
« Reply #3 on: May 17th, 2005, 12:30am » |
Quote Modify
|
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.
|
|
IP Logged |
|
|
|
Chinpokomon
New Member
MIDI-OX Rules!
Posts: 1
|
|
Re: Annoyances, Requests, Bugs
« Reply #4 on: May 17th, 2005, 8:52pm » |
Quote Modify
|
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. 
|
|
IP Logged |
|
|
|
Chris_L
New Member
MIDI-OX Rules!
Posts: 6
|
|
Re: Annoyances, Requests, Bugs
« Reply #5 on: May 20th, 2005, 2:21pm » |
Quote Modify
|
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.
|
|
IP Logged |
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
 |
Re: Annoyances, Requests, Bugs
« Reply #6 on: May 30th, 2005, 12:29am » |
Quote Modify
|
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: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).
|
|
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.
|
| « Last Edit: May 30th, 2005, 12:31am by Jamie OConnell » |
IP Logged |
--Jamie
Music is its own reward.
|
|
|
RickN
Member
HP Calculator Enthusiast
Gender:
Posts: 45
|
|
Re: Annoyances, Requests, Bugs
« Reply #7 on: Jun 1st, 2005, 2:36am » |
Quote Modify
|
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
|
| « Last Edit: Jun 1st, 2005, 10:08am by RickN » |
IP Logged |
|
|
|
RickN
Member
HP Calculator Enthusiast
Gender:
Posts: 45
|
|
Re: Annoyances, Requests, Bugs
« Reply #8 on: Jun 1st, 2005, 11:01am » |
Quote Modify
|
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
|
|
IP Logged |
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
|
Re: Annoyances, Requests, Bugs
« Reply #9 on: Jun 1st, 2005, 5:57pm » |
Quote Modify
|
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.
|
|
IP Logged |
--Jamie
Music is its own reward.
|
|
|
Chris_L
New Member
MIDI-OX Rules!
Posts: 6
|
|
Re: Annoyances, Requests, Bugs
« Reply #10 on: Jun 2nd, 2005, 1:30am » |
Quote Modify
|
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.
|
| « Last Edit: Jun 2nd, 2005, 1:32am by Chris_L » |
IP Logged |
|
|
|
RickN
Member
HP Calculator Enthusiast
Gender:
Posts: 45
|
|
Re: Annoyances, Requests, Bugs
« Reply #11 on: Jun 4th, 2005, 1:23pm » |
Quote Modify
|
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.
|
|
IP Logged |
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
|
Re: Annoyances, Requests, Bugs
« Reply #12 on: Jun 7th, 2005, 2:23pm » |
Quote Modify
|
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".
|
|
IP Logged |
--Jamie
Music is its own reward.
|
|
|
Chris_L
New Member
MIDI-OX Rules!
Posts: 6
|
|
Re: Annoyances, Requests, Bugs
« Reply #13 on: Jun 7th, 2005, 5:06pm » |
Quote Modify
|
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.
|
|
IP Logged |
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
|
Re: Annoyances, Requests, Bugs
« Reply #14 on: Jun 10th, 2005, 3:23pm » |
Quote Modify
|
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  ]
|
| « Last Edit: Jun 12th, 2005, 2:35pm by Jamie OConnell » |
IP Logged |
--Jamie
Music is its own reward.
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
|
Re: Annoyances, Requests, Bugs
« Reply #15 on: Jun 10th, 2005, 10:52pm » |
Quote Modify
|
on Jun 1st, 2005, 2:36am, 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:
|
| « Last Edit: Jun 10th, 2005, 10:52pm by Jamie OConnell » |
IP Logged |
--Jamie
Music is its own reward.
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
|
Re: Annoyances, Requests, Bugs
« Reply #16 on: Jun 13th, 2005, 12:32am » |
Quote Modify
|
on Jun 2nd, 2005, 1:30am, Chris_L wrote: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.
|
|
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.
|
|
IP Logged |
--Jamie
Music is its own reward.
|
|
|
RickN
Member
HP Calculator Enthusiast
Gender:
Posts: 45
|
|
Re: Annoyances, Requests, Bugs
« Reply #17 on: Jun 16th, 2005, 2:31am » |
Quote Modify
|
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...
|
| « Last Edit: Jun 16th, 2005, 2:33am by RickN » |
IP Logged |
|
|
|
RickN
Member
HP Calculator Enthusiast
Gender:
Posts: 45
|
|
Re: Annoyances, Requests, Bugs
« Reply #18 on: Jun 17th, 2005, 10:49am » |
Quote Modify
|
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.
|
|
IP Logged |
|
|
|
RickN
Member
HP Calculator Enthusiast
Gender:
Posts: 45
|
|
Re: Annoyances, Requests, Bugs
« Reply #19 on: Jun 17th, 2005, 10:56am » |
Quote Modify
|
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.)
|
| « Last Edit: Jun 17th, 2005, 10:56am by RickN » |
IP Logged |
|
|
|
|
User Forum ::
Powered by YaBB
Home 
Help 
Search 
Members 
Login 
Register
Reply
Notify of replies
Send Topic
Print