HP-150 MS-DOS Computer

[Tony Duell]

> 
> > > > 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 
schematics. 

> 
> 
> 
> > 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


-tony