The Museum of HP Calculators

HP Forum Archive 21

[ Return to Index | Top of Index ]

Where should I post new HP35s bugs
Message #1 Posted by Andres Capdevila on 9 Mar 2012, 6:55 p.m.

Well, this is probably not new but I was not aware of it before...

In indirect addressing mode (I) or (J), if the program stores 0 in the register 55 or higher and then when it tries to recall it, it shows Invalid(I) or Invalid(J).

Example:

LBL D

55

STO I

0

STO(I)

RCL(I)

If I replace the 55 with a lower number then it's fine or if I replace 0 with any other number then it's also okay.

Does this bring any bell?

Thank you.





      
Re: Where should I post new HP35s bugs
Message #2 Posted by bill platt on 9 Mar 2012, 8:40 p.m.,
in response to message #1 by Andres Capdevila

Posting as did is just fine.

Paul has been keeping a comprehensive list here: http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=735

      
Re: Where should I post new HP35s bugs
Message #3 Posted by Paul Dale on 9 Mar 2012, 10:25 p.m.,
in response to message #1 by Andres Capdevila

Is this a bug? Try storing a non-zero number there? Does that work?

What is in register 54 on your device?

After storing 0 in register 55, does doing the same with register 54 produce the error?

The 35S deallocates the highest numbered registers if they contain zero & I'm guessing this is what is happening here.

- Pauli

      
Re: Where should I post new HP35s bugs
Message #4 Posted by Matt Agajanian on 9 Mar 2012, 11:06 p.m.,
in response to message #1 by Andres Capdevila

Is there a workaround?

            
Re: Where should I post new HP35s bugs
Message #5 Posted by Kiyoshi Akima on 10 Mar 2012, 12:50 a.m.,
in response to message #4 by Matt Agajanian

Quote:
Is there a workaround?
Store a non-zero value in a register numbered higher than 55. Storing a zero in a register only deallocates registers if no higher-numbered register contains a non-zero value.
                  
Re: Where should I post new HP35s bugs
Message #6 Posted by Matt Agajanian on 10 Mar 2012, 8:51 a.m.,
in response to message #5 by Kiyoshi Akima

This confirms what I was experimenting with last night. I took the base code and I experimented with several variations between changing the '55' value and the '0' value. I changed both or either of these numbers in various combinations: reg>55, val<>0; reg<55, val<0, reg>55, val>0, etc. And yes, I did notice that when a non-zero quantity for 'val' was involved, I was allowed access to the higher registers.

            
Re: Where should I post new HP35s bugs
Message #7 Posted by Bart (UK) on 10 Mar 2012, 10:21 a.m.,
in response to message #4 by Matt Agajanian

I do not see what the problem is in the first place. From p14-24 of the manual:

Quote:
The calculator allocates memory for variable 0 to the last non-zero variable. It is important to store 0 in variables after using them in order to release the memory.
The training module on using the HP-35s Indirect Registers, it states it more clearly:
Quote:
If the highest used register is cleared or has a zero stored into it, the allocation will shrink down to the next highest non-zero indirect register.
If you need to work with 0 values in indirect registers, then allocate a non-0 value to your highest required register + 1 (just store 0 in it at the end of your program to release the memory).
                  
Re: Where should I post new HP35s bugs
Message #8 Posted by Andres Capdevila on 10 Mar 2012, 10:41 a.m.,
in response to message #7 by Bart (UK)

Thank you Bart for the clarification, it makes sense now.

I appreciate the inputs received from everybody.

                  
Re: Where should I post new HP35s bugs
Message #9 Posted by Matt Agajanian on 10 Mar 2012, 11:09 a.m.,
in response to message #7 by Bart (UK)

SO, the questions become:

1--how do you find the highest register available at the time so that you can store a non-zero value in the n+1th register that you set at the max register?

2--if the highest register you want to use is not accessible (already has been de-allocated), how do you reset the availability of all registers so that you can set your max+1th register by placing a non-zero value there?

                        
Re: Where should I post new HP35s bugs
Message #10 Posted by Marcus von Cube, Germany on 10 Mar 2012, 12:13 p.m.,
in response to message #9 by Matt Agajanian

You can store a non-zero value any time in any register. This will create the necessary allocation for the register and all lower numbered registers. You normally should know how many registers your program will need. Just allocate one more as the "curtain" by storing a 1 into it. De-allocating can be done with the clear command.

                              
Re: Where should I post new HP35s bugs
Message #11 Posted by BruceH on 11 Mar 2012, 6:10 a.m.,
in response to message #10 by Marcus von Cube, Germany

Would it break anything if RCL from an unallocated register returned zero instead of invalid j?

                                    
Re: Where should I post new HP35s bugs
Message #12 Posted by Paul Dale on 11 Mar 2012, 6:39 a.m.,
in response to message #11 by BruceH

I doubt it.

- Pauli

                        
Re: Where should I post new HP35s bugs
Message #13 Posted by Bart (UK) on 10 Mar 2012, 2:40 p.m.,
in response to message #9 by Matt Agajanian

Quote:
1--how do you find the highest register available at the time so that you can store a non-zero value in the n+1th register that you set at the max register?
Let's say my program has just started using the nth indirect register, which may contain a 0 at some time - and I wish to be able to recall that 0.

...
nth register allocated, now allocate n+1th register: 
1
STO+ I
STO (I)
STO- I
Rv
Notes:
  • Line numbers omitted
  • assumes I was used to reference indirect registers
  • increments and decrements I so that eventual reference doesn't change
  • Rv is roll down and restores the X-register present before incrementing I
  • uses one stack register
  • you can manually clear all indirects after the program finishes



Quote:
2--if the highest register you want to use is not accessible (already has been de-allocated), how do you reset the availability of all registers so that you can set your max+1th register by placing a non-zero value there?
Seeing that as in the text above, the register that is one higher than which you want to use is allocated with a non-0 value, it should not be a problem. Remember that when an indirect register is allocated, all lower registers are automatically allocated too - this means memory management as I stated here.

Edit:
edited to correct spelling.

Edited: 10 Mar 2012, 2:44 p.m.

                              
Re: Where should I post new HP35s bugs
Message #14 Posted by Marcus von Cube, Germany on 10 Mar 2012, 2:50 p.m.,
in response to message #13 by Bart (UK)

Normally you should know in advance how many registers to allocate and can do it once for the whole program. For a polynomial of degree N you will need (N+1) registers for the coefficients. In this case you even know that the highest coefficient can't be zero so it's just a matter of how you store the coefficients: just assign the highest coefficient to the highest indirect register and you are done.

      
Re: Where should I post new HP35s bugs
Message #15 Posted by Andres Capdevila on 10 Mar 2012, 11:03 a.m.,
in response to message #1 by Andres Capdevila

Then I was playing with SOLVE and found this very odd behavior, maybe someone can explain it...

If I try to SOLVE this program everything works as expected: Example 1 (no problem here):

D001 LBL D

D002 10

D003 STO N

D004 DSE N

D005 GTO D006

D006 RCL X

D007 COS

D008 RTN

And I assign this to FN=D and finally SOLVE X, then no problem. However if instead of jumping forward (line D005) I jump backward the calculator displays "SOLVING" for ever until I hit R/S or C: Example 2 (problem when try to SOLVE):

D001 LBL D

D002 10

D003 STO N

D004 DSE N

D005 GTO D004

D006 RCL X

D007 COS

D008 RTN

Running this simple program outside SOLVE returns the expected result.

Both tests on the HP41 with the Advantage module work fine.

Am I doing something wrong, a bug, or a "feature"?

Thanks in advance.

            
Re: Where should I post new HP35s bugs
Message #16 Posted by Paul Dale on 10 Mar 2012, 7:56 p.m.,
in response to message #15 by Andres Capdevila

Seems like a bug to me. Once someone confirms this, I'll add it to the list.

- Pauli

                  
Re: Where should I post new HP35s bugs
Message #17 Posted by Andres Capdevila on 11 Mar 2012, 8:32 a.m.,
in response to message #16 by Paul Dale

Hi Pauli,

I've seen this person complaining about the same issue:

http://compgroups.net/comp.sys.hp48/HP35s-solving-functions-in-user-programs

Thank you!

Andres.-

                        
Re: Where should I post new HP35s bugs
Message #18 Posted by Paul Dale on 13 Mar 2012, 5:20 p.m.,
in response to message #17 by Andres Capdevila

That's good enough for me. Added as a bug.

I really do wonder why people still bother enough with this lemon of a calculator to keep uncovering its flaws.

- Pauli

                              
Re: Where should I post new HP35s bugs
Message #19 Posted by Andres Capdevila on 15 Mar 2012, 3:05 p.m.,
in response to message #18 by Paul Dale

Haha! that's a good question... I was trying to port some programs from my old 41.... but I gave up now and getting the promising WP34S, I think it's going to get here this Saturday! BTW, even when I haven't experienced it yet, I can tell that you have done a tremendous job, congratulations to you and all the other contributors.

Andres.-

                              
Re: Where should I post new HP35s bugs
Message #20 Posted by Alexander Oestert on 16 Mar 2012, 4:33 a.m.,
in response to message #18 by Paul Dale

Quote:

why people still bother

Easy: Because it is the best looking calculator in portrait version that HP ever made and it does everything I need in daily use, none of the bugs ever bothers me while doing basic programming and checking my high school kid`s homework.

                                    
Re: Where should I post new HP35s bugs
Message #21 Posted by Andres Capdevila on 16 Mar 2012, 11:10 a.m.,
in response to message #20 by Alexander Oestert

It has a "sexy" design indeed, too bad it has no flash memory and any PC connectivity or flash card slot to be able to load new FW versions and for long term memory for programs and data.

                                          
Re: Where should I post new HP35s bugs
Message #22 Posted by bill platt on 16 Mar 2012, 12:39 p.m.,
in response to message #21 by Andres Capdevila

It can't have I/O because it has a specific target marchet which bans that.

For I/O, go to the 50G...I know, I know, too bad there isn't a small I/O machine. Perhaps someday they will make a small I/O machine. Maybe the 30b platform will go this direction.

                                                
Re: Where should I post new HP35s bugs
Message #23 Posted by Marcus von Cube, Germany on 16 Mar 2012, 1:06 p.m.,
in response to message #22 by bill platt

Bill, there is a version of the 30b with I/O. It's just not running the original firmware. :-)

                                                      
Re: Where should I post new HP35s bugs
Message #24 Posted by bill platt on 16 Mar 2012, 1:07 p.m.,
in response to message #23 by Marcus von Cube, Germany

That's what I suspected. But is that I/O a "stock" feature of the WP34s or is it another project?

                                                            
Re: WP 34S I/O
Message #25 Posted by Marcus von Cube, Germany on 16 Mar 2012, 1:38 p.m.,
in response to message #24 by bill platt

I/O is an integral part of the design. You can write programs on your PC (with an editor), compile it, test it on the emulator, and then send it to the calculator through the same cable used for flashing the firmware. Programs written on the device can be sent back to the emulator and even disassembled to a text file for archiving, sharing, and for further development.

                                                                  
Re: WP 34S I/O
Message #26 Posted by bill platt on 16 Mar 2012, 2:08 p.m.,
in response to message #25 by Marcus von Cube, Germany

Holy cow, I hadn't noticed this! If this is an easy and painless interface, then that is TERRIFIC!

One of

                                                                        
Re: WP 34S I/O
Message #27 Posted by Walter B on 16 Mar 2012, 3:08 p.m.,
in response to message #26 by bill platt

The holy cow must have eaten your third sentence ;-) Yes, the WP 34S contains everything we always wanted to have and the HW of the 30b allows. d:-)

                                                                              
Re: WP 34S I/O
Message #28 Posted by Marcus von Cube, Germany on 16 Mar 2012, 7:24 p.m.,
in response to message #27 by Walter B

WP 34S is the intersection of two sets: { whishes } and { possibilities }. :-)

                                                                                    
Re: WP 34S I/O
Message #29 Posted by fhub on 16 Mar 2012, 7:28 p.m.,
in response to message #28 by Marcus von Cube, Germany

Quote:
WP 34S is the intersection of two sets: { whishes } and { possibilities }. :-)
'union' of both would still be better than 'intersection'. ;-)
                                                                                          
Re: WP 34S I/O
Message #30 Posted by Paul Dale on 16 Mar 2012, 7:39 p.m.,
in response to message #29 by fhub

Once we figure out the impossibilities we'll give it a try :-)

- Pauli

                                                                                          
Re: WP 34S I/O
Message #31 Posted by Marcus von Cube, Germany on 16 Mar 2012, 7:41 p.m.,
in response to message #29 by fhub

Sorry, Franz, but { possibilities } was an unsurmountable constraint. { whishes } includes many aspects not contained in { possibilities } such as more memory to handle tagged objects like in the RPL machines or a better display for more readable fonts and a more elaborate user interface. I have the feeling we went pretty far given the contents of { possibilities } but at some point we just had to give up. :-(

                              
Re: Where should I post new HP35s bugs
Message #32 Posted by Andres Capdevila on 16 Mar 2012, 9:28 p.m.,
in response to message #18 by Paul Dale

Sorry for being a pain... I observed the same bug integrating a "program". Therefore no jump backward possible in a program if you expect to integrate it... I'll put it away now, I promise!!!

      
Re: Where should I post new HP35s bugs
Message #33 Posted by Gabor Czvikovszky on 13 Mar 2012, 10:46 a.m.,
in response to message #1 by Andres Capdevila

Hello,

This is not related to the bugs. I am new here and this was the first article related to the HP35s. I have a question: Is there any way to attach caracters to a LBL or variable that are visible (to indentify them later easier)?

Thanks

Gabe

            
Re: Where should I post new HP35s bugs
Message #34 Posted by Jeff O. on 13 Mar 2012, 1:00 p.m.,
in response to message #33 by Gabor Czvikovszky

There is no direct way to attach characters to a label or variable with the 35s. You can use equations to provide prompts or reminders of the program, for example.

A001 LBL A
A002 SF 10
A003 QUADRATIC (entered as an equation, i.e., press EQN first then type it in)
A004 PSE
A005 CF 10
...

The above assumes you have a program you would like to label "QUADRATIC". When viewing the program listing, it will be there to tell you what the program is. When run, the program will pause, display QUADRATIC briefly then continue. Similar messages can be used to tell you what variables are going into what registers.

Sorry if you are well aware of the above.

Edited: 13 Mar 2012, 1:54 p.m.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall