7 Nov
2014
7 Nov
'14
8 p.m.
So, my local bookstore guy has an IBM 5151 monitor for sale, which is
surprising because:
a) I haven't seen *any* vintage IBM PC kit locally in the last 8 years,
b) I picked up a 5160 with an MDA display adapter but non-IBM monitor from
John over in Duluth a few weeks ago, and I was thinking what a shame it was
that it didn't have the original IBM screen.
So, it's almost like it's meant to be, or something...
Of course working condition is unknown, so before I commit to it, are there
any common showstoppers with these displays (failed CRT, yoke windings,
LOPT etc.) - or are whatever faults that may be typical with them all in
components that are still available?
(I'm kicking myself a bit because he said I was welcome to bring it home
over the weekend to try it out and then bring it back if I decided I didn't
want it - I just couldn't remember at the time if the 5151 was the MDA
display or something else, but with hindsight I probably should have just
taken it regardless!)
cheers
Jules
7 Nov
7 Nov
9:44 p.m.
On 11/07/2014 05:00 PM, Jules Richardson wrote:
Of course working condition is unknown, so before I
commit to it, are
there any common showstoppers with these displays (failed CRT, yoke
windings, LOPT etc.) - or are whatever faults that may be typical with
them all in components that are still available?
In general, they were pretty reliable and *very* simple internally. The
big gotcha I've seen in these is screen burn. I can't opine on
available parts, however.
There was a time that the MGA (Hercules Graphics) was one of the better
adapter-monitor combinations for fine work. Shadow-mask color CRTs have
a certain granularity to the display, while the monochrome display
doesn't suffer from that.
--Chuck
8 Nov
8 Nov
12:49 a.m.
Of course working condition is unknown, so before I
commit to it, are there
any common showstoppers with these displays (failed CRT, yoke windings,
LOPT etc.) - or are whatever faults that may be typical with them all in
components that are still available?
It's a very simple circuit, the schematic is in the TechRef. One odd feature is that
there is no horizontal oscillator, it just drives the horizontal section from
the pulses on the Hsync (more correctly HDrive) input. As for failures, the CRT
is a common 7 pin one (although finding a spare with the long persistance
phosphor might be interesting), I have never had one fail, though. Screen
burn can be a problem (particularly if the old owner used it for spreadsheets
a lot :-)). I've never had a yoke fail. At one time the LOPT was available
from 3rd party suppliers, no idea if you can still find
one.
Biggest Gotcha is getting inside. You can end up dropping the mains transformer
(linear PSU) on the back of the CRT if you do it wrongly!. Take out the 2 square caps on
top
and the screws under them. Put the monitor face down, free the cables from the back case
and take out the 2 screws on the flange that obviously join the case parts. On the bottom
are 6 further screws, often covered by paper circles (!). Take out the 4 on the back case
part
only. These hold the chassis in place, with the heavy transformer on it, you do not want
it
totally free. Now lift off the back case.
-tony
12:17 p.m.
Hey, I had a question about this..
On Fri, Nov 7, 2014 at 11:49 PM, tony duell <ard at p850ug1.demon.co.uk> wrote:
It's a very simple circuit, the schematic is in the TechRef. One odd
feature is that
there is no horizontal oscillator, it just drives the horizontal section
from
the pulses on the Hsync (more correctly HDrive) input.
This is the same situation as the Osborne Vixen + Zenith 7" display. The
display takes in a horiz. signal (a vert. as well, but that's another
matter) which gets routed to a transistor, and then a 555 timer. From
there, one more transistor and then comes the horiz. driver & opt. section.
Anyway, the first two transistors and the 555 are collectively labeled
"horizontal oscillator".. but that's not exactly the case, is it?
I measured the horiz. input signal at roughly 16Khz; the chassis says it
uses a 15.7Khz signal, so I assume that's the true freq. So if that's the
case, it doesn't actually need an oscillator, does it? My guess was that
the 555 was more of pulse-shaping deal.. it only uses the horiz. input as a
trigger pulse, and then outputs a clean square / rectangle wave of whatever
duty they want from the 555. That pulse then gets amplified. shaped,
whatever by the next stage until it feeds the horiz. driver which in turn
feeds the HOT.
Is that what's going on in these monitors?
@Jules
I'm pretty sure I have one good-working 5151 monitor here, and just maybe a
dead unit as well. If you need the worker as a reference, you're welcome to
borrow it for as long as you require it to get yours repaired. Please just
promise to be very careful with it.. ;-)
And if I have it, the other one might be a parts donor should you need
anything specific to the design, that you can't get off the shelf etc. Keep
it in mind, for when we meet-up next spring or whenever.
6:01 p.m.
It's a
very simple circuit, the schematic is in the TechRef. One odd
feature is that
there is no horizontal oscillator, it just drives the horizontal section
from
the pulses on the Hsync (more correctly HDrive) input.
This is the same situation as the Osborne Vixen + Zenith 7" display. The
display takes in a horiz. signal (a vert. as well, but that's another
matter) which gets routed to a transistor, and then a 555 timer. From
there, one more transistor and then comes the horiz. driver & opt. section.
Anyway, the first two transistors and the 555 are collectively labeled
"horizontal oscillator".. but that's not exactly the case, is it?
10:24 p.m.
Tony,
Ok, then I guess I +really+ don't get it.
Why does the Zenith +need+ a horiz. osc. when it also requires the horiz.
input signal - which just happens to be at the exact same frequency
(15.7KHz) as the horiz. osc? What is the horiz. input used for, then, if
not to set the frequency of the 555 output?
The 555 acting as a monostable (aka one-shot) triggered by the horiz.
signal makes more sense.. I'm not saying that's the case, just that I can't
see why it would need be otherwise when a properly-clocked signal is
already provided for it. Then again, if it works the way I am presuming,
the 555 could maybe be replaced with a Schmitt trigger - eh?
On Sat, Nov 8, 2014 at 5:01 PM, tony duell <ard at p850ug1.demon.co.uk> wrote:
section.
> It's a very simple circuit, the
schematic is in the TechRef. One odd
> feature is that
> there is no horizontal oscillator, it just drives the horizontal
section
from
the pulses on the Hsync (more correctly HDrive) input.
This is the same situation as the Osborne Vixen + Zenith 7" display. The
display takes in a horiz. signal (a vert. as well, but that's another
matter) which gets routed to a transistor, and then a 555 timer. From
there, one more transistor and then comes the horiz. driver & opt. Anyway, the first two transistors and the 555 are
collectively labeled
"horizontal oscillator".. but that's not exactly the case, is it?
The IBM 5151 has no horizontal oscillator at all. The input signal goes
straight to the horizontal
driver stage.
This Zenith monitor does have an oscillator. The 555 is an astable
(compare it with the standard 555
circuits).
-tony 
11:26 p.m.
On 2014-Nov-08, at 7:24 PM, drlegendre . wrote:
Tony,
Ok, then I guess I +really+ don't get it.
Why does the Zenith +need+ a horiz. osc. when it also requires the horiz.
input signal - which just happens to be at the exact same frequency
(15.7KHz) as the horiz. osc? What is the horiz. input used for, then, if
not to set the frequency of the 555 output?
No, in a strict sense, a TV or monitor doesn't 'need' a horizontal or vertical
oscillator, it just needs the V & H sync pulses to start the ramp generation at the
proper time.
Historically however, a TV had V & H oscillators so that:
1. A raster would be present when there was no signal, in part so it didn't burn a
hole in the center of the screen.
2. The raster would ride through sync pulse dropouts on weak or marginal signals, rather
than collapsing sporadically.
3. The horizontal oscillator needed to keep going, consistently, so the CRT HiV would be
generated and stable.
(One might argue 3 mitigates 1, no HiV, no burn).
Once you have the oscillators, you still need the sync pulses to keep the raster scan
ramps in phase sync with the video picture information.
Early computer monitors were just slightly hacked/improved versions of TV monitors and old
design habits die hard.
As mentioned, some designs did do away with the oscillators, when the sync could be
relied upon to be present and stable. IIRC, the Commodore PET with it's built-in
monitor was another of those.
9 Nov
9 Nov
12:03 a.m.
Hey Brent,
I guess I'm still confused.. and for the purposes of my inquiry &
discussion, let's stick to what's going on with the Osborne / Zenith setup
- OK?
It sounds like you're saying that the horiz. osc. in the Zenith monitor is
synced in both phase & frequency to the horiz. input signal provided by the
computer motherboard. But if the horiz. signal were to disappear for some
reason, the osc. would continue to run... is that correct?
So if the osc. continued to run in absence of the horiz. signal, how would
it stay on-frequency? And much more importantly - If it's capable of
setting its own operating frequency, how does the horiz. signal input
override that? And why didn't Osborne "trust" their hardware to provide a
horiz. signal - while IBM and (as you say) Commodore PET clearly did -
ultimately, what did this amount to, if anything?
Sorry for so many dumb questions. Oh, and here's another.. about the
meaning of 'raster'.
When we talk about the presence or lack of a /raster/, do we mean the
'lighted rectangle' on the CRT screen? Or is the raster the horiz & vert
travelling beam that 'paints' the lighted rectangle? I ask, as some video
t-shooting guides have determiners like "Raster present / No raster?". I
ask, as I was taught that the scanning beam itself is the 'raster'.. but it
seems more like the evidence of that beam - a lighted rectangle - is what's
actually meant.
And yes, I know the derivation of the term. Raster is from Greek 'rastrum',
essentially meaning a rake.. which makes some sense, of course, as the H/V
systems produce a pattern on the screen much like a rake dragged across
sand.
On Sat, Nov 8, 2014 at 10:26 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2014-Nov-08, at 7:24 PM, drlegendre . wrote:
Tony,
Ok, then I guess I +really+ don't get it.
Why does the Zenith +need+ a horiz. osc. when it also requires the horiz.
input signal - which just happens to be at the exact same frequency
(15.7KHz) as the horiz. osc? What is the horiz. input used for, then, if
not to set the frequency of the 555 output?
No, in a strict sense, a TV or monitor doesn't 'need' a horizontal or
vertical oscillator, it just needs the V & H sync pulses to start the ramp
generation at the proper time.
Historically however, a TV had V & H oscillators so that:
1. A raster would be present when there was no signal, in part so
it didn't burn a hole in the center of the screen.
2. The raster would ride through sync pulse dropouts on weak or
marginal signals, rather than collapsing sporadically.
3. The horizontal oscillator needed to keep going, consistently,
so the CRT HiV would be generated and stable.
(One might argue 3 mitigates 1, no HiV, no burn).
Once you have the oscillators, you still need the sync pulses to keep the
raster scan ramps in phase sync with the video picture information.
Early computer monitors were just slightly hacked/improved versions of TV
monitors and old design habits die hard.
As mentioned, some designs did do away with the oscillators, when the
sync could be relied upon to be present and stable. IIRC, the Commodore PET
with it's built-in monitor was another of those.
5:19 a.m.
On 2014-Nov-08, at 9:03 PM, drlegendre . wrote:
Hey Brent,
I guess I'm still confused.. and for the purposes of my inquiry &
discussion, let's stick to what's going on with the Osborne / Zenith setup
- OK?
It sounds like you're saying that the horiz. osc. in the Zenith monitor is
synced in both phase & frequency to the horiz. input signal provided by the
computer motherboard. But if the horiz. signal were to disappear for some
reason, the osc. would continue to run... is that correct?
That would be the idea, you'd still have HiV, and you'd still have some semblance
of a ..raster.
So if the osc. continued to run in absence of the
horiz. signal, how would
it stay on-frequency?
And much more importantly - If it's capable of
setting its own operating frequency, how does the horiz. signal input
override that?
Speaking vaguely, each sync pulse restarts the oscillator to the beginning of a cycle.
But the free-running F of the oscillator should be near the target F so that the sync
pulse only has to 'pull' it a little ways (in time).
When you adjust the H-sync control of an (old) TV/monitor you're adjusting the H
oscillator F, to bring it into the capture range of the sync control.
Electronically, it can be accomplished in a number of manners, from a simple
'reset' of some sort to PLL style phase detection.
And why didn't Osborne "trust" their
hardware to provide a
horiz. signal - while IBM and (as you say) Commodore PET clearly did -
ultimately, what did this amount to, if anything?
Might be just a matter of who they sourced the monitor from.
It was the beginning of the period of transition from 'TVs' to 'computer
monitors'.
There are some other benefits to having the raster and HiV there when sync is lost, such
as the visible raster may give some clues as to a problem.
In the Zenith case, how much difference is there between a 555 astable and monostable? (A:
not much).
Sorry for so many dumb questions. Oh, and here's
another.. about the
meaning of 'raster'.
When we talk about the presence or lack of a /raster/, do we mean the
'lighted rectangle' on the CRT screen? Or is the raster the horiz & vert
travelling beam that 'paints' the lighted rectangle? I ask, as some video
t-shooting guides have determiners like "Raster present / No raster?". I
ask, as I was taught that the scanning beam itself is the 'raster'.. but it
seems more like the evidence of that beam - a lighted rectangle - is what's
actually meant.
I've always taken raster to mean, as you say, the lighted rectangle, drawn by an
electron beam in a progressive line by line scan.
The mere presence of a drawing beam would encompass many/all other types of CRT displays
besides raster displays.
And yes, I know the derivation of the term. Raster is
from Greek 'rastrum',
essentially meaning a rake.. which makes some sense, of course, as the H/V
systems produce a pattern on the screen much like a rake dragged across
sand.
On Sat, Nov 8, 2014 at 10:26 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
> On 2014-Nov-08, at 7:24 PM, drlegendre . wrote:
>> Tony,
>>
>> Ok, then I guess I +really+ don't get it.
>>
>> Why does the Zenith +need+ a horiz. osc. when it also requires the horiz.
>> input signal - which just happens to be at the exact same frequency
>> (15.7KHz) as the horiz. osc? What is the horiz. input used for, then, if
>> not to set the frequency of the 555 output?
>
> No, in a strict sense, a TV or monitor doesn't 'need' a horizontal or
> vertical oscillator, it just needs the V & H sync pulses to start the ramp
> generation at the proper time.
>
> Historically however, a TV had V & H oscillators so that:
> 1. A raster would be present when there was no signal, in part so
> it didn't burn a hole in the center of the screen.
> 2. The raster would ride through sync pulse dropouts on weak or
> marginal signals, rather than collapsing sporadically.
> 3. The horizontal oscillator needed to keep going, consistently,
> so the CRT HiV would be generated and stable.
>
> (One might argue 3 mitigates 1, no HiV, no burn).
>
> Once you have the oscillators, you still need the sync pulses to keep the
> raster scan ramps in phase sync with the video picture information.
>
> Early computer monitors were just slightly hacked/improved versions of TV
> monitors and old design habits die hard.
>
> As mentioned, some designs did do away with the oscillators, when the
> sync could be relied upon to be present and stable. IIRC, the Commodore PET
> with it's built-in monitor was another of those.
11:43 a.m.
I'll add this to the 5151 issue. Because the 5151 responds to *every*
horizontal sync pulse, it's quite possible to toast the flyback
transformer with the wrong frequency. I know--I've done it.
Contrast with a simple astable multivibrator which would simply lose synch .
--Chuck
12:10 p.m.
And it only takes a few seconds to disable the flyback.. permanently (yup.. done it too),
George Rachor
georgerachor at gmail.com
On Nov 9, 2014, at 8:43 AM, Chuck Guzis <cclist at sydex.com> wrote:
I'll add this to the 5151 issue. Because the
5151 responds to *every* horizontal sync pulse, it's quite possible to toast the
flyback transformer with the wrong frequency. I know--I've done it.
Contrast with a simple astable multivibrator which would simply lose synch .
--Chuck
12:20 p.m.
I also lost a 5151 monitor to a program crash, it was "Gone in Sixty
Seconds" or less. I replaced it with a third party monitor that had the
advertised feature of not burning up due to lost sync.
Michael Holley
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chuck Guzis
Sent: Sunday, November 09, 2014 8:44 AM
To: General at classiccmp.org; Discussion at classiccmp.org:On-Topic and Off-Topic
Posts
Subject: Re: IBM 5151 (MDA display) - common faults / gotchas?
I'll add this to the 5151 issue. Because the 5151 responds to *every*
horizontal sync pulse, it's quite possible to toast the flyback transformer
with the wrong frequency. I know--I've done it.
Contrast with a simple astable multivibrator which would simply lose synch .
--Chuck
1:28 p.m.
That's nuts.. so not only is the monitor relying on the computer to feed it
a sane horizontal pulse, but that pulse rate isn't fixed or
even securely delimited in hardware? Just POKEing the wrong memory location
or writing bad data to some software register can set a catastrophically
destructive video mode?
Ok, yeah, I think I see the merits of having a fail-safe system ala the
oscillator in the Zenith units we've elsewhere discussed. But of course,
this does raise yet another obvious question.. why feed the monitor with a
H-sync from the computer hardware in the first place?
In the Zenith / Osborne situation, the only possible answer would seem to
be "No need to ever adjust (and as such, no need to even implement) a
manual horizontal hold control". But for the IBM PC / 5151, it's a little
less clear.. was there a perceived or real need to be able to
software-switch the hotizontal (and/or vertical) scan rates? Some kind of
text / framebuffer vs. hi-res mode-timing situation as we see in more
modern (SVGA etc) monitors?
FWIW, way back in the bad old days of manually editing /etc/XF86Config, I
do recall various warnings about tinkering with / feeding a bad modeline to
the wrong type of monitor.. could result in major damage, and so on. So I
guess this sort of thing went on for a very long time, then.. same basic
situation?
On Sun, Nov 9, 2014 at 10:43 AM, Chuck Guzis <cclist at sydex.com> wrote:
I'll add this to the 5151 issue. Because the
5151 responds to *every*
horizontal sync pulse, it's quite possible to toast the flyback transformer
with the wrong frequency. I know--I've done it.
Contrast with a simple astable multivibrator which would simply lose synch
.
--Chuck
1:49 p.m.
On 11/09/2014 12:28 PM, drlegendre . wrote:
That's nuts.. so not only is the monitor relying
on the computer to feed it
a sane horizontal pulse, but that pulse rate isn't fixed or
even securely delimited in hardware? Just POKEing the wrong memory location
or writing bad data to some software register can set a catastrophically
destructive video mode?
IBM mentality at work, possibly - they figured nobody would be running
non-IBM software on it, and of course their own software would be tested to
ensure that it didn't happen :-)
(Weren't certain Commodore PETs susceptible to a similar scenario?)
cheers
Jules
1:52 p.m.
On 11/09/2014 10:28 AM, drlegendre . wrote:
That's nuts.. so not only is the monitor relying
on the computer to feed it
a sane horizontal pulse, but that pulse rate isn't fixed or
even securely delimited in hardware? Just POKEing the wrong memory location
or writing bad data to some software register can set a catastrophically
destructive video mode?
Yup, just some stray port outputs is enough to do it. You'll note that
the 5153 doesn't go this route, but has a regular horizontal oscillator
circuit.
Ok, yeah, I think I see the merits of having a
fail-safe system ala the
oscillator in the Zenith units we've elsewhere discussed. But of course,
this does raise yet another obvious question.. why feed the monitor with a
H-sync from the computer hardware in the first place?
I'm not entirely sure what you mean. If it's "why not have the monitor
furnish sync signals instead of the CRT controller>", it's a matter of
what's available, I guess. There weren't that many LSI CRTC's back
then, and none of them could support such a scheme, that I'm aware of.
In the Zenith / Osborne situation, the only possible
answer would seem to
be "No need to ever adjust (and as such, no need to even implement) a
manual horizontal hold control".
It's there, but intended to be an "adjust at the factory and then cross
your fingers".
But for the IBM PC / 5151, it's a little less
clear.. was there a
perceived or real need to be able to software-switch the hotizontal
(and/or vertical) scan rates? Some kind of text / framebuffer vs.
hi-res mode-timing situation as we see in more modern (SVGA etc)
monitors?
You really do need to tweak the timing. Witness the arguments to the
DOS MODE command that allows for shifting the image one way or the other.
FWIW, way back in the bad old days of manually editing
/etc/XF86Config, I
do recall various warnings about tinkering with / feeding a bad modeline to
the wrong type of monitor.. could result in major damage, and so on. So I
guess this sort of thing went on for a very long time, then.. same basic
situation?
Pretty much. It's worth noting that the danger pretty much disappeared
with multisync monitors.
--Chuck
1:47 p.m.
On 11/09/2014 10:43 AM, Chuck Guzis wrote:
I'll add this to the 5151 issue. Because the
5151 responds to *every*
horizontal sync pulse, it's quite possible to toast the flyback transformer
with the wrong frequency. I know--I've done it.
I'd remembered something about being able to damage the display and
mentioned it to book store guy - I didn't realise it was the flyback itself
that it toasted, though. I'll have to borrow it and see if it works before
buying, I suppose.
cheers
Jules
8 Nov
8 Nov
12:23 p.m.
On 11/07/2014 11:49 PM, tony duell wrote:
Screen burn can be a problem
Hmm, that's a good point. I think in severe cases it's usually visible with
the screen powered off, so I suppose I can tell if it's really bad. Or I
might just haul my 5160 in and try it out at the store :-)
Biggest Gotcha is getting inside.
Thanks for the details - fingers crossed it won't come to that!
Book store guy also buys electronics scrap by the pound, so I'll see how
many junk modern PC motherboards I can rustle up to help offset the cost...
cheers
Jules
4:19 p.m.
On 11/08/2014 11:23 AM, Jules Richardson wrote:
Book store guy also buys electronics scrap by the pound,
so I'll see how many junk modern PC motherboards I can
rustle up to help offset the cost...
If anybody comes across an 80286 motherboard, I have a pick
and place machine
that has a NON-PC 286 that runs it, and I might like a set
of spare 286 chips,
"just in case...".
I'm in the central US.
Thanks,
Jon
11 Nov
11 Nov
3:46 p.m.
On 11/07/2014 07:00 PM, Jules Richardson wrote:
So, my local bookstore guy has an IBM 5151 monitor for sale
Well, I ended up picking it up yesterday - and it works fine :-)
I'd forgotten about the long persistence phosphor in the CRT until Tony
mentioned it - is it highly temperature-dependent? I was running the
machine in a cold room (~57F/14C) and it was taking close on 20 seconds for
an image to decay completely. I've no problem with that, because the
brightness tails off quickly at first and so it's perfectly usable - I just
don't remember it taking anything like that long on the 5151 I had over in
England (where I don't think I would ever have run that one at so low an
ambient temperature)
cheers
Jules
5:42 p.m.
I'd forgotten about the long persistence phosphor
in the CRT until Tony
mentioned it - is it highly temperature-dependent
It does take a very long time although 20 seconds seems a bit extreme. The
first time I turned one on after not having used one for over a decade I was
surprised as well.
-Ali
6:03 p.m.
Persistence is directly related to beam intensity.. does it still linger so
long when its dimmed down?
Otherwise, I don't see any way for the phosphor chemistry to change much
over time, being hermetically sealed up in there. If anything, I'd expect
persistence to +diminish+ with age, as the materials deplete (if such
action occurs).
But like most chemical / physical processes, temperature may well have a
notable effect. Longer persistence when cold would make sense, in that
instance.
On Tue, Nov 11, 2014 at 4:42 PM, Ali <cctalk at fahimi.net> wrote:
I'd
forgotten about the long persistence phosphor in the CRT until Tony
mentioned it - is it highly temperature-dependent
It does take a very long time although 20 seconds seems a bit extreme. The
first time I turned one on after not having used one for over a decade I
was
surprised as well.
-Ali
3613
days inactive
3616
days old
21 comments
10 participants
participants (10)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
cctalk＠fahimi.net -
cisin＠xenosoft.com -
drlegendre＠gmail.com -
elson＠pico-systems.com -
georgerachor＠gmail.com -
hilpert＠cs.ubc.ca -
jules.richardson99＠gmail.com -
swtpc6800＠comcast.net