Newsgroups: rec.autos.simulators
Subject: Re: MS Force Feedback Wheel Question
From: netlarry@xhisx.com (Larry)
Date: Fri, 20 Nov 1998 15:57:34 -0500
Message-ID: <1disuqn.9fgym5fosjf6N@aln-65-92.jmb.bah.com>
References: <4CP02.2249$o3.1091797@newse2.tampabay.rr.com> <1di59dq.1lcnq451go1fxrN@[10.158.57.13]> <7238bk$eea$1@news-2.news.gte.net> <1diflpk.1v0fctq1776k14N@[156.80.65.113]> <72pveq$hqd@news.dns.microsoft.com>
User-Agent: MacSOUP/2.4b3 (unregistered)
NNTP-Posting-Host: aln-65-92.jmb.bah.com
Organization: Heller Information Services
Lines: 93
X-Authenticated-User: mactech
Path: news.jprc.com!dca1-feed2.news.digex.net!digex!news1.radix.net!news.er.usgs.gov!mcmcnews.er.usgs.gov!news.indiana.edu!NewsNG.Chicago.Qual.Net!nyd.news.ans.net!newsfeeds.ans.net!news.idt.net!nntp.giganews.com!solomon.io.com!outfeed1.news.cais.net!news4.his.com!netlarry
Xref: news.jprc.com rec.autos.simulators:58800

Ok, Paul and Randy.  Thanks for your responses...

But...

While we have to facinating and technical lessons here, neither one of
them tells _us_ how to make _our_ MSFFW's work with Nascar 2.

I've re-read them several times, and I don't see the answer.

Your theories are nice, but they don't appear to work for us :)

If your answer is to run Nascar 2 in DOS mode, that won't work for many,
if not most of us, as we run NROS.  NROS is a Win9x front-end, and can't
be launced from DOS mode.

So, the question still remains.  How _does_ one get the MSFFW to work
with Nascar 2.  Everything I've read says it _cannot_ be done  because
the MSFFW is a digital device and that Nascar 2 does _not_ work with
digital devices.

If you have some sort of step-by-step plan to get around this issue, it
would most certainly be appreciated.

Thanks!

-Larry


-Paul <paulsan@microsoftSPAM.com> wrote:

> Sure it can.  When a write operation is detected to the game port (address
> 0x201), the DOS game is trying to charge the capacitors in the game card.
> The DOS game goes into a software timing loop reading the bits on the game
> port waiting for the capacitors to discharge.  The digital controller
> pretends to be an analog device and resets the bits when an appropriate
> decay time has been reached.
> 
> Technically, a VxD is involved in the above, but it is sometimes easier to
> conceptualize it if you think of the controller doing the delay.
> 
> For most DOS games the above works pretty well.  Papyrus tried to improve
> the efficiency of reading the port on Nascar 2.  This threw off our VxD as
> well as a few other wheel's VxDs.  I've met most of the wheel people out
> there and they all had some issues with N2.
> 
> -Paul


Randy Cassidy <rcassidy@remove_this.aloha.mv.com> wrote:

> Paul is quite right.  Port 201 joystick read routines work by issuing an
> OUT to port 0x201, and then sit in a tight loop performing IN's on this
> port, looking for each axis' bit value to change.  Simplistic port 201
> routines just count the number of INs it takes for each axis to change.  A
> slightly more sophisticated port 201 joystick reader will also disable
> interrupts during the read.  Servicing interrupts during the read can lead
> to jumpy reads, so disabling interrupts is essential if you want your reads
> to be accurate.  Up until the Rendition version of IndyCar Racing, Papyrus'
> joystick reader "counted the INs", and disabled interrupts.
> 
> Unfortunately, the "counting the INs" method works poorly when there are
> bus mastering devices active in the system.  Such devices (I bet you can
> guess one) can stall the processor, leading to intermittently lower "IN"
> counts than would be appropriate, and thus jumpy joystick reads.  There's
> nothing we can do about a bus mastering card stealing cycles away from the
> CPU, so if we "count the INs" we'll have dicey reads.
> 
> "Counting the INs" can also work rather poorly when the serial port is
> active if you haven't disabled interrupts, since the serial port interrupts
> will intermittently skew the IN count lower than it should be.  You can
> disable interrupts during the joystick read, but this can cause loss of
> incoming data, and poor outgoing throughput on the serial port.  Unless, of
> course, you put two-and-two together, and service the serial port directly
> while you have interrupts disabled.  In the good old DOS days our joystick
> read routine did exactly that.  It would disable interrupts, and it would
> service the serial port(s) in its loop.  This gave us lossless incoming and
> kick-ass outgoing serial port throughput (_without_ a 16550 UART!), and
> accurate joystick reads.
> 
> Unfortunately, this doesn't work unless you run the game by rebooting the
> machine into exclusive DOS mode (Windows "virtualizes" our request to
> disable interrupts - by not disabling them.)  If we wanted to allow our
> NASCAR Racing 2 customers to play two- or multi-player games through a
> serial port while in Windows, and we wanted reasonably smooth joystick
> reads, we couldn't use the "counting the INs" method.
> 
> So we abandoned "counting the INs" in favor of a more accurate method of
> measuring the passage of time.  My guess is that these VxD's don't "reset
> the bits when an appropriate decay time has been reached", but, instead,
> reset the bits when some number of INs have been performed.  So all the
> jumpiness we eliminated, these VxD's put right back in.
> 
> Randy
