HP-150 MS-DOS Computer
ard at p850ug1.demon.co.uk
Fri Apr 27 17:11:25 CDT 2007
> > > > What's the problem with your unit? Does it appear to be a digital
> > > > problem, or a problem with monitor circuit?
> > >
> > > Digital, I suspect. Although, this is a rather bizarre problem, and
> > > COULD be a video problem, I suppose. When I boot it up, it works
> > > correctly, as far as I can tell, with the single exception that the
> > > screen shows what it should be showing, only in reverse video, and
> > > without the characters being visible, whatever the brightness level. In
> > I am not sure quite what you mean here. Do yuo mean that all characters
> > (other than space) appear as solid blocks?
> Okay... Yeah, I muffed the explanation somewhat. I don't, upon
> re-thinking it, have a much better explanation. However, if you would
> imagine a scenario in which you are TRYING to make a "normal" HP-150
> look like mine, I CAN tell you how to do it, quite simply. First,
> replace all characters on the screen with spaces in the same scheme
> (normal or inverse video) as the characters were, and then invert the
> whole screen, on for off and off for on. Then, all the "on" bits are
> made bright. Other than that, it seems to work just fine.
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...
> > 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.
Ypu're lucky (or I'm stupid). Most of the time I find I do need
> > 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 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.
I can't see how the 'S153 would slow the signal down sufficiently to
remove all the character pattern data.
> > The complicated bit is round those shift registers I mentioned. There's
> > some logic to, I think, make the line-drawing characters touch on-screen.
> > This is controlled bu U46b ('S74) and is based rounf U78b ('S112) and
> > U713b and a ('S09),, U712d ('LS00) and U610a ('S32)
> > There's even a couple of gates between the 2 shift register ICs, but I
> > think if that was the problem you'd get half of each character displayed
> > correctly.
> > > > I have an _old_ -- over 40 eyars old -- HP frequncy counter.
> > >
> > >
> > > Sounds like you are discussing an HP 5245L...
> > Exactly. Well, it could also have been a 5243L, which is the 10MHz
> > version (the 5245 being 50MHz). I have one of each. Actually, a fair
> > number of the PCBs are common to both instruemtns. I also have some, but
> > certianly not all, of the plug-ins
> Now THAT was some fine engineering. Old enough that they had to use
Indeed it was. As I keep on saying, that's what I loved about the old HP
and what I miss in the mdoern stuff. Built like a brick outhose, easy to
work on, reliable, accurate.
> > > Yes! Our lab had a cesium beam that we used as an external standard
> > > for the 5245Ls. Truth be told, however, there really wasn't much
> > Alas I have to 'make do' with the internal crystal. I am told that HP
> > sold a rubidium beam (sub)standard that was in a 19" rack module, and
> > which you simply cabled up to the external oscillator input on the 5245L.
> > I don't hjave it, thouhg.
> 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. What actually controls the frequency of the Rb beam standard,
and how does it drift
More information about the cctalk