VT52s wanted

From: Tony Duell <ard_at_p850ug1.demon.co.uk>
Date: Fri May 28 17:34:51 2004

>
> Yep, That was my plan. I've never done that kind of thing before,
> but I'm ready to try. You're right, the boards don't look very
> complicated. How big is the printset that you have?

The printset _I_ have is a ssetion in a much larger printset, covering
the Lab 11/03 (LSI 11/03 + ADC, DAC, etc cards). I assume it's avallable
separately, isn't it on Bitsavers?

The other thing I have is the Microfiche trchnical manual for the VT50 (a
closely related terminal, with only 12 lines IIRC). This includes a
commented source of the microcode....

Anyway, The VT52 logic is not that complicated, but it might throw you
the first time. It's built a as a very specialised 'processor' with a
simple 7 bit data path. If you're not used to working on processors, now
is the time to learn!

Anway, as you have 2 units, I'd start by swapping over the microcode
PROMs as a set (they're socketed), just to rule them out. Of course if
you have dumps of them, you can verify them using a PROM programmer.

I'd then attack the more-working unit (if only because, being a
processor-like design, for it to do anything correctly much of the logic
has to be working). I'd see if the keyboard is being scanned at all (IIRC
it's scanned in firmware), if not, find out why not. if it is, check the
condition logic, and so on.

For the really dead one, I'd make sure the clock was running, and that
the microcode address lines are not stuck. I've had the address latches
fail in other microcoded systems (including an 11/05, and that was
'fun'...) Then see what it thinks it's doing, and if it's doing it correctly.

You really need a logic analyser, but it is possible to get a long way
without one...

-tony
Received on Fri May 28 2004 - 17:34:51 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:37:13 BST