HP Forums

I recently obtained a navigation module for the HP 41CX calculator. It seems to be working but majority of the functions end up giving a NONEXISTENT read out instead of the answer. I do not have a printer, and I have tried playing with Flag 21 with no success.

Is there a problem with this module? Or am I missing something? I have tried all the steps given in the manual.

Any insight will be greatly appreciated.

Thanks

Can you give us an example with sample data (preferably from the manual) that results in this error message? I will then try it on my P41CX for Palm as I do not have the real module for my 41C.

Jeff

Sounds like you don't have enough numeric registers. The Nav pac manual says you need at least SIZE 054. If you do STO 54 and get NONEXISTENT that's your problem.

I think I know the problem. This could be a major bug in this module or maybe it is broken, which I hightly doubt.

The manual says there should be a JD program, but there is no JD function, rather a JF program.

Second and more importantly, there is a FUNCTION call in the programs that display NONEXISTENT which is branching to *SRT function, however, there in no *SRT function in the catalog of the module. There is a SRT program in the module, and even this program itself has some bugs as the prompts should be L=? and D=?, I get N?? an F?? instead, respectively. Then the SRT program gives a NONEXISTENT display on the following line:

10 T Jc?

Whatever that means?

Basically all GREAT-CIRCLE programs and functions that branch to the SRT (Sight Reduction Table) get hosed with the NONEXISTENT displayed.

The Module is HP00041-14028 NAVIGATION.

Does anyone know how to open one of these modules?

Thanks

Muhammad

I have an HP-41 Navigation module, and have used the Great Circle program to calculate points on a great circle at specific longitudes with no problem. The Navigation module is one of a few 8K modules that HP produced, the significant majority were 4K. I am not an expert on the inner workings of HP modules, but if half (4K) of the module malfunctioned, you'd likely get some of the behavior you mention. I've never opened up one of these modules myself, but have heard of many doing it.

Is your module's part number different?

Thanks

The JD routine calculates the "Julian Day" number which is used by astronomers to avoid using dates like July 18, 1934. The SRT is the "Sight Reduction Table" used to develop a position. Both are required. If your module does not have them the NAVPAC cannot do its job. I have no idea what "10 T Jc?" means. I believe your module is probably defective.

Quote:

---

I have no idea what "10 T Jc?" means.

---

Hi,

I mostly open the modules by gently (but firmly) prying both sides of the contact slot apart with a flat nose pliers. Some other methods have been described elsewhere.

However, and according to your description of the malfunction, there is very little (if any) thing you can do.

Here is what you'll find when you take a module apart.

Image of a Math 1-B open module. All HP ROM PAC's use the same base PCB, which allows up to three chips to be welded (12K).

The "NO SERVICEABLE PARTS INSIDE" warning is fully applicable.

Not much of a help here, sorry.

Best from Spain.

Diego.

Hi Garth, You are probably right on your interpretation. I haven't used the HP41 in quite a while and no longer own one. I was able to respond to the question because I do have the program listings for the NAV Module.

Where can I get a listing for the NAV module?

Thanks

Thanks for the info.

Do you have any information on how the ROM data is transfered to the main computer. Is it serial or in parallel. From the number of lines I would think it is serial.

The strange part is that other functions and programs that do not use the SRT function work just fine.

I got out my module and here is what I can share:

The part number on my module is HP 00041 - 14028. Made in Singapore. "Navigation" is printed on the end. The serial number is 8726 (26th week of 1987). When I do a CAT 2, the header function is "NAVIG 1B". There are 61 entries in the catalog (besides the header) consisting of all user code programs, no machine code functions.

Flag 21 should have no effect on this problem, having it set versus clear will not normally cause a "NONEXISTENT" error.

Insufficient register allocation could, but if you have at least a size of 54, there is not a problem there. (By the way Randy, if you do a "SIZE 054", and then "STO 54", you will get a 'NONEXISTENT' error. The correct test is "STO 53". You forgot about register 00. ;-) )

In my module, there is a "JD" program, but there is no "JT" program, and I don't see one mentioned in the manual. If your module shows a "JT" program, that is definitely a problem.

There is a "*SRT" program in the module (or there is in mine, and it is supposed to be there in every module).

There is also an "SRT" program. An interesting thing that you can look at is; the Label "SRT" is line 001 of the program that it is in. Label "*SRT" is in line 017 of that same program. And line 10 of that program (where you have "10 T Jc?" is supposed to be "10 THc=" or more appropriately "'Hc=", where the T or the ' is the small text symbol that is elevated, and signifies a text entry line for the HP-41.

And in answer to your question about how the ROM data is transferred to the HP-41: The HP-41 ROM 'byte', or more appropriately 'word', is 10 bits long, not 8. And yes, a look at the connector count between the calculator and the module would indicate that the data is clocked out serially from tne module to the processor of the calculator. User code program instructions are limited to 8 bits, the extra two go essentially unused. But the HP-41 processor uses a 10 bit instruction set, and uses all 10 bits of the ROM word to store M-Code (micro-code) which is the progamming language used for the calculator functions.

Bottom line: unless your HP-41 has a serious problem (I would not rule that out without testing the Navigation module in a second HP-41) your Navigation module is hosed; irreversibly. I hope that you did not just buy this from someone else.

Edited: 9 July 2008, 11:30 p.m.

Thank you very much for your detailed response. I got this module with the purchase of an HP-41CX, and the seller had mentioned that he had never gotten the module to work for him. I do not know where he got it.

Just out of curiosity, can these ROMs go bad? It seems to me that the module is defective in that there are certain parts of the ROM that are spitting out garbage data. I have confirmed that if I enter the *SRT function in the program memory, the Great Circle programs work correctly. Similarly, when I entered the JD program manually, the other programs that depend on it work OK too.

OR maybe this module is a boot leg version???

Thanks you all for the great insight into this.

I've never had a module go bad, but HP seemed to think it was possible. From the Navigation Module manual:

"CAUTION Always turn off the HP-41 off before inserting or removing any plug-in extension or accessories. Failure to turn the HP-41 off could damage both the calculator and the accessory." This warning is repeated two more times in the same section of the manual. There still is a very slight possibility the problems could be related to the calculator. I wouldn't toss the module until it was tried in another HP-41.

I doubt that it is a 'bootleg' version since it appears to be labelled properly with part number and module name. If the module was blank or the labelling was inconsistent with HP's, then it would be suspect.

Hi,

As it has been stated before, communication between HP-41 and its peripherals is done serially.

Regarding the possibility of a ROM PAC module failure, it is certainly very rare, but it happens.

Most common failure comes from the fact that one of the lines of said serial interface gets broken either in the connector-to-PCB solder (which can be fixed) or inside the module itself (tiny golden wire jumpers that connect the PCB pads to the silicon chip) these micro wires are covered by the expoxy "bloob" thus the cannot be reached or repaired by any *conventional* method. In both cases the module does nothing at all when plugged into any port. I've come across a few of these failures.

The other, less common, failure comes from the mask ROM silicon chip (and this seems like if it is your case). Some portions of the code does not perform as expected and CAT 2 shows inconsistent or different function list to what it's supposed to show.

So far I have only found one module with such a behaviour, and I still have it: a TIMER module. There's no cure for this either.

Again not much help but hope this clarifies the issue a little bit.

Best regards.

Diego.

Quote:

---

I've never had a module go bad, but HP seemed to think it was possible. From the Navigation Module manual:

"CAUTION Always turn off the HP-41 off before inserting or removing any plug-in extension or accessories. Failure to turn the HP-41 off could damage both the calculator and the accessory." This warning is repeated two more times in the same section of the manual.

---

It is the ROM that has a portion of it that is bad.  It seems their is a stuck bit in the data retrieved from the ROM in a particular address range.  Their is definitely a pattern to this:

Begins in the 05 instruction of SRT program, only bad listed here

GOOD CODE               BAD CODE

05 T L=?                05 T N??         L is N and = is ? off by 2

07 T D=?                07 T F??         D is F and = is ? off by 2

09 XEQ T *SRT           09 XEQ T *SRV%N  T is N and additional chars*

10 T Hc=                10 T Jc?         H is J and = is ?

13 T ZN=                13 T ZN?         = is ?

16 RTN                  16 CLA           Totally different Instruction

17 LBL T *SRT           17 LBL T *SRV%N  

18 1                    18 3

20 R/                   20 LASTX

21 X<>Y                 21 CLST

23 R/                   23 LASTX

24 STO 00               24 STO 02

25 X<>Y                 25 CLST

27 X<> 00               27 X<> 02

28 R/                   28 LASTX

30 X<> 00               30 X<> 02

31 +                    31 *

32 X<> 00               32 X<> 02

33 -                    33 /

35 RDN                  35 CLX

36 180                  36 3.2

37 +                    37 *

38 RCL 00               38 RCL 02

39 ASIN                 39 ATAN

* the % sign represents a char in which ALL segments of digit are on!

Then the bad code continues into the JD program which is too long to list here.  First the label is JF so the D is F instead.

Any clues to which of the bits is stuck?

Thanks

Edited: 12 July 2008, 5:43 p.m. after one or more responses were posted

Quote:

---

Too see the GOOD and BAD code side by side you may have to click the Edit button

---

HTH

Raymond

I used to engineer the manufacture of Dynamic RAM memory chips. This looks like a row (or column )failure. Memory is manufactured in blocks, with each bit within a block at a specific row and column address, as on a grid. At the end of each row, there is a component that reads the bit. If that component is damaged, it will read every bit in that row as either off or on, depending on the design of the chip and the nature of the damage. Along the columns is typically the transistor that tells the column of bits to read their answer out on their respective rows. If this transister is bad, then the bits don't read out, and the answers are all just on or off, instead of the actual data. Because of the nature of your data damage, it appears that one row or column is defective, which will affect bits in a 'patterned' way, for a segment of the memory.