16 Jan
2011
16 Jan
'11
12:15 p.m.
I guess the HP150 counts as a 'classic computer'...
I have an HP150 (origianl model, 9" CRT) on my bench, and amongst other
things it's reporting touchscreen problems in the POST. This is quite
common with such machines, and nearly always means that one or more of
the IR beams was blocked during the test. This is often due to dirt
build-up on the faces of the opto-devices. it can be due to failure of
the devices themselves.
The touchscreen electroncis is mounted on a frame-shaped PCB that fits
just behind the front bezel. The interface to the rest of the machine is
1 10 pin header plug. From what I rmemeber (and I do have pinouts and
shcematics), there are 3 +12V pins, 3 ground pins, a -12V pin and 3
signals :
A clcok input (to touchscreen) that moves the IR beam on to the next position
A synv output (from the touchscreen) which indicates that the last IR
beam is being sampled (or maybe last + 1) I would ahve to check
A data output which indicates if the currently selected beam is open or
blocked.
These signals are all at odd voltage levels (the touchscreen cirucitry is
4000 series CMOS running off a 10V supply obtained from the +12V rail).
HP use transsitors on the CPU PCB to get them to/from TTL levels. they
then end up on the pins of an 8042 microcontroller which also handles the
keyboard and beeper.
Connecting a logic analyser to these signals indeed shows that there are
some beams that appear blocked. The obvious thing is to be able ot
determine which ones so I know which optodevices to test/inspect.
I can think of several ways of doing this :
Count the clock pulses on the logic analyser screen :-)
Make a circuit -- a handful of logic chips, shfit registers, etc that
connects to the touchscreen, generates the clock signal, etc and displys
the state of each beam on a separate LED. Probably possible with the
contents of my junk box, and anywas as I've said, I like soldering.
Ditto, but use a microcontroller. It keeps the chip count down, bnt it's
probably more work for me.
The command list for the 8042 on the HP150 CPU board (in one of the HP
manuals) includes a command to test which IR beams are blocked (this is
not the same as reporting the touchscreen corrdinates). Unfotunately, (a)
you can't use this if the makhine is scannign the keyboard and (b) the
description seems incomplete. It says that this command will return 2
bytes giving the numbers of any blocked berams. Well, with only 16 birs
(and 36 beams), it can't be a bit vector. It also says that if both bytes
are 0xff, then no beams are blocked, if one is 0xff then only one beam is
blocked (specified by the other byte). What happens if more than 2 beams
are blocked? More importantly, since to use this command you have to
disable interrupts and stop the keyboard scanning, it's not going to be
possible to do it from interpretted BASIC. And the programming lanaugages
on this old version of MS-DOS are not that pleasant...
iI can't find an HP diagnostic that gives detailed information on
touchscreen problems, or any reference to one.
Any suggestions/comments?
-tony
16 Jan
16 Jan
2:07 p.m.
-----Oorspronkelijk bericht-----
Van: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
Namens Tony Duell
Verzonden: zondag 16 januari 2011 21:16
Aan: cctalk at classiccmp.org
Onderwerp: HP150 Touchscreen diagnostic
I guess the HP150 counts as a 'classic computer'...
I have an HP150 (origianl model, 9" CRT) on my bench, and amongst other
things it's reporting touchscreen problems in the POST. This is quite common
with such machines, and nearly always means that one or more of the IR beams
was blocked during the test. This is often due to dirt build-up on the
faces of the opto-devices. it can be due to failure of the devices
themselves.
The touchscreen electroncis is mounted on a frame-shaped PCB that fits just
behind the front bezel. The interface to the rest of the machine is
1 10 pin header plug. From what I rmemeber (and I do have pinouts and
shcematics), there are 3 +12V pins, 3 ground pins, a -12V pin and 3 signals
:
A clcok input (to touchscreen) that moves the IR beam on to the next
position
A synv output (from the touchscreen) which indicates that the last IR beam
is being sampled (or maybe last + 1) I would ahve to check
A data output which indicates if the currently selected beam is open or
blocked.
These signals are all at odd voltage levels (the touchscreen cirucitry is
4000 series CMOS running off a 10V supply obtained from the +12V rail).
HP use transsitors on the CPU PCB to get them to/from TTL levels. they then
end up on the pins of an 8042 microcontroller which also handles the
keyboard and beeper.
Connecting a logic analyser to these signals indeed shows that there are
some beams that appear blocked. The obvious thing is to be able ot determine
which ones so I know which optodevices to test/inspect.
I can think of several ways of doing this :
Count the clock pulses on the logic analyser screen :-)
Make a circuit -- a handful of logic chips, shfit registers, etc that
connects to the touchscreen, generates the clock signal, etc and displys the
state of each beam on a separate LED. Probably possible with the contents of
my junk box, and anywas as I've said, I like soldering.
Ditto, but use a microcontroller. It keeps the chip count down, bnt it's
probably more work for me.
The command list for the 8042 on the HP150 CPU board (in one of the HP
manuals) includes a command to test which IR beams are blocked (this is not
the same as reporting the touchscreen corrdinates). Unfotunately, (a) you
can't use this if the makhine is scannign the keyboard and (b) the
description seems incomplete. It says that this command will return 2 bytes
giving the numbers of any blocked berams. Well, with only 16 birs (and 36
beams), it can't be a bit vector. It also says that if both bytes are 0xff,
then no beams are blocked, if one is 0xff then only one beam is blocked
(specified by the other byte). What happens if more than 2 beams are
blocked? More importantly, since to use this command you have to disable
interrupts and stop the keyboard scanning, it's not going to be possible to
do it from interpretted BASIC. And the programming lanaugages on this old
version of MS-DOS are not that pleasant...
iI can't find an HP diagnostic that gives detailed information on
touchscreen problems, or any reference to one.
Any suggestions/comments?
-tony
I'll use an old video cam to see witch LED isn't sending, Sony has an
excellent 'night view"mode witch is very IR sensitive.
Do you have the HP 150 technical reference ?
-Rik
2:39 p.m.
I'll use an old video cam to see witch LED
isn't sending, Sony has an
excellent 'night view"mode witch is very IR sensitive.
Do you have the HP 150 technical reference ?
Any digital camera can see IR from leds. But if the problem is in the
receiver? Use a scope to see the signals on the foot of the IR receiver, I
think it is an "easier" way of doing that, beyond using a digital camera (or
ANY camera, I can't remember a videocamera with no IR detection) to detect
IR emission
Good luck! :D
17 Jan
17 Jan
1:56 a.m.
-----Oorspronkelijk bericht-----
Van: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
Namens Alexandre Souza - Listas
Verzonden: zondag 16 januari 2011 23:40
Aan: General Discussion: On-Topic and Off-Topic Posts
Onderwerp: Re: HP150 Touchscreen diagnostic
I'll use an old video cam to see witch LED
isn't sending, Sony has an
excellent 'night view"mode witch is very IR sensitive.
Do you have the HP 150 technical reference ?
Any digital camera can see IR from leds. But if the problem is in the
receiver? Use a scope to see the signals on the foot of the IR receiver, I
think it is an "easier" way of doing that, beyond using a digital camera (or
ANY camera, I can't remember a videocamera with no IR detection) to detect
IR emission
Good luck! :D
You're right but many new cameras have built-in IR-filters with makes them
less usable for viewing IR-led's in daylight.
The mechanical construction looks a lot like the ones used for HP 16500
LA's only the HP150 use a casing with holes in it where the 16500 LA uses
dark IR passing plastic .
The touchscreen PCB is bent a little to follow the curves of the screen.
This makes it a bit tricky to measure because when the PCB isn't exactly in
line with the holes it doesn't work right.
So it's a lot easier to diagnose with everything in place, if you know the
digital coding of the touchscreen.
-Rik
9:40 a.m.
On Mon, Jan 17, 2011 at 1:56 AM, Rik Bos <hp-fix at xs4all.nl> wrote:
?The mechanical construction looks a lot like the ones used for HP 16500
LA's only the HP150 use a casing with holes in it where the 16500 LA uses
dark IR passing plastic .
On the couple of occasions when I have looked at an HP 16500 where the
power up diagnostics said the touch screen was 'impaired' it was due
to one of the plastic IR guides working its way loose and out of
position. Putting the guide back in its proper position fixed the
problem.
-Glen
11:25 a.m.
The mechanical construction looks a lot like the ones
used for HP 16500
LA's only the HP150 use a casing with holes in it where the 16500 LA uses
dark IR passing plastic .
That may well have been an improvement casued by the known problem of
dirt collecting in the holes (particularly along the bottom edge) and
blocking the beams. HP sold some plastic strips to clip into the holes on
the HP150, but theydidn't do a lot of good.
The 12" touchscreen that I've seen (e.g. on the HP150-II) works on the
same principle, but has an HP-HIL interface. It also has a redesigned
bexel without physical holes, presuably to avoid the problem/
The touchscreen PCB is bent a little to follow the
curves of the screen.
I will ahe to look at that. It's mounted by 4 corner screws onto the back
of the bexzel, I didn't realise that it bent the PCB.
This makes it a bit tricky to measure because when the
PCB isn't exactly in
line with the holes it doesn't work right.
-tony
1:06 p.m.
On 17/01/11 19:12, Tony Duell wrote:
'ANY camera'? I think finding IR film for some
of my cameras would be a
challenge to say the least...
Ilford SFX200 might work...
I've got two rolls of the stuff in the fridge, and an IR filter. One of
these days I'll load the EOS33v with it and have a play...
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
18 Jan
18 Jan
10:10 a.m.
On 17/01/11 19:12, Tony Duell wrote:
That's why I said 'some of my cameras' :-). I assume it's available in
35mm cassettes, maybe 120 roll film or 5*4 sheet film. But I doubt very
much if you cna get it in 110 or 126 cartridges. 127 roll film. 16mm
Minolta/Keiv Vega cartridges. Minox cartridges. 16mm cassettes for a
Narciss. And so on.
-tony
'ANY camera'? I think finding IR film for
some of my cameras would be a
challenge to say the least...
Ilford SFX200 might work...
I've got two rolls of the stuff in the fridge, and an IR filter. One of
these days I'll load the EOS33v with it and have a play...
17 Jan
17 Jan
11:09 a.m.
I'll use an old video cam to see witch LED
isn't sending, Sony has an
excellent 'night view"mode witch is very IR sensitive.
I can think of at least 3 problems with that approach :
1) It only checks the emitters, not the detectors (or the path through
the 4051 muxes)
2) You may be able to see if a beam looks a bit dim (e.g. the IR LED is
weak, or more likely it's covered in dirt), but will you know how dim is
too dim to work?
3) I am not sure my video camera has much sensitivity in the IR. It
depends on which vidicon is fitted, I think.
Do you have the HP 150 technical reference ?
Yes, and the HP150-II suplement.
I don't find it that good. The schematics are incomplete, there's at
least one error (in that what is shown couldn't work correctly), and I
think there are some other differences with the mahcines I have. The
programming information is not that clear either (e.g. the section o nthe
commands ot the 8042 doesn't explain what the touchscreen diagnostic
command does if there are more than 2 blocked beams)
-tony
2:05 p.m.
I'll use an old video cam to see witch LED
isn't sending, Sony has an
excellent 'night view"mode witch is very IR sensitive.
I can think of at least 3 problems with that approach :
1) It only checks the emitters, not the detectors (or
the path through the
4051 muxes)
Yes I know, but it is excluding the most obvious faults (the led's).
2) You may be able to see if a beam looks a bit dim
(e.g. the IR LED is
weak, or more likely it's covered in dirt), but will you
know how dim is too
dim to work?
No but in most cases the working of led's in binary they work or they don't.
3) I am not sure my video camera has much sensitivity
in the IR. It depends
on which vidicon is fitted, I think.
Yes, stupid of me I should have known, mea culpa ;-)
Do you have the HP 150 technical reference ?
Yes, and the HP150-II suplement.
I don't find it that good. The schematics are
incomplete, there's at least
one error (in that what is shown couldn't work
>correctly), and I think
there are some other differences with the mahcines I have. The programming
information is not >that clear either (e.g. the section o nthe commands ot
the 8042 doesn't explain what the touchscreen diagnostic >command does if
there are more than 2 blocked beams)
Yes but it's better then nothing...
-tony
-Rik
2:45 p.m.
On Mon, Jan 17, 2011 at 5:05 PM, Rik Bos <hp-fix at xs4all.nl> wrote:
No but in most cases the working of led's in
binary they work or they don't.
I would have to counter with two situations of non-binary-fail
specific to classic machines:
1) dirt on the LED (especially tobacco smoke residue because it's dark
and sticky and gets on everything)
2) LEDs all dim with age. I've had Sun optical mice die because the
IR LED was too dim to reflect off the pad and retain enough brightness
to be picked up by the IR phototransistor. ISTR the nominal curve is
something like a half-life of tens of thousands of hours, and a
multplexed array would leave each individual LED on for less of the
time than a continuous-on LED as one might find in a Sun optical
mouse, but that's just fine-tuning the time when they will eventually
dim to the point that detection is erratic or non-existent.
For a first-cut diagnostic, viewing the IR LED side could be useful,
but even though I do own an HP IR-LED touchscreen frame (purchased as
a loose item at the Dayton Hamfest many years ago) and have a general
sense of how it works, I wouldn't be sure what the duty cycle for an
individual LED is - if I saw none lit, I couldn't be sure if that was
a global fault, or perhaps they just weren't on long enough to
visually register. Having a working unit to compare against could
help mitigate that. I agree if you spot one or two dim LEDs and the
rest bright enough to see clearly, there's a reason to investigate
that specific symptom, but the absence of that doesn't tell me as
much.
-ethan
18 Jan
18 Jan
10:18 a.m.
On Mon, Jan 17, 2011 at 5:05 PM, Rik Bos <hp-fix at xs4all.nl> wrote:
Which I suspect is one of the most common problems with the HP150
tocuchscreen. The optodevices are down little plastic tubes, so at least
for the ones along the bottom edge of the screen (LEDs for the horizontal
axis IIRC), then can easily collect dirt. Of course sticky smoke residue
can collect on any of them (no, I don't smoke, and I won't allow it near
any of my machines, but I haven't owned this machine from new).
No but in most cases the working of led's in
binary they work or they don't.
I would have to counter with two situations of non-binary-fail
specific to classic machines:
1) dirt on the LED (especially tobacco smoke residue because it's dark
and sticky and gets on everything)
2) LEDs all dim with age. I've had Sun optical mice die because the
IR LED was too dim to reflect off the pad and retain enough brightness
to be picked up by the IR phototransistor. ISTR the nominal curve is
something like a half-life of tens of thousands of hours, and a
multplexed array would leave each individual LED on for less of the
time than a continuous-on LED as one might find in a Sun optical
Yes, but a multipexed array also runs the LEDs at a much higher peak
current, which may make things worsde than you'd expect from the duty cycle.
mouse, but that's just fine-tuning the time when
they will eventually
dim to the point that detection is erratic or non-existent.
For a first-cut diagnostic, viewing the IR LED side could be useful,
but even though I do own an HP IR-LED touchscreen frame (purchased as
a loose item at the Dayton Hamfest many years ago) and have a general
sense of how it works, I wouldn't be sure what the duty cycle for an
individual LED is - if I saw none lit, I couldn't be sure if that was
I think it's a lot less than you'd expect. The LED is turned on by a
monostable on the touchscreen board (at lesat in the orignial HP150
version), and from waht I remeebr it's only one for a small fraction of
the time taken to scna that LED. And then there are 36 or so LEDs to scan
through. I would have to look up the monostable timing and the scan clock
freqeuncy if you rally want to know the duty cycle, but ti could be
around 1:1000
-tony
12:38 p.m.
On 2011 Jan 18, at 10:18 AM, Tony Duell wrote:
LED's typically run at a higher peak current for visual displays where
the objective is to bring up the average energy output to achieve the
same 'brightness' for perception by the human eye. In an application
such as that at issue though, the instantaneous output from the LED is
what matters to the opposing phototransistor/diode. The 'normal' LED
current may well be enough (or even more than enough). I wouldn't
expect even a 1:1000 duty cycle to be an issue. The peak current
requirements could go either way, depending on the sensitivity of the
detectors.
As to the original question, what about just hacking up an IR
phototransistor/diode or an IR receiver/amp module to a scope, manually
run it past the LED holes looking for activity (the modules may not
provide much indication of relative output though, just
presence/absence).
Similarly, power up an IR LED and run it past the holes of the
detectors and look for activity/change on the detectors data line.
On Mon, Jan 17, 2011 at 5:05 PM, Rik Bos <hp-fix at xs4all.nl> wrote:
Which I suspect is one of the most common problems with the HP150
tocuchscreen. The optodevices are down little plastic tubes, so at
least
for the ones along the bottom edge of the screen (LEDs for the
horizontal
axis IIRC), then can easily collect dirt. Of course sticky smoke
residue
can collect on any of them (no, I don't smoke, and I won't allow it
near
any of my machines, but I haven't owned this machine from new).
No but in most cases the working of led's in
binary they work or
they don't.
I would have to counter with two situations of non-binary-fail
specific to classic machines:
1) dirt on the LED (especially tobacco smoke residue because it's dark
and sticky and gets on everything)
2) LEDs all dim with age. I've had Sun optical mice die because the
IR LED was too dim to reflect off the pad and retain enough brightness
to be picked up by the IR phototransistor. ISTR the nominal curve is
something like a half-life of tens of thousands of hours, and a
multplexed array would leave each individual LED on for less of the
time than a continuous-on LED as one might find in a Sun optical
Yes, but a multipexed array also runs the LEDs at a much higher peak
current, which may make things worsde than you'd expect from the duty
cycle. mouse, but
that's just fine-tuning the time when they will eventually
dim to the point that detection is erratic or non-existent.
For a first-cut diagnostic, viewing the IR LED side could be useful,
but even though I do own an HP IR-LED touchscreen frame (purchased as
a loose item at the Dayton Hamfest many years ago) and have a general
sense of how it works, I wouldn't be sure what the duty cycle for an
individual LED is - if I saw none lit, I couldn't be sure if that was
I think it's a lot less than you'd expect. The LED is turned on by a
monostable on the touchscreen board (at lesat in the orignial HP150
version), and from waht I remeebr it's only one for a small fraction of
the time taken to scna that LED. And then there are 36 or so LEDs to
scan
through. I would have to look up the monostable timing and the scan
clock
freqeuncy if you rally want to know the duty cycle, but ti could be
around 1:1000
-tony
10:51 a.m.
Yes, but a
multipexed array also runs the LEDs at a much higher peak
current, which may make things worsde than you'd expect from the duty
cycle.
LED's typically run at a higher peak current for visual displays where
the objective is to bring up the average energy output to achieve the
same 'brightness' for perception by the human eye. In an application such as that at issue though, the instantaneous output
from the LED is
what matters to the opposing phototransistor/diode. The 'normal' LED
current may well be enough (or even more than enough). I wouldn't
expect even a 1:1000 duty cycle to be an issue. The peak current
requirements could go either way, depending on the sensitivity of the
detectors.
The LEDs are wired in a matrix with a ULN2804 driver to ground and a
ULN2580 drive to the +10V line. There's a 10 Ohm resistor in series with
each of the outputs of one of the drivers. This suggests a peak current
of a little under 1A. It is a low duty cycle, my guyess of 1:1000 seems
about right.
As to the original question, what about just hacking up an IR
phototransistor/diode or an IR receiver/amp module to a scope, manually
run it past the LED holes looking for activity (the modules may not
provide much indication of relative output though, just
presence/absence).
Possible. But I still think dim beams are a very common problem.
Similarly, power up an IR LED and run it past the holes of the
detectors and look for activity/change on the detectors data line.
It may be less work in the end to make up some kind of tester to plug
into the touchscreen PCB and display the status of all the beams...
-tony
19 Jan
19 Jan
11:58 a.m.
Re: viewing IR beams.
You may be able to borrow an IR sensor card from a friend who works
with IR laser equipment. Alternatively, a sensor card can be had for
not a lot of money:
http://www.mcmelectronics.com/product/DISTRIBUTED-BY-MCM-72-6772-/72-
6772
No electronics involved at all.
FWIW,
Chuck
18 Jan
18 Jan
12:39 p.m.
Re: viewing IR beams.
You may be able to borrow an IR sensor card from a friend who works
with IR laser equipment. Alternatively, a sensor card can be had for
not a lot of money:
I wonder how such a card would manage with light pulses foa few us and a
1000:1 duty cycle...
I do have an electronic IR handset tester, built from the Maplin keit
many years ago. IR photodiode + A few trasnsitors driveing an LED. I
think there's an RC pulse stretcher circuit in there too. Runs off one of
those 12V batteries that are a bit smaller than an N cell (and FWIW, it
still runs on the battery I put in when I built it).
I could try that, but I am not sure it't tell me much...
I suspext (without checking) that the shipping would cost more than the
device...
-tony
20 Jan
20 Jan
12:16 a.m.
On 2011 Jan 18, at 10:51 AM, Tony Duell wrote:
Narrows the problem down, but then you still don't know whether it's
the emitter or detector.
If the logic analyser gives indication of blocked beams as you stated
in your original message, why not just poke a finger around on the
screen to find which locations don't change the data stream (or change
it for only one axis). Appropriate poking sequences should distinguish
between X & Y blockages. (Assuming the detectors feed selectors giving
individual time slots in the data stream, as opposed to being
wire-ORed.) Or finger poking on the good beams to map out the data
stream.
Similarly, power up an IR LED and run it past the holes of the
detectors and look for activity/change on the detectors data line.
It may be less work in the end to make up some kind of tester to plug
into the touchscreen PCB and display the status of all the beams...
11:56 a.m.
On 2011 Jan 18, at 10:51 AM, Tony Duell wrote:
Narrows the problem down, but then you still don't know whether it's
the emitter or detector.
If the logic analyser gives indication of blocked beams as you stated
in your original message, why not just poke a finger around on the
screen to find which locations don't change the data stream (or change
it for only one axis). Appropriate poking sequences should distinguish
between X & Y blockages. (Assuming the detectors feed selectors giving
individual time slots in the data stream, as opposed to being
wire-ORed.) Or finger poking on the good beams to map out the data
stream.
Oh, I know the format of the data output -- and I have schematics for the
touchscreen PCB, which cotnains just 4000-series CMOS logic chips, a quad
op-map (324 I think) and the LED drivers. Nothing custom, nothing
programmable. The microcontroller I mentioned is on the CPU board and
interfaces between the 8088 bus and the touchscreen, keyboard interface
(simuilar, but IIRC the microcontroller, not the device provides the sync
pulse), and the beeper. If I look at the ribbon cable to the
touchscreen, I am looking at the raw signls before the microcontroller
has a go at them :-)
The format is something like : X axis in oder (L->R), one unusued, Y
sesors in order (Top->Bottom), Sync pulse (on the other output), repeat.
That's from memory, I can find the exact details if you want them.
But I have heard it said that a 'hacker' is somebody, who, if he has to
do a task a dozen times and each time takes 5 minutes, he'll happly spend
a day finding an automatic to do it. So yes, I could just count pulses on
the logic analyser, but the hacker in me (is there one?) says that I
whould be finding a way to avoid doing that ;-)
-tony
Similarly, power up an IR LED and run it past the holes of the
detectors and look for activity/change on the detectors data line.
It may be less work in the end to make up some kind of tester to plug
into the touchscreen PCB and display the status of all the beams... 
21 Jan
21 Jan
12:22 a.m.
Vidicon - 1949 - 1953 CBS
CCD - 1969 - Bell Labs
Regards
?
Rod Smallwood
-----Original Message-----
From: cctech-bounces at classiccmp.org [mailto:cctech-bounces at classiccmp.org]
On Behalf Of Tony Duell
Sent: 20 January 2011 19:56
To: cctalk at classiccmp.org
Subject: Re: HP150 Touchscreen diagnostic
On 2011 Jan 18, at 10:51 AM, Tony Duell wrote:
Narrows the problem down, but then you still don't know whether it's
the emitter or detector.
If the logic analyser gives indication of blocked beams as you stated
in your original message, why not just poke a finger around on the
screen to find which locations don't change the data stream (or change
it for only one axis). Appropriate poking sequences should distinguish
between X & Y blockages. (Assuming the detectors feed selectors giving
individual time slots in the data stream, as opposed to being
wire-ORed.) Or finger poking on the good beams to map out the data
stream.
Oh, I know the format of the data output -- and I have schematics for the
touchscreen PCB, which cotnains just 4000-series CMOS logic chips, a quad
op-map (324 I think) and the LED drivers. Nothing custom, nothing
programmable. The microcontroller I mentioned is on the CPU board and
interfaces between the 8088 bus and the touchscreen, keyboard interface
(simuilar, but IIRC the microcontroller, not the device provides the sync
pulse), and the beeper. If I look at the ribbon cable to the
touchscreen, I am looking at the raw signls before the microcontroller
has a go at them :-)
The format is something like : X axis in oder (L->R), one unusued, Y
sesors in order (Top->Bottom), Sync pulse (on the other output), repeat.
That's from memory, I can find the exact details if you want them.
But I have heard it said that a 'hacker' is somebody, who, if he has to
do a task a dozen times and each time takes 5 minutes, he'll happly spend
a day finding an automatic to do it. So yes, I could just count pulses on
the logic analyser, but the hacker in me (is there one?) says that I
whould be finding a way to avoid doing that ;-)
-tony
Similarly, power up an IR LED and run it past the holes of the
detectors and look for activity/change on the detectors data line.
It may be less work in the end to make up some kind of tester to plug
into the touchscreen PCB and display the status of all the beams...
1:53 p.m.
Vidicon - 1949 - 1953 CBS
CCD - 1969 - Bell Labs
Was that using a CCD as an image sensor, or as a shift register (analogue
or otherwise)? And if the former, I assume it was a linear, not area, device.
Anyway, I think that confirms the vidicon is older than the CCD. And
AFAIK, that's the order they appeared in small-ish video cameras too. A
vidicon-based camera is likely to be olde rthan a CCD one.
-tony
12:48 p.m.
But I have heard it said that a 'hacker' is
somebody, who, if he has to do
a task a dozen times and each time takes 5
>minutes, he'll happly spend a
day finding an automatic to do it. So yes, I could just count pulses on the
logic analyser, >but the hacker in me (is there one?) says that I whould be
finding a way to avoid doing that ;-)
-tony
And that's what makes it "Zen and the art of hacking" to use some
plagiaristic sentence.
-Rik
18 Jan
18 Jan
10:13 a.m.
I'll use an old video cam to see witch LED
isn't sending, Sony has an
excellent 'night view"mode witch is very IR sensitive.
I can think of at least 3 problems with that
approach :
1) It only checks the emitters, not the detectors
(or the path through the
4051 muxes)
Yes I know, but it is excluding the most obvious faults (the led's). 3) I am not
sure my video camera has much sensitivity in the IR. It depends
on which vidicon is
fitted, I think.
Yes, stupid of me I should have known, mea culpa ;-) Do you have the HP 150 technical reference ?
Yes, and the HP150-II suplement.
I don't find it that good. The schematics are
incomplete, there's at least
one error (in that what is shown couldn't work
>correctly), and I think
there are some other differences with the mahcines I have. The programming
information is not >that clear either (e.g. the section o nthe commands ot
the 8042 doesn't explain what the touchscreen diagnostic >command does if
there are more than 2 blocked beams)
Yes but it's better then nothing...
17 Jan
17 Jan
1:59 a.m.
-----Oorspronkelijk bericht-----
Van: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
Namens Tony Duell
Verzonden: zondag 16 januari 2011 21:16
Aan: cctalk at classiccmp.org
Onderwerp: HP150 Touchscreen diagnostic
I guess the HP150 counts as a 'classic computer'...
I have an HP150 (origianl model, 9" CRT) on my bench, and amongst other
things it's reporting touchscreen problems in the POST. This is quite common
with such machines, and nearly always means that one or more of the IR beams
was blocked during the test. This is often due to dirt build-up on the
faces of the opto-devices. it can be due to failure of the devices
themselves.
The touchscreen electroncis is mounted on a frame-shaped PCB that fits just
behind the front bezel. The interface to the rest of the machine is
1 10 pin header plug. From what I rmemeber (and I do have pinouts and
shcematics), there are 3 +12V pins, 3 ground pins, a -12V pin and 3 signals
:
A clcok input (to touchscreen) that moves the IR beam on to the next
position
A synv output (from the touchscreen) which indicates that the last IR beam
is being sampled (or maybe last + 1) I would ahve to check
A data output which indicates if the currently selected beam is open or
blocked.
These signals are all at odd voltage levels (the touchscreen cirucitry is
4000 series CMOS running off a 10V supply obtained from the +12V rail).
HP use transsitors on the CPU PCB to get them to/from TTL levels. they then
end up on the pins of an 8042 microcontroller which also handles the
keyboard and beeper.
Connecting a logic analyser to these signals indeed shows that there are
some beams that appear blocked. The obvious thing is to be able ot determine
which ones so I know which optodevices to test/inspect.
I can think of several ways of doing this :
Count the clock pulses on the logic analyser screen :-)
Make a circuit -- a handful of logic chips, shfit registers, etc that
connects to the touchscreen, generates the clock signal, etc and displys the
state of each beam on a separate LED. Probably possible with the contents of
my junk box, and anywas as I've said, I like soldering.
Ditto, but use a microcontroller. It keeps the chip count down, bnt it's
probably more work for me.
The command list for the 8042 on the HP150 CPU board (in one of the HP
manuals) includes a command to test which IR beams are blocked (this is not
the same as reporting the touchscreen corrdinates). Unfotunately, (a) you
can't use this if the makhine is scannign the keyboard and (b) the
description seems incomplete. It says that this command will return 2 bytes
giving the numbers of any blocked berams. Well, with only 16 birs (and 36
beams), it can't be a bit vector. It also says that if both bytes are 0xff,
then no beams are blocked, if one is 0xff then only one beam is blocked
(specified by the other byte). What happens if more than 2 beams are
blocked? More importantly, since to use this command you have to disable
interrupts and stop the keyboard scanning, it's not going to be possible to
do it from interpretted BASIC. And the programming lanaugages on this old
version of MS-DOS are not that pleasant...
iI can't find an HP diagnostic that gives detailed information on
touchscreen problems, or any reference to one.
Any suggestions/comments?
-tony
Tony,
At page 3-37 to 3-49 of the HP-150 technical reference manual the
touchscreen is described.
If you don't have it let me know I'll make a scan (can take a few days I'm
on a business trip this week).
-Rik
2:12 a.m.
New subject: [OT]: Altera DE1/DE2 board
Anyone has a spare DE1/DE2 Altera board to sell?
A friend of mine is looking for one of that, for a
classic-computer-related project
You can contact him directly if you prefer at miguel (you know the
symbol) tabalabs.com.br
Thanks!
---
Enviado do meu Motorola PT550
8:16 a.m.
New subject: [OT]: Altera DE1/DE2 board
On 1/17/2011 5:12 AM, Alexandre Souza - Listas wrote:
Anyone has a spare DE1/DE2 Altera board to sell?
I just bought a Terasic Altera DEO board this weekend -- it should
arrive this week. I've had a Xilinx Spartan-3E board for a couple
years, and I wanted to go to Altera and check out the competition.
Basically, see how capable Altera is in comparison.
Most of the Xilinx tools(ISE, Project Navigator, EDK) seem pretty big,
and if not bloated, then just resource hungry(and I'm not talking about
synthesis or place/route.)
Altera's Quartus II seems better, but I haven't played with it enough
yet to make a call. Everything I read seems to indicate that Altera's
software is not only better laid out, more lightweight, but is actually
several times faster for the whole compilation. Plus, I've heard from
friends who work in the field, that they do a better job of squeezing
logic into less amount of resources by optimizing w/ better results than
ISE.
The call between the DE0 board and the DE1 board is tough. The DE0 is
newer and contains a Cyclone III although it is slightly smaller than
the Cyclone II on the DE1. The on-chip resources of the Cyclone III
kill the Cyclone II --- namely offering much more on-chip dedicated
memory(and are M9K blocks vs M4K blocks), having more available 18x18
multipliers, and just about every other stat. The Cyclone II chosen for
the DE1 has about 18k logic elements where the Cyclone III chosen on the
DE0 has about 15k. 3k, you say, but that's another 20% or so.
Sorry for hijacking your thread. :)
Keith
11:20 a.m.
At page 3-37 to 3-49 of the HP-150 technical reference
manual the
touchscreen is described.
Yes, I have that. I've also looked at the signals with a logic analyser
(on the 'other side' of the TTL level shifters on the CPU board, and the
signals seem to agree with the manual.
-tony
5084
days inactive
5089
days old
26 comments
10 participants
participants (10)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
classiccmp＠philpem.me.uk -
ethan.dicks＠gmail.com -
glen.slick＠gmail.com -
hilpert＠cs.ubc.ca -
hp-fix＠xs4all.nl -
keithvz＠verizon.net -
pu1bzz.listas＠gmail.com -
rodsmallwood＠btconnect.com