CRT and Lightpen problem

Running the signal through a VGA converter loses the original timing information needed to synchronize the light sensor with the computer’s notion of where the CRT is currently painting. The VGA signal draws the whole screen roughly twice in the time the C128 draws it once, so the C128 is going to get pulses from what it thinks is several places on the screen until your finger comes off the trigger a few screen repaints later.

Of course it’s not bloody possible to make it work anyway! The ratio of C128 screen repaints to VGA screen repaints is not only not exact, it also varies enormously depending on the VGA signal parameters (resolution and refresh rate). On top of that, the light pen pulses are coming in at least twice as fast as the 128 expects them to, and in no apparent relation from one pulse to the next. I’d honestly be shocked if the VIC-IIe even registered a value for it, because there’s no consistency to it at all.

So, finally, I see that I must to look at any Commodore monitor...

Miro

Your talk of somehow adapting to the signal had me scratching my head. I didn’t think it was physically possible until I stepped through the logic, and even if you did acquire the user’s help to calibrate your software, it would NOT be straightforward. To show exactly why (and what you would have to overcome), let us step through the exact timeline of events. The following is equally applicable to VIC-IIe (no matter whether PAL, NTSC, SECAM, they’re all pretty similar if you ignore the colour encoding) and to VDC output, as the main difference between them from a timing perspective is that the VDC crams a faster-changing signal (more pixels) onto each scanline.

(1) The C128 begins to draw the first field of the frame. Standard video signals, which is what the C128 produces on both monitor outputs, always come in two fields, each consisting of every second scanline from the complete frame. Whether the even lines or the odd lines are drawn first depends on the video standard, and doesn’t really matter for our purposes here. (Unless you’ve gone to some effort to set up an interlaced display, both fields are exactly the same anyway.) The C128 begins the frame with vertical synchronization pulses prior to the start of the visible signal, which the VGA converter catches, causing it to begin buffering a new frame. It’s most likely going to still be painting the second-to-last previously buffered frame for a random amount of time, varying between roughly zero to 1/30 of a second (0–2 “ticks” in Commodore jargon, or “thirds” to more traditional horology).

(2) As the first field is partly painted, let’s call it about 3/4 done, the user (who started pressing the light pen trigger a few frames ago) finally closes the trigger switch enough to connect the sensor in the pen to the trigger input on the video chip. However, the electron beam is being directed by the VGA converter, which at this point is finally drawing the first part of the last previously buffered frame.

(3) The C128 finishes drawing the first field, puts out some more vertical sync pulses, and starts to paint the second field. The VGA converter is now filling in the missing every second line in its idea of what the current frame looks like, and since that’ll be going on for a bit yet, is probably getting ready to paint the last buffered frame for a second time. (Or, possibly, a third time. Depending on the refresh rate your VGA monitor has negotiated with the converter [generally somewhere between 54 and 85 Hz], some frames will most likely be repainted once more often than others, as the converter waits for the current frame to finish coming in at its TV-derived speed of around 25–30 Hz.) The actual currently-displayed frame could be at any stage of having been painted at this point, but going by how I have described this example so far, it’s probably about 60% of the way through painting the previously-buffered frame image.

(4) The electron beam in your monitor sweeps past the sensor in the light pen, which sends a pulse down the wire and, eventually, into the video chip, which latches the current scanline value into an output register for when your program comes looking. Light pens are not precision instruments, so this pulse is actually several pulses in close proximity, which the video chip has to adjust for. (The whole process takes a small but, to the computer, noticeable amount of time, meaning that even when you have a monitor connected directly to the C128, the value that gets latched isn’t quite the one where the electron beam actually was, so some software calibration is always needed with a light pen, no matter what.) Since the electron beam is not, in fact, controlled by the video chip like it expects, it will register a value near the top of the screen even though in this example the VGA converter is painting nearer the bottom.

(5) The VGA converter starts repainting the screen again, still using the last previously-buffered frame. The C128 has nearly finished filling in the current frame.

(6) The electron beam sweeps past the light pen again, causing another chain of trigger pulses and, eventually, a new raster number to be latched in the video controller. The user hasn’t moved the pen appreciably in the fraction of a second since the last pulse-train came in, but since the actual position of the VGA-converter-controlled electron beam at any given moment can’t be predicted at all from the video chip’s notion of what the current scanline is, your program has no way of knowing that. The scanline number recorded by the video chip is near the bottom of the screen.

**IMPORTANT**: Since the light pen trigger pulse-trains are coming in roughly 0.9–1.7 times as often as the C128 is expecting them (and the pulses are both a bit shorter and twice as numerous as anticipated), there is no guarantee that any specific video chip will be able to keep up. You’d have to try it and see.

At this point, you had better hope your program has been keeping a close eye on a CIA timer through all of this. Assuming the user really is holding the pen still, and you set up an interrupt routine to record (time, raster number) pairs with the least delay possible whenever the light pen trigger goes off, you now know the time between VGA repaints and thus the VGA refresh rate. That in turn will let you calculate the ratio of VGA frames to C128-native ones, which will (provided you’re still keeping a very close eye indeed on the CIA timer) allow you to fudge the recorded raster positions to approximate a correct value. Since this involves a large amount of multiplying and dividing and incredibly precise timing, I think the only way to get acceptable speed out of it is to use a bunch of lookup tables. You would likely have to calculate them from scratch every time you run through the “calibrate light pen” routine, too.