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.
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
still an uncertainty of one word in where that pixel count lies. I suppose one
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
which case uncertainty still persists. Given, say, a pixel clock of 16 MHz
(pretty slow for high-res, but typical for the '80's) you'd have to have a
damn-fast amplifier or comparator to generate a light pen strobe that would
register the last pixel in a word before the CRTC registered the next address.
OTOH, if it were the first pixel in the next word, a compensation scheme might
break down, particularly since there's risk the pixel might be dimmer than the
one just previous because it's not yet been refreshed since the last frame.
The problem has been solved, though, hasn't it? I'm just curious as to how.
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.
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Wednesday, July 18, 2001 2:15 PM
Subject: Re: Light Pens ...
> >
> > What's got me wondering here is that the 6845 has a minimal resolution of
one
> > character width, typically 8 bits. It has an upper limit on count rate, and
> > between that and the dot clock frequency, you get an upper limit on the
number
> > of pixels per line for every frequency of character clock.
>
> Well, your video memory and shift registers can be as wide as you like.
> Suppose the maximum speed of the 6845 is x MHz. Then if you have 8-bit
> memory (1 bit/pixel) you have a pixel rate of 8x MHz. If you have 32 bit
> memory, 32x MHz, and so on.
>
> >
> > Now, I haven't looked at the 6845 spec for a couple of decades, (It was new
> > then.) but IIRC, the minimal resolution of the value in the light pen
register
> > is the character clock, which is the dot clock DIV pixels-per-character.
> >
> > You can, of course, draw whatever you want in the video refresh RAM, but I'm
not
> > clear on how this process works in conjunction with the function of the
6845.
> >
> > Could you tie those two together, plz?
>
> I really don't see what the problem is here.
>
> You have a 6845. The function of the 6845 is to generate video RAM
> addresses and sync pulses. The address produced by the 6845 selects a
> particular location in video memory. External logic then turns the
> contents of that location in memory to a bit stream to send to the
> monitor. Each location in video memory corresponds (in general) to
> several pixels on the screen.
>
> The 6845 has another function. It accepts the light pen signal. When it
> gets that signal, it latches the video address. And lets the software
> read it out. So the software then knows that the light pen is pointing at
> one of the pixels corresponding to that location in video memory. But not
> which particular pixel it is.
>
> However, presumably the logic that turns memory words into pixels knows
> which pixel within the word is being sent to the monitor at a given time.
> So, a little extra logic added here can cause the light pen signal to
> latch this information and allow it to be read by software.
>
> So, when you have a light pen event, the software reads 2 things
>
> From the 6845 it gets the information that the light pen is somewhere
> over pixels 48-55 of line 27 on the screen (say)
>
> From the word->pixels hardware it gets the information that the light pen
> is over the pixel corresponding to bit 3 of a memory word (I'll assume
> LSBs are displayed first).
>
> Combining those 2 facts, the software knows that the light pen is over
> pixel (51,27).
>
> -tony
>
>
Received on Wed Jul 18 2001 - 18:57:43 BST