28 Apr
2007
28 Apr
'07
8:13 p.m.
On Fri, 2007-04-27 at 23:11 +0100, Tony Duell wrote:
Ypu're lucky (or I'm stupid). Most of the time I find I do need
schematics
Dunno... Is working on mostly the same type of equipment lucky? If
so, I am. I just get familiar with the "top ten" failures, and often
know about them. I worked for a while repairing warehouse robots. They
communicated with the central computer via a serial signal imposed on
the A.C. mains. That meant that they used optical isolators to keep the
A.C. out of the computer itself. When an I/O board would come in that
couldn't talk via serial, I'd just pull the optical isolators, and
replace them. Those chips were very cheap. Nine times out of ten, or
better, that got it. No magic, no special luck, no great talent, just
experience.
I wouldn't. I'd want to go back a stage to that dot-expansion logic I
mentioned later. I think, if that was malfucntioning, it could hold the
dotstram line to that 'S153 in either state.
Maybe you should bet me. <Grin> I say that because nothing is
half-bright, it's all off or full. Also, NO dots. The dots and the
brightness only come together in the mixer... no?
Sorry... beyond the scope of my education...
So, if you disable PAM and just get na MS-DOS screen,
what you're saying
is that the screen is mostly white, with black blocks where the prompt
would be ? THat's really strange...
You have it... Yeah, I thought it was strange, too.
Boy do you need the schmatics! I've looked at the
150 'Video Alpha
Display Sybsystem' and the overall design is what you'd expect, but the
details are odd. And I susepct it's one of those odd bits that's causing
the problems
Yeah. <Grumble, grumble.> Most problems I've seen with computers,
probably more than three quarters, do NOT need schematics to solve. OK, the basic dsegin is a CRT controller -- here an
SMC9007 (U315) which
addreeses the video RAM. The output of the video RAM is 16 bits wide
(character and attrboutes), the character part -- 10 bits of it -- goes
to the address lines of a character generator ROM U512. The output of
that goes to a shift register (U511 and U612, 'S195) which does the
obvious dot serialisation.
The attribute logic is compiclated, but based round a 16L6 HAL (mask
programmed PAL) U314. I do _not_ have the PAL equatiuons. The outputs of
that are latced (U614, '174) and feed the 'Dot Stream Mixer', a 'S153 mux
which combines the alpha dots and the graphics system dots, and which
then produses the Full Brightness and Half Brightness signals to the
'Sweep' (monitor) PCB.
Just from the symptoms, I'd bet a reasonable meal on the S153 mux. I can't see how the 'S153 would slow the
signal down sufficiently to
remove all the character pattern data.
Slow down? How about a burnt-out amp in the mixer that is not
passing the dot data?
The
calibration of the crystal oscillator takes about three days to
do correctly, and stays within tolerance for about 15 months, if I
remember the data correctly. You'd be disappointed by the rubidium beam
frequency reference, however. It drifts, too, albeit not quite as fast
I am suprised. What on earth is the mechanism for that, and how do you adjust it.
Likewise.
What actually controls the frequency of the Rb beam
standard,
and how does it drift
EVERY frequency drifts. The question is: How much, and how
repeatably? (or, maybe that's two questions....)
As far as I know, there's no way to adjust the Rb beam. A beam of
electrons is deflected by electronics, and hits a target. The frequency
of the adjusting signal is "tuned" to keep the beam spot on the target.
The Rb standards were a couple of orders of magnitude less stable than
the Cs standards. Again, I don't know why, I just know WHAT.
Peace,
Warren E. Wolfe
wizard at voyager.net