The Museum of HP Calculators

HP Forum Archive 16

[ Return to Index | Top of Index ]

TESTP returns BAD with 82242A IR Printer Module
Message #1 Posted by Les Wright on 17 Jan 2007, 9:38 p.m.

I am using my newly acquired IR module with both a CV and CX and a 82240B printer. I have fresh batteries in both printer and calculators and I know the printer works properly with my other compatible calculators (42S, 48G, 49G+, 28S).

At first the module seemed to be behaving as expected--PRPLOT works correctly, and interim calculations are displayed with TRACE mode.

But when I try to print programs (PRP), the stack (PRSTK), or registers (PRREG), for example, the system seems to hang for a few seconds and the calculator stops with PRINT ERROR in the display.

On referring to the manual, I learn pretty quickly this is not good. I try the RESETP command as instructed, to no avail.

Finally, with trepidation, I execute the TESTP command, and the result returned is BAD.

The manual doesn't say much about this, other than indicating that the module needs service. But what possible could be serviced in these things, and who would do it after all these years?

If anyone can give me some insight about this I would be grateful. The module was sold as "like new", and indeed it looks pristine. I paid a goodly amount for it and wonder what can be done to restore it to full functionality.

Les

Edited: 17 Jan 2007, 9:39 p.m.

      
Re: TESTP returns BAD with 82242A IR Printer Module
Message #2 Posted by Les Wright on 17 Jan 2007, 10:16 p.m.,
in response to message #1 by Les Wright

I have another question: Much of the module's intact functionality is of use to me--PRX, PRA, proper behaviour with VIEW and AVIEW, proper behaviour in TRACE and NORM mode in showing interim steps--so I could see my way to keep it for its partial usefulness (I may try to negotiate a partial rebate from the seller). However, if it tests BAD, is it harmful to run any functions out of it? Does its presence pose a threat to the calculator or other peripherals hooked to the calculator?

Les

      
Re: TESTP returns BAD with 82242A IR Printer Module
Message #3 Posted by Eric Smith on 17 Jan 2007, 11:03 p.m.,
in response to message #1 by Les Wright

"Service" meant sending it to HP, whereupon they destroyed it and sent you a new one. Since it's out of the service life, that service is no longer available.

Most likely a result of "BAD" indicates that the ROM has gone (partially) bad.

Using the functions that still work should not cause any actual physical harm to the calculator, but of course there is no guarantee that the calculator will operate correctly with the bad module installed.

If I were you, I'd return it and wait for another to show up on eBay.

      
Re: TESTP returns BAD with 82242A IR Printer Module
Message #4 Posted by Les Wright on 17 Jan 2007, 11:04 p.m.,
in response to message #1 by Les Wright

I have learned that save dirty or corroded contacts, these modules can't be fixed.

The contacts look pretty clean to me, but I have attempted nonetheless to clean what I can safely reach.

The module still tests BAD in both calculators.

If anyone has any wisdom to offer, I would be grateful. I know these things are hard to find, and that I should get some satisfaction from the partial functionality, but it would be lovely if I could access all of the functions.

At least my 82143 printer works okay, and thermal printer works fine with my other calculators.

Les

            
Re: TESTP returns BAD with 82242A IR Printer Module
Message #5 Posted by Steve Borowsky on 17 Jan 2007, 11:29 p.m.,
in response to message #4 by Les Wright

Are you sure you're not using speeded up 41's? When you execute beep on the 41's does it sound the same as on the 42?

                  
Re: TESTP returns BAD with 82242A IR Printer Module
Message #6 Posted by Les Wright on 17 Jan 2007, 11:38 p.m.,
in response to message #5 by Steve Borowsky

The pattern of tones sounds the same on both 42S and 41s, but on the 42s the pitch of the pattern is lower. In short, they sound similar but NOT the same, in the musical sense.

The CX is a 1987 model (SN 27xxxxxxxx etc) and the CV a 1984 model (SN 24xxxxxxxxxx etc).

What is the significance of your query? Is it possible for the module to test BAD when it really isn't?

Les

                        
Re: TESTP returns BAD with 82242A IR Printer Module
Message #7 Posted by Steve Borowsky on 18 Jan 2007, 6:53 a.m.,
in response to message #6 by Les Wright

Is it just a slight difference in pitch or is it very noticeable? There was a mod available for 41's that sped up the clock for purposes of calculation but made the 41 incompatible with certain modules because it also altered the timing of the pulses reaching the ports. For this reason it was easily reversible by a hidden switch mounted in the side of the casing where the ac adapter was originally intended to go. Try pressing the small ac adapter cover on the right side, or better yet carefully pry off the cover and see if there's a small microswitch mounted there. If there is you have a sped up 41. If you press the microswitch and then execute beep you'll see the pitch of the tone will match the 42 and your 41 will behave correctly with all the modules.

Edited: 18 Jan 2007, 6:57 a.m.

                              
Re: TESTP returns BAD with 82242A IR Printer Module
Message #8 Posted by Les Wright on 18 Jan 2007, 11:30 a.m.,
in response to message #7 by Steve Borowsky

Steve, I am a musician, among other things, so the difference in pitch is very noticeable to me. On the 42S, the pitches a A, E, C#, A. On the 41s, the pattern is a major fifth higher--E, B, G#, E. This is a big difference in terms of frequencies. I am no wizard in the physics of sound, but stopping a string seven semitones (a major fifth) up is done by shortening it to about 2/3rds its original length (I think the actual ratio in an even tempered scaled is the Golden Mean, but I am not sure).

Steve, would you be comfortable sending me your email address? I can send you short little mp3 recordings of the tones on all there calcs and you can inform me accordingly.

Les

                        
Re: TESTP returns BAD with 82242A IR Printer Module
Message #9 Posted by Poul Kaarup (Denmark) on 18 Jan 2007, 8:51 a.m.,
in response to message #6 by Les Wright

Yes, if you use a speed-up HP41, the IR module won't pass the selftest, although the module is OK.

/Poul

                  
Re: TESTP returns BAD with 82242A IR Printer Module
Message #10 Posted by Ronald on 18 Jan 2007, 5:06 p.m.,
in response to message #5 by Steve Borowsky

To test if it is a speeded up 41, program a small loop and measure how long it takes for example to run this loop a 100 times. If you put your code in this forum we can test the same loop on a known not speeded up version and make the verdict ........

My 2 cents

Ronald

            
Re: TESTP returns BAD with 82242A IR Printer Module
Message #11 Posted by Meindert Kuipers on 18 Jan 2007, 7:43 a.m.,
in response to message #4 by Les Wright

If you have access to an ROM Emulator (MLDL, Clonix, HEPAX) there might be a solution, but this depends on the IR module being hard addressed or not. The original printer ROM is hard addressed to Page 6. With this method you could put a known good copy of the IR Printer ROM in the ROM Emulator and test it. I have been able to revive a Wand with a broken ROM in this way using the MLDL2000.

Meindert

      
Re: TESTP returns BAD with 82242A IR Printer Module
Message #12 Posted by Les Wright on 18 Jan 2007, 11:52 a.m.,
in response to message #1 by Les Wright

The seller refunded the full amount this morning, no questions asked, and told me to KEEP the lot! I feel oddly guilty--if this is actually a "speeded up 41" issue and the module is fine, then I will need to come clean with him.

As it stands now, I have no clue how to pry apart anything to see if I have this little switch, so I will leave it alone.

Les

      
Re: A new wrinkle!
Message #13 Posted by Les Wright on 18 Jan 2007, 12:55 p.m.,
in response to message #1 by Les Wright

Now this is weird....

I have discerned that the routines that misbehave have to do with printing out lists of things. Here is what I have discovered.

If I want to print a program, I execute the PRP command and then use SST to print each line manually....

If I want to print the stack, I execute the PRSTK command and then use SST to print each line manually....

If I want to print my program catalog with byte info, in TRACE mode I execute CAT 1 and step thru each line to print with SST....

I have been able to replicate this behaviour with PRSigma, PRREG, PRREGX, PRFLAGS, and LIST too--I can get my desired list of whatever by executing the command, the SSTing thru each line to coax the calc into sending the output.

Weird!!!!

Any clue about this behaviour? I am glad I found a sort of workaround, albeit a nuisance. Could this be related to the "sped up" issue mentioned earlier?

Les

            
Re: A new wrinkle!
Message #14 Posted by Dia C. Tran on 18 Jan 2007, 1:15 p.m.,
in response to message #13 by Les Wright

do you have the problem with both 41s or only with one of them? It's unlikely that you have both of your 41s speeded up.

                  
Re: A new wrinkle!
Message #15 Posted by Steve Borowsky on 18 Jan 2007, 1:27 p.m.,
in response to message #14 by Dia C. Tran

Quote:
do you have the problem with both 41s or only with one of them? It's unlikely that you have both of your 41s speeded up.

Unless he bought them from the same source.

                  
Re: A new wrinkle!
Message #16 Posted by Les Wright on 18 Jan 2007, 1:33 p.m.,
in response to message #14 by Dia C. Tran

Behaviour with both CV and CX. I bought them both from separate sources--the CV in Toronto in 1984, and the CX on eBay last May.

Les

            
Re: A new wrinkle!
Message #17 Posted by Steve Borowsky on 18 Jan 2007, 1:22 p.m.,
in response to message #13 by Les Wright

Les, you don't have to pry the cover off, that was just a suggestion. The mod is intended to work just by pushing the ac adapter cover in firmly, that should activate the switch and toggle between sped up mode and normal mode. You can then tell by executing beep which mode it's in. Try it! See if you get a change in the pitch of the beep after trying it a few times.

BTW, the cover is very easy to take off, you can use a small flat screwdriver to pry it out. Just be careful not to scratch the case.

                  
Re: A new wrinkle!
Message #18 Posted by Les Wright on 18 Jan 2007, 1:37 p.m.,
in response to message #17 by Steve Borowsky

Steve, can you email a photo?

All I have is a little rectangular port cover that pops out easily when I take out the battery holder and pop the prongs from the inside.

I see just two holes in the little recess. Nothing that looks remotely like a switch activated by pressing in on this cover. Just black plastic, and holes.

Looks exactly the same on 1987 CX and 1984 CV.

Les

                        
Re: A new wrinkle!
Message #19 Posted by Steve Borowsky on 18 Jan 2007, 1:50 p.m.,
in response to message #18 by Les Wright

Quote:
Steve, can you email a photo?

All I have is a little rectangular port cover that pops out easily when I take out the battery holder and pop the prongs from the inside.

I see just two holes in the little recess. Nothing that looks remotely like a switch activated by pressing in on this cover. Just black plastic, and holes.

Looks exactly the same on 1987 CX and 1984 CV.

Les


I could send you a photo but I don't think it's necessary since the switch would be pretty obvious. Sorry for the false hope and wild goose chase, but I guess the module is bad after all.

            
Re: A new wrinkle!
Message #20 Posted by Vieira, L. C. (Brazil) on 18 Jan 2007, 1:34 p.m.,
in response to message #13 by Les Wright

Hi, Les;

are you using another module, mainly system-related, togheter with the IR module? The [SST]-related behavior called my attention.

If so, could you remove all of them and try TESTP again?

Cheers.

Luiz (Brazil)

                  
Re: A new wrinkle!
Message #21 Posted by Les Wright on 18 Jan 2007, 1:41 p.m.,
in response to message #20 by Vieira, L. C. (Brazil)

Luiz, I did a reset of the CX (I didn't have much of importance on it), and ran TESTP with the module in each port as the only module. BAD in all four.

Les

                        
Re: A new wrinkle!
Message #22 Posted by Massimo Gnerucci (Italy) on 18 Jan 2007, 1:59 p.m.,
in response to message #21 by Les Wright

Les,
out of curiosity I took my IR module and put it in a CV that had a very long sleep without batteries.
Slots 2 and 4 were, respectively, already filled with Math/Stat and Stress modules. Since slot 1 was without cover I plugged the IR module into it. After the usual MEMORY LOST greeting I executed several TESTP. I saw flag 0 and 1 come on and off and, every time, an output of BAD.
After turning the calc off I removed the other two modules and tried again: this time the result was OK. Soon I plugged in the other modules and the result was OK, again.
Now I cannot have a BAD no matter how many times and how many different configurations I try...

Maybe a not so foolproof testing procedure?

Massimo

Edited: 18 Jan 2007, 2:04 p.m.

                              
Re: A new wrinkle!
Message #23 Posted by Les Wright on 18 Jan 2007, 4:06 p.m.,
in response to message #22 by Massimo Gnerucci (Italy)

I was thinking about the "SST quirk" I have discovered. Could this be related to me using a 82240B Printer, vs. the 82240A?

Of course, that doesn't explain the BAD return of TESTP.

The seller is letting me keep the module despite the kind refund, so maybe if I let one of the calculators sleep a few days with batteries out I can try your experiment to see if I can replicate your results.

The fact remains, though, that in both calculators the list printing commands getting "stuck" is very real indeed. I think the ROM is bad in this very specific regard.

I have confidence in the port interface of both my calculators. I have a Math Pac, Stat Pac, Advantage Pac, 82143 printer, wand, and card reader, and they both work flawlessly. This is the first time I have encountered a bug with a peripheral, so I must reasonably guess the module is flawed.

Les

                                    
Re: A new wrinkle!
Message #24 Posted by Eric Smith on 18 Jan 2007, 7:38 p.m.,
in response to message #23 by Les Wright

Quote:
I was thinking about the "SST quirk" I have discovered. Could this be related to me using a 82240B Printer, vs. the 82240A?

No. The communication is one-way, so the calculator has no way to know which printer you're using, or whether you actually have a printer at all, or more than one printer.

When you use PRSTK, will keys other than SST cause it to print another line of the stack?

                                          
Re: A new wrinkle!
Message #25 Posted by Les Wright on 18 Jan 2007, 11:28 p.m.,
in response to message #24 by Eric Smith

Quote:
When you use PRSTK, will keys other than SST cause it to print another line of the stack?

Yes!!!

Same behaviour with CAT 2 (good one to try since I have a lot of labels to scroll thru), PRREGX, and PRSigma. The SST key is not the answer. It seems that any keypad input prods the list printing along....

Any diagnostic ideas?

Les

                                                
Re: A new wrinkle!
Message #26 Posted by Eric Smith on 19 Jan 2007, 12:23 a.m.,
in response to message #25 by Les Wright

The fact that any key, not just SST, will proceed, and that this happens in the middle of printing functions that can't normally be paused or SST'd, suggests to me that the calculator is going into a low power state waiting for the module to finish sending its buffer out the infrared, and the module is failing to generate the signal that would wake the calculator up. In the "light sleep" state, pressing any key does wake it up, so when you press a key it resumes.

This further suggests that the ROM code might actually be OK, and the self-test may be failing due to the failure of the wake-up circuitry.

The way a 41C bus chip (and hence module) wake up the calculator from sleep is to drive the ISA line high, which is the signal normally used to transfer ROM addresses and instructions between the ROMs and the CPU. The chip (or module) knows that the calculator is asleep if the PWO line is low.

Since the ROM works (at least mostly), the ROM chip's driver for the ISA line is probably OK. Possible the I/O chip's driver has goone bad. It's remotely possible thatthe receiver for the PWO line has gone bad, or maybe there is just corrosion or crud on that pin of the module. But that seems less likely because they normally put pulldown resistors in the chip for the PWO line.

I believe the PWO line is the fourth contact from the left on the bottom side of the module, as you look into the module's connector area.

Does holding a key down (vs. pressing it once per line) allow the listing to complete?

                                                      
Re: A new wrinkle!
Message #27 Posted by Les Wright on 19 Jan 2007, 1:15 a.m.,
in response to message #26 by Eric Smith

Quote:
Does holding a key down (vs. pressing it once per line) allow the listing to complete?

Yes!

I don't know if this means I can salvage this module, but I have referred the seller to this thread so if he elects to re-sell it (I will most likely return it to him now) he can tell prospective buyers what the bug is.

Let me know if there is anything I can do. As far as I can see inside, the contacts look clean as a whistle.

Les

                                                            
Re: A new wrinkle!
Message #28 Posted by Eric Smith on 19 Jan 2007, 6:19 p.m.,
in response to message #27 by Les Wright

Sounds pretty definitely like the interface chip inside the module has gone bad. I don't think there's any possibility of repair. :-(

                                                                  
Re: A new wrinkle!
Message #29 Posted by Tony Duell on 20 Jan 2007, 5:05 a.m.,
in response to message #28 by Eric Smith

A couple of thoughts, probably of little help, but anyway.

Firstly, IIRC, at the end of every plug-in ROM on the HP41 are a few vectors that allow routines in the module to be 'hooked into' various functions of the HP41. Now one of the versions of one of the MLDL development ROMs didn't correctly honour said vectors, and it could cause other ROMs to do odd things (IIRC the data acquisition ROM would take single readings but not sequences, which is how I first came across this problem -- I was running the data acquisition ROM from an MLDL RAM box which had said development ROM in it too). This might explain what's up with the printer ROM, not that you can fix it (if the ROM is corrupted).

Secondly, IIRC the IR printer ROM is a bank-switched module. Can you run that from a Clonix/whatever?

      
Re: TESTP returns BAD with 82242A IR Printer Module
Message #30 Posted by Les Wright on 20 Jan 2007, 5:19 p.m.,
in response to message #1 by Les Wright

Thank you, everyone, for walking me through a diagnosis of this issue. It seems that the module has a very specific flaw that affects several routines that do basically the same thing, i.e., print multiline listings of something, and that the admittedly inconvenient workaround is to activate the keyboard between printed lines until the list is done. This affects PRSTK, PRREG, PRREGX, PRSigma, PRP, LIST, CAT n (TRACE mode), and PRFLAGS (did I miss any?). It does not seem to affect single line printing (PRA, PRX, AVIEW, VIEW), and the printer does the proper thing with interim results in NORM and TRACE modes. I don't yet entirely understand the various buffer accumulation routines, but I am able to print a single line alpha buffer without problems. I should spend some time trying to accumulate a buffer of more than one line and the PRBUF it and see if the "sticking" after each line occurs there too. I am guessing it will.

The interesting thing is that PRPLOT works flawlessly, but when I look at the program code the reason is obvious--all of the printing done involves single-line instructions (like PRA) that don't inspire the "list-freeze" problem.

As for the future of this item, I have already mentioned that the seller has given me a full refund and doesn't want the item back. I am getting another module (hopefully fully functional) and it was suggested to me by the original seller that whatever net proceeds I get from disposing of the buggy article I pass on to a charity. As a variant on this, if anyone one wants to take this off my hands I ask simple that you cover the cost of mailing plus about $7US (about what I paid Canada Customs to import the thing in the first place) and to pledge a reasonable amount to the charity of your choice. As for latter idea, I am not going to demean anyone to ask for documentary proof, so please don't tell me your are going to give a hundred bucks to the Red Cross or SPCA or your college alumni association unless you plan to follow through. My experience is that most regular members of this Forum are actually pretty darn honourable, so that shouldn't be an issue.

I am going to hang onto this a few more days and try to further delineate the limitations of the module, but when I decide to move it along I will post a Classified with a more specific articulation of this idea. Keep in mind that the shrink-wrapped manual is nearly mint (alas, some slight splitting of the cellophane), and that may be of some interest as a collectible.

Les

            
Re: TESTP returns BAD with 82242A IR Printer Module
Message #31 Posted by Les Wright on 21 Jan 2007, 3:38 p.m.,
in response to message #30 by Les Wright

Quote:
I don't yet entirely understand the various buffer accumulation routines, but I am able to print a single line alpha buffer without problems. I should spend some time trying to accumulate a buffer of more than one line and the PRBUF it and see if the "sticking" after each line occurs there too. I am guessing it will.

I have actually written a little routine that accummulates a few hundred characters in the buffer and then calls PRBUF (or, alternatively, ADV) to print them. On my 82143 thermal printer the printer starts printing the overflow and ends up printing the entire task. The IR Module and 82240B printer prints the first 200 characters (the buffer size of the printer), but then issues the lost information code (black rectangle with white diagonal thru it) and then stops. I understand that this is entirely normal behaviour and reflects the limitations of the IR printer, not a bug in the module.

So, at present, it looks up the only bug is this "wake up" bug.

I do have a taker for the module and manual already.

Thanks again for helping me understand this most interesting and peculiar problem.

Les


[ Return to Index | Top of Index ]

Go back to the main exhibit hall