Light Pens ...

From: Richard Erlacher <edick_at_idcomm.com>
Date: Tue Jul 17 21:22:07 2001

see comments inline, plz.

Dick

----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, July 17, 2001 5:51 PM
Subject: Re: Light Pens ...


> >
> > > Getting the horizontal location right, as you'd have to in order to do
> > precise
> > > drawing, might be a bit more complicated, don't you think? An 8-pixel
> > extent of
> > > uncertainty is quite a bit on a 640-pixel display.
> >
> > But it's usually less than 8 bits. For example, the pen I built (which had
> > assorted other problems as per my other responses) was mostly used on a
> > 4-bit-per-pixel display (16 colours) or a 2bpp (4 colour) display, so the
> > resolution was usually 2 pixels or, at worst, 4.
>
Ordinarily, displays that support both text and graphics, as was the practice
back when the 6845 was cooked up, normally means a two-pathed pipeline, one with
an extra stage of delay and bypassing the character generator, and the other
without the delay stage, but using that interval for the character-generation to
do its work. Since the character generator normally took bytes line count and
translated them into bytes to be loaded into a shift register clocked at the
pixel rate, the same shift register, hence shift register width and load rate,
was used. This was not a requirement, but since the 6845 is driven by the
character clock rather than the pixel clock, it's less convenient to switch
divisors in order to reduce the resolution and change the sync/blanking timing.
Normally, if one had three colors, one had three bit planes and three shift
registers. It seems to me that the Apple did things that way too, by the way.
The color video memory was in three banks so that it could be concurrently
accessed into the three colors and subsequently combined. I've not made a study
of the Apple low-level mechanics, but that certainly seems representative of how
a number of systems did things.
>
> Alternatively, in any video display system the following signals exist
> somewhere (maybe only inside an ASIC, but that's not my problem :-)) :
>
> A clock signal at the pixel frequency
>
> A signal which loads another word from video memory into the video output
> circuitry. In general this will occur every n pixel clock pulses, where n
> is the number of pixels in a memory word.
>
that's what MOT calls the character clock.
>
> The light pen strobe.
>
> What you do is count the pixel clocks with a counter that is reset by the
> load-next-word signal. You have to be a little careful with synchronising
> the latter signal, but it's not that difficult.
>
There are some standard counters that do this remarkably well. An 'LS590 will
register this count and hold it in a tristate register until it's needed, yet
update it whenever it's told to do so.
>
> Then latch the value of that counter when you get a light pen strobe. The
> software reads both the registers in the 6845 (giving the address of the
> word in video memory) and the latched value of this count, giving the
> pixel position within the word.
>
> Of course in many cases the video output circuitry is effectively a
> pipeline, clocked by the pixelclock, and it takes several clock cycles to
> move a pixel from memory to the screen. But that's a constant number of
> clock cycles and so can be corrected for easily in software.
>
If the refresh memory is to support text and graphics, the pipeline must be
two-forked.
>
> -tony
>
>
Received on Tue Jul 17 2001 - 21:22:07 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:33:52 BST