I have three AlphaServer 2100 systems in storage in the UK
(Oxfordshire). The storage, however, is due to be demolished (soon, but
no fixed date).
I won't have room to store these three systems, so if anyone would be
interested in offering them a home, then please get in touch!
I can probably get some pictures in the next day or two.
These systems were SMP Alphas and could sport as many as 4 CPUs. I'm not
sure of the configuration of these systems but I can probably find that
out soon.
They have not been run since ~2003 so they may be in need of some TLC.
OTOH they are not rusted to death so you have a chance of getting them
back to life.
Just so you know what you might be dealing with these systems are about:
700mm H x 430mm W x 810mm L.
I can't find the weight in any of my references right now but they are
very heavy. Three people can move them up a slight slope with some
effort but you would not successfully lift it into a car (assuming that
it would fit). I'm planning to dismantle them to move them (i.e. remove
PSU/PSUs etc. until they are light enough to move). A tail-lift would
probably be the sane way to go (and is, indeed, how they got to their
current location.
I'm hoping that someone can step forward and offer one or more of these
machines a new home. Please contact me off-list (once you're sure you
understand what you are getting into :-)).
Antonio
--
Antonio Carlini
antonio at acarlini.com
> From: Tony Duell
> A short in FET Q15 on the bias/interface board in the PSU could do it.
> The gate of that FET is driven from an LM339 comparator the -ve supply
> of which is -15V.
Ah; I hadn't even looked at the P/S prints.
(Like I said, I'm really weak on analog: for digital, I have the advantages
that i) although I'm basically/mostly a software person, the MIT CS
department is part of the EE department, and they made sure that all the CS
people had a decent grounding in the fundamentals of digital hardware; and
ii) in my early years, I was involved in a number of actual hardware
projects, including a UNIBUS DMA network interface that tuned into an actual
product. So I'm pretty good with a digital circuit diagram, like these CPU
prints. But analog stuff is still a mostly-closed book to me! :-)
Anyway, I'm happy to let you provide the analysis of the P/S... :-)
> From: Rob Jarratt
> [Perhaps] something else on the CPU caused Q15 to fail (if indeed it
> did).
I'd guess 'unlikely' (if Q15 has failed); UNIBUS ACLO is connected, on the CPU
card, to only a single gate (on K2), and that 383 ohm pull-up (on K3), and the
1K pF cap there (the purpose of which I still don't understand, unless it's
just a smoother). Although I suppose that if that cap failed, shorted, maybe
that could have taken out Q15 somehow.
> Perhaps I should ... and disconnect ACLO, DCLO and LTC, they are all on
> the same connector
Now why didn't I think of just un-plugging that whole connector! Duhhhh! My
only concern would be leaving inputs floating...
DCLO, no problem; it has that pull-up on K3. (Ditto for ACLO, if the buffering
input gate isn't dead.) LTC, let's see... It's on K6, upper left corner. I'm
too lazy to work out what leaving that input floating will do, and, if it has
bad consequences, trace out all the places it goes (it should be connected up
to cause an interrupt, somewhere), but there's no point; the KW11 has an
'interrupt enable' that has to be set by software before it can do anything;
so at the moment it's safe to just ignore it for now, and stay with a focus on
getting the main CPU clock running. (LTC is not on the UNIBUS, so there's no
pull-up on the M9302 for it the way there is for ACLO & DCLO.)
So unplug that connector, and see if E70 (on K2, lower right corner) is OK.
(Remember, the pull-up will give it an Ok input with BUS ACLO disconnected.)
If yes, great, go check the main CPU clock.
If not, time to i) see how far the rot has spread (e.g. have other gates in
that package died - not sure what else is in there; not just looking at things
connected to the output - on pin 2), and ii) decide how to repair or
temporarily bypass. (Ditto for anything else that got taken out.) I'd be
tempted to bypass it (since I doubt you stock 8837's - although I do :-) -
ACLO handling isn't needed to get the CPU running. Tie BUF (not BUS!) ACLO to
ground, I'd say, and we can move on to look at MCLK.
> If that works then I think repair ACLO and see if anything on the CPU
> is bad or anything else that might cause a short on the ACLO signal of
> the bus.
Well, your call, but i) working ACLO isn't needed to get the CPU running -
and, in particular, to look for other problems that might be preventing it
>from running, and ii) fixing ACLO isn't guaranteed to make the CPU work.
I'd recommend 'keeping the eye on the ball', and focus on the main CPU clock,
getting ODT running, etc. The ACLO issue(s) can be cleaned up at your leisure.
Noel
> From: Brent Hilpert
> So apparently I've been looking at the wrong +5V supply (H777) because
> the rest of you are indeed looking at a different +5 supply (H7140),
> both of which are in that same 11/24 pdf document
That's because the H777 is the P/S for the BA11-L 5-1/4" box, and the H7140
is the P/S for the BA11-A 10-1/2" box - both of which are, quite reasonably,
covered in the -11/24 print set.
> I really wish when people are asking for assistance or talking about a
> schematic or circuit they would include a link/reference to exactly
> what they are looking at
But everone probably _was_ looking at the same document - just different
pages! Alas, DEC doesn't number _all_ the pages with a 'unique within the
print set' identifier. Still, one could say 'page xx of the PDF'.
Noel
> From: Rob Jarratt
> I found these two signals and ACLO is low (-15V)
'Good news, bad news'...
Bad is that something is seriously wrong there; 'allowed' values are 0v
(asserted) and +3V (un-asserted). I'm worried that the -15V will have taken
out some of the semiconductors that are 'listening' to ACLO (like E70, page
K2 of the CPU prints, lower right corner) - and possibly some of the things
that are connected to _them_.
Good news is that i) this would definitely cause a problem, so we're closing
in, and ii) even better, the machine doesn't actuallly _need_ the ACLO (or
DCLO) signal from the P/S to function properly. Just disconect them (which may
be a bit tricky; IIRC you've got a BA11-A - but you can pull the pin in the
connector shell of the power harness from the backplane, details of that here:
https://gunkies.org/wiki/DEC_power_distribution_connectors
or, worst case, just cut the yellow wire to pin 4 of the 6-pin connector). At
that point the pullups on ACLO (on the M9302 and the CPU - page K3 of the CPU
prints - that's odd, there's a pullup to +5V there, but a cap to ground; the
M9302 does indeed have the pull-up/down resistor pair on both ACLO and DCLO)
should pull ACLO high and the clock should now run (CLK LED on) - unless the
-15V killed something.
If the machine then runs, it's up to you as to whether you get the P/S
repaired so that ACLO work properly - your call. (I wonder how the -15V got
to ACLO - I suspect a solder bridge from the prior repair - but knowing the
answer is not important to getting the machine running.)
> DCLO is high and the DC ON light is illuminated
Good.
> the CPU doesn't do anything presumably because ACLO is asserted.
Yes. As long as the CLK LED is off, the machine will definitely be totally
dead. If you can get it on, ODT should run (modulo issues yet to be sorted
about the minimal functional machine - I'll post on that in a moment).
Noel
I had the H7140 PSU in my PDP 11/24 repaired a little while ago and I posted
about it here: https://robs-old-computers.com/2022/02/10/pdp-11-24-progress/
I have since had the PSU fixed again and it came back a couple of weeks ago.
When I installed it and applied power to the input, I heard a reassuring
relay click.
So I powered it on. The fans turned, but there was a crackle and I smelt
something burning. I couldn't locate the smell, there were no lights on the
CPU board, but the fans continued to turn.
I had to leave it a few days and today I went back to it to check things a
bit more carefully. All the power outputs of the PSU appear nominal.
However, the ripple seems quite high, with an amplitude of 600mV on the +5V
output: https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-ripple.jpg.
The DC ON light comes on, but the M7133 CPU LEDs show no activity
whatsoever.
There is no apparent damage to the CPU or to the M7134 that was also
installed. So, I guess the component that blew up must be inside the PSU.
Presumably, whatever the part is, it is stopping the CPU working, because
previously the CPU did appear to show some activity, although of course it
could still be a failure on the CPU. I am not sure what other outputs the
CPU might depend on. There is the LTC signal for the line time clock, but I
don't know if its absence would stop the CPU working. I have not been able
to test the LTC signal as yet.
Can anyone suggest what else the CPU might need? Or is it LTC?
Regards
Rob
Its 600mV, but it is more of a spike than a ripple. Here is a trace: https://rjarratt.files.wordpress.com/2022/03/pin-1-5v-ripple.jpg
Regards
Rob
> -----Original Message-----
> From: Wayne S <wayne.sudol at hotmail.com>
> Sent: 28 March 2022 23:15
> To: rob at jarratt.me.uk; Rob Jarratt <robert.jarratt at ntlworld.com>; General
> Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
> Cc: Chris Zach <cz at alembic.crystel.com>
> Subject: Re: PDP 11/24 - A Step Backwards
>
> How bad is the ripple?
> Anyone on the list know what?s acceptable?
>
>
> Sent from my iPhone
>
> > On Mar 28, 2022, at 14:46, Rob Jarratt via cctalk <cctalk at classiccmp.org>
> wrote:
> >
> >
> >
> >> -----Original Message-----
> >> From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Chris Zach
> >> via cctalk
> >> Sent: 28 March 2022 20:57
> >> To: cctalk at classiccmp.org
> >> Subject: Re: PDP 11/24 - A Step Backwards
> >>
> >>> I don't think the CPU is working at all. The reason being that there
> >>> is absolutely no LED activity. Including an LED that is supposed to
> >>> indicate a clock. Having hopefully eliminated all the power voltages
> >>> it left me wondering if there was a fault on the CPU or in the PSU.
> >>> Having had activity on those LEDs recently it seems most likely that
> >>> it will be the PSU, particularly as *something* in there blew up.
> >>> The only signal that I can identify that seems likely to have this
> >>> kind of effect is LTC, but I don't know enough about LTC to know if
> >>> its absence could cause the CPU board not to work at all, although I
> >>> see above that you think it unlikely. I suppose the fault could be
> >>> something I can't see on the CPU board, particularly as there do
> >>> seem to be some quite large spikes, otherwise I am not sure if there
> >>> is anything else from the PSU that could prevent the CPU getting going.
> >>
> >> I'm on a nice long train trip right now but I recently got my 11/24
> >> running again. One thing that baffled me was it would not do anything
> >> on the serial port. No ODT, no nothing.
> >>
> >> Turns out you really need to make sure the slots are filled properly.
> >> The CPU top, then the memory map, then for the next 4 boards one has
> >> to be either a properly configured MS11-PL (the 128kw board) or the
> >> memory boards specific to that type of 11/24. Or you have to put
> >> G7273's in the CD slots.
> >>
> >
> > I have been reluctant to put everything back in, in case the PSU fries
> something. And the ripple I noticed is certainly something that bothers me.
> Previously I had a burning smell from the memory board. I have since
> replaced all the electrolytics on the memory board, but I have not tried
> putting it back in the machine since. Just checking my notes, it seems I have
> had *intermittent* lack of activity on the CPU LEDs before, so it may be
> worth trying to put everything back in, although the ripple makes me
> hesitant to do so. For the record, right now I have only the M7133, M7134
> and G7273 installed.
> >
> >
> >> Next you need proper devices or G7273's in the next two slots and a
> >> proper terminator in the left sockets of the last slots and a G7273 in the
> center slots.
> >> Only then will ODT work.
> >>
> >> Another oddity is that the 5.25 inch box has +5 and +12 I think and
> >> the
> >> 10.5 has +5 and +15. There are different memory boards that work in
> >> one and not the other, or both depending on jumper settings that have
> >> to be right. Unibus drives me bonkers sometimes with the number of
> >> different voltages requires (+5, +12, +15, +20, -15, etc....) It
> >> doesn't help that the +15 and +12 are on the same pins.
> >>
> >> Plus it's possible someone screwed with some switches, make sure they
> >> are set properly (ie: default is a good start).
> >>
> >> If you're still stuck next week drop me a line and I'll fire up my
> >> 11/24 and see if I can replicate your failure.
> >>
> >>>
> >>>>
> >>>> The first will tell you that i) the CPU is basically functional,
> >>>> executing
> >>> micro-
> >>>> instructions, etc; ii) that the bus is basically functioning (for
> >>> master-slave
> >>>> cycles; DMA and interrupts will remain to be checked out); iii)
> >>>> that the console port is working. (Yes, on the KDF11-U, the console
> >>>> is on an
> >>> internal
> >>>> bus, and so in theory a machine could have the ODT 'front panel'
> >>>> working, _and_ still have a problem with the bus, but depending on
> >>>> the exact details of said problem, maybe not.)
> >>>>
> >>>> So, hook up a console, set the machine to 'halt', and power on. Is
> >>>> console ODT working? If so, congrats, you win, go to stage ii) below.
> >>>
> >>> I had a console attached. There is nothing on the console. When I
> >>> first got the machine I did get output on the console. But that was
> >>> before the PSU first failed on me, which is quite a few years ago now.
> >>>
> >>>>
> >>>> If not, you have a reduced area in which you have to investigate -
> >>>> and
> >>> you'll
> >>>> need a 'scope of some kind to make any progress. (If you don't have
> >>>> one, you're SOL. Get one.). In order i) is the CPU's internal clock
> >>>> (and thus, probably the microcode) running? (At this point you will
> >>>> need to consult
> >>> the
> >>>> "PDP-11/24 System Technical Manual", EK-11024-TM.) If so, is it
> >>>> trying to
> >>> talk
> >>>> to the console's registers? (See Section 4.6 of the TM, "Internal
> >>>> Address
> >>>> Decode".) If so, is the UART working properly? (4.7 of the TM,
> >>>> "Serial
> >>> Line
> >>>> Units".)
> >>>>
> >>>> If so, console ODT is running, you're now at stage ii): you can see
> >>>> if the
> >>> CPU
> >>>> will run. Deposit a 0777 ('BR .') in a likely location (I usually
> >>>> use
> >>>> 0100 or 01000); read it back to make sure the write succeeded. (If
> >>>> not,
> >>> likely
> >>>> either the UNIBUS or the main memory has a problem.) Start the
> >>>> machine; the 'Run' light should come on - if you're lucky!
> >>>>
> >>>> Depending on which bin you wound up in, further assistance s
> available.
> >>> :-)
> >>>>
> >>>> Noel
> >>>
> >
> From: Brent Hilpert
> But the LED and CPU clock are not driven directly by that RC oscillator
> - there's a bunch of logic in-between the oscillator and the LED / CPU
> clock.
Oh, sure; it was late (for me; the dog woke me up at AM today :-), and it had
taken me a while to get even that far (find the freakin' thing), so I just
wanted to pass the ball forward and crash!
I saw the "STOP OSC H" signal feeding into the production of "PRE OSC L", but
couldn't fully work out all the things that fed into that - and it now looks
like that's not an important thing anyway, "MCLK H" is the one to look at.
> [RC clock] => K1 OSC H/L
> --> [4-bit counter w parallel load] => K1 MCLK H/L
> --> LED
It seems to me that the LED, being driven directly by MCLK L, should be
flashing at the basic clock rate (i.e. dim to the eye) - so if it's totally
off, MCLK L must not be running. So that's thing absolutely numero uno to
investigate.
> --> [driver] => K1 CHIP CLK H (fonz CPU clock)
Yeah; the Fonz also gets "MCLK L" on pin 19, though - not sure what that's
for. Eh, not important at the moment.
> The 4-bit counter looks to be generating some additional phases
Yeah, section 4.2 "Timimg" of the -11/24 TM talks about all the various
clocks in some detail.
> but it's also controlled by a bunch of other signals. One of those
> signals is K6 BUF DCLO L which can hold the counter in reset, i.e.
> disable the Master/CPU clock (and LED). K6 BUF DCLO L is derived
> on-board from K2 P FAIL H
Huh? BUF DCLO L is just BUS DCLO L, run through that DS8641 bus transceiver.
But yes, because DCLO can stop the clock, checking ACLO and DCLO is priority
numero uno in the debugging process, now. (Contrary to my previous fear, the
CPU might be OK, and it might just be a power supply issue.)
> which is derived from K2 BUS ACLO L
I haven't bothered to check to see where BUF ACLO L (generated on K2) goes,
but I assume it's used in power-fail trapping stuff. (ISTR that PDP-11 PS's
sequence ACLO before DCLO, to allow power-fail trapping, before the machine is
frozen as DC power actually goes low.) Likewise, not important at the moment.
> which is input from BF1-in-funky-hex-box which I presume is a bus
> connector pin.
Yes; the ID ("BF2") is an indicator to that.
> Even if ACLO is good, there's a whack of logic on the CPU board -
> including two monostables - just to get from ACLO to DCLO
The import of those two monostables isn't completely clear to me. However,
notice that the output is fed through the DS8641 bus transceiver to _drive_
BUS DCLO; my _guess_ is that there's a delay between the PFAIL H input (which
comes from BUS ACLO L) and _the CPU_'s assertion of DCLO - i.e. if the P/S
goes bonkers and indicates ACLO, and doesn't promptly (after a suitable short
delay to allow for power-fail action) follow it with DCLO, as it is
_supposed_ to, the CPU will indicate DCLO on its own - and do it on the bus
so everbody else will freeze too.
Anyway, I think we've got as far as we can until ACLO and DCLO are checked.
I'm upgrading the CHWiki KDF11-U page to cover the stuff that's not in the
CPU chapter of the -11/24 TM, like the meaning of those on-board LED's, etc.
Noel
> From: Rob Jarratt
> today I went back to it to check things a bit more carefully. All the
> power outputs of the PSU appear nominal.
> ...
> Presumably, whatever the part is, it is stopping the CPU working,
> because previously the CPU did appear to show some activity, although
> of course it could still be a failure on the CPU. I am not sure what
> other outputs the CPU might depend on. There is the LTC signal for the
> line time clock, but I don't know if its absence would stop the CPU
> working. I have not been able to test the LTC signal as yet.
> Can anyone suggest what else the CPU might need? Or is it LTC?
I'm going to start with some meta-comments, and then add some practical
suggestions for how to proceed.
Reading this, I'm guessing that you're a software person, right? Not that
there's anything wrong with that (_I_'m basically a sofware engineer), but if
one is going to collect and run (which inevitably means maintain/repair - it
was ever thus, including BITD) vintage computers, you need to have mildly
decent hardware skills. Yes, to some degree, one can lay this off on others
(as has been done here with the power supply - something I'd do myself, as my
analog skills are not very good), but I think developing some decent digital
hardware understanding would really help.
For instance, take your question about the LTC. To some degree, a complete,
entirely accurate answer is dependent on the details of the software
(bootstrap and/or OS). However, knowing how the LTC works, what the low-level
details are of what the CPU hardware does with it, etc would tell you whether
it is a cost-effective (in terms of overall 'getting the hardware working'
project) thing to spend time on looking at, to begin with.
(Parenthetical observation: I reckon that debugging _any_ issue, hardware
_or_ software, is a process of 'what's the _cheapest_ [easiest, quickest,
etc] test I can do that will produce the _maximal_ reduction in the area that
the bug could be in. Rinse, repeat, until you've tracked the problem to its
lair.)
(You may discover, once you get the machine mostly working, that the LTC
_specifically_ isn't working - at which point you can dive into it in detail.
But until then, I'd ignore it. It's a relatively small aount of stuff, and the
chance of a problem in there is small. And even if it's broken, the likely
effects are small. There are better things to look at - below. Having a clear
understanding of the machine's major functional units, and how they interact,
would have made that clear.)
So, in addition that that overview of the major functional units, you
definitely need to know how the QBUS works (read the QBUS chapter in the
"Microcomputer Products Handbook" or the "Microcomputer Processors"
books). (Yes, I know, the -11/24 is a UNIBUS machine, but the two busses
differ only in extremely minor details; if you fully understand one, you can
learn the other in half an hour. And the -11/24's CPU is a KDF11 CPU, and uses
the microcode ODT 'front panel' of the QBUS CPUs.)
Having said that, and starting with the "All the power outputs of the PSU
appear nominal" (which rules out a large area), this is the process I'd
follow to reduce the area the problem is in as quickly as possible. (And
maybe I should transform this into a 'fault analysis of QBUS (and some
UNIBUS) PDP-11 systems' on the CHWiki.)
You need to see if the CPU is _basically working. Two stages to that: i) is
the ODT 'front panel' (in microcode) working, ii) is the CPU basically
functional - i.e. can it fetch and execute instructions. Answers to those
will greatly reduce the area in which the problem (if there's _only_ one - a
possibility one must keep in mind).
The first will tell you that i) the CPU is basically functional, executing
micro-instructions, etc; ii) that the bus is basically functioning (for
master-slave cycles; DMA and interrupts will remain to be checked out); iii)
that the console port is working. (Yes, on the KDF11-U, the console is on an
internal bus, and so in theory a machine could have the ODT 'front panel'
working, _and_ still have a problem with the bus, but depending on the exact
details of said problem, maybe not.)
So, hook up a console, set the machine to 'halt', and power on. Is console ODT
working? If so, congrats, you win, go to stage ii) below.
If not, you have a reduced area in which you have to investigate - and you'll
need a 'scope of some kind to make any progress. (If you don't have one,
you're SOL. Get one.). In order i) is the CPU's internal clock (and thus,
probably the microcode) running? (At this point you will need to consult the
"PDP-11/24 System Technical Manual", EK-11024-TM.) If so, is it trying to
talk to the console's registers? (See Section 4.6 of the TM, "Internal
Address Decode".) If so, is the UART working properly? (4.7 of the TM,
"Serial Line Units".)
If so, console ODT is running, you're now at stage ii): you can see if the
CPU will run. Deposit a 0777 ('BR .') in a likely location (I usually use
0100 or 01000); read it back to make sure the write succeeded. (If not,
likely either the UNIBUS or the main memory has a problem.) Start the
machine; the 'Run' light should come on - if you're lucky!
Depending on which bin you wound up in, further assistance s available. :-)
Noel
> From: "Rob Jarratt"
> Thanks for the lengthy reply.
Glad to help - or try to.
> As an aside I have also been trying to find a fault on a Pro 350 which
> uses the same CPU chipset. I have a pinout but no datasheet.
There doesn't seem to be as lot on the F-11 set. I looked in the DEC
semiconductor handbook, and it's not there - although perhaps it
had been dropped by the one I looked at (which was mostly uVAX stuff)
as obsolete?
If you look in the KDF11-A and KDF11-U Tech Manuals, there is a chapter on
the F-11 chip set, as used in those cards, and that's better than nothing -
it talks a fair amount about the low level details of how the various chips
operate and interact, etc.
> I don't think the CPU is working at all. The reason being that there is
> absolutely no LED activity. Including an LED that is supposed to indicate
> a clock.
Looking at the KDF11-U prints, I finally found that LED (it's pretty low
level - I was worried that it might be a bit in a register, and driven by
software, but it's not, it's actually driven directly by the the CPU's
internal clock signal; it's on page K1 of the prints, 'Clock, State Decode',
in the very upper left corner). (The source of the CPU's internal clock is
just an RC circuit, in the lower middle of that page, and the trim pot that's
part of it - along the upper edge of the board - can be adjusted to set the
clock speed 'properly', per the note at the back of the prints on the page
which lists the configuration switches. The 2MHz crystal along the upper edge
drives the baud rate generator.)
> Having hopefully eliminated all the power voltages it left me wondering
> if there was a fault on the CPU or in the PSU.
If ODT isn't running, the problem is almost certainly in one of those two
areas.
> Having had activity on those LEDs recently it seems most likely that it
> will be the PSU, particularly as *something* in there blew up.
I'm not so sure. Those boards mostly just want +5V; looking a bit more, the
CPU chips do seem to use +12V. The RS232 drivers will use +/-12V.
I'm afraid that if i) it used to show activity, but no longer does so, and
ii) the main voltages (+5V, +12V) look good, something on the CPU card has
failed. But it will take a bit of digging to i) verify that, and ii) identify
the fault.
> The only signal that I can identify that seems likely to have this kind
> of effect is LTC, but I don't know enough about LTC to know if its
> absence could cause the CPU board not to work at all, although I see
> above that you think it unlikely.
I have yet to trace how the LTC signal is used in the KDF11-U, but on the
KDF11-A, it not being there is a total NOP. (In fact, in the BA11-N/S type
mounting boxes, there's a 'Clock Enable' switch on the front panel which turns
the LTC signal off - and the machine runs fine with it off - except for the
TOD clock not ticking.) That clock signal - totally different from the main
CPU clock - is only used as an input to what is in effect a peripheral.
> I had a console attached. There is nothing on the console. When I first
> got the machine I did get output on the console.
Not a good sign, alas.
If you have a scope of some kind, and want to keep poking, I'd recommend that
you start by seeing if the clock is running, and move forward from there. The
KDF11-U prints are online, as is the KDF11-U Tech Manual. Skim the chapter on
the CPU (4, I think), and then grovel around in the prints for a bit. Don't
try to totally understand it all, just skim through it, so you know roughly
where most things are.
Noel
