# HP Forums

Full Version: Conversion Routine
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
In his three volume publication of Structural Programs for the HP67 programmable calculator, W. L. Ashley (PE) includes a program for FEET-INCHES-SIXTEENTHS arithmetic with a 77 line routine for conversion to (LBL B) and from (LBL A) FEET-DecimalFeet and FEET-INCHES-SixteenthsInches. I developed a similiar but much more compact routine for my Hp calculators when I was employed by an International Bridge Design firm in the early 80's.

The savings in program steps begins with a parallel comparison of the two separate conversion routines, as follows:
[attachment=3706]

which yield a 40 line replacement (if used directly as listed)

BUT

when merged, as follows;
[attachment=3707] error in line 30, see reply #2

yield a 31 line program (less than half the original size).

To use;
Code:
```     FIX 4    set display to SEE sixteenths digits where   FT = Feet         IN = inches         in = sixteenths     with feet left of radix and inches & sixteenths right or radix.         convert FT.ft to FT.INin  (LBL B)     1.5208     GSB B    1.0604    read as 1 foot six and four sixteenths, or one quarter, inches.         convert FT.INin to FT.ft (LBL A)     1.0604     GSB A    1.5208    read as one and five thousand two hundred eight ten-thousanths feet.```
The program is of limited utility BUT illustrates one of the many step-saving techniques so important in the early days of handheld programmables. ENJOY!

BEST!
SlideRule

ps: I would include the 77 line program for the Hp67 if the copyright is waived. The algorithm presented is fairly universal among the early RPNs' but has plenty of opportunity for modification / improvement. Press to Test!
(07-02-2016 02:45 AM)SlideRule Wrote: [ -> ]The savings in program steps begins with a parallel comparison of the two separate conversion routines, as follows:

The 31 step program uses flag 0 which is initially set at LBL A but not cleared at LBL B. However, at the end of the program flag 1 (!) is cleared. I think this is an error. In any case it's good practice to always initialize a flag and not rely on a certain state at program start, e.g. like this:

Code:
```LBL A SF 0 GTO 0 LBL B CF 0 LBL 0 ...```

You say this is a HP67 program, but the keycodes look strange: f and g in the fourth row (that's the one with the ENTER key), flag commands with g prefix and keycodes like 20, 40 or 36. Which calculator does this refer to?

Dieter
(07-02-2016 06:07 AM)Dieter Wrote: [ -> ]The 31 step program uses flag 0 which is initially set at LBL A but not cleared at LBL B. However, at the end of the program flag 1 (!) is cleared. I think this is an error.
Yes, I had a small conversion problem from a real calculator and an emulator. This slipped by me!
Quote:You say this is a HP67 program ... which calculator does this refer to?
Dieter
The program is compared to a 67 program. I understand the inference to keep the base calculator the same but the universality of RPN was also being illustrated so I chose an HP-15LE. I do believe the key sequences will work (not necessarily the key codes) on an HP67, but I leave that to the audience to discover and report in their usual and thorough manner. The listings are from an Excel spreadsheet I use to transfer RPN programs from photocopied sources to a more legible reading.

BEST!
SlideRule

ps: ok here's a 67 listing
[attachment=3708]
(07-02-2016 12:43 PM)SlideRule Wrote: [ -> ]...so I chose an HP-15LE. I do believe the key sequences will work (not necessarily the key codes) on an HP67, but I leave that to the audience to discover and report in their usual and thorough manner.

So let's take a closer look. ;-)

In general the code is fine, but flag 0 still is not initialized. So if the flag happens to be set when the program is run for the first time it will produce wrong results when routine B is called.

(07-02-2016 12:43 PM)SlideRule Wrote: [ -> ]The listings are from an Excel spreadsheet I use to transfer RPN programs from photocopied sources to a more legible reading.
...
ps: ok here's a 67 listing

May I humbly suggest the following version that initializes flag 0 so that both routines will run reliably? This way the CF command at the end may even be omitted.

Code:
```LBL A SF 0 GTO 0 LBL B CF 0 LBL 0 INT STO I EEX 2 ENTER 1 2 F0? X<>Y LASTX FRAC * INT LASTX FRAC . 1 6 F0? 1/x * + RUP / RCL I + RTN```

OK, on a real 67/97 you can record the program with flag 0 cleared so that it is initialized as the card is read. ;-) On the other hand initializing the flag is essential on the 15C as its state is preserved by continuous memory. That's why I suggest an explicit CF 0 at LBL B.

Dieter
(07-04-2016 08:22 PM)Dieter Wrote: [ -> ]May I humbly suggest the following version that initializes flag 0 so that both routines will run reliably? This way the CF command at the end may even be omitted.
Dieter

Sehr gut, danks!

BEST!
SlideRule
Code:
``` … how might one proceed when NO flags are available, say on an HP-33 calculator?     instruction                        input       KEYS    output 1. Key in Program 2. Set Display                                    f FIX 4 3. Decimal Feet to Feet.Inches/16’s    FF.ffff    GSB 01    FF.INin 4. Feet-Inches to Decimal Feet         FF.INin    GSB 17    FF.ffff 5. repeat steps 3 or 4 as needed 00 01  GSB 32 02  1 03  2 04  * 05  GSB 32 06  . 07  1 08  6 09  * 10  + 11  EEX 12  2 13  / 14  + 15  GTO 00 16  R/S 17  GSB 32 18  EEX 19  2 20  * 21  GSB 32 22  . 23  1 24  6 25  / 26  + 27  1 28  2 29  / 30  + 31  GTO 16 32  INT 33  LST x 34  FRC 35  GTO 00```

... advice ... critique ... rebuttal?

ENJOY!!

BEST!
SlideRule
(07-07-2016 01:13 AM)SlideRule Wrote: [ -> ]... advice ... critique ... rebuttal?

There are ways to do this without flags, but I fear these will require as least as much steps as the current solution. ;-)

Anyway – don't you think that the last step of the subroutine...

Code:
```32  INT 33  LST x 34  FRC 35  GTO 00```

...should be a RTN ?
Or does a GTO 00 do the same here?

Dieter
(07-07-2016 05:20 PM)Dieter Wrote: [ -> ]There are ways to do this without flags, but I fear these will require as least as much steps as the current solution. ;-)

Well, it can be done with the same 35 steps and one data register.

Here is a solution without flags. The idea is that decimal feet are positive and ft.inss are negative. So 1.5208 feet are entered and displayed as 1.5208, while for 1 ft, 6 in and 4/16 it's –1.0604. This way the user always knows how to read a result and, as an additional benefit, two separate starting points are not required.

Code:
```01  STO 0 02  EEX 03  2 04  ENTER 05  . 06  1 07  6 08  ENTER 09  1 10  2 11  RCL 0 12  X>0? 13  GTO 21 14  R↓ 15  ENTER 16  R↓ 17  R↓ 18  1/x 19  x<>y 20  RCL 0 21  FRAC 22  * 23  INT 24  x<>y 25  LastX 26  FRAC 27  * 28  + 29  x<>y 30  / 31  RCL 0 32  INT 33  + 34  CHS 35  GTO 00```

Enter the program, set FIX 4 and GTO 00

1,5208 [R/S] => –1,0604 = 1 ft 6 in and 4/16
–1,0604 [R/S] =>  1,5208 = 1,5208 ft

Dieter

Edit: Replaced Rdn in listing with R↓
(07-07-2016 06:33 PM)Dieter Wrote: [ -> ]Well, it can be done with the same 35 steps and one data register. Here is a solution without flags.
Dieter

I LIKE, very creative!

BEST!
SlideRule
(07-07-2016 05:20 PM)Dieter Wrote: [ -> ]Anyway – don't you think that the last step of the subroutine...
Code:
```32  INT 33  LST x 34  FRC 35  GTO 00```
...should be a RTN ?
Or does a GTO 00 do the same here?

Dieter

Dieter

I think I sent the pointer back to the top to facilitate the primary use of this more than 35-years-ago routine: convert FT-IN to decimal feet for SUMMATION, otherwise, I've long since forgotten the reason & neglected to document same in the source document.

Anyway, I greatly enjoy the analysis & perspective of these old utility routines from an era that struggled thru capability & capacity far less than todays' available calculator selection.

Thanks for the second look.

BEST!
SlideRule
(07-08-2016 01:58 PM)SlideRule Wrote: [ -> ]I think I sent the pointer back to the top to facilitate the primary use of this more than 35-years-ago routine:

Sure, ending a program with GTO 00 is a good idea as the next R/S will start the program from the beginning. But in this case we are talking about a subroutine call: There are several occurences of GSB 32 which calls line 32 and then is supposed to return to the calling program with a RTN. Ending this subroutine with GTO 00 just stops the program at this point. Which of course will yield strange results.

Have you tried this code on a real HP-33C/E? I did so on the Panamatic 33E emulator. Indeed GTO 00 does not work while everything is fine with a final RTN.

Dieter
(07-08-2016 06:32 PM)Dieter Wrote: [ -> ]Have you tried this code on a real HP-33C/E? I did so on the Panamatic 33E emulator.
Dieter

Dieter

ALL my first print code comes from printed archives; documentation I retained from work projects. I have NO reason to assume this documentation is in error, that's why I retained the code - I used it, once upon a time ago. However, I DO NOT routinely use simulators / emulators designed for computers, so, I can't say.

Once, I did submit a MASTERMIND program for the HP-25. I KNOW it worked as recorded, yet would NOT run as advertised on an emulator. For this ONE program I modified the original to run on a specific emulator (similar issue with branching instruction).

I wait in anticipation for another to answer your query on this archive from the past.

BEST!
Sliderule
(07-08-2016 06:32 PM)Dieter Wrote: [ -> ]Have you tried this code on a real HP-33C/E? I did so on the Panamatic 33E emulator. Indeed GTO 00 does not work while everything is fine with a final RTN.
Dieter

Dieter

Entschuldigen mir! I misread your reply concerning the RTN & GTO 00 keystrokes. YES, there is a missing RTN prior to the string of GTO 00's that pad out the program memory. Your observations are appreciated, danks!

BEST!
SlideRule
Reference URL's
• HP Forums: https://www.hpmuseum.org/forum/index.php
• :