Dan Miller, a friend of mine, is working on a project. He is trying to create a driver for a light pen he found. He bought the lightpen, which hooks into the gameport, but it did not come with software.
I've been relaying some messages to the internet for him to get information about Apple II video modes, etc.
I worked on parts of the driver. The driver is complete.
What it does:
The driver first has to synchronize to the Apple II video VBL. It tells
the user to point the gun at the upper right corner of the screen. The driver then waits for VBL to start, and then end. The program could be several cycles late in detecting VBL start or end (which is the one we are concerned with.) It looks at the gameport for detected light. The lightpen outputs a signal when it detects a pixel that was just drawn (or is being drawn). When detected, the program knows how long it was since it detected the VBL end. It then calculates EXACTLY when the VBL period ended.
The program then counts the remaining cycles to end up at VBL end, and starts looking at the gameport again. During the Horizontal blanks, it increments the Y location, and waits the rest of the 25 cycles to get to the next scan line. It does this until it detects light on the pen, and then draws the cursor on the screen.
COL1 LDA #1
COL2 LDA #2
It does this 10 times for each scanline. With the timing of the detection code, there is a horizontal resolution of 10. It takes 4 cycles for each check of the port, and the screen is 40 bytes/40 cycles wide. 40/4=10.
Problems: Each time the user wants to use the pen, the program has to calibrate, or the program has to be coded with the cycle count in mind. For instance, a drawing program could fit in the VBL period, or after there has been light detected at the port, but the code has to have the correct ammount of cycles to keep synchronized to the VBL.