Text 126, 107 rader
Skriven 2006-05-31 18:56:02 av Peter Knapper (3:772/1.10)
    Kommentar till text 124 av Bob Ackley (1:2905/3)
Ärende: eCS 2 of 4.
===================
It had a single multiplexer channel and a single selector channel. The
selector channel was all in hardware, but the multiplexer channel was
implemented in microcode, with a small amount of dedicated hardware.
There was some additional 'auxiliary storage' (outside the main 64k
address space) which was used to store the 360's register contents
(excluding the instruction pointer which was stored in hardware) and the
multiplexer sub-channel status, where it kept track of up to 32
concurrent transfers.

The CPU clock was about 1.3MHz. In one cycle (750ns) the core could do a
single read, and on the following cycle the data would have to be
rewritten, as core reads were destructive, unless of course the data was
to be modified before being re-stored. As registers were in core the
same procedures applied there.

After much deliberation, the unit was dismembered into several large
chunks: the power supplies (after removing a very dead rat), the CCROS
unit, the core modules, the logic gate and the front panel. I didn't
have to cut many wires, but kept good records to assist with reassembly.
With the panels removed this left a bare frame, though still none too light.

The 2841 unit turned out to be the DASD (disk) controller. It was almost
as complicated as the computer itself, having its own microcode, and an
interface for each of the four drives. The drives were type 2311, with
about 7MB each (that was a huge amount in those days) and I had plenty
of disk packs. The 2841 was similarly dismantled, though it wasn't so
much of a problem.

I made up small paper templates of each unit, and shuffled them around
on a plan of the office so as to make sure I could open all the doors
and still have the cables reach between units. An electrician friend,
Doug Hook, wired three-phase power from the switchboard into the office.

All the moving was done at weekends, any other time it would have been
too difficult with traffic and other tenants. The CPU frame and the
logic gate were man-handled up the stairs without causing too much
damage to the banisters, while everything else fitted into the lift,
though at times it strained a bit.

Once everything was there, it was reassembly (reassembler?!) time. This
went pretty well, my notes were good enough and nothing had been
damaged. As this progressed, I was able to understand the FEMM manuals
more and more. They contained all the circuit diagrams, including
connector layouts, and while the components were unfamiliar I could
still use them to trace connections. One unit that was a bit tricky was
the 1051/1052 console typewriter. This was a Selectric-style unit which
was wired directly into the circuitry of the CPU, and had been
disconnected before being put into storage.

The logic was IBM's "SLT" (solid logic technology) which was similar to
DTL, and based on 0.5" square modules, each of which contained about one
gate. Four to eight modules would be mounted on a board about 2" by 3",
and these boards were in turn plugged into boards about 8" x 12", of
which there were about 30 in total on the main gate.

Once it was all back together to the best of my ability, the day came
for the big start-up. I really can't remember it too well, as it wasn't
really that eventful - in retrospect I was lucky that nothing blew up or
caught fire.

We switched on the main power feed to the CPU. There was a small clunk
from a relay somewhere, and the high-pitched squeal of the switching
supply - this evidently ran all the time even when the computer was
"off". I reached out and nervously pushed the "ON" button. There was a
loud series of relay clacks, the sound of lots of fans and the air
compressor starting, then another click and everything shut off.

I never really resolved what was happening, but I think I worked out
that there was a problem with the emergency shut-off circuitry (there
was a line running down the channel cable which linked the shut-off
switches on each unit together - I think I may have had to move the
terminator from the 2841 into the 2030 to temporarily override this) and
this was fixed by cleaning the contacts on all of the relays.

Now starting the system would produce a continuous cacophony. The air
compressor would stop after about 20 seconds, starting up every few
minutes as the air bags leaked down, but there must have been 40 fans in
there all whirring and pushing out vast quantities of hot air. I had to
remove the false ceiling panels and open the window if I wanted to have
it running for more than ten minutes.

I soon noticed that all was not well, and that the machine was stopping
soon after startup with a microcode check. This led me down a convoluted
path. The microcode is stored on a special punch card, which has silver
conductive traces screened onto it. When fed through a card punch, some
of the silver pads are removed, and the remaining pads become one half
of a small capacitor, the other half being on the circuit board (hence
the CCROS designation.) Over time, some of the silver had corroded,
resulting in dropped bits. Luckily each microcode word had several
parity bits, so these errors were picked up. I went out and bought a
small bottle of silver conductive ink from Philips and proceeded to do
my own repair jobs. It worked a treat.

Diagnosis was aided by the fact that each microcode bit had a lamp on
the front panel, and there was a single-microcode-step mode of
operation. There was also a complete set of manuals containing the
microcode (CLDs), using a graphical representation, which I soon got to
understand. Before then I had never encountered microcode. The microcode
system was quite nifty and most instructions seemed to execute in the
minimum time feasible, though even a simple register to register add
would take some 33 cycles (25 microseconds).

Contd...


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)