1 Mar
2005
1 Mar
'05
9:03 p.m.
Based on the docs I got from Ashley I was able to re-arrange the memory
section to be sane, cards were in the wrong slots. I was also able to get
the jumpers set right on the G110 card. Now when I power up I can definitely
read core correctly. There's a random assortment of data in sequential
locations and returning to those same locations I always get the same value.
That's a plus.
However, I can't store anything. Anytime I store a new value in a location,
that location gets all zeros. Moving to another location I get data, and
moving back - zeros. So it appears to be challenged in writing, but not
reading, memory. The plot thickens :)
One thing I can't be sure of that the docs from Ashley don't say for sure is
how to configure a less than full section of memory. I ASSumed you start
from right to left, but in the HP core section that
would be a bad
assumption. Humm... But if I had that wrong, I'm suprised
I'd be able to
consistently read memory locations. A different G231 and G110 and H214
didn't change the problem.
Jay
2 Mar
2 Mar
2:06 a.m.
Jay wrote:
There's a random assortment of data in sequential
locations and returning to those same locations I always get the same
value. [...] However, I can't store anything. Anytime I store a new
value in a location, that location gets all zeros.
The fact that you can read a location repeatedly and get consistent
data (provided that you don't explicitly write to the location)
indicates that most of the circuitry involved in writing is actually
working correctly. Reading core memory is destructive; you have to
attempt to flip the magnetization and determine whether it actually
flips. So a read operation is normally followed by a write of the
same data to restore the original contents. That must be working.
On the Unibus, there are two types of read cycles, DATI, and DATIP.
DATI does what you would expect: it reads a word of the core memory,
and the memory control (part of the memory system) is expected to
handle restoring the data.
On a DATIP cycle, the memory is not required to restore the data,
because it will be followed by a DATO or DATOB cycle that writes
new data to the same location.
So your memory appears to be handling DATI cycles correctly,
including the implicit rewrite. But either the memory is not
handling DATO cycles correctly, or the CPU is not issuing them
correctly.
Eric
6:32 p.m.
Based on the docs I got from Ashley I was able to re-arrange the memory
section to be sane, cards were in the wrong slots. I was also able to get
the jumpers set right on the G110 card. Now when I power up I can definitely
read core correctly. There's a random assortment of data in sequential
locations and returning to those same locations I always get the same value.
That's a plus.
However, I can't store anything. Anytime I store a new value in a location,
that location gets all zeros. Moving to another location I get data, and
moving back - zeros. So it appears to be challenged in writing, but not
reading, memory. The plot thickens :)
Ah, but your memory is core, right? In which case, a 'read' is actually a
write followed by a restore. Since you can read the same location and
keep on getting the same data from it (you can do that, right?), the
memory is basically working (for both read and write).
Now, Unibus lines are almost all active-low. The data lines certainly
are. Which means that a word of 0's corresponds to all the lines being
high. And they're pulled up by the terminator ,and pulled down by the
drivers on one of the CPU boards. Maybe you've got an enable problem to
that driver, or maybe the data input buffers on the memory are playing
up, or....
You could try writing to something else (perhaps the data register on
your conosle termial card) to see if you can write to anything on the
Unibus. Or if you have a logic probe, you could see if the data lines
pulse low when you try writing 1's to a memory location.
-tony
3 Mar
3 Mar
1:12 a.m.
Tony wrote...
Ah, but your memory is core, right? In which case, a
'read' is actually a
write followed by a restore. Since you can read the same location and
keep on getting the same data from it (you can do that, right?), the
memory is basically working (for both read and write).
Correct, I'm aware core
does the write after read. I'm suspecting unibus
trouble but see below...
You could try writing to something else (perhaps the
data register on
your conosle termial card) to see if you can write to anything on the
Unibus. Or if you have a logic probe, you could see if the data lines
pulse low when you try writing 1's to a memory location.
I'll have to
figure out what address my console card is. I'll see if there's
any docs on bitsavers for the M7800. If I'm reading some of the paperwork
correctly, whatever memory address the card is set for corresponds to a real
core location and I'd just read/write to that specific address (DEC has a
rather odd definition of the word "register" to me) to see if the problem
changes. However, if I have a unibus problem, isn't the M7800 which is in an
SPC slot still going across the unibus? I haven't had my logic probe out in
years... I thought it blipped on pulse high not pulse low. Surely that's
settable. I'll check :) More germane info below...
One thing I noticed I'm not sure I mentioned. When I turn on both power
supplies, 9 out of 10 times the system will come up with the pause and
master lights lit. No switches on the front panel will do anything at all.
Even setting the halt switch and hitting start (the lights change while
start is depressed, but when releasing start the lights go back just the way
they were and no switches change anything). The only way I found to turn on
the system and have the front panel come up active is to move the halt
switch to halt and then power up. Then I can read core, etc. I'm not sure
what this behaviour means, but reading some docs I have it sounds like this
indicates a problem with unibus getting to the memory.
Thanks for all the advice!
Jay West
6:34 p.m.
Tony wrote...
Might be listed as DL11-A through DL11-E.
Ah, but your memory is core, right? In which
case, a 'read' is actually a
write followed by a restore. Since you can read the same location and
keep on getting the same data from it (you can do that, right?), the
memory is basically working (for both read and write).
Correct, I'm aware core
does the write after read. I'm suspecting unibus
trouble but see below...
You could try writing to something else (perhaps
the data register on
your conosle termial card) to see if you can write to anything on the
Unibus. Or if you have a logic probe, you could see if the data lines
pulse low when you try writing 1's to a memory location.
I'll have to
figure out what address my console card is. I'll see if there's
any docs on bitsavers for the M7800. If I'm reading some of the paperwork correctly, whatever memory address the card is set for
corresponds to a real
core location and I'd just read/write to that specific address (DEC has a
rather odd definition of the word "register" to me) to see if the problem
changes. However, if I have a unibus problem, isn't the M7800 which is in an
SPC slot still going across the unibus? I haven't had my logic probe out in
Yes, exactly. My idea was to see if you could write to anything on the
Unibus. If you can't, then the problem is probably in the processor. If
you can, then the problem is probably in the memory.
years... I thought it blipped on pulse high not pulse
low. Surely that's
settable. I'll check :) More germane info below...
It doesn't matter. The data line is normally high, when you write a 1,
the processor brings it low, and then lets it go high again at the end of
the cycle. If your probe detects the rising edge, it'll still show
something changing (which is what you care about here).
-tony
10:40 p.m.
Ok, found the jumpers for the DL11 in the schematics section on bitsavers. I
have two M7800's, one is set for 777560 and one is set for 776500.
I'm assuming that when a card is jumpered so (the high bits are constant
anyways), that it appears exactly at that address no matter how much memory
is installed in the machine (ie. it doesn't move around based on maxmem).
Anytime I exam 777560 I get an address error. If I exam 776500, I get a 200,
but anytime I store a value and read it back, there's all zero's in the data
register.
Methinks the problem wasn't memory, but something amiss in the cpu section.
Bummer as I have no spare cpu cards. But I guess at this point I still don't
know if it's a unibus problem or a cpu problem.
Something else I noticed is the terminator cards in front and back as well
as the cpu backplan to MF11-L had what I would think is a lot of "up down
wiggle" in them. I'm quite sure they are seated completely, but I can turn
them up or down more than I would think one should be able to. Is that
common?
Hopefully sage listemembers can offer some advice as to where to go next :)
Jay West
8:06 p.m.
You wrote...
It's a UART. Unless you wire it for loopback, you
normally won't read
back the same data you wrote.
Yeah, it's a UART. But I assumed you wrote data
to a register, then wrote
data to a different register to strobe the data out, etc. So I figured the
first register was just a temporary buffer that would hold it's contents
until replaced by data in the opposite direction. My bad.
I'll look up the test loopback adapter wiring.
Jay
5 Mar
5 Mar
4:12 p.m.
>>>> "Jay" == Jay West <jwest
at classiccmp.org> writes:
Jay> You wrote...
> It's a UART. Unless you wire it for loopback,
you normally won't
> read back the same data you wrote.
Jay> Yeah, it's a UART. But I
assumed you wrote data to a register,
Jay> then wrote data to a different register to strobe the data out,
Jay> etc. So I figured the first register was just a temporary buffer
Jay> that would hold it's contents until replaced by data in the
Jay> opposite direction. My bad.
DEC UARTs have a receive and a transmit register. Receive is
read-only, of course. Transmit could be write-only or read-write. I
would have expected read-write. Usual practice was to make things
read-write if they had to be writeable, as an aid to diagnostics.
Write-only registers are a real pain for diagnostics writers because
you can't tell if the bits are working, so DEC avoided them as a
normal design practice.
paul
4 Mar
4 Mar
7:35 p.m.
Ok, found the jumpers for the DL11 in the schematics section on bitsavers. I
have two M7800's, one is set for 777560 and one is set for 776500.
OK, a farily standard pair of addresses. The former is the console port.
I'm assuming that when a card is jumpered so (the high bits are constant
anyways), that it appears exactly at that address no matter how much memory
is installed in the machine (ie. it doesn't move around based on maxmem).
Absolutely.
Anytime I exam 777560 I get an address error. If I exam 776500, I get a 200,
Odd... That implies your console card is not responding. Maybe it's
defective too.
but anytime I store a value and read it back,
there's all zero's in the data
register.
You shouldn't be able to read/write all 16 bits -- some of them plain
don't exist in the heardware, some are read-only. But IIRC there's at
least one bit (my memory is weak on this, but I think it's the interrupt
enable bit, maybe bit 6) that you should be able to read and write from
the panel.
My idea was going to be to hang a terminal off the card (assuming you
have an RS232 lead and can decode the word foramt and baud rate settings
[1] and then try writing to the transmit data registers at 777566 or
777656. See if you can transmit chracters to the terminal.
[1] The baurd rate is set by a rotary switch on the card and by the
frequency of the crystal fitted. I found the quickest way to work it out
was to connect a frequncy counter to pin 17 (Rx clock) and 40 (Tx clock)
of the UART chip. Then divide that frequency by 16 to get the baud rate.
But I guess you don't have a frequency counter sitting on top of your
machine...
Methinks the problem wasn't memory, but something amiss in the cpu section.
So do I.
Bummer as I have no spare cpu cards. But I guess at
this point I still don't
I am going to get you to repair that machine properly -- without swapping
boards -- even if I have to get on the next p'lane across the Pond and
show you where to stick your 'scope probe ;-)
know if it's a unibus problem or a cpu problem.
Something else I noticed is the terminator cards in front and back as well
as the cpu backplan to MF11-L had what I would think is a lot of "up down
wiggle" in them. I'm quite sure they are seated completely, but I can turn
them up or down more than I would think one should be able to. Is that
common?
You have got them in the right way round, with the resistors towards the
front of the machine, I hope! If not, you will have all sorts of
problems.
Hopefully sage listemembers can offer some advice as to where to go next :)
Ge ta Unibus pinout, grabe the logic probe, and see if the data lines
ever go low on a CPU (frontpanel) write operation.
-tony
9:04 p.m.
Tony wrote...
Odd... That implies your console card is not
responding. Maybe it's
defective too.
Kinda what I figured :)
But IIRC there's at
least one bit (my memory is weak on this, but I think it's the interrupt
enable bit, maybe bit 6) that you should be able to read and write from
the panel.
Ah ok, good thing I printed off those engineering notes. I'll track
down the
interrupt enable bit and try that.
My idea was going to be to hang a terminal off the
card (assuming you
have an RS232 lead and can decode the word foramt and baud rate settings
[1] and then try writing to the transmit data registers at 777566 or
777656. See if you can transmit chracters to the terminal.
I have the appropriate
cable from the card to mate & lock, I'll cobble
something together to go from that to a terminal. I thought you were saying
just to read/write to that register. I'll decode the rest of the settings on
the board (other than the register address) including the crystal, and hook
up a terminal.
[1] The baurd rate is set by a rotary switch on the
card and by the
frequency of the crystal fitted. I found the quickest way to work it out
was to connect a frequncy counter to pin 17 (Rx clock) and 40 (Tx clock)
of the UART chip. Then divide that frequency by 16 to get the baud rate.
But I guess you don't have a frequency counter sitting on top of your
machine...
Well, as of now, my HP 5315A counter is sitting on top of it :) I'll
make
the measurements tomorrow. I'm glad you said that, because I noticed the
rotary switches for TX & RX speed settings weren't labled (1-10) on the
card. This way I can be sure. However, my usual question follows... if I
connect to 17 and 40 (separately of course), what is the ground reference
location for those measurements? I never seem to know where to hook the
other lead :\ In this case, if I can find a pinout for the UART, I'm sure
that would be a good spot for ground.
I am going to get you to repair that machine properly
-- without swapping
boards -- even if I have to get on the next p'lane across the Pond and
show you where to stick your 'scope probe ;-)
I'm willing to learn, travel
won't be necessary, just an informed instructor
:)
You have got them in the right way round, with the
resistors towards the
front of the machine, I hope! If not, you will have all sorts of
problems.
Yes, component side of all boards is towards the front, including the two
terminators.
Ge ta Unibus pinout, grabe the logic probe, and see if
the data lines
ever go low on a CPU (frontpanel) write operation.
If I can get some 11/45 time
this weekend, I will do just that.
Thanks!
Jay
11:11 p.m.
Nah, thanks though. I'm ok as long as I have at least one working. I'll have
to just fix the other one sometime!
Jay
----- Original Message -----
From: "Ashley Carder" <wacarder at usit.net>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Friday, March 04, 2005 8:49 PM
Subject: RE: 11/45 progress
I have a few spare M7800s if you want to borrow one.
Ashley
Odd... That implies your console card is not
responding. Maybe it's
defective too.
Kinda what I figured :)
5 Mar
5 Mar
7:41 p.m.
Tony wrote...
Or alternatively you've got address bus problems too...
Odd... That implies your console card is not
responding. Maybe it's
defective too.
Kinda what I figured :) But IIRC there's at
least one bit (my memory is weak on this, but I think it's the interrupt
enable bit, maybe bit 6) that you should be able to read and write from
the panel.
Ah ok, good thing I printed off those engineering notes. I'll track
down the
interrupt enable bit and try that. My idea was going to be to hang a terminal off
the card (assuming you
have an RS232 lead and can decode the word foramt and baud rate settings
[1] and then try writing to the transmit data registers at 777566 or
777656. See if you can transmit chracters to the terminal.
I have the appropriate
cable from the card to mate & lock, I'll cobble [1] The baurd
rate is set by a rotary switch on the card and by the
frequency of the crystal fitted. I found the quickest way to work it out
was to connect a frequncy counter to pin 17 (Rx clock) and 40 (Tx clock)
of the UART chip. Then divide that frequency by 16 to get the baud rate.
But I guess you don't have a frequency counter sitting on top of your
machine...
Well, as of now, my HP 5315A counter is sitting on top of it :)
I'll make the measurements tomorrow. I'm glad you said that,
because I noticed the
rotary switches for TX & RX speed settings weren't labled (1-10) on the
card. This way I can be sure. However, my usual question follows... if I
connect to 17 and 40 (separately of course), what is the ground reference
location for those measurements? I never seem to know where to hook the
There is one common ground (0V) rail for the entire machine. It is
carried over the unibus cables (unlike the power voltages, which are
separately supplied to each backplane and device). It's also connected to
the chassis metalwork of the machine
For high-frequency work, you should pick a ground close to the point
you're measuring since the ground wires do have some impedance. But for
low frequency tests which this is, you can use any ground in the machine.
The best one is the ground pin of the chip you're working on, or a chip
near it on the same board, but I suspect just clipping the ground lead of
your counter onto the CPU chassis will do.
other lead :\ In this case, if I can find a pinout for
the UART, I'm sure
that would be a good spot for ground.
My memory says pin 3, but _please check that_.
You have got
them in the right way round, with the resistors towards the
front of the machine, I hope! If not, you will have all sorts of
problems.
Yes, component side of all boards is towards the front, including the
two
terminators. 
8:34 a.m.
----- Original Message -----
From: "Tony Duell" <ard at p850ug1.demon.co.uk>
To: <cctalk at classiccmp.org>
Sent: Friday, March 04, 2005 7:35 PM
Subject: Re: 11/45 progress
<snip>
Here here!
And its about time too.
Jay's been spoiled working with HP's too long, and the next thing he need to
check is where he's left his o-scope.
Bummer as I
have no spare cpu cards. But I guess at this point I still
don't
I am going to get you to repair that machine properly -- without swapping
boards -- even if I have to get on the next p'lane across the Pond and
show you where to stick your 'scope probe ;-)
8:34 p.m.
Bummer as I have no spare cpu cards. But I guess at
this point I still
don't
I am going to get you to repair that machine properly -- without swapping
boards -- even if I have to get on the next p'lane across the Pond and
show you where to stick your 'scope probe ;-)
10:36 p.m.
Tony wrote...
YEs, many HP 'service manuals' were just
boardswapper guides,
Hasn't been my experience anyways. Every piece of HP gear
I have includes
full schematics, detailed theory of operation, etc. There is one
exception... a service manual on some of the very late 5.25 hard drives...
no schematics there.
Jay
6 Mar
6 Mar
2:20 p.m.
Tony wrote...
It probably depends on which HP division produced the manuals...
The ones I have for test equipment are _excellent_, with schemaitcs,
theory, calibration information, and so on. Some of the best manuals I've
seen.
Ones for handheld calculators were not supposed to get out from service
centres, but a few did. Again, they're excellent, and contain a lot more
info than you'd need to fix the machine (particularly if you're a service
centre with all the spares to hand!)
I've not see many computer manuals. Certainly the one for the 2100A is
excellent (one day I must get that machine running again). The one for
the 85A is less good. There are full schematics in the appendix, but no
theory of operation, etc.
Which leaves the class of machine I work on the most. Desktop
calculators. AFAIK, _no_ desktop calculator service manual contained any
schematics for the logic. If you're lucky the PSU schematics are there.
Which is why HOPCC started producing their own info on these machines...
-tony
YEs, many HP 'service manuals' were just
boardswapper guides,
Hasn't been my experience anyways. Every piece of HP gear
I have includes
full schematics, detailed theory of operation, etc. There is one
exception... a service manual on some of the very late 5.25 hard drives...
no schematics there.
5 Mar
5 Mar
11:28 p.m.
No, I'm implying that HP's very rarely need component level debugging.
It seems your average HP 21MX will have a lot fewer hours on it than an
11/35 or an 11/34.
----- Original Message -----
From: "Tony Duell" <ard at p850ug1.demon.co.uk>
To: <cctalk at classiccmp.org>
Sent: Saturday, March 05, 2005 8:34 PM
Subject: Re: 11/45 progress
Here here!
And its about time too.
Jay's been spoiled working with HP's too long, and the next thing he need
to
check is where he's left his o-scope.
I hope you're not implying that HP machines can't be repaired properly
(to component level) as well. YEs, many HP 'service manuals' were just
boardswapper guides, but there are unofficial schematics of many HP
calculators (including desktops) available from Dave Colver at HPCC.
We've not attacked any minicomputers -- YET!
-tony
Bummer as I
have no spare cpu cards. But I guess at this point I still
don't
I am going to get you to repair that machine properly -- without
swapping
boards -- even if I have to get on the next p'lane across the Pond and
show you where to stick your 'scope probe ;-)
7074
days inactive
7078
days old
20 comments
6 participants
participants (6)
-
ard＠p850ug1.demon.co.uk -
bshannon＠tiac.net -
eric＠brouhaha.com -
jwest＠classiccmp.org -
pkoning＠equallogic.com -
wacarder＠usit.net