Mon, 13 Nov 2000 Sundeep Kapila wrote:
> On Mon, Nov 13, 2000 at 01:06:52PM +0100, David Olofson wrote:
> > Mon, 13 Nov 2000 Sundeep Kapila wrote:
> > > Hello,
> > >      I want to read input from a joystick (attached on a game port)
> > >    as a real-time periodic process. Can someone give me pointers how
> > >    and where to start ?
> > 
> > linux/drivers/char/joystick
> > 
> > NOTE: Standard PC joystick interfaces suck, as they require busy waiting for
> > accurate reading. If you want a solution that allows you to read the stick
> > without wasting cycles, look for something that uses a different interface, or
> > some sound card (or possibly main board) with a joystick interface with *real*
> > ADCs; not CPU driven capacitor discharge measurement style crap.
> I am not aware of these issues involved in getting  input from game
> ports.

The basic issue is that you have to do the analog to digital conversion by
measuring the time it takes a capacitor to discharge through the potentiometer
in the joystick. There is no hardware to do this, so you end up starting the
conversions, and then waiting for the triggers to flip, keeping track of the
time that takes. These times are in the ms range, IIRC.

> could u give me a reference where i can get more details.

Hmm... There is
        linux/drivers/char/joystick/joy_analog.c
which seems pretty simple to me, but I could try to find some docs as well.
(Don't have any here.) A web search on gameport, joystick, games, programming,
DOS etc should probably result in some old, but informative pages coming up.

> i have a sound card with a game port to which the joystick is
> attached.

What kind of sound card?

If it's a modern PCI card, it *might* have real ADCs that you can use for fast,
accurate and cheap conversions, but I think the old legacy crap is still
the standard. I don't know of *any* sound card that doesn't use the joy_analog
driver for the gameport, but I haven't really looked for one... (A quick browse
through the sound drivers of a 2.2.x kernel gives me an unpleasant feeling of
not having missed anything.)

> this game port would not have different irq as that of the
> sound card.

No, because the gameport does not have an IRQ at all. You have to use some
other timing source to start the conversion, and then do the conversions
through polling.

You *might* get away with a smart RTL thread that does polling for just a
fraction of the time window where it saw the "switch" the last time, and then
have that window chase (auto center) on the actual position.

Normal algo:

        start_conversion();
        js_time = 0;
        while(js_time < MAX_TIME)
        {
                if(axis_status_bit has changed)
                        axis.raw_position = js_time;
                if(all_done)
                        break;
                uslepp(???);
                ++js_time;
        }


Smart algo: (Requires RTL, RTAI or other "�s class" RTK.)

on_periodic_irq()
{
        start_conversion();
        poll_start_time = now + axis.raw_position - POLL_WINDOW_SIZE/2;
        if(poll_start_time < 0)
                do_poll(0);
        schedule do_poll at poll_start_time with arg poll_start_time;
}

do_poll(start_time)
{
        js_time = start_time;
        while(js_time < POLL_WINDOW_SIZE)
        {
                if(axis_status_bit has changed)
                        axis.raw_position = js_time;
                if(all_done)
                        break;
                uslepp(???);
                ++js_time;
        }
}


NOTE: Onle one axis is handled here! The second version becomes more complex if
      there are more than one axis. (You have to track each axis separately,
      but also make sure that no Bad Things happen when their polling windows
      overlap.)


> how can i selectively make reading from this port as a
> real-time process.

Well, as there's no IRQ assigned to the average game port, there's not really
a conflict here, at least not with the classic variants, where the gameport has
some ports of it's own, starting at 0x200. (That is, the audio drivers only
enable the gameport; they don't touch it's registers.)

> can things like inb/outb used to read data from these
> registers periodically in a real-time thread on rtlinux kernel ?

Yep. See above. Copy code from joy_analog.c, as that's a working implementation
that seems to be used with most cards with standard PC gameports. You may want
to chop it up as described above, to save CPU power, but then again, you may
not need to - depends on your application, of course.


//David

..- M u C o S -------------------------. .- David Olofson --------.
|         A Free/Open Source          | |      Audio Hacker      |
|   Plugin and Integration Standard   | |     Linux Advocate     |
|                 for                 | |  Open Source Advocate  |
|      Professional and Consumer      | |         Singer         |
|             Multimedia              | |       Songwriter       |
`-----> http://www.linuxdj.com/mucos -' `---> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Reply via email to