VOGONS

Search

Common searches

CGA light pen strobe and latching?

Topic actions

First post, by superfury

Posted on 
User metadata
Rank l33t++
Rank
l33t++

Exactly what is the difference between accessing ports 3DB("Clear lightpen latch") and 3DC("Preset lightpen latch")?

https://www.seasip.info/VintagePC/cga.html just explains 3DB (for clearing it to latch the lightpen position at a later time).
https://pdos.csail.mit.edu/6.828/2008/reading … /vgadoc/CGA.TXT says that 3DC latches the lightpen address from the light pen position.

Reengine says that (https://www.reenigne.org/blog/cga-reading-the … lightpen-latch/) the reading from 3DB and 3DC then reading the lightpen registers gives the current beam position instead of from the light pen inputs?

So does 3DB cause the lightpen to latch into the registers without 3DC being accessed? And if 3DC is accessed after it, it will trigger immediately instead of during the light pen location(otherwise, wait for the light pen location to get a pulse from the light pen pin on the CGA lightpen port)? Or am I missing something here?

If I check Reenigne's own tested code, https://github.com/reenigne/reenigne/blob/mas … n/lightpen3.asm , it means that 3DB rearms the latch (and clears the bit in the input status register), while 3DC is only used to cause it to latch immediately instead of waiting for the light pen pulse (so it's in fact a preset pulse manual input from the light pen triggered from the CPU)?

Edit: So, 3DB clears the light pen latch and allows a hardware pen to trigger it's latching. 3DC causes a cleared light pen latch to immediately trigger as if the hardware pen was giving a pulse when the port is written (so in effect this port access itself directly causes the pulse to be registered)? So without 3DB accessed first it would have no effect (pulse registered while the light pen is set, or otherwise registering a 'pulse' at that very moment and cause a latch (if the latch wasn't set already))? And just 3DB without 3DC will cause documented light pen reading behaviour?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 2, by kdr

Posted on 
User metadata
Rank Member
Rank
Member

Yep, so on the CGA there is a flip-flop (half of chip U11) with its Q output connected to the CRTC's LPEN input.

(Check the schematics at e.g. http://www.minuszerodegrees.net/oa/OA%2 ... 0(CGA).pdf for the gory details.)

When you access port 3DB this asserts the flip-flop's /CLR input and when you access port 3DC this asserts the flip-flop's /PR input. The light pen input (the photosensor) is connected to the flip-flop's CLK input, and the flip-flop's D input is wired to +5V.

What all of this means in practice: first you access port 3DB to reset the flip-flop, which sets the LPEN signal to 0. Then the electron beam triggers the light pen sensor, which clocks a 1 through the flip-flop, setting the LPEN signal to 1. If the beam triggers the sensor again, nothing happens and the LPEN signal stays 1. (This is just a simple 'debouncing' type circuit!)

Accessing port 3DC is just an alternate way to trigger this flip-flop. Again, once the flip-flop ends up in the 'set' state, further triggers of the light pen sensor or accesses to the 3DC port have no effect until the flip-flop is reset via port 3DB.

On the rising edge of the LPEN signal, the MC6845 CRTC will latch the current memory address (i.e. whatever is being output on MA0..MA13) into the light pen position registers. In text mode, this will be the memory address of the *character* being displayed; the row address (RA0..RA3) is not captured. So you only get a very imprecise position. In graphics mode the situation is better, since each graphics "character" is only two scanlines high.

The intended usage with an actual light pen would go something like: wait for vblank, reset the light pen flip-flop, wait for the next vblank, then check the status port and see if the LPEN signal is asserted. If so, the light pen was positioned somewhere on the screen, so read the light pen registers from the CRTC to get the character address. Then reset the light pen flip-flop and repeat as many times as desired.

Why did IBM provide a way for software to trigger the light pen strobe? I'm almost certain it's for diagnostic purposes so that it's possible to test the light pen portion of the CGA card without needing either user interaction or an actual light pen attached.

Reply 2 of 2, by superfury

Posted on 
User metadata
Rank l33t++
Rank
l33t++

OK. So it's implemented correctly.

One little thing I notice when using the MS-DOS prompt with the light pen is that when I press the button on the light pen (inside UniPCemu running MS-DOS 6.22), the cursor changes to a block cursor when the light pen button is pressed and returns to normal when it's released? Any idea why or if MS-DOS actually supports the light pen in some way? Perhaps it's emulating some mouse input for software or something like that?
Anyone knows more about this?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Go to top of page Go to top of page
Back to PC Emulation
Close window
Close window