1
0
mirror of https://github.com/PDP-10/its.git synced 2026-01-13 15:27:28 +00:00
PDP-10.its/doc/sysdoc/kl10.flklor
Lars Brinkhoff 6d577568a2 KL10 microcode.
Plus assorted KL10-related documents.
2018-06-12 07:58:19 +02:00

55 lines
1.9 KiB
Plaintext
Executable File
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Copyright (c) 1999 Massachusetts Institute of Technology
See the COPYING file at the top-level directory of this project.
------------------------------
KL10 Folklore
Sometimes an MF10 memory gets hung. Often the INC RQ light will be
on. Sometimes raising the RESET switch inside the memory's front door
will help; sometimes a module in the port control is fried. (Any of
several modules.)
TU41 blower belt has to correct belt, has to not be worn out, and has
to have pulleys aligned. Otherwise it drops off or breaks and tape
rotates backwards.
RP04 oscillating seeks & Maytag mode when loading => tachometer output
needs to be adjusted.
When powering machine back on, circuit breaker in disk DF10 may trip.
When powering machine back on, sometimes disk #0 needs to be stopped,
powered off and on, and started again, to reset the two-massbus
switch.
If DECtape motor doesn't win, may be G848 seating problem.
If kicking the LA36 causes power fail, "power warn" lead to top left
edge of CPU backplane needs to be disconnected. (Apparently the other
end is unconnected.) [Missing ECO in 863.]
Bad door-open switches (?) in MF10. Memories have to be operated with
over-ride turned on.
Apparently power supplies in CPU and IO box can drift voltages.
Apparently air-flow sensors can fail sporadically. I am told that
disconnecting one => indication of good airflow.
RP04 attention/error conditions are super-random.
Often mysterious marginality is caused by bad seating of modules.
CONO'ing a PI channel off doesn't necessarily prevent it from
interrupting. It works to have each interrupt routine do CONSO to make
sure the channel is enabled, and dismiss if not.
Before running a memory diagnostic, do PE0, because the memory
diagnostics don't know how to handle parity faults.
MF10's always fail solidly.
Obscure cases in the microcode tend to have bugs. E.g. you could
interrupt out of a PI cycle, hence BLKI/BLKO as interrupt instructions
tended to be flakey.