rec.autos.simulators

% Michael, what differences does the dedicated game card make as far as
% driveability is concerned?

One more difference I noted.  I had a hell of a time maintaining the
proper pit speed with my soundcard gameport.  I had to consitantly keep
the speed down (about 2-3 mph) as just the slightest touch of the pedal
would send it over the limit and I would get black flagged.  With the
Thrustmaster ACM card, I can comfortable keep it within the speed limit
(or 1 mph under), without worrying that any "tremble" of the foot will
cause it to go over.  

--
**************************** Michael E. Carver *************************
     Upside out, or inside down...False alarm the only game in town.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./.  [-  < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

% Continued in next post. . .

Part II:

--------------------------------------------------------------------

Subject:      Re: Dedicated game card really needed?

Date:         1996/08/27
Newsgroups:   comp.sys.ibm.pc.games.flight-sim,rec.autos.simulators,comp.sys.ib
m.pc.soundcard.games

Michael,

Think about it - suppose the DREADED 12% impact were true and you were
running a sim or game that you got 7 fps on - a better game port could
improve that to about 7.8 fps.  On the highest end of the spectrum, say
at 25 fps, that would go to 28 fps.  25 fps is where things look smooth
to you and any more really doesn't help all that much.

On the lower end (6% improvement) the numbers are:

7 fps to 7.42 fps
25 fps to 26.5 fps

Likely you'd see it somewhere in between - maybe the 9%???

that's:

7 fps to 7.63 fps
25 fps to 27.25 fps.

And that's assuming you can ignore everything else that's going
on inside the computer and in the software itself that also can
interfere at different points.  Unfortunately, although you, and
magazine writers and marketing people can ignore them, the computer,
the software, and the game port can't ignore them.

The issue is simply how the joystick routine is written, how the
game port responds to the signals from it, and how everything else
in that particular person's computer is impacting things all have
something to do with it.  For those who have the problem, they should
get a speed adjustable game port and fix the problem.

For those who do not run into this situation, they should use what they
have and not fix something that is not broken - UNTIL and IF they run
into a game or sim that they encounter the situation with.

Saying "You don't need one because it all works fine on MY system is not
an intelligent answer."

Saying "You may need one on your system for some software IS the answer.

Buzz
   _________________________________________________________________

Continued in next post. . .

--
**************************** Michael E. Carver *************************
     Upside out, or inside down...False alarm the only game in town.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./.  [-  < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

% I would have swore when I first got this game there was something in one
% of the add on readme files on th CD that talked about adjusting the
% throttle required to induce wheel spin, which I didnt care less about
% when I read it. Then I played the game and thought...hey too much wheel
% spin at low % throttle. I went back and tried to find the read me and
% never could!!! Did I dream this am I losing it!!!!! Am I a little bit
% crazy hehehehe. Hey! I have got to know!

I think we are all losing it <g>.  I thought there was alot more
detailed information on the wheelspin than I was able to find out by
reading the various readme's.  I guess we just have accumalated
knowledge from readeing r.a.s. ;-)

--
**************************** Michael E. Carver *************************
     Upside out, or inside down...False alarm the only game in town.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./.  [-  < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

% Part II:
<snip>
% Continued in next post. . .

Part III:
---------------------------------------------------------------
Subject:      Re: How does a joystick card work?

Date:         1996/09/21
Newsgroups:   comp.sys.ibm.pc.games.flight-sim

David,

Not too dazzling, but:

The short version.

Each game has a joystick routine written by the programmer of that game.

The joystick routine sends random data to port 201h (that's an address inside
the PC).

The random data basically wakes the game card up and alerts it that the
joystick routine in the game is coming its way to take a reading.

The game port resets and gets ready to be read by the joystick routine.

Caps on the game card will trigger a signal either high or low for:

4 analog inputs:
Joystick 1 - X1 - Roll axis
Joystick 1 - Y1 - Pitch axis
Joystick 2 - X2 - Rudder pedals (ALL RUDDER PEDALS no matter who makes
them or if they are operated by your feet, by twisting a joystick handle
or on the joystick base itself - they all operate thru this analog input
on the game card)

Joystick 2 - Y2 - Analog throttles - YES ALL OF THEM - little throttle
wheely things, big throttles, slider throttles, etc.  As long as they are
in analog mode they operate thru this analog input on the game card.  The
ThrustMaster hat switch can operate thru here as analog hat instead if the
throttle is being used as a digital (thru the keyboard line not the game
port) instead in which case the computer is being fooled into thinking
that this analog input is really 5 inputs).

4 button inputs:

Joystick 1 - button 1 (all triggers but wouldn't have to be)
Joystick 1 - button 2
Joystick 2 - button 1 (aka button 3)
Joystick 2 - button 2 (aka button 4)

The joystick routine starts a counter and reads the state of the pulse
on the above eight inputs at port 201 (there are no more inputs on port
201 so you cannot have another throttle input, analog toe brakes on
your rudders, etc, etc, etc. here - this is a limitation of the original
design of the PC not anyones fault - it was just one of them "who'd
ever need any more than that" things that PCs are so subject to.

Each time it 'loops back' and reads the pulse it increments the counter
for each of the inputs.

The time it takes for the signal for each of the 4 joystick axes inputs to
change from a high state to a low state (or vice versa) tells the joystick
routine at what position the handle of the joystick (throttle or rudders)
is being held at by the user (this happens in microseconds so human movements
can all be tracked by the pc and the joystick routine and game card).

The joystick routine takes the number of counts and converts them to stick
position info (the 4 buttons btw are simply on or off, no need to time them)
and uses this information within its program to move the aircraft, the car,
or whatever you are controlling the movement of.

What can go wrong:
1. The joystick routine is written on say, a 486/66 - by the time the game
gets on the market and is wildly popular the typical pc is a 486/100 or a
Pentium 75, etc.  The 486/100 and Pentiums run far faster than the 486/66
so the number of loop counts the joystick routine sees is way higher than
the counter was designed for so the routine counts itself into oblivion and
fails to see the stick, or misinterprets the position information, etc, etc.

i.e. Routine written on a 486/66 typically sees loop counts of 400 to 500
so the counter is a three digit one made to count up to 999 and then start
over again at 001.  Game is installed on a Pentium 75 and the joystick
routine runs and the counts come out in the thousands, i.e. 1500.  The
counter here will read like 500 to the joystick routine in the game since
it can only accomodate up to 999 and the routine misinterprets the position
information.  Worse, I've seen routines where they have a provision that
if they see numbers above or below the range they expect to see they simply
ignore the stick input as though not joystick is attached.  Others will
interpret the stick to be in the upper left corner (the low end of both
positioning pots.)

Having a joystick routine count itself into oblivion is not a rare thing
in joystick routines - I've seen more than a few.  Many of the game programmers
are extremely good at writing joystick code as well as graphics, etc.  Others
do not seem to understand the whole gameport/joystick routine process.

2. Heat from the computer builds up over time and causes the number of
loop counts to vary significantly so the joystick requires recalibration
every so often to get the nubers back in line.  The ACM card is designed
to eliminate this completely (the mil spec components in it allows a
drift of only +/-1% the typical game port uses 20% tolerance components.)

Too bad too, it doesn't require much to have the joystick routine adjust
itself to the speed of the processor in the machine (that info is available
to the programmer in a memory location in each computer and it can be
easily read by his program).

3. The game port has a one shot that resets too slowly so the joystick
routine triggers port 201 that it is about to be read and then immmediately
attempts to read it before the one shot on the game port has had time to
reset itself and the joystick routine gets a bad reading - and it can interpret
this many ways - no joystick there, joystick in upper left, or lower right,
or anywhere else but where it really is or jittering, etc, etc.

Let me emphasize that ALL OF THE ABOVE can be cured by a properly executed
joystick routine in the game with the possible exception of the heat drifting.

But, what with things being as they are - it's not likely that everyone is
going to write a 'proper' joystick routine and it's not even the programmers
fault, necessarily.  His routine can encounter situations in a different
computer setup that will not work properly with that routine when it worked
perfectly fine in his.  There are way too many varieties of computer systems
out there to be able to make this just a simple - "it's the joystick
routine's fault." or "it's the game ports fault"  It's quite likely a
combination of a lot of things in that particular end users compute system.

Now, aren't you glad I gave you the SHORT version. 8)  The long version is
likely why how joystick really work on a compute is one of the most
misunderstood things there is.  And why the joystick so often gets blamed
when it has the least to do with it.

The joystick is wires, potentiometers (two, three or four) and buttons (two,
three or four) (THESE ARE GAME PORT inputs - the multi-button programmable
joystick buttons and hats work on the keyboard line so don't relate to this
discussion at all) and that's all.

The game card has a lot of electronic circuits and components on it.

The joystick routine is the thing that controls the whole process - the
starting and reading of the game card and the interpretation of what it
sees on the game port.

Buzz Hoffman
ThrustMaster, Inc.

   _________________________________________________________________

Okay, folks that's all from the archives. . .

--
**************************** Michael E. Carver *************************
     Upside out, or inside down...False alarm the only game in town.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./.  [-  < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

I'm not convinced.
If I had any of the problems described, I would solve them.
1.  Jitter on the calibration scale
2.  readings of zero
3.  Readings that go off the scale and wrap

Instead, the question is:

Is there any anvantage to using a game port that yields a 0-200 range
in the calibration screen, vs a game port that yields a 0-1500 range
in the claibration screen?

If both give smooth movement with no jitters, which is better?

Granted, the 0-200 might LOOK smoother since the same foot or wheel
movement will result in fewer changes to be reflected on the
calibration screen.  You might even be able to see the jumps, like
looking at the second hand of a quartz watch?

We might need to know how Papyrus is reading these values to
understand which is better?

Here is a stab at one interpretation:

Let's say you use half the range for gas and half for brakes.  0-200
gets split in half.  That means 100 different throttle settings and
100 different brake settings.  That sounds like alot, maybe more than
the human foot/brain is capable of?  Until you realize that the car is
going 200 MPH?  Now those 100 different throttle settings might only
give you a 2 MPH resolution?  If pace speed is 90, your only choices
might be 87, 89, 91, 93, etc.????  I doubt this... since there are 4
gears.  

Maybe the 0-200 range is better once the pots start getting twitchy?
(and we know that ALL pots start getting twitchy at some point?)

Still looking for information...
--
Best Wishes!!!
Robert Huggins
Raleigh, NC

Okay, I give up...  How many angels can dance on the head of a pin?

We are talking a very small slice of a microsecond here.  If you haven't
tried a quality game card in your system, you won't really know the
difference.  If you are at all curious, find a store that will allow you
to return hardware and try a ThrustMaster ACM card.  

% I'm not convinced.
<snip>
% Instead, the question is:

% Is there any anvantage to using a game port that yields a 0-200 range
% in the calibration screen, vs a game port that yields a 0-1500 range
% in the claibration screen?

The answer depends on the software and how well it compensates for the
wider range.  This is were Grand Prix 2 really shines in the fine
adjustments one can make on how the joystick routine responds.  

The shorter the pulse lenght required to get the results, the smaller
the range.  The faster the results are obtained the faster the program
can use the data.  To quote Buzz Hoffman:
"The advanced precision IS there, but you really have to be
looking for it to see it. And, once again, it is a question of small
differences that, over time, can add up to big ones."

% If both give smooth movement with no jitters, which is better?

% Granted, the 0-200 might LOOK smoother since the same foot or wheel
% movement will result in fewer changes to be reflected on the
% calibration screen.  You might even be able to see the jumps, like
% looking at the second hand of a quartz watch?

% We might need to know how Papyrus is reading these values to
% understand which is better?

% Here is a stab at one interpretation:

I think you are missing the concept.  It isn't really the range that is
the issue.  It is how long it takes for the program to generate the
counter it needs to judge the location of the wheel.  Looking at the
range of the numbers is very confusing.  And as mentioned in an earlier
post, it is counter-intuitive.  If my car is going 200+ MPH I would
rather have the controlling devices sending responses back to the
"brain" as fast as possible.  Again the key is "shorter pulse length".
If the brain has to wait 2-3X as long to get the data it required to
know where the brake pedal is going at 200 mph, it will simply react
later.  This is something we all suffer with age. <g>

% Let's say you use half the range for gas and half for brakes.  0-200
% gets split in half.  That means 100 different throttle settings and
% 100 different brake settings.  That sounds like alot, maybe more than
% the human foot/brain is capable of?  Until you realize that the car is
% going 200 MPH?  Now those 100 different throttle settings might only
% give you a 2 MPH resolution?  If pace speed is 90, your only choices
% might be 87, 89, 91, 93, etc.????  I doubt this... since there are 4
% gears.  

% Maybe the 0-200 range is better once the pots start getting twitchy?
% (and we know that ALL pots start getting twitchy at some point?)

% Still looking for information...

Again the range is just a visual "cue" as to the difference between a
highly tuned game card and one that just hums along.  

But actually, the point is.  If you are not experiencing any problems
and you are quite happy with your current game port.  Forget about
trying to figure out the number of angels.  It just like any racer
though, always looking for an edge.  I believe that a quality speed
adjustable game card provides a "slight" edge.  I will admit, it's
slight, but it's and edge.

--
**************************** Michael E. Carver *************************
     Upside out, or inside down...False alarm the only game in town.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./.  [-  < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=

OK, I think I understand the concept.  The computer can read the
values in the range 0-200 more frequently than it can read the values
in the range 0-1500.  Can someone confirm this?

I seem to remember the code is different for true Intel Pentium
processors -vs- some cyrix chips and 486 level processors.  Can
someone provide an answer to the differences in reading different
ranges based on the different processor types?  I suspect the
advantage of the Thrustmaster ACM was reduced by the pentium specific
circuitry and corresponding code?

Is the relationship straightforward?  i.e. can the values from 0-200
be read 7.5 times more often than values from 0-1500?

Is there a happy medium between the range of values and the rate at
which this range is polled?  If this is true then a speed adjustable
card like the ThrustMaster ACM card can provide an edge.  Is the 0-200
range the most popular adjustment for Papyrus products?

How much of an edge does this provide?  .... How many angels on the
head of a pin?  This is exactly the question.  Is it obvious?  How
much difference does it make?  What factors does it depend on?

If we knew that the range of 0-1500 got mapped to 15 degrees of
steering lock in .5 degree increments, then the chunks of 50 on the
calibration screen might not be worth the added time to read that
large range.  I might apply some twisting of Nyquist's Theorem and
conclude that I want a range of 0-60 to accurately provide input to 15
degrees of steering lock in .5 degree increments.  Without knowing the
actual code there might not be a way to eliminate the aliasing
distortion in the A/D conversion or the round-offs in the simulation.

How far away can the digital wheels be?  Will they use the USB?
Force-feedback and digital...  thats what I want....

--
Best Wishes!!!
Robert Huggins
Raleigh, NC