VOGONS

Common searches


EF2000 for DOS with 3DFX patch

Topic actions

Reply 60 of 97, by Nigel

User metadata
Rank Newbie
Rank
Newbie

Well thanks for all the work so far Paul (and the other guys).

I knew it would be a tough nut to crack.

I'm a rank amateur at the programming lark, but I assume that even with a direct link to a graphics card (as opposed to through an external API) all the executable is actually looking at is a memory address. If that is true would it be possible for a TSR to intercept the memory calls and redirect them, or is it too dynamic to keep control of?

(If that sounds daft then bare in mind my first words in the last paragraph!)

Taking your point about modifying the built-in code library, some one has done this in a minor way for DID's Total Air War so that it goes above the 800x600 limit to 1024x768. It's purely for the latest D3D patch (and it doesn't work on my graphics card!) but it obviously works for some and so is possible.

Reply 61 of 97, by Glidos

User metadata
Rank l33t
Rank
l33t
Nigel wrote:

I'm a rank amateur at the programming lark, but I assume that even with a direct link to a graphics card (as opposed to through an external API) all the executable is actually looking at is a memory address. If that is true would it be possible for a TSR to intercept the memory calls and redirect them, or is it too dynamic to keep control of?

I think something like that would be possible, but its a big project. VDMSound works a bit like that; it pretends to be a real SoundBlaster card. In the case of Glide, I think it would be easier though to patch the game's executable.

Reply 62 of 97, by Stiletto

User metadata
Rank l33t++
Rank
l33t++

I've met a few hackers online, Paul. If anyone takes the bait, what directions should I give them? What stub library where? 😀

Your comment about the TSR brings up another question of mine:
Could someone write a TSR that could intercept any and all DOS mode (or possibly Win16) video code? Not just VESA calls... A comment from a friend:

As far as writing a 32-bit TSR in DOS, though, that sounds like it could get very nasty. Calling this 32-bit code from the INT 0x10 handler isn't something I'd want to have to think about. The other concern I have is any backdoors that the DOS apps might use instead of the front door of INT 0x10 for the VESA functions. Or the DOS apps mixing and matching direct VGA register addressing with VESA functions...

I've a 32-bit-only library in mind to handle the calls, which is why we're referring to it as a 32-bit TSR. IMHO, I don't think it's possible to intercept EVERY video function, but I'm hoping for more discussion and thought down the road. *idly wonders if Harekiet is reading*

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 63 of 97, by Snover

User metadata
Rank l33t++
Rank
l33t++

It seems to me that an emulated system would do a much better job of this, since it will catch EVERYTHING that occurs. By this I mean, if it tries to use a different door, the isolated emulated system will know about it, but the TSR might not. At least as a debugging platform, something like DOSBox would be far superior.
But then again, I'm really, really tired, and I don't know that much about TSR programming, so I might be thinking in complete gibberish, in which case, excuse me. 😀

Yes, it’s my fault.

Reply 65 of 97, by Glidos

User metadata
Rank l33t
Rank
l33t
Stiletto wrote:
I've met a few hackers online, Paul. If anyone takes the bait, what directions should I give them? What stub library where? :) […]
Show full quote

I've met a few hackers online, Paul. If anyone takes the bait, what directions should I give them? What stub library where? 😀

Your comment about the TSR brings up another question of mine:
Could someone write a TSR that could intercept any and all DOS mode (or possibly Win16) video code? Not just VESA calls... A comment from a friend:

I've a 32-bit-only library in mind to handle the calls, which is why we're referring to it as a 32-bit TSR. IMHO, I don't think it's possible to intercept EVERY video function, but I'm hoping for more discussion and thought down the road. *idly wonders if Harekiet is reading*

Glidos's Gldvesa.exe already calls 32bit code from from hooked int 10h interrupts in real mode. It does sound difficult, and it took me months to work up the courage to try it, but it turned out not so difficult.

The main conceptual problem with taking over all int 10h calls, VGA as well as VESA, is that there are IO ports involved and the documentation on VDDs says that you aren't allowed to hook the VGA port access. That might just be a warning and it might work for some systems. If there were some way around that then it can be done I think, but its a hell of a lot of work.

Reply 66 of 97, by Snover

User metadata
Rank l33t++
Rank
l33t++
Unregistered wrote:

heh, stop researching stuff.
It's interesting that that guy could find and post so much information and still be so clueless in how to use it ("how to use the variables is anybody's guess").

Yes, it’s my fault.

Reply 69 of 97, by bored

User metadata
Rank Newbie
Rank
Newbie

It was a bit of a loaded question. 😀

Virtual hardware?
If I run the game on 'Virtual PC', is it possible to intercept the calls to the non-existent PCI card?

Patching the binary?
Probably the 'easiest' way, but I guess this would need some 'dll injection' trick?

I have the non-3dFX versions of the game running in dosbox, but I would like to find a way to run the 3dX version on a modern PC.....and would be very interested to hear what your approach would be.

Reply 71 of 97, by janskjaer

User metadata
Rank Member
Rank
Member

I'm having some trouble applying the Graphics+ patch (gfxplus.zip -> tactcom.exe) to my EF2000 + TACTCOM installation.

via DosBox, I've installed EF2000 from my CD, then installed the TACTCOM patch. I can run this version without any problem.

I then tried to install the Graphics+ patch via DosBox to find the patch must be run under the Win32 environment.

So, I did just that, executing the TACTCOM.exe under Windows (I'm currently using Win7 x64).

The patch interface has two options:

- 3DFX Update
- Rendition Update

However, regardless of which option I choose, I get the following message:

"please copy to the TACTCOM directory".

so I copied the TACTCOM.EXE into my EF2000 game directory and run the patch but I get the same message.

How can I apply this patch? Do I need to apply this on an older version of Windows (95?)?

DELL Dimension XPS M200s
:Intel P1 MMX 200MHz
:64MB EDO
:DOS 6.22/Win95b
:Matrox Millenium II + m3D (PowerVR PCX2)
Chaintech 7VJL Apogee
:AMD AthlonXP 2700+
:512MB DDR
:Win98SE/2000 SP4
:3dfx Voodoo5 5500 AGP

Reply 72 of 97, by bored

User metadata
Rank Newbie
Rank
Newbie

IMHO the easiest method is to carry out the installation and patching process on a pre-64bit machine, then copy across the resulting directory to the Win7 x64 machine.....which presumably isn't the one in your sig.

Note that you'll need a version of Dosbox to with kekko's patch to experience the 3dfx goodness.

Reply 75 of 97, by Gamecollector

User metadata
Rank Oldbie
Rank
Oldbie
Glidos wrote:

I would be very interesting if there were a patch that made EF2000 support the later versions of Glide that required Glide2x.ovl

No. So, the best option is DosBox with the voodoo1 software emulation. Ykhwong's build, as the example.

Another games with statically linked glide - Battle Arena Toshinden (patch), Fatal Racing, Starfighter 3000. X-Car and Tomb Raider have versions with and without static link. All working good with custom DosBox build.
Fatal Racing 3dfx and Starfighter 3000 3dfx are OEM only, IIRC.
Not sure about Actia Soccer, don't have the 3dfx version.

Reply 76 of 97, by janskjaer

User metadata
Rank Member
Rank
Member
bored wrote:

IMHO the easiest method is to carry out the installation and patching process on a pre-64bit machine, then copy across the resulting directory to the Win7 x64 machine.....which presumably isn't the one in your sig.

Note that you'll need a version of Dosbox to with kekko's patch to experience the 3dfx goodness.

I'm using my laptop (which is my Win7 x64 machine). I'm test-installing the game via DosBox first before I try it out on my Retro Rig (the one in my sig).

I've tried running the patch under Windows 95 in VMWare and it has the same error message. So I know that when I run this on my Retro Rig (under real Win95) I'll get the same message.

Putas wrote:
janskjaer wrote:

"please copy to the TACTCOM directory".

check if your g+ patch uses same language as the game

How would I check that?

Considering that the error messages are in English, and I'm using the English UK version of the game, I'd say that they were a match.

Unless you know of any other way I can check the language version of the patch. There is no Help/About.

Three buttons on the patches interface. "3DFX Update", "Rendition Update" and "Cancel". That's it.

DELL Dimension XPS M200s
:Intel P1 MMX 200MHz
:64MB EDO
:DOS 6.22/Win95b
:Matrox Millenium II + m3D (PowerVR PCX2)
Chaintech 7VJL Apogee
:AMD AthlonXP 2700+
:512MB DDR
:Win98SE/2000 SP4
:3dfx Voodoo5 5500 AGP

Reply 77 of 97, by bored

User metadata
Rank Newbie
Rank
Newbie

Hmmn, I notice that a couple of people have had exactly the same problem as you, without finding any solution.
On the other hand, it seemed to go OK for 'redfalcon' in this thread:
http://community.combatsim.com/topic/27189-3dfx-ef2000/

Reply 78 of 97, by Gamecollector

User metadata
Rank Oldbie
Rank
Oldbie
bored wrote:

Hmmn, I notice that a couple of people have had exactly the same problem as you, without finding any solution.
On the other hand, it seemed to go OK for 'redfalcon' in this thread:
http://community.combatsim.com/topic/27189-3dfx-ef2000/

Looks like Graphics+ patch don't installing on "EF 2000 2.0" DOS version (\tactcom\install.exe on cd) at all. So you must install "EF 2000 2.0 for 3dfx", then copy it to dosbox c drive and then run.

Reply 79 of 97, by janskjaer

User metadata
Rank Member
Rank
Member
bored wrote:

Hmmn, I notice that a couple of people have had exactly the same problem as you, without finding any solution

So if anyone else has had this problem, let me know. Similarly, if you've fixed the problem, this is even more of a reason to get in touch.

DELL Dimension XPS M200s
:Intel P1 MMX 200MHz
:64MB EDO
:DOS 6.22/Win95b
:Matrox Millenium II + m3D (PowerVR PCX2)
Chaintech 7VJL Apogee
:AMD AthlonXP 2700+
:512MB DDR
:Win98SE/2000 SP4
:3dfx Voodoo5 5500 AGP