The Commodore VIC-II also supports light pens in hardware. When the switch is closed, the light pen registers in the chip latch at the current raster position if light is present and an IRQ is generated. (In simplistic terms. *grin*) -- ----------------------------- personal page: http://www.armory.com/~spectre/ -- Cameron Kaiser, Point Loma Nazarene University * ckaiser(a)stockholm.ptloma.edu -- This message will self-destruct in five seconds. Good luck, Jim. -- M:I ----

A non-text attachment was scrubbed... Name: not available Type: text Size: 3334 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20010716/97c6ade7/at…

On slower systems when the light pen is pressed against the screen (or a button is pressed) the screen would "flash" which was the video circuit sending one frame of 'white' so that the pen would detect it. This is how the old console displays on the System/370 worked (god would I love to have one of those to play with) Other systems would light up a single row (move it down through the frame) which was less intrusive visually. There are other ways to make it work but basically without light eventually hitting the sensor you were stuck. --Chuck At 02:01 PM 7/16/01 -0700, you wrote:

On Mon, 16 Jul 2001, Sellam Ismail wrote: There are several ways. What I did (with TRS-80) was that whenever the software saw the SWITCH engaged, it would call the locate function. The locate function would light pixels and then turn them back off. Although you can scan the pixels one at a time (an XOR function is VERY handy), you can also light all of the pixels in the top half of the screen, and then restore them, to find which half of the screen it is. Then light half of that and restore it, etc. You can identify which character positions with less than a dozen writes. Then toggle the "found" position a few times to confirm. The "extra" confirmation tests won't bother the user - "the light pen produces a flashing dot on the screen". In a hardware assisted environment (such as CGA), you can just flash the screen. Note: MY TRS-80 software in BASIC was too slow for commercial release. Others did better. -- Grumpy Ol' Fred cisin(a)xenosoft.com

I've only handled one system that had a light pen on a raster display. My experience with a lightpen is actually limited to the vector displays on CDC systems back in the early-mid '60's. They were quite precise in their placement on the rather large screeen, and didn't make first-approximations and let you correct as you went as one might do on a raster display. Since putting a pixel under the light pen was tantamount to making the entire screen white and then erasing/redrawing it, which took quite a while, and that's not what they did, what do you suppose they did on those storage tubes? BTW, with a small-enough aperture at the tip of the light pen, they could have achieved single-pixel resolution, though it might not have been terribly helpful, since the amps used back in the '80's when the 6845 weren't generally fast enough to resolve a single pixel at, say, 16 MHz, which was a pretty slow dot clock, but adequate for the popular rasters of that time, e.g. 512-768 pixels per line. Some makers did manage it, however. more questions/comments below ... Dick ----- Original Message ----- From: "Tony Duell" <ard(a)p850ug1.demon.co.uk> To: <classiccmp(a)classiccmp.org> Sent: Monday, July 16, 2001 6:31 PM Subject: Re: Light Pens ... What do you suppose they did to keep the cursor centered? Did the integrate the waveform from the light pen? How would they handle the vertical centering? Do you suppose they might have used two integrators with one for each axis? I can envision such a scheme allowing them to acquire the pulse from the light pen, then detect the peak and resolve to the single-pixel resolution with a pixel counter. The scheme would work for either axis, though the pixel counter would only be involved in the horizontal scan. The Motorola system on which I saw the demo of a "full" implementation of the light pen together with a 6845 was able to do the job all right, but I'd be surprised to learn they didn't have a dedicated processor just for diddling with the cursor location to track the light pen. I can see that the button on the light pen was used to invoke a "find the pen" command, and, probably, while the button was pressed, tracked the position of the pen on the CRT. That would explain the presence of a 68121 (68121 = 6803+6834 on a single device) video board, since that was possibly where the intelligence for the light pen, plus the 2-ported semaphores + RAM for sharing data between the two processors (68K+68121) would reside. It made for a pretty complex system, though. I doubt this sort of thing would have popped up in a system costing less than $10K at the time.

see questions below, plz Dick ----- Original Message ----- From: "Tony Duell" <ard(a)p850ug1.demon.co.ukTo: <classiccmp(a)classiccmp.orgSent: Tuesday, July 17, 2001 3:35 PM Subject: Re: Light Pens ... placement you pixel then did, the Do Viewed from the 6845, is the block 1 scan line high? The minimal width is probably 8 bits, or whatever else the character width is. How do you suppose they got the resolution down to the individual pixels? IIRC, the MOT raster system I mentioned previously had the horizontal lines modulated with the dot clock, so horizontal lines were dotted and not any brighter than the vertical ones. That impressed me more than the function of the light pen, but it was interesting to see the precision with which the light pen worked. the with 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.

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. 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? Dick ----- Original Message ----- From: "Tony Duell" <ard(a)p850ug1.demon.co.uk> To: <classiccmp(a)classiccmp.org> Sent: Tuesday, July 17, 2001 5:40 PM Subject: Re: Light Pens ... integrate centering? suppose precise extent of

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(a)p850ug1.demon.co.uk> To: <classiccmp(a)classiccmp.org> Sent: Wednesday, July 18, 2001 2:15 PM Subject: Re: Light Pens ... one number register not 6845.

----- Original Message ----- From: "Tony Duell" <ard(a)p850ug1.demon.co.ukTo: <classiccmp(a)classiccmp.orgSent: Wednesday, July 18, 2001 6:13 PM Subject: Re: Light Pens ... the start that here 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, length one 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. 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. be, of and ambient has circumstances count, in Yes, and we're in complete agreement on the details relating to how that happens. However, ... 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. Yes, but what about the variations in ambient lighting? Those move the differential thresholds around. in use as was 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.

Sellam Ismail skrev: The only light pen I've worked with is the Vectrex pen. And while a vector screen differs somewhat from a CRT (it's non-linear, which doesn't help decoding), the drawing program simply projected a dot on the screen, which was moved using the pen. IOW, the dot was registered by the pen, and placing the pen in any other spot on the screen didn't result in anything, one would have to move the dot around as a pointer, much like drag-and-drop. I suppose CRT programs worked the same way. -- En ligne avec Thor 2.6a. I can't understand ANY current MICROS~1 product names! Are they now created with a random word generator? What is the intent behind the name "Visual Studio" for their compiler suite? What is "Interdev"? Why is the Virus Transfer Protocol product named "Outlook"? Grumpy Ol' Fred

Storage tubes could display in non stored mode. If the write beam was below a threshold it wouldn't store, and would need to be refreshed. The 'refreshment' generated the necessary timing signal. Menus were probably always non-stored for that reason. John A.

Tony Duell skrev: First of all, I'm sorry, I realised after dispatching that message that I had written "CRT", when what I meant was "raster screen". What's non-linear about a vector screen is that the beam doesn't move in any particular pattern. That's nice. Did you ever figure out how to use it for anything else than drawing a big umbrella? -- En ligne avec Thor 2.6a. Alle Verallgemeinerungen sind gef?hrlich, sogar diese. --- Alexandre Dumas der ?ltere