TESTP returns BAD with 82242A IR Printer Module



#32

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.


#33

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

#34

"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.

#35

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


#36

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?


#37

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


#38

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.


#39

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

#40

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

/Poul

#41

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

#42

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

#43

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

#44

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


#45

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.


#46

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.

#47

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

#48

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.


#49

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


#50

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.

#51

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)


#52

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


#53

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.


#54

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


#55

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?


#56

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


#57

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?


#58

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


#59

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


#60

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?

#61

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


#62

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


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP50g: Writing a function that returns a function Chris de Castro 2 826 12-10-2013, 06:49 PM
Last Post: Han
  Help: HP-41CX and IR module Marcel Samek 13 1,711 11-14-2013, 11:00 AM
Last Post: Marcel Samek
  IR printer failure Andrew Nikitin 7 1,090 11-05-2013, 11:25 AM
Last Post: Andrew Nikitin
  Bad Flash in HP Prime Han 11 1,568 09-27-2013, 12:38 PM
Last Post: Han
  Trouble dumping Pioneer ROM via IR Neil Hamilton (Ottawa) 6 1,006 06-20-2013, 08:14 AM
Last Post: Neil Hamilton (Ottawa)
  HP42S and IR printer matti 9 1,238 06-10-2013, 12:11 PM
Last Post: matti
  Does IR printing not work on your converted WP34s? Then read on... Harald 3 733 04-04-2013, 05:46 PM
Last Post: Harald
  IR Link Problem: HP48 <-> PC Waon Shinyoe (China) 1 473 03-16-2013, 03:37 AM
Last Post: Eric Smith
  Cheap hp32sii in bad condition on sale on Taobao Waon Shinyoe (China) 1 508 03-01-2013, 08:35 PM
Last Post: Raymond Del Tondo
  WP-34s data exchange with PC over IR Marcel Samek 3 693 02-26-2013, 11:53 PM
Last Post: Marcel Samek

Forum Jump: