HP-71B Startup Time - ROM Differences

[rprosperi]

I recently acquired an HP-71B with ROM version 2CDCC (at last!) and have noticed a significant difference in startup time (from press of [ON] to blinking cursor). ROM 1BBBB machines all seem to start in about 1 second, however the 2CDCC machine can take 10 seconds or more to come on, and I'm wondering if this is typical for this later ROM.

The machine passes diags and is in every way I've tried stable, functional and consistent with other machines. The s/n indicates very late 1989 production (2951A00046) and has HP-IL 1B installed.

I've verified the config is correct (OFF IO when loop is not connected, and all devices in the loop are on and loop is processing messages when connected), and all ports are readable. Also the machine performs at normal speed for programs, loop operations, etc.

Lastly, for a while right after I power down the 71 (by pressing Shift-[ON] or typing BYE or OFF) if I then power-on, it comes on in 1-2 seconds, but after a longer while, maybe a couple hours or overnight, the long startup delay occurs again.

Is this typical for a 2CDCC 71B? If not, can anyone suggest other tests or things to try?

[Geoff Quickfall]

I know you said off io when loop is not connected.

I have the same version with 3; 32k modules and the math. Startup is almost instant to the cursor and is the same on my other 5 machines of differing versions.

Have you tried executing the OFF IO command, then check the startup. IO can be on even when a loop is NONEXISTANT and mine then exhibits the slow start if I had not selected OFF IO after using the tape deck, ink jet printer, disc drive...

Geoff

[Joe Horn]

(09-09-2014 12:05 AM)Geoff Quickfall Wrote:  Have you tried executing the OFF IO command...

Also, DISPLAY IS * sometimes speeds things up if you want the loop operational.

[rprosperi]

(09-09-2014 12:05 AM)Geoff Quickfall Wrote:  I know you said off io when loop is not connected.

I have the same version with 3; 32k modules and the math. Startup is almost instant to the cursor and is the same on my other 5 machines of differing versions.

Have you tried executing the OFF IO command, then check the startup. IO can be on even when a loop is NONEXISTANT and mine then exhibits the slow start if I had not selected OFF IO after using the tape deck, ink jet printer, disc drive...

Geoff

Yes, I checked this, however will do so again. Of course I can't tell if it makes a difference until tomorrow, as shortly after shutdown it always comes right back on as noted.

Maybe you're right and I just spaced out on the IO OFF. Will know in the morning..

Thanks Geoff.

[rprosperi]

(09-09-2014 01:47 AM)Joe Horn Wrote:  

(09-09-2014 12:05 AM)Geoff Quickfall Wrote:  Have you tried executing the OFF IO command...

Also, DISPLAY IS * sometimes speeds things up if you want the loop operational.

Will try this as well, but again, can't tell result 'till morning. Maybe I'll try OFF IO first to see the effect, then move on to this if it doesn't. Doing both may correct it, but I'd hate not knowing why...

Thanks Joseph.

[Sylvain Cote]

(09-09-2014 01:58 AM)rprosperi Wrote:  Doing both may correct it, but I'd hate not knowing why...

In my book, when it comes to communications issues, a sniffer is always saying the truth.
I would setup a loop with a sniffer (PILBox/ILPILBox/ILScope) to record the communication frames.
I would then analyze the frames to understand what's going on in the loop.

Sylvain

[J-F Garnier]

(09-09-2014 01:58 AM)rprosperi Wrote:  

(09-09-2014 01:47 AM)Joe Horn Wrote:  Also, DISPLAY IS * sometimes speeds things up if you want the loop operational.

Will try this as well, but again, can't tell result 'till morning. Maybe I'll try OFF IO first to see the effect, then move on to this if it doesn't. Doing both may correct it, but I'd hate not knowing why...

Thanks Joseph.

First, there is no difference in startup time between versions 1BBBB and 2CDCC.

The most probable cause of a delayed startup is indeed the DISPLAY setting. Try DISPLAY IS * first.
If it doesn't help, try RESET HPIL. The HP-IL module could be in a strange state.

Then, check your installed LEX files and option ROM, and remove unknown LEX files that could do something at startup.

Finally, check your STARTUP setting, or clear it with STARTUP "" (with JPC ROM, you can check it with STARTUP$).

Quote:Doing both may correct it, but I'd hate not knowing why...

For a tentative explanation, see here

J-F

[Paul Dale]

Try it with the HP IL module unplugged. I noticed that the 71B starts a lot slower with an IL module without cable. Unless you are in CALC mode in which case there was no difference.


- Pauli

[rprosperi]

Brief update:

Upon hitting [ON] this morning, the long delay occurred again, but all was normal after. I did do RESET HP-IL before OFF IO.

I have now just tried "DISPLAY IS *" and will check behavior after work. I will enable the scope on ILPer to see loop activity, if any. Thanks for suggestion Sylvain.

Thanks to all that have confirmed the ROM ediiton is not the cause, and to J-F for the additional comments and background. Though I regularly use PRINTER IS :PRINTER(2) to direct output to ILPer, I don't recall using DISPLAY IS. Could PRINTER IS also cause the same issue as DISPLAY IS (presumably the 71 is trying to access the 'current' device and eventually times-out)?

Pauli - I believe OFF IO is (should be?) effectively the same as having the module removed? I never noticed that Calc mode bahaves differently, though I rarely use it (I have and RPN Calc program installed).

Thanks all, will report results later today.

[J-F Garnier]

(09-09-2014 08:14 AM)Paul Dale Wrote:  Try it with the HP IL module unplugged. I noticed that the 71B starts a lot slower with an IL module without cable. Unless you are in CALC mode in which case there was no difference.
- Pauli

(09-09-2014 12:48 PM)rprosperi Wrote:  Though I regularly use PRINTER IS :PRINTER(2) to direct output to ILPer, I don't recall using DISPLAY IS. Could PRINTER IS also cause the same issue as DISPLAY IS (presumably the 71 is trying to access the 'current' device and eventually times-out)?

The DISPLAY IS :DISPLAY is the default power-up state (first insertion) of the HP-IL module. So unless an explicit DISPLAY IS * is done, the HP-71B will search for a display at every turn-on, even if the loop is open or broken, causing a delay. PRINTER IS will not cause any problem, until you do a printer operation (PRINT, PLIST, ...).

[rprosperi]

(09-09-2014 01:13 PM)J-F Garnier Wrote:  The DISPLAY IS :DISPLAY is the default power-up state (first insertion) of the HP-IL module. So unless an explicit DISPLAY IS * is done, the HP-71B will search for a display at every turn-on, even if the loop is open or broken, causing a delay. PRINTER IS will not cause any problem, until you do a printer operation (PRINT, PLIST, ...).

So this 71B still comes up with a 10+ second delay, even after doing DISPLAY IS *, RESET HP-IL and OFF IO. I read in the thread J-F pointed to that OFF IO resets DISPLAY IS and PRINTER IS assignments, so maybe a better sequence would be OFF IO followed by DISPLAY IS *.

Anyhow, the basic issue has been answered, it's not the ROM, so it's just this machine has some weird config inside, so I'll probably just INIT:3, wipe all RAM and build it again. But I will explore it a bit longer, just because I want to know what the cause is. Curiosity is such a bitch.

Regardless of the initial casue, a key thing I don't understand is why does the amount of time i wait after shutdown affect the next startup behavior? Do things really happen in a powered off 71 several hours after shutdown?

Thanks to all who replied; as usual, lots of useful and interesting info.

[Dave Frederickson]

I know that OFFIO should be the same as removing the HP-IL module, but did you actually try removing the module? That would definitively determine whether it's an HP-IL issue or something else. I think its worth trying before you perform an INIT 3.

Dave

[rprosperi]

(09-10-2014 01:40 AM)Dave Frederickson Wrote:  I know that OFFIO should be the same as removing the HP-IL module, but did you actually try removing the module? That would definitively determine whether it's an HP-IL issue or something else. I think its worth trying before you perform an INIT 3.

Dave

Agree Dave, thats 2nd on my list of things to try. Tonite, I'm just trying the alternate command sequence, ending with DISPLAY IS *. Will let you excited fans know what happens.

[jebem]

(09-10-2014 03:54 AM)rprosperi Wrote:  Tonite, I'm just trying the alternate command sequence, ending with DISPLAY IS *. Will let you excited fans know what happens.

Interesting subject, Bob!
I do not own a 71B (it is on my wanted list to be acquired when funds allow it... ) but I would like to know what was the cause of that long awakening time from a deep sleep symptom as well.

If all the planned operation procedures fails, maybe this issue can be caused by a small component (like a capacitor) failure inside the calculator PCB.

I have found out the service manual available for free here.
I did a search in that page for "71b" and found it. Very comprehensive documentation I would say.

From the service manual, page 2-10:
Capacitors C1, C2 and C8 (...) provides power supply noise isolation (...).
The symptom you describe fits a hardware failure in a resistor (higher value than the correct one) or most likely a faulty capacitor (lost capacitor and/or leakage).
- I would start by checking capacitors and the resistors in the neighborhood.
In fact I would just replace all the electrolytic caps with new ones.

On page 2-18 the deep sleep state is described:
On every 4 hours the display/timer awakes the cpu to let it service the real time clock.
The average current consumption is 20uA.
Other things to check:
- Remove all the devices (as previously recommended by Dave) to make sure there are no interrupts being generated from them (if one interrupt in being served, no other interrupts will be served until the current interrupt service routine returns, and that can affect the ON sequence - pls read page 2-8);
- Is the rtc updated after that long hours in deed sleep state?
- Using a good current meter (a digital multimeter should do it) check the actual current drain.

And section 4 - troubleshooting and testing - provides a very comprehensive checking procedures, like diagnostic recommendations, and hardware procedures to check all the components in order to eliminate possible issues - providing one's have access to the required tools like an oscilloscope to start with...

Good luck with the problem "hunting" and please keep posting additional information.

[Sylvain Cote]

(09-10-2014 01:13 AM)rprosperi Wrote:  Regardless of the initial casue, a key thing I don't understand is why does the amount of time i wait after shutdown affect the next startup behavior? Do things really happen in a powered off 71 several hours after shutdown?

The slow wakeup could be cause by a loop peripheral.
I would suggest to do a test with a loopback cable connected to the HP-IL interface and see if you have the same behaviour.
If not, then it's coming from a loop peripheral and I would redo the test with each peripheral one by one.
Sylvain

[rprosperi]

Thanks Jose and Sylvain for additional suggestions.

This morning, the 71 had another slow start, so here's the next few things I will try, in order:

• Replace actual Loop with single (loopback) cable
• Remove HPIL Module
• Remove SHOWPORT LEX file and Forth41 ROM
• Remove all BASIC Programs
• Do INIT:3 to wipe RAM
• Remove RAM modules
• Not open the case and fiddle w/Hardware (I'd rather start slow than possibly harm inside)
  

I just wish I didn't have to wait so long (seems like 4-hours is the likely inflection point) between tests.

[Dave Frederickson]

While we're waiting for test results other things you could try include:

• Reset the calc by removing the batteries and holding ON down for several seconds
• Depending on test results:
  • Swap the HP-IL modules
  • Find a Diagnostic ROM. Maybe something funky is going on.
    

Dave

[cruff]

(09-10-2014 03:54 AM)rprosperi Wrote:  Tonite, I'm just trying the alternate command sequence, ending with DISPLAY IS *.

On one of my 71Bs with an HP-IL module installed but not connected, I've never entered DISPLAY IS *, but have entered OFF IO, and the prompt appears in less than 2 seconds. After I entered DISPLAY IS *, it still powered on in less than 2 seconds. Even entering either RESTORE IO or RESET HPIL makes no difference in the startup time.

[rprosperi]

(09-10-2014 06:36 PM)Dave Frederickson Wrote:  While we're waiting for test results...

An update:

All command combinations have no effect.
Removing HP-IL module, power-cycling 71, and reinstalling HP-IL has no effect.
Another 71B (ROM 1BBBB) behaves normally when plugged into the same loop configuration.
Loopback cable installed, followed by RESET HPIL, OFF IO, DISPLAY IS * has no effect.
Real-time clock is keeping time normally (since 4-hour timer plays with RTC, thought I'd check)

Later will proceed with more drastic steps resetting RAM, etc. but my conclusion is this has nothing at all to do with HP-IL, and the memory config has somehow been wacked in a strange way.

I wish I had a Diag ROM to check with, but I suspect it's more of a software induced issue. If it were a hardware issue, I don't imagine it would work fine after short periods of being off, have delays after a long time off, and then run properly once started. Does not feel like hardware to me, but I welcome opinions from more knowledgeable folks.

Thanks Dave and Cruff for comments and suggestions.

[J-F Garnier]

(09-11-2014 12:57 PM)rprosperi Wrote:  ... my conclusion is this has nothing at all to do with HP-IL, and the memory config has somehow been wacked in a strange way.

Yes, it seems so. Corrupted file chain (especially in independent memory port) can cause a delay. It happened to me with an EPROM module, which appears to the HP-71B as a corrupted CAT chain. Turn-on was delayed by several seconds, but I don't remember any effect related to short or long off time, like you.
You could check if you have independent RAM ports (SHOW PORT), and clear them (CLAIM PORT).
Last chance will be a global memory clear.

J-F