Easiest groups/lineages of machines to port software between?

[Dave Britten]

What programmable calculators have the advantage of being able to run programs written for previous or lesser-equipped contemporaries with little or no software changes required?

For instance, you could forward port something from the 41C to a 41CX or 41CV, and probably a 42S if external hardware or the clock isn't needed, and I think 11C to 15C would be a relatively easy conversion as well.

What about the 67? Does that translate forward to anything easily? (Excepting the hardware assistance from the card reader for the 41C.)

Then there's the 32S family, with a rather different approach to labels and register naming, so there's usually a good amount of overhaul to bring something over, but going from 32S to 32Sii to 33S to 35S is relatively painless.

And in TI land, you can go from the 58C to the 59 with no changes, and also to the 66 if the program doesn't use any ROM modules, and you can adapt any printer usage (watch out for the CE behavior difference though). But the 66 doesn't have enough memory to handle large 59 programs, nor does it have a card reader.

What other porting family trees are there? Mostly I want to have an idea what I've got the best shot of running something on if I find an interesting program on the museum DVDs or elsewhere.

[Paul Dale]

The 34C would go to the 15C in a straightforward manner. What about the 25 to the 33E or 33C?

The 34S was designed to just about run 42S (and hence 41C) programs as is. It isn't quite there but it is close. We changed the bitwise operations (for the better I think) which broke easy compatibility with the 16C. It should also run 34C, 11C programs as is and 15C programs that avoid some matrix operations.


- Pauli

[Csaba Tizedes]

(05-10-2015 09:17 PM)Dave Britten Wrote:  going from 32Sii to 35S is relatively painless.

I have a hydrostatics example where the program code totally same for the two calculator and the 32Sii can to SOLVE that program and after few seconds gives a result but 35s can't.

[Dave Britten]

(05-10-2015 10:13 PM)Csaba Tizedes Wrote:  

(05-10-2015 09:17 PM)Dave Britten Wrote:  going from 32Sii to 35S is relatively painless.

I have a hydrostatics example where the program code totally same for the two calculator and the 32Sii can to SOLVE that program and after few seconds gives a result but 35s can't.

Now that's interesting, though I guess not totally surprising, given all the other, let's say, "quirks" of the 35S.

And I forgot that the 35S changed the indirection register setup, so there's a potential incompatibility.

[Dieter]

(05-10-2015 10:13 PM)Csaba Tizedes Wrote:  I have a hydrostatics example where the program code totally same for the two calculator and the 32Sii can to SOLVE that program and after few seconds gives a result but 35s can't.

Then obviously the 35s program contains an error. There are some significant differences between these two calculators, so 32s code may not work on the 35s and 35s code may not work on the 32s. For instance the 35s supports direct line addressing while the 32s doesn't.

If you post the 35s program here I'm sure the error will be found.

(05-10-2015 10:29 PM)Dave Britten Wrote:  Now that's interesting, though I guess not totally surprising, given all the other, let's say, "quirks" of the 35S.

And I forgot that the 35S changed the indirection register setup, so there's a potential incompatibility.

The mentioned problem most probably is not due to a "quirk" in the 35s. Indeed there are significant differences that make both less than 100% compatible. Using indirection is just one example: the 32s uses positive indices to address the variables A–Z. Which is ok due to its limited memory. The 35s uses the same indices for its huge extended memory (800+ variables), while the variables A–Z are addressed by negative indices.

Dieter

[TASP]

For purposes of this thread would the 41/71 translator module for the 71 be considered cheating?



I have the module, but have never used it.

[Dave Britten]

(05-13-2015 01:00 PM)Dieter Wrote:  The mentioned problem most probably is not due to a "quirk" in the 35s. Indeed there are significant differences that make both less than 100% compatible. Using indirection is just one example: the 32s uses positive indices to address the variables A–Z. Which is ok due to its limited memory. The 35s uses the same indices for its huge extended memory (800+ variables), while the variables A–Z are addressed by negative indices.

I wouldn't be so sure without seeing the program. I was reading the 35S bug list yesterday, and it mentioned the silver going into an infinite loop with certain programs containing looping. This could be one of those cases. Would have to see the code to tell, of course.

(05-13-2015 01:47 PM)TASP Wrote:  For purposes of this thread would the 41/71 translator module for the 71 be considered cheating?



I have the module, but have never used it.

Yes, but still worth mentioning. Impressive that it could convert RPN keystroke programs to BASIC.

[Jake Schwartz]

(05-13-2015 01:55 PM)Dave Britten Wrote:  Yes, but still worth mentioning. Impressive that it could convert RPN keystroke programs to BASIC.

I think you may have it backwards - HP41 programs were able to be run on the 71B but conversion to BASIC was not involved.

Jake

[Dave Britten]

(05-13-2015 07:01 PM)Jake Schwartz Wrote:  

(05-13-2015 01:55 PM)Dave Britten Wrote:  Yes, but still worth mentioning. Impressive that it could convert RPN keystroke programs to BASIC.

I think you may have it backwards - HP41 programs were able to be run on the 71B but conversion to BASIC was not involved.

Jake

Oh, so it's not like the 41C card reader that would convert 67 programs on the fly? Was it a bytecode interpreter, or would it convert them to actual 71 machine code that could be run independently?

[HrastProgrammer]

(05-13-2015 09:37 PM)Dave Britten Wrote:  Was it a bytecode interpreter, or would it convert them to actual 71 machine code that could be run independently?

It's FORTH, actually. There is a separate HP-41 environment where you can execute most HP-41 functions/instructions + you also have FORTH here. It is not an emulator at CPU level - no synthetic programming etc., just the regular HP-41 code.

[Csaba Tizedes]

(05-13-2015 01:00 PM)Dieter Wrote:  If you post the 35s program here I'm sure the error will be found.

Sorry for the long time delaying, now I have a little time to post this short article about that hydrostatics example - only for Hungarian, but I think it's not a big issue to translate the text to English.

This is an example of a centrifugal process of air. What is the required rotation speed (omega in rad/s) if we want to produce pressure at the (A) point 200'000 Pa. The temperature is constant.

In the paper you can found an analitycal solution, an Euler method and a Predictor-Corrector method also.

For SOLVING program I you need to set variable H, which is a distance step and according to your distance step selection the number of divisions in program line I06.

If you have any question, I'll try to answer

Try to use these programs on 32SII and on 35s. The 32SII will produce the right result and 35s can not.

The link:
https://drive.google.com/file/d/0B1AqWV7...sp=sharing


Csaba

[Csaba Tizedes]

(05-13-2015 01:00 PM)Dieter Wrote:  Then obviously the 35s program contains an error. If you post the 35s program here I'm sure the error will be found.

So, Dieter, what is your opinion? (Don't afraid from Hungarian sentences, try to imagine you're in Los Alamos during WWII.)

As you can see, no direct GTO, no indirect addressing, only a simple Euler method with SOLVE.
I think it's a real bug in the SOLVE routine, therefore the real question is that what is the solution if I want to use my calc for these type problem solving? With this bug this calculator is useless when I try to solve more complex examples than "A+B=C".

Csaba

[Thomas Klemm]

(05-10-2015 10:13 PM)Csaba Tizedes Wrote:  I have a hydrostatics example where the program code totally same for the two calculator and the 32Sii can to SOLVE that program and after few seconds gives a result but 35s can't.

(05-29-2015 09:14 AM)Csaba Tizedes Wrote:  Try to use these programs on 32SII and on 35s. The 32SII will produce the right result and 35s can not.

The link:
https://drive.google.com/file/d/0B1AqWV7...sp=sharing

This can reproduced with a simpler program:

Code:

I001 LBL I
I002 INPUT F
I003 INPUT O
I003 1.001
I004 STO I
I005 0
G001 LBL G
G002 RCL+ 0
G003 ISG I
G004 GTO G001
G004 RCL- F
G005 RTN

You can test the program with:

XEQ I ENTER
F? 140 R/S
0? 100 R/S
-40

To solve for O you can run:

FN= I
100 STO O
200 SOLVE 0
F? 140 R/S

After this the calculator just displays:

SOLVING

The solver returns immediately with the correct result when lines G003-G004 are removed:

O=140


Cheers
Thomas

[Thomas Klemm]

This program is a little shorter:

Code:

F001 LBL F
F002 1
F003 STO K
F004 RCL A
F005 RCL- X
F006 DSE K
F007 GTO F005
F008 RTN

To test the program you can use:

140 STO A
100 STO X
XEG F ENTER


This should return:

40


Use the solver to solve \(a-k\cdot x=0\) for x:

FN= F
SOLVE X


The calculator hangs and just displays:

SOLVING


Cheers
Thomas

[Thomas Klemm]

From item 20 of the HP-35s bug list:

Quote:Solve infinite loops for some program based functions. Assign FN=D and SOLVE the following for X. The solve doesn't finish. This seems to be related to using a loop in the function being solved.

Code:

D001 LBL D
D002 10
D003 STO N
D004 DSE N
D005 GTO D004
D006 RCL X
D007 COS
D008 RTN

A workaround for this is to include an always false conditional after any INPUT statements with a RTN instruction and a STOP. For example:

Code:

B001 LBL B
B002 INPUT T
B003 INPUT X
B004 CF 1
B005 FS? 1
B006 RTN
B007 FS? 1
B008 XEQ C001
B009 0.2xX-T
B010 RTN
C001 LBL C
C002 STOP
C003 RTN

Not sure how this workaround should be applied to the example above.

Cheers
Thomas

[Dieter]

(05-30-2015 06:22 AM)Csaba Tizedes Wrote:  So, Dieter, what is your opinion?

Your problem is caused by a bug in the 35s solver. It simply does not solve programs with loops. #-\

In this way the 35s solver is different from all other HP solvers I know of. I cannot imagine this behaviour was intended, so I would call it a bug

(05-30-2015 06:22 AM)Csaba Tizedes Wrote:  I think it's a real bug in the SOLVE routine, therefore the real question is that what is the solution if I want to use my calc for these type problem solving? With this bug this calculator is useless when I try to solve more complex examples than "A+B=C".

The solver itself is quite powerful. In equation mode it can even solve simple equations symbolically (if the desired variable appears only once). But indeed it has this limitation: no loops, no DSE, no ISG.

Dieter