----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Wednesday, July 18, 2001 6:13 PM
Subject: Re: Light Pens ...
> >
> > Well, I've had the sense I was missing something in your description of how
the
> > 6845 supports the precise location of the pixel at which you want, say, to
start
> > a line. While I agree with your description below, I have a problem tying
that
> > to the notion of somewhat larger blocks to which you alluded earlier in the
> > thread. I have no doubt you know what you mean, but I'm being a mite dense
here
> > and would like to understand your interpretation of how the 6845 helps to
> > resolve the location beyond the +/- 1 CCLK level.
>
> OK... _Again_...
>
> The 6845 tells the software which memory word was being displayed when
> the light pen strobe occured. Actually I am simplifying this -- it tells
> you the address of the memory word which was being read out and sent to
> the video pipeline when the light pen strobe occurs. That is not
> neccessarily the same thing, but the 'error' (in terms of the dot clock
> cycles) will be constant and so can be corrected for by software.
>
This is all perfectly clear, and well described in the data sheet. However, the
threshold at which the light pen recognizes a pixel (since it presumably can't
recognize an un-pixel) can vary for the reasons I pointed out previously,
>
> Therefore the 6845 will tell you which group of 8 (or whatever) pixels
> had the lightpen pointed at it. 8 horizontally adjacent pixels, of course.
>
> You now need some extra hardware (the '590 counter, for example) that
> counts the pixels being displayed from that memory word. Again there
> might be some (contant) offset between the counter value and the actual
> pixel being sent to the CRT, but that, again, can be corrected for in
> software.
>
> So, when you get a light pen event you read 2 things. The 6845's light
> pen registers and the '590 value.
>
> The former might tell you that the light pen is somewhere over pixels
> 80-87 of row 74 on the screen. The latter may tell you that you're over
> pixel 4 in the word. So the light pen is pointing at pixel (84,74).
>
>
> >
> > It seems to me that if you use, say, a '590 counter, as I suggested earlier
> > might be a decent enough device to use for counting pixels in whatever
length
> > (up to 256 bits/pixels per word), and use that same light pen strobe that
> > triggers the 6845 to latch the location of the current memory word, there's
>
> Sure...
>
> > still an uncertainty of one word in where that pixel count lies. I suppose
one
>
> Why? If you're thinking of the fact that there's the pipeline delay, so
> what. It's constant. Maybe the '590 does read '2' just as the video
> address changes, but that's easy to correct for. It's a constant offset.
>
No, it's got nothng to do with the pipeline delays, as they're a constant. The
response of the photosensor isn't, though. The response of most photosensors
available in the '70's was quite mushy as compared with a crisp 16 MHz clock.
I'm curious how one deals with the variation in light level depending on the
influence of ambient lighting, variation in illumination of the pixels on
different parts of the screen, and, of course, the influence of system noise, on
the performance of the comparator or amplifier that processes the signal from
whatever photodetctor the light pen uses. Any variation can cause the perceived
location of the pixel in question to be in error, not just by a pixel or two,
but by a word either way, depending on the end of the word at which the subject
pixel resides. It's certainly not safe to assume that the offset between the
signal arriving at the 6845 from the light pen will be shifted in phase from the
optical event by less than a pixel width, particularly if the pixels are
modulated with the dot clock, as they were in the MOT system I once examined.
With a light-pen-dedicated CPU, e.g the one in the MOT system, I can see how
they might have done it, but I don't see how the 6845 was precisely synchronized
enough to be particularly helpful in the horizontal timing. While it's likely
that the 6845 will catch the right word if the pixel is at the middle of the
word, it seems quite risky to assume that it is within the right word if it's a
pixel or two from either end. Clearly it's been dealt with, but I still don't
see how the uncertainty in phase between the incidence of the illuminated pixel
and the one just turned on is managed. Back in the '70's, an LM310 was
considered quite a fast op-amp, and it offered, IIRC, a 10 MHz gain-bandwidth
product. Maybe an LH0032 would have done the job, or something even costlier.
I just have a problem envisioning the analog tools of the time being fast enough
to get the job done.
> If, on the other hand, you've got some kind of race condition in the
> logic so it's not clear when the light pen signal arrives, well, you need
> to design it properly. It is not hard to synchronise the light pen signal
> to the dot clock, for example.
>
It's not races that concern me, but rather the variation in response time of the
photosensor to the available light. Since the pixels occur at the rate at which
they're spewed forth from the high-speed timing logic, there should be some
syncrhonization between when they occur on the CRT. The different levels of
room lighting would cause variation in the differential level seen by the
photosensor, though. It seems to me that the software runs the risk of
oscillating between two or more locations if the light pen can't be relied on to
respond in just a handful of nanoseconds.
>
> > could experimentally determine it, but I don't know how reliable that would
be,
> > owing to the variation in threshold levels at the light pen, and the speed
of
> > its response. I suppose that one could use carefully biased photosensors
and
> > fast comparators to accomplish the detection but I'm not convinced that
ambient
> > lighting and variations in screen intensity, depending on how long the CRT
has
> > been run that day, etc, wouldn't have a greater effect than all that careful
> > tuning. It seems to me that there's risk that under some extreme
circumstances
> > the light pen strobe would occur earlier/later by a count or two than under
> > others at the other extreme. Moreover, it could be off by just half a
count, in
>
> THis is a different problem, and one that I agree exists.
>
> Until now you've been saying that a 6845 can only tell you the address of
> the word in video memory, not the pixel position within that word. This
> is true, but as I've hopefully explained, a little extra hardware will
> give you that extra information. What this gives you is a system that can
> tall you the pixel that was being displayed when the light pen strobe
> arrived. This is a nice, simple digital system that can be made to work
> every time.
>
Yes, and we're in complete agreement on the details relating to how that
happens. However, ...
>
> The other problem is the light pen itself, along with the CRT. Can they
> be made to give a pulse that uniquely identifys a pixel. This is partly
> an optical problem (focusing a single pixel onto the phototransistor,
> partly a CRT phosphor problem (Does the light pen pulse occur cleaning
> just as that pixel is hit by the electron beam -- I hope it is obvious
> that we make the digital circuits triggered by the leading edge of the
> light pen pulse), partly an analogue electronics problem (the
> amplifier/comparator for the light pen phototransistor), and so on.
>
> My view is that this is the difficult part, and that most light pens
> don't have anything like that sort of performance. I would guess that
> most of them will identify something about the size of a character cell
> (an 8*8 region of pixels) on the screen.
>
My point, exactly! However, THEY (whoever that was) managed somehow to get
quite precise resolution within a single pixel, and not at tremendous expense.
That's what puzzles me. Fast op-amps like the LH0032 were being used in pretty
demanding systems like the barcode scanners used in grocery stores, but they
(the barcode scanners) had MUCH higher contrast gradients, and their spectral
response was tightly controlled.
>
> In which case it's probably not worth adding the extra digital
> electronics.
>
> But if the light pen is capable of resolving single pixels, then the
> 6845+logic will tell you which pixel it's just detected.
>
Yes, but what about the variations in ambient lighting? Those move the
differential thresholds around.
>
> > The reason I'm being so dense is that I allowed myself to be persuaded back
in
> > the late-'70's-early '80's that the light pen register was not of as much
use as
> > originally intended and that a pixel counter run from the high-speed timing
> > would make the software burden less trouble. That way all one had to track
was
> > the scan line number in the 6845 and the value in the pixel counter.
>
> Err, isn't that what I've been talking about all along? OK, I'm using the
> 6845 for part of the pixel address within the line, but there's no reason
> why that can't work either...
>
Yes! and that's what I still believe to be difficult to make work because of
the uncertainty in light pen response timing. If you use external logic to do
the horizontal timing, then the problem's solved, with the exception of that
uncertainty, but since you externally count the entire scan line, the 6845
hasn't helped with the horizontal part. You gate the auxiliary counter with the
display enable and latch it with the light pen strobe. That's clear. However,
resolving the resulting differential timing between the edge within the 6845 and
the edge outside essentially necessitates one ignore all the horizontal data the
6845 provides, doesn't it? After all, the worst-case circumstances call the
validity of the word address into question, since the external edge and internal
one aren't precisely synchronized with the CCLK.
Maybe I'm being too much of a grandma with these details, but I remember
wrestling with these details some back in '79-'80, and finding them quite
difficult. IIRC, if one used the fastest op amp, the fastest photosensor, and
modulated the horizontal scan with the dot clock so as to avoid the difference
between old and new pixels, (that way they're always new), you could get the
light pen resolution down to about +/- 15 ns, which was quite fast, but that
would have cost a pretty penny. It's certainly clear that the mouse offered a
cheaper alternative.
>
Received on Wed Jul 18 2001 - 22:06:10 BST