HP-49G+ anomaly with 'CR'.



#6

I have discovered what may be an anomaly with 'CR' on the HP-49G+. In order to demonstrate this anomaly I will describe six different procedures, please bear with me. You may want to hold your 49g+ close to your ear while you do the following.

1.) Enter CR then press and hold the enter key for about a second. Did the calculator beep?

2. Enter CR then press and release the enter key as quickly as possible. Did the calculator Beep?

3.) Open the CATalog and scroll to CR. Press and hold the OK key for about a second. Did the calculator beep?

4.) Again find CR in the catalog. This time press and release the OK key as quickly as possible. Did the calculator beep?

5.) Create the following program and duplicate it a number of times on the stack:

\<< CR \>>

Now press and hold the EVAL key for about a second. Did the calculator beep?

6.) Then press and release the EVAL key as quickly as possible. Did the calculator beep?

7.) The answers I get are: Yes, No, Yes, No, Yes & Yes. Should the calculator really beep when it executes a CR? And in any event why does it react differently depending on how the executing key press is applied?

rdb.


#7

Maybe a problem with the key buffer ?

Perhaps the Xtra-Long-Hold gimmick isn't defined correctly there...


Raymond

#8

Well, it's not something new on the 49g+; essentially the same behaviour occurs on the 48SX, except of course that the 48SX lacks the catalogue. And it's not just CR, but all of the print commands. Notice that it doesn't actually send the CR until after you've released the key. I suppose that it beeps because it unexpectedly finds a key pressed when it tries to print.

Regards,
James


#9

Then why does the 49G+ beep when it encounters a 'CR' in a running program?

rdb.


#10

Because a key is down when the CR tries to execute? I tried inserting a CR into a few programs without getting any beep from them, but just \<< CR \>> by itself, or CR as the first object in a program, does beep when I press the EVAL key on the 49g+. On the 48GX, this doesn't happen unless I intentionally hold the key down longer than normal. I expect that the "problem" is that on the 49g+, the program executes so fast that I don't have time to release the EVAL key before it tries executing the command. Maybe the fact that I have to press harder than "normal" on the 49g+ influences how fast I can release the key. With the program \<< .1 WAIT CR \>>, I don't get the beep with a normal keypress. Personally, I'd rather ignore this "problem" than have HP add a delay at the beginning of each print command.

But I am a bit curious about why the print commands beep when a key is down, but not the XMIT command (even when using the IR port) for instance.

If I use PR1 to print a string too long to fit on a single line, and hold the key down, then it prints out the first line and beeps. When I release the key, the rest of the string is printed. That it prints out the first line tells me that the "CR" ("print line and leave head at right", actually character 4) was sent while the key was still down.

The 48SX and 48GX seem to behave the same, so I continued experimenting with them. Using the INPRT program to capture the "Red Eye" IR stream does indeed confirm that the first line, beginning with the switch to ECMA 94 and ending with character 4, is sent while the key is down. If it can send that much, why the beep and delay in sending the rest of the string?

But with the CR command, with the key held down, it just beeps, and the character 4 isn't sent until after the key is released.

Switching to serial IR for printing and using the SRECV command to capture the print stream, the entire string is sent out while the key is held down, and then it beeps if the key is still down when it finishes sending. With the CR command, the line termination string is sent while the key is still down, and then it beeps. Printing by wire to either another calculator's SRECV or an actual serial printer shows the same behavior.

I really doesn't see a reasonable explanation for why it should behave this way. Maybe you've noticed a "bug" that's been in the ROM since the 48SX, but that nobody found objectionable until the 48g+'s extra speed made it so noticeable.

Maybe someone at comp.sys.hp48 has an answer? Should we take this discussion there?

Regards,
James


Possibly Related Threads...
Thread Author Replies Views Last Post
  41CL TURBO anomaly? M. Joury 8 595 05-15-2012, 12:11 PM
Last Post: M. Joury
  OT: Pioneer anomaly Jeroen Van Nieuwenhove 4 369 04-20-2012, 08:35 AM
Last Post: Walter B
  HP-71B, CMT-CR-128K memory module John Pierce 2 247 04-25-2007, 06:29 PM
Last Post: John Pierce
  Re: Porting 49G Programs to 49G+/50G Les Wright 0 218 02-21-2007, 10:16 AM
Last Post: Les Wright
  Porting 49G Programs to 49G+/50G Les Wright 6 578 02-20-2007, 06:27 PM
Last Post: Tim Wessman
  HP41CX Clock Anomaly JaSon 1 201 07-13-2006, 11:04 AM
Last Post: David Smith
  Anomaly with the HP 33s Palmer O. Hanson, Jr. 17 902 03-11-2006, 11:14 PM
Last Post: Karl Schneider
  HP30S Numerical Anomaly Rodger Rosenbaum 0 166 01-22-2006, 12:16 AM
Last Post: Rodger Rosenbaum
  TI-57 Emulator for HP-48S/SX/G/G+/GX, HP-49G and HP-49G+ is finished HrastProgrammer 9 754 01-17-2006, 12:57 AM
Last Post: HrastProgrammer
  HP-35 display anomaly David Ramsey 7 472 07-20-2004, 08:26 PM
Last Post: David Smith

Forum Jump: