Help with vintage HP 3000 series30/33 computer

[Klyball]

looking for some suggestions on troubleshooting this 3000, i'm going in circles right now. im not a novice but electronics is just a hobby for me so im learning as i go .

To run the on board cpu diagnostic the unit needs to be halted, here is the first problem, when the computer is turned on the run light is on , if i press halt, the light comes on but its not really halted.Pressing run/load/start or halt has no effect other then lighting the lights. pressing dump will start to handshake with the gic then stops and after a bit the halt light will come on and now it is halted.
So here i can now run the cpu self test which fails at step 23 which is near the end of the rass chip section. the manuals solution is to replace the cpu or bic boards not really an option.
At least we know the the cpu is running the selftest from rom and processing microcode instructions.  A lot needs to be working for it to do what it is doing. i have done a lot of probing around with a logic probe, but maybe a fresh set of eyes on the schematic could see a possible area that could be causing it to fail.
if i press run after it is halted the instruction fetch led on diag panel is strobing, but will only halt again after dump is pressed.
So the first thing to get working would be the halt circuit.

Thanks and happy new year
Grant


http://www.bitsavers.org/pdf/hp/3000/schems/30070-90009_S33_schem_Jan79.pdf
http://www.bitsavers.org/pdf/hp/3000/diagnostics/30070-90044_HPIB_Diags_Vol1.pdf
http://www.bitsavers.org/pdf/hp/3000/ce_handbooks/30070-90010_HPIBsysCE_May87.pdf

[m k]

Is that MI diagnostics a must, what if you just start the normal operation?

Test 5 CPU mentioned, but it's only an external flip-flop of its state.
Test 11 IMB basics, bus something I guess.
Test 12 uses CPU communications, still basically on the edge of it.
Test 14 checks CPU clock halt possiilities.
Test 16 CPU jump, first real thing.
Test 17 load test.
Test 18 dump test.
Test 19 pause test.
Test 20 DSW breakpoint test.
Test 21 ROM breakpoint test.
Test 22 ROM breakpoint HALT test.
Test 23 IMB control test.

What message there is?
What #11 is not testing?

[Klyball]

Thanks for the reply
There is no way to get the dus tape loaded as cold start will not function.
The MI can be removed and the first tests you refer to are for the mi card  and can be skipped and just run the the cpu diagnostics from rom using the test switch and diagnostic lights on the bus interface board.
this fails at test 23 the tests are described on page 63(511f-9) of the diagnostic manual linked below , the only boards that need to be analyzed are the cpu board and bus interface board, this i believe is where the problem lies. the cpu needs to be halted to start the tests but the halt button will not halt the cpu.
the only way to halt the system is press the dump button which somehow causes the cpu to halt after a time. then the self test can be run.

other relevant pages from the ce manual are
5-5 selftest summary
9-3 and 9-4 bic test leds
along with a better description from the diagnostic manual noted above

[m k]

So I was reading wrong stuff.

MI board (schematics 3-41) has HLT in U194 LS240 status driver.
(hard to follow these pages)
Can you halt it from there?

Other side of the chip can be trickier but not much if you're lucky and your probe supports it.
If memory serves LS240 wasn't the most robust chip, maybe they were generally just stressed too much.

RASS tests,
since they are on the way already when #23 comes and since it's registers that are in question it feels something very internal.
PCU and RALU are also tested first so there are not much external that can be faulty.
What kind of a chip that RASS is, any replicas available?

One other possibility is to read that test ROM and pin point that exact cause, maybe I just couldn't find that better explanation part.
I read somewhere that test ROM is 8080 stuff and starting from C800, maybe that was also from a wrong page.
Anyway, that is not much even if the whole 65k is the case since all messages are probably hard coded and so can be easily traced back.

[Klyball]

I have removed the MI board as it is not necessary to run the system, The system wont halt from the MI board using the console. anyway.

I believe the system on start up should be halted but its not and i cant halt it with the from panel . The manual states the the bic board is tied to those tests also.  the RASS is a custom hp chip , highly unlikely to find a replacement , here is some info for the curious http://www.cpushack.com/2016/11/26/hp-3000-series-33-16-bits-of-sapphire/ i wonder if that test starts using the data buss and thats where the problem lies , also the front panel controls i think are using the data buss, the light work but it does not do the action.

I'm hoping what is keeping the system from halting is the cause of the trouble , but there is a lot of interconnection with the buses and address lines. also the external registers .

FYI the ls241 on the buss interface board  board seem abnormally hot.
I appreciate you having  a look , i know some of those schematics are not very readable

[m k]

That page was quite good, with hand written text.
Some traces and their dots indicates that everything can be someones handiwork.

Replicating that transistor count of RASS should be easy.
Mechanicals are one thing but that variable clock speed is also something, but if that one pin is still undocumented then obviously there won't be any replicas.

3-48, left side B,
J1-18 and P2-39 are shorted inputs and go to U72 pin 4.
J1-16 is their output from U72 pin 5, what is opposite of low pin 4.
So if pin 4 is low then pin 6 must also be low.

Quite far is that one LS253 of CPUBus is overloading that external register LS241 and also that U72.
If that is the HALT we are talking about.

The whole section is labeled as ISR, right and up of it is NIR.
Should the fault be visible in NIR also and where is the rest of NIR?

[Klyball]

The flip-flop u72 seems to be functioning properly,  but the output on pin 6 looks to be interconnected to all the flip-flops on that sheet. It also heads out to the cpu buss. I will have to check all the logic around there ,and then move on to the buss drivers.it look like !pon (power on should also halt the system on power up but does not.

[m k]

Rest of NIR means that CE 9-4 BIC leds A-F are NIR bits 10-15 and CE 5-5 HW test numbers are possibly bits 0-5, bits 6-9 are still missing.
With luck those missing ones can give some relevant info.

PON is good.
With it and _SRST or _FPRST you can force all of those flip flops one way or another.

With BIC SEL 0/1 as 00 (flip flops selected, plus _IRQ and _CSRQ)
CPUDOIT should go to CPUBus7, _PONFF to CPUBus5 and _HALTFF to CPUBus8
If BIC SEL is bad then flip flop selection can be something else and they and CPUDOIT are all for BIC SEL 00, higher lines are pulled up.

[Klyball]

I had thought this at first with the nir bits . But looking again  its most significant bit is A nir bit 10 , so you read them from A to F and G To I are for other uses. I will attach a link to the selftest,  you can see it pause at test 16 and then stop at test 23 nir. In octal 010011000 or 230
www.klyball.com/HP/3000test.mp4

I will check the bicsel area

[m k]

So test number and leds are the same.
Then NIR bits 0-9 are nowhere.

I still don't know how the actual halting happens.
What "(PMP)" under HLT means?

If HLT goes to M.I. then actual halting must be something through CPUBus.

Is it certain that CPUBus in general is functional through the backplane?
If External Register 01 is easier then _PONFF bit5 is same as _FPLD and _HALTFF bit8 is same as CPP MODE LED.

[Klyball]

PMP lines are for the maintenance panel , all signal seem to be pulled so the maintenance panel can be ignored it is used for controlling the system test from a console.  system should operate with out the mi card as far as i could tell. If i had a way to get the maintenance software on to the terminal i could skip over the 23 test and continue, but that is a whole other problem.I can control the system the same way from the terminal as the front panel but with same results, does not halt. i am hoping to do some testing on the weekend on the buss drivers as most of the logic have tested seems fine , but i need to take a more orderly approach.

 what order would you test to find the halt fault.

 the one thing that does do almost correct is the dump. when it is pushed it start to handshake with the drive but then stops talking and after a bit, times out and actually halts the system.

One other activity is after running selftest  and you push run , the instruction call light will be strobing , load,start and halt still do nothing only dump will rehalt the system

[m k]

Dang, I forgot that halt and led, if it's _FPLED then situation is quite simple.
If led comes on when it should then bit8 is most likely ok.
(CPUBus above ISR and 8 there)
Only thing in between is U73 LS253.
So it seems that only one question remains, is it the chip or its control.

BIC SEL is a good start.
Like checking that U26 is outputting what it should and that those values are present at the other end.

Same with _BICGO.
_FPLD and _FPRUN goes to External Register 01 and so have nothing to do with above selections

The problem is that if actual halting is later in the line of operations and closer to CPU the problem can be ROM code.
Something like comparing databus value and ROM value.
If that is bitwise then fine but other ways can give wrong results.

BTW, I've also learned that there are no such thing as CPU register.

[Klyball]

Yes the front panel led's act as they should , but the operations do not , except dump starts and run light come on, it contacts the drive then stops and the halt light comes on and now it is actually halted . that when i can run the cpu diag. I will test over the weekend and share any results . I Appreciate your help .the circuits are a little more complicated then what i have worked on before.everything is so interconnected. but this unit deserves be be revived.

Cheers

[m k]

I've thought that _FPRST is reset, is it actually something else?

If you use something as device 0 from channel 0 and it actually is that then you can be quite sure that wrong BIC SEL has stayed away.
That is because _CHL and _DEV signals go through ExReg03 and same bits from those flip flop selected LS253s are pulled up.

SELF TEST LED and _STESTFF are ExReg01 bit1 and that comes straight from CPUBus, if PON and _CLEARFP allows it.
CPP MODE is also allowed by _CLEARFP and that is ExReg01 bit8.

All but one of those flip flops are normally operated through CPUBus.
That one is 2nd from right and it is clocked by _FPRUN, when others are clocked by SISR.
That one is also without own output and is combined with _PON and _FPHLT and then go to bit8 through that 5th LS253.
One addendum, that flip flop output is _HALTFF and it is opposite to _FPLED.
Means that when there is no halt there is led, so _PON, _FPRUN and _FPHLT can operate that led without any other operation.

But you said that drive contacts.
What is _PERFF, or its CPUBus side partner _PER, port/parity error?
This bit3 and bit8 from halt flip flop are two that can bypass their flip flops.
So it seems that things are rounding those LS253s quite all right.

Seems also that I've found those NIR leds, section B right, U51 7407.
Are you reading those test numbers from leds or can you check them from somewhere else also?
Means that CPUBus is setting those leds but reading NIR goes through those LS253s.

If BIC SEL 0 is always up those flip flops are never on line and BUSD has taken their places, same with NIR where MEMA has taken its place but if _BICGO is activated when it shouldn't those SEL signals can also be what ever and still be ok.
The difference here is that BIC SEL 0/1 is activating something all the time but output is only activated when _BICGO goes low.

[Klyball]

There is drive contact with the dump button only. After after a short time system has true halt. I will post the nir lights when dump is frozen and the lights with true halt, this might help
I have a logic analyzer ,what would you test first

Thanks

[Klyball]

I think one other clue is that with power on the  cpu should be in a halted state, but it is not.

[m k]

It's very clear that _HALTFF is what puts halting forward so I'd start from that CPUBus bit8.

So probe U73
pin
02 BIC SEL 1
14 BIC SEL 0
01 _BICGO
15 _BICGO
07 CPUBus bit8
06 _HALTFF
05 BUSD 8 (for reference)
04 NIR 8 (for reference)
03 MEMA 8 (for reference)
10 pulled up
09 CPUBus bit9 (for reference)

When 2 and 14 are low should 7 be 6 and 9 be 10 when 1 and 15 go low.

[Klyball]

Here are the results of 4 tests all triggered on haltff

#1 is after power on pressing halt system not halted , halt light on
#2 is pressing the dump button halts system , halt light lit
#3 running selftest run light on then halts , haltlight on
#4 while halted during selftest pressing run then halt , system not halted haltlight on

[m k]

#1
Seems to be like it could be after power on.
BIC SEL is 0 all the time and module is waiting next button.

How do you decide the state of the machine, is it a primary thing from CPU's point of view?
Switch board's run and halt leds seems to be opposite polarities of _FPLED.
If so then _HALTFF is a dummy led initiator and also despite what happens elsewhere.

#4
Quite silent, I'd say that that is what and how halted should be.

#2
Pressing dump is clearly there so signal goes through EXReg01 to the CPU.
Halt light changes its state but system continues.
Can't say why _HALTFF changes its state before BIC SEL goes 3 MEMA.
Maybe that is the point where error is put forward.

#3
Here also the thing continues after _HALTFF so it's clearly not so good trigger.

Next probe could be concentrating to that test 23 and it reasons.
So probe ExReg01 and 03 so that all bits are probed from three positions.
Two from U83 and U75 sides and one from after backplane of BIC board connection to processor board direction.

Use _BX01 and _BX03 from chip end as triggers.
You can do it in parts, CPUBus bits 7 and 9 are not used.

[m k]

One more thing, high and low are not equal.
If your analyzer supports high impedance level, use it.

And then one more thing.
If one CPUBusbit is not changing its level at all try something else that give you a solid answer of its level changing capability.
Same with those register values, like device and channel, even if low is a problem try it anyway.

[Klyball]

Thanks for the insite , will do some more testing over the next few days and post my results.

Cheers

[m k]

How difficult is one session, how much forward you should be able to go?

It seems that you didn't say witch chip is the hot one.
I've thought it's ExReg01 or 03.
Is it warm or hot?
You can concentrate to that also.
Problem is that you need to trig its selections and then i/o is what it is and you can't say if those pins can flip their levels or not.
 
If your analyzer can trig using combinations you can also use NIR leds and 23, three ones are enough.
There next wires should go so that one register selections pins are added to the combination and test is done.
If trigger happens you know that this register testing has started.
For next round you change those selection pins and continue until all selections are tried.
Then you know those registers that are not involved.
Maybe that is doable with _HALTFF also.
Quite complicated anyway.

With _HALTFF method you connect
U/LMEMACK
_BUSDCK and BUSDSEL
_NIRCK and NIRSEL
and BIC SEL 0/1 and _BICGO
and then trigger as _HALTFF.
Then do test 23.
It doesn't matter how many other tests are done, only _HALTFF matters.
Then finally with some luck you can say something about how the test stopped.

Maybe after all the easiest thing there is a single module test.
There you take all but BIC board out, maybe leaving front panel connected, it's not so different than it may feel first, backplane is giving power and all other things are missing, nothing is electrically wrong.
Then you just start pulsing some pins and things start coming out.

You need 'store' and 'bbus' controls and few others.
Floating should be high so you flip everything low.

Writing
MEMA
P1-22 _IOAD and
P1-19 _MARST down gives you ADDST and enables MEMA.
P1-15 CPUCLK flipping will write MEMA, flip it few times.
U/LMEMACK are also clock pulses but timing is as it is with normal operation so it should work.

NIR
P1-4 _BIRC and
P1-20 _NIR down enables NIR.
P1-15 CPUCLK flipping will write it, flip it few times.
There seems to be a led also.

BUSD
P1-21 DATST is floating up, so enables BUSD.
P1-6 _RDRQST and
P1-2 _RSET and
P1-3 _MCRS down gives you READRQ and enables BUSD
P1-15 CPUCLK flipping will write it, flip it few times.
This has a bit more logic, maybe I missed something.

You can check them
J3-13 UMEMACK
J3-7 LMEMACK
J3-2 NIRSEL and led
J3-43 _NIRCK
J3-4 BUSDSEL
J3-45 _BUSDCK

Reading is same for all
P1-10 _BNIR and
P1-11 _BBUSD and
P1-13 _BMEMA gives you BIC SEL 0/1, all up is flip flops.
P1-12 LDEX is floating up, so enables _BICGO.
P1-15 CPUCLK flipping does _BICGO and enables LS253 outputs and so read what is selected.

Data is in the CPUBus, if you write 0s CPUCLK flipping read should flip the bit down and high impedance.
Don't forget to release them bits after writing.

BTW, it's 25 below here and how awful lot it is after few warm winters.

[Klyball]

Thank you, that gives me a lot to work on

here is some more info  page 5-8
 https://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1979-07.pdf

Stay Warm and cheers

Grant

[m k]

Page 5 explains some of that not very common ROM addressing system.
It's almost like I've read that those chips are used for guite some time.
Maybe bunch of them are hiding in forgotten devices in unkown storages.

IMB is excluded from above.
It's actually quite handy since it can check what are stored in MEMA and BUSD.
Problem is that its selection seems to be a bit less handy.

One more thing.
if you decide to take that single module route you should check that power supply supports it.
So that there are no hickups because some loads may be missing.
External power is one possibility of course but then things start being overly complicated again.

[Klyball]

I think i am going to go the route of the bench ,as it is very awkward to work on it .

I believe there are only 4 systems that use these chips.

1- HP 300 "Amigo"
2- HP 3000 Series 33
3- HP 3000 Series 30
4- HP 30341A "Starfish"

2,3,4, use the same boards
 
i have feelers out with people in the know , so far there is only 1 other known 33 out there. So revival of this machine i think is important.