Difficulty in turning left
Daniel M. Coleman
Gamepad and a Flightstick Pro.
Machine:
Gateway 4DX2-66V
64K Cache
VLB ATI Ultra Pro
12M RAM
340M IDE HD
Soundblaster Pro (IRQ5, DMA1)
Microsoft Mouse (COM2, IRQ3)
Telepath II Modem (COM1, IRQ4)
Spare Serial (COM3, IRQ9)
MS-DOS 6.2
I noticed similar difficulty on a friend's 486.
Anybody else notice similar behavior, or know how to fix it?
Thanks for any help,
Dan
--
Daniel Matthew Coleman | Internet: dcol...@mbs.telesys.utexas.edu
-----------------------------------+ DECnet: UTXVMS::DCOLEMAN
The University of Texas at Austin | IRC: Shiner
Electrical/Computer Engineering | "Sure thing, Giant Beer!"
Rob Flax
time I played the reg. version. I have a cheapo Warrior 5 stick and a
Gravis gamecard, both of which have never failed me before, including with
the shareware DOOM. For now, I just use the shareware doom.exe file along
with the registered .wad file, renamed to doom1.wad. This fixes the joystick
problem, omits that annoying calibration prompt, and I think even makes
the game run faster.
Good luck.
Rob
*******************************
Rob Flax
University of Virginia ()_()
Charlottesville, VA (_)
ra...@faraday.clas.virginia.edu
Adam Robert Fields
I had a similar problem with my gravis gamepad. Try re-initializing the joy-
stick (re-start the game) and be SURE you hit the right spots on your gamepad.
That seemed to clear up the problem. I never had the problem with my Mach III,
so I'm pretty sure it's only a problem with sticks (and such) that don't have
well-defined corners...
- Adam
*- "Because only natural products are used, taste, color and body may vary."
*- - Snapple
*>> Adam Fields (ar...@columbia.edu)
*>> The Philolexian Society, ADP, Horizon's Edge Enterprises, Userfriendly Inc.
Apotheosis
: I just got DOOM v1.1 and I noticed a difficulty in turning left using a Gravis
: MS-DOS 6.2
I have the exact same problem. Didn't have it on version .99.... I was
able to play it through to the end with my Gravis Gamepad just great
(I also have a 486DX2-66), but once I upgraded to v1.0 it started doing
that. There may be a bug in the 1.0 upgrade... I tried playing it with
the various Dos extenders, but no luck.....
-Apotheosis
Al Walters
to the right and do everything else just fine, except turn to the left...If you ever
find out how to get this working please post it here.
Thanx,
Al
Cory Serratore
I have a workaround:
When calibrating the joystick, only place it about halfway to
each corner in either direction. This works consistently for
my flightstick.
Cory
Doug Marien
If you have enough memory, like 16meg or more, load RAMDRIVE.SYS
in your CONFIG.SYS file with the options:
device=c:\dos\ramdrive.sys 12288 512 1024
Reboot your computer, and tada, you have a 12 meg disk in memory.
Switch to that drive, it should be labeled something like:
MS-RAMDRIVE. Copy DOOM onto that drive, but beware, because everything
you copy will be erased once you shut the power off, now run DOOM.
It is really fast!!! (loading and stuff)
Have fun, be careful, and always play Ultra-Violence!!
--
"Kill one man you're a murderer. | Doug Marien
Kill a million you're a conquerer. | mari...@gold.tc.umn.edu
Kill everyone you're a god." -Unknown- | sl...@mermaid.micro.umn.edu
---------------------------------------+ Life's short. Slug hard.
Jericho
Marien) writes:
> Have fun, be careful, and always play Ultra-Violence!!
> --
> "Kill one man you're a murderer. | Doug Marien
> Kill a million you're a conquerer. | mari...@gold.tc.umn.edu
> Kill everyone you're a god." -Unknown- | sl...@mermaid.micro.umn.edu
> ---------------------------------------+ Life's short. Slug hard.
^^^^^^^
Try Conrad Bland.
-Jericho
robert logan
: In article <CJ8FG...@news.cis.umn.edu>,
: Doug Marien <sl...@landshark.micro.umn.edu> wrote:
: >Have you ever wanted to speed up DOOM??? Then try this:
: >
: >If you have enough memory, like 16meg or more, load RAMDRIVE.SYS
: >in your CONFIG.SYS file with the options:
: >
: >device=c:\dos\ramdrive.sys 12288 512 1024
: A far more intelligent option is to install a disk cache.
Hopefully Chris means a software cache. A hardware cache
is a far less intelligent solution. With the money
you spend on a disk cache you could buy more ram and
configure as you like.
bert
--
Where's your other hand. |
Between two pillows. | r...@dmu.ac.uk
Those aren't pillows! |
The Renaissance Man
] Chris "Strunoph" Norman (cbno...@undergrad.math.uwaterloo.ca) wrote:
] : Doug Marien <sl...@landshark.micro.umn.edu> wrote:
] : >If you have enough memory, like 16meg or more, load RAMDRIVE.SYS
] : >in your CONFIG.SYS file with the options:
] : >device=c:\dos\ramdrive.sys 12288 512 1024
] : A far more intelligent option is to install a disk cache.
] Hopefully Chris means a software cache. A hardware cache
] is a far less intelligent solution. With the money
] you spend on a disk cache you could buy more ram and
] configure as you like.
Well, personally *I* kind of *LIKE* my hardware cache. I have an EISA
32-bit caching IDE controller, and (a) it's blindingly fast, (b) I don't
have to burn conventional memory on loading software caches, (c) cache
conflicts are a thing of the past, and (d) I have one cache that works
for both DOS and Linux.
--
"I am the NRA." \ "Ultimately, the strongest argument for the people
Alaric Tekiahyn \ to retain the right to keep and bear arms, is to
ala...@netcom.com \ protect themselves against tyranny in government."
The Renaissance Man \ -- Thomas Jefferson (exact wording not guaranteed)
robert logan
: r...@dmu.ac.uk (robert logan) wrote:
: ] Chris "Strunoph" Norman (cbno...@undergrad.math.uwaterloo.ca) wrote:
: ] : Doug Marien <sl...@landshark.micro.umn.edu> wrote:
: ] : >If you have enough memory, like 16meg or more, load RAMDRIVE.SYS
: ] : >in your CONFIG.SYS file with the options:
: ] : >device=c:\dos\ramdrive.sys 12288 512 1024
: ] : A far more intelligent option is to install a disk cache.
: ] Hopefully Chris means a software cache. A hardware cache
: ] is a far less intelligent solution. With the money
: ] you spend on a disk cache you could buy more ram and
: ] configure as you like.
: Well, personally *I* kind of *LIKE* my hardware cache. I have an EISA
: 32-bit caching IDE controller, and (a) it's blindingly fast, (b) I don't
: have to burn conventional memory on loading software caches, (c) cache
: conflicts are a thing of the past, and (d) I have one cache that works
: for both DOS and Linux.
Some points here.
If youve got a 4 Meg machine would you upgrade to
8 Megs or get a 4 Meg cache controller (c.c)?
With 8 Megs you can choose to give 1,2,4,6 Megs for a cache
as you like - and this cache is fast (RAM to RAM). With a
4 Meg c.c you run at EISA speed, and are stuck at that size.
With Linux, you use the full 8 Megs for the system, it uses
a sophisticated *dynamic* cache allocation scheme - grows and
shrinks - as needed. It doesnt know of the 4 Megs on a c.c,
and therefore wastes memory using its sophisticated *dynamic*
cache allocation scheme. Much the same is true for Windows.
DOS may seem faster, but Ill bet a good EISA controller (no
cache) with a software cache of 4 Megs and another 4 Megs
of RAM is as "blindingly fast" as a 4 Meg c.c on a 4 Meg machine.
My analogy : A car (machine) with a trailer (controller).
You could improve performance by putting an engine in the
trailer - or getting a bigger engine for the car. Which
would you do?
The Renaissance Man
] The Renaissance Man (ala...@netcom.com) wrote:
] : Well, personally *I* kind of *LIKE* my hardware cache. I have an EISA
] : 32-bit caching IDE controller, and (a) it's blindingly fast, (b) I don't
] : have to burn conventional memory on loading software caches, (c) cache
] : conflicts are a thing of the past, and (d) I have one cache that works
] : for both DOS and Linux.
]
] Some points here.
Which I'll answer here this time, but if it goes any further we really
should move the discussion to a more appropriate group.
] If youve got a 4 Meg machine would you upgrade to
] 8 Megs or get a 4 Meg cache controller (c.c)?
In that situation, the obvious choice is to upgrade main memory to 8Mb.
4Mb is really inadeuate for any serious use. However, I'm not in that
situation; I have 16Mb of main memory plus my 4Mb caching controller.
Your mileage may vary, obviously.
] With 8 Megs you can choose to give 1,2,4,6 Megs for a cache
] as you like - and this cache is fast (RAM to RAM). With a
] 4 Meg c.c you run at EISA speed, and are stuck at that size.
With a software cache, you can transfer data from system RAM to system
RAM, using the system CPU's time, at system bus speed. With an EISA
caching controller, you transfer data from controller RAM to system RAM
at EISA burst-mode speed, up to 33Mb/sec, using the comtroller's CPU
time. My experience, having tried both, and having tested both with
four different speed testing utilities plus real-world usage, is that
the caching controller is significantly faster and *LOTS* more reliable.
And incidentally, if I only had 8Mb, I'd never burn 6Mb of it on cache.
With only 8Mb, RAM is too precious to burn more than 2Mb on cache.
] With Linux, you use the full 8 Megs for the system, it uses
] a sophisticated *dynamic* cache allocation scheme - grows and
] shrinks - as needed. It doesnt know of the 4 Megs on a c.c,
] and therefore wastes memory using its sophisticated *dynamic*
] cache allocation scheme. Much the same is true for Windows.
The same is *not* true for Windows at all. Windows doesn't *do* any
caching of its own. That's why it insists on loading SmartDrive (even
if you're already using another, better, software cache).
Meanwhile, Linux's own cache can write to controller cache instead of
directly to disk - looking like about a hundred times faster disk, to
Linux - even if you *don't* install the controller's Unix drivers.
] DOS may seem faster, but Ill bet a good EISA controller (no
] cache) with a software cache of 4 Megs and another 4 Megs
] of RAM is as "blindingly fast" as a 4 Meg c.c on a 4 Meg machine.
Well, if we're going to get picky enough at speed comparisons that we're
going to worry about the difference between EISA bus speed and main memory
bus speed, let me point out that my caching controller (like most others)
is a bus-mastering device with its own processor (in this case, an 80186),
and is quite happy to go off and perform disk and cache management tasks
in the background while the CPU is busy working on other things. With a
software cache, the CPU has to take time out to manage the cache. As stated
above, my observation - from real world experience, backed up by testing
utilities - is that the caching controller *is* faster. Plus, it's one
extra device driver and/or TSR I don't have to load - and cache software
can be a real memory hog. The biggest value to me of the caching controller
over, say, SmartDrive 4.0 (when running DOS), is that I get back almost
40k of conventional memory, *even loading Smartdrive high*.
] My analogy : A car (machine) with a trailer (controller).
] You could improve performance by putting an engine in the
] trailer - or getting a bigger engine for the car. Which
] would you do?
Poor analogy. Here's a better one:
You have a library with an attendant at the front desk, who checks books
in and out *AND* restocks the shelves. You want to improve service at
the library. Do you:
(a) Tell the front-desk attendant to work harder, or
(b) hire an assistant to re-shelve returned books?
robert logan
NB, Im not contesting many of the arguments here, they
are valid, but Im trying to look at a typical user.
: ] If youve got a 4 Meg machine would you upgrade to
: ] 8 Megs or get a 4 Meg cache controller (c.c)?
My example was (perhaps) for the more typical user, with
the standard 4 megs, having Windows etc.
: With a software cache, you can transfer data from system RAM to system
: RAM, using the system CPU's time, at system bus speed. With an EISA
: caching controller, you transfer data from controller RAM to system RAM
: at EISA burst-mode speed, up to 33Mb/sec, using the comtroller's CPU
: time. My experience, having tried both, and having tested both with
: four different speed testing utilities plus real-world usage, is that
: the caching controller is significantly faster and *LOTS* more reliable.
As above, most folks dont have EISA, and disk activity is
important - VLB doesnt have burst mode (PCI does), and most machines
are ISA/VLB - the processor time to disk time is far less important.
For ISA this is very important. did I make a point here!?
Getting back to DOOM - on my 8 Meg machine, with 4 Meg SMARTDRV cache
(only for DOOM), I never see disk activity once it has been on for a
while - the same would be true of a 4 Meg controller. But I can cut
this down to 2 Megs when doing some work. A more typical situation
perhaps.
: And incidentally, if I only had 8Mb, I'd never burn 6Mb of it on cache.
: With only 8Mb, RAM is too precious to burn more than 2Mb on cache.
Neither would I, just pointing out flexability.
< Linux stuff deleted, irrelevant to DOOM, but interesting because >
< it should make DOS users realize that something better awaits >
We can Leave this for a Linux group (comp.os.linux.misc).
< Some points on SMARTDRV memory wastage and the benefits of how >
< contoller processors release more time for the main one. >
<my duff analogy deleted - getting better>
: You have a library with an attendant at the front desk, who checks books
: in and out *AND* restocks the shelves. You want to improve service at
: the library. Do you:
: (a) Tell the front-desk attendant to work harder, or
: (b) hire an assistant to re-shelve returned books?
What happens when this kind of system needs to grow and shrink?
Ok, Ill have to admit that Alaric is winning this on most counts.
But I want the last word (in this group at least :) - The final
blow...
Cached controllers are better because they have a seperate processor
to do the work - not just because they have RAM on them. Ideally,
one would have a co-processor for disk management which can 'chat'
with the main processor about how much memory it needs (using
the main system RAM) and release it as required. This sounds like
what Alaric mentioned with Linux - more or less. For the DOS
and Windows user who wants a good price/performance improvement
with DISK and other things - get more RAM and use soft cacheing.
If you run DISK intensive stuff - get a cached controller.
Pigdog of SF Bay Area
: Hopefully Chris means a software cache. A hardware cache
: is a far less intelligent solution. With the money
: you spend on a disk cache you could buy more ram and
: configure as you like.
: bert
Please save us your moronic input.
--
+____________________________________________________________________________+
| TOP 40 USENET NEWSGROUPS IN ORDER BY TRAFFIC VOLUME AS OF 12/05/93 |
| ------------------------------------------------------------------ |
| +----- Note: This is the *most* popular group in the WORLD. |
| | +-- Estimated total number of people who read the group, worldwide. |
| | | +-- Recent traffic (kilobytes per month) |
| | | | +-- Name of group. |
| V V V V |
|(1) 280000 23920.1 alt.binaries.pictures.erotica |
| |
| This Reality Check brought to you by: pig...@netcom.com |
+----------------------------------------------------------------------------+
robert logan
: Please save us your moronic input.
A well considered response. Absolutely wonderful to
have you here.
Roger A. Krupski
> you spend on a disk cache you could buy more ram and
> configure as you like.
disk controller) then ALL your disk data is funneled through the rather
slow AT bus (8 mhz, 12 if you are lucky). A _software_ cache is in ram,
running at full system speed (i.e. 33 mhz).
So, a SOFTWARE cache usually works better (faster) and also you can easily
re-configure your setup (steal memory from the cache for other uses) simply
by editing the CONFIG.SYS or AUTOEXEC.BAT line that loads the cache.
A hardware cache controller's ram is usually not available to your system
unless you physically swap SIMM modules.
Hardly a moronic concept (in my opinion) ;-)
Roger
--
Roger A. Krupski .-- .- ..--- ... -.- ---
State University of New York at Buffalo
Internet: kru...@acsu.buffalo.edu
Brian Tottleben
: Please save us your moronic input.
I know this is going to sound incredible hypocritical, but what the hell.
You spend 6 lines quote someone else only to make a pathetic one line
comment and then tack your 12 line signature at the end of it all.
Whose giving the moronic input?
Pigdog of SF Bay Area
: I know this is going to sound incredible hypocritical, but what the hell.
: You spend 6 lines quote someone else only to make a pathetic one line
: comment and then tack your 12 line signature at the end of it all.
: Whose giving the moronic input?
I just feel that this thread is a prime example of ANAL netters.
Of *course* the man meant a software cache. This is almost too obvious
to dispute. Yet we have to waste another good 10 posts to discern this.
Yeah, yeah, I realize I started it, and admit it, but I can only take so
much before I just have to be mean.
Whatever...continue with the thread...flame me at LEAST another five times,
so we make par.
:) :) :) <--- Happy faces. Don't get your feelings hurt by this post.
Ciao, baby..
robert logan
: Of *course* the man meant a software cache. This is almost too obvious
: to dispute. Yet we have to waste another good 10 posts to discern this.
: Yeah, yeah, I realize I started it, and admit it, but I can only take so
: much before I just have to be mean.
Of *course* he meant a software cache. Working at that level
will help no-one. Someone posted about using a RAM disk. The
software cache solution was easier - someone posted it - but
if you thought RAM disks were the answer then maybe your
knowledge is limited and requires some considerable clarification.
Im glad of my ANAL abilities - are you?