14 Jun
2003
14 Jun
'03
10:31 a.m.
Is anyone here familiar with the HP 1350 (or HP 1351)
graphics
translators, or low-level HPIB protocol debugging?
I have a pair of HP1350s, and the complete operating/service manual. The
latter is a rather thick binder containing schematics, parts lists,
theory of operation, etc....
For curious minds not familiar with this device, the HP 1350 is a vector
graphics controller with a 1K by 1K addressable
It's actually 1024*1023 points. You can also display text on the screen
(the little daugterboard on the main display board contains the character
generator ROMs, etc). This is stred by a value of 1023 in one axis
(normally illeagal), and the character code, flags, etc in the other axis.
Display memory is a row of 4K DRAM chips, of course.
One odd feature is that there's no CPU, and no logic wired up in a
CPU-like fashion. It's all essentially random logic. To decode ASCII
commands/data to vectors in random logic is a somewhat perverse hack.
There are 2 10 bit DACs on the mainboard, mostly discrete components.
THere are 2 rows of 6 presets that set up the top 6 bits of each DAC. Due
to their appearance and function, most hackers call this the 'graphic
equaliser' :-)
display space. Usually they come with a HPIB
interface but there was a
serial (RS-232) I/O option. The HP 1350 can
I on;t have data on the HPIB version.
draw vectors or letters and symbols with a simple
ASCII command language
(called GTML) and its own internal display
list memory, and were often used with older HP calculators and computers
such as the HP 1000 line.
I have been tinkering with a HP 1350 using a HP 1000 minicomputer and
the 12821A bus interface, as well as a HP bus analyzer to see whats
going on at the bus level. I've run into a bit of a problem, perhaps
someone here can help?
As long at I have the HP bus analyzer connected, and set for SLOW or
HALT bus speeds, I can correctly transfer commands and data to the HP
1350 (a listen only device). When the bus analyzer is removed, or
connected and set to FAST the bus transfers
will lock up at the inter-command "::" seperator characters. Its almost
as if the HP 1350 cannot signal the bus that it needs to
wait and think about the last command.
What would happen if a HPIB listener could not drive NRFD?
THis does sound like an HPIB interface/timing problem...
There is a troubleshooting procedure in the manual for the I/O card. I'll
give the first bit of it here. It assumes you have an HP9825 calculator
as the controller, but I guess you can modify this for other machines. At
least knowing where it goes wrong would be a start. It gives a lot more
explantion in the manual, but I'll give that for the problem area only
1 Listen program check.
a) Cycle 1350 power
b) Type [Reset[ wrt 718 [Execute] on the 9825
c) Check program LED is on, data LED is off
2) Unlisten check
a) Type cmd 7,?" [execute]
b) check program and data LEDs both off
3) Listen Data check
a) Type [reset] wtb 718,"PA" [Execute] (note, this does not send CR/LF)
b) Check program LED off, Data LED on
4) Return to listen progrma check
a) Type wrt 718,":" [Execute]
b) Check data LED off, program LED on
5) Clear power interrupt LED check
a) type wtb 718,20,13,10 [execute] (that's sending DC4, CR, LF)
b) Verify power interrupt LED off, program LED on
6) Pen enable check
a) Type wrt 718"PE0,"[execute]
b) check U35 pin 5 is low (U35 is in the column of chips at the edge of the
PCB closest to the HPIB connector, and is in the 6th row from the HPIB
end)
c) Type wrt 718"PE1,"[execute]
d) Check U35 in 5 is high
And so on...
However, this may not be a fault with the 1350. It sounds as though, for
some reason, the handshake is not being completed properly. Do you know
what state DAV, NRFD, NDAC are in when the bus locks up. Do you have data
on the interface in the HP1000 -- can you tell if that's in a sane state
or not?
I think that there are three possibilities here..
1. A hardware problem in the HP 1350.
I have swapped the HPIB interface module with one from a 'parts machine'
HP 1350, and the behavior was exactly the same.
Interesting. So it doesn't sound like is module is playing up (unless
both have the same fault)
I also swapped a logic control and timing board, but
the one from the
parts machine does not draw vectors very well, and the
bus protocol issue appears to have been uneffected.
Right...
Also the HP 1350 draws beautiful vectors, with perfect end-point
matching, and the letters are very well formed. The 'hard'
parts of the machine are really working so well, I'm skeptical there is
a hardware fault here (which is not being objective).
Hmmm... One IC failure coupld cause a problem, and wouldn't necessarily
affect vector generation.
2. A GTML protocol problem.
I have very limited documentation for the HP 1350, a partial photocopy
of a manual that uses an ancient HP calculator to drive
the display controller. Maybe there is some trick to formatting command
strings that makes it handshake properly?