VOGONS

Common searches


EF2000 for DOS with 3DFX patch

Topic actions

Reply 40 of 97, by Tanyrhiew

User metadata
Rank Newbie
Rank
Newbie

I've tried the pif memory settings - no go

I've followed the instructions to the letter.

I think there is a problem with my original voodoo card - just out of interest i tried the same voodoo card in an old 200 mhz pentium box - same corrupted graphics in RBas on my athlon.

Ef2000 loads the menu screen but freezes on entering the 3d.

Reply 41 of 97, by Glidos

User metadata
Rank l33t
Rank
l33t

Well I've gotten nowhere with EF2000. It looks to me as though the 3dfx version is statically linked with the Glide library, and doesn't use Glide2x.ovl, in which case there's no chance with Glidos. On the other hand, I can't even get it running in software mode.

Reply 42 of 97, by Unregistered

User metadata
Glidos wrote:

Well I've gotten nowhere with EF2000. It looks to me as though the 3dfx version is statically linked with the Glide library, and doesn't use Glide2x.ovl, in which case there's no chance with Glidos.

The DOS Glide version is statically linked? Are you sure? Could you do some binary patching to replace it?

Reply 43 of 97, by Nigel

User metadata
Rank Newbie
Rank
Newbie
Glidos wrote:

Well I've gotten nowhere with EF2000. It looks to me as though the 3dfx version is statically linked with the Glide library, and doesn't use Glide2x.ovl, in which case there's no chance with Glidos. On the other hand, I can't even get it running in software mode.

Well I understand from prev posts that you had the OEM version first. Is this with Version 2?

Tips to get the sim to run (software mode) as I know them...

Don't try on a Nvidia card if poss. I have the feeling support was dodgy. The DOS version uses Univesa. Run the Univesa *.exe to create a new driver file (*.drv) in the sim directory.

Remove the Clump*.txt files that are created during install. For some reason they stop the sim working (!)

SET BLASTER environment variables and use the basic default SB driver, or none at all. When I had problems I rang the support line DID offered and they told me the sim was only tested on genuine SB cards. I bought one and it worked! Emulation should be better nowadays.

Windows XP isn't very happy with the DOS version - tweaking of a serious nature needs applying. I was lucky with just fiddling the basic memory and expanded, plus full-screen settings.

If you have a seriously fast PC (most who look in here seem to!) try a slow-down utility. There's some internal timer which can get baffled by the big-frequency-numbers about nowadays.

Try initial screen resolution as low (320x200) to get it running, then try Alt-R in-game to go hires - if possible.

Reply 44 of 97, by Glidos

User metadata
Rank l33t
Rank
l33t
Nigel wrote:
Well I understand from prev posts that you had the OEM version first. Is this with Version 2? […]
Show full quote

Well I understand from prev posts that you had the OEM version first. Is this with Version 2?

Tips to get the sim to run (software mode) as I know them...

Don't try on a Nvidia card if poss. I have the feeling support was dodgy. The DOS version uses Univesa. Run the Univesa *.exe to create a new driver file (*.drv) in the sim directory.


I have a GF3, and Univesa says "No supported VGA card"


Remove the Clump*.txt files that are created during install. For some reason they stop the sim working (!)

SET BLASTER environment variables and use the basic default SB driver, or none at all. When I had problems I rang the support line DID offered and they told me the sim was only tested on genuine SB cards. I bought one and it worked! Emulation should be better nowadays.


So far I've been trying to run without sound.


Windows XP isn't very happy with the DOS version - tweaking of a serious nature needs applying. I was lucky with just fiddling the basic memory and expanded, plus full-screen settings.


I set DPMI to 65535, but still the game complains it only can find 16MB. What were your settings?


If you have a seriously fast PC (most who look in here seem to!) try a slow-down utility. There's some internal timer which can get baffled by the big-frequency-numbers about nowadays.

Try initial screen resolution as low (320x200) to get it running, then try Alt-R in-game to go hires - if possible.


Be great if I could get that far. 🙁

Reply 46 of 97, by Glidos

User metadata
Rank l33t
Rank
l33t
Snover wrote:

😮

That was thoroughly incomprehensible. You've bested yourself this time, Paul. 😜

That's nothing: you should have seen the message I posted afterwards explaining the mistake. Luckily I'm admin so I could delete if before anybody saw it. 😁

Reply 47 of 97, by Nigel

User metadata
Rank Newbie
Rank
Newbie

[QUOTE]Originally posted by Glidos
What were your settings?

Well I've just tried a fresh install of the basic software mode EF2000 for DOS...

Settings needed were 600kb base mem, 4mb expanded. (XP happy but ME complained not enough total memory to do what I asked... Jiggled the figures a bit) Auto all else. No sound. The Sound config will not work in it's raw form - not sure about VDM* etc.

The manual recommends 500kb and total ram of 16MB.

Univesa would not recognise my nvidia chipset, or ATI radeon in the laptop. Generic used.

On start the EXE properly finds the total memory available (192MB Win ME in the laptop, 512MB Win XP in the desktop)

Very unstable in Windows. DOS much better (works but jerky due to timer probs and 640x400 hi-res I think!)

Reply 48 of 97, by Unregistered

User metadata

For WinME: Update Univesa....
For WinXP: There's got to be a way to use it without Univesa...

Wait, that's just it! UniVBE wasn't called UniVESA since the v3.x days... Man, that's SERIOUSLY crippled then. I wonder if you could rename UNIVBE.EXE to UNIVESA.EXE and have it work. No, because I don't think it would create a driver file, as you say. I don't think UNIVBE works that way.

You might want to try experimenting with SciTech Display Doctor for DOS 7.0. It supports the Radeon Mobility (likely what is in your laptop): http://www.scitechsoft.com/ftp/sdd/sdd-dos-7. … .0.340-BETA.exe

The problem is that it doesn't work the same as UNIVESA... and doesn't create *.drv files, I think... hmm... What are DRV files anyhow? I've never run into one using the later versions of SDD.

Aha! We have some clues here... http://unirefresh.demonews.com/videoproblems/

Note: If you're lost... UniVesa is from the same programmers as UniVBE (the name was changed to prohibit confusion due to the request of the Video Electronics Standards Association, I think) and then became part of SciTech Display Doctor.

Reply 49 of 97, by Unregistered

User metadata

*smacks self* I haven't used UNIVBE in a while. Anyhow, use SDD 7.0's UVCONFIG to generate a univbe.drv for your card. Make sure you find a registration key or buy one, I'm not sure if it would time out. Voila! (hopefully)

But you'll still have problems in XP... 🙁

Perhaps there's a "don't use UNIVESA/UNIVBE" switch?

-Stiletto
(the above was me too)

Reply 51 of 97, by Nigel

User metadata
Rank Newbie
Rank
Newbie

Thanks! That sounds *very* useful. I for one will try the downloads.

I was up against the limits of my knowledge on this one. I suppose I was also hoping that Paul would be spared some of the load because I think I knew this was going to be a tricky one.... There's been plenty of interest in this topic judging by the views. However that's hat VOGONs is all about isn't it?

I think I mentioned elsewhere that it wasn't until F22ADF by DID, and it's subsequent D3D patch, that the Nvidia problem went away. If the newer version of Uni-whatever can produce a more apporpriate driver than that's a plus.

It's a whole other ball game as to whether the GFX+ glide update used VESA. It probably didn't as the installer for the patch is, paradoxically, a Win95 application!!

Reply 52 of 97, by Unregistered

User metadata

Okay, I don't know what sort of crack I was smoking when I posted all that. I spent the night looking into UNIVBE, SDD, SNAP, Nucleus and related things.

1. UniVBE, even with version 7.00 of SDD, doesn't support your card. It doesn't support nearly every modern PCI or AGP video card, for the most part.

2. The Nucleus drivers, part of SNAP, the latest thing from SciTech (from SDD 7.0 to SNAP 2.0) DO support your card. However, as I understand it, the application has to be written in SciTech's MGL to make use of the Nucleus drivers. (Support for Win9x/2000/XP coming soon!)

3a. One workaround for EF2000 would be to follow the directions in this FAQ: http://db.gamefaqs.com/computer/doswin/file/m … rilogy_vesa.txt - i.e., Use Rob Muller's UniVBE workarounds:http://unirefresh.demonews.com/videoproblems/

If you're using EF2000 (software renderer, unpatched) use the workaround for Univbe 5.1a. This MAY work in Win2000/XP also, using NOLFB mentioned elsewhere in our forums along with the workaround.

3b. OR - when SNAP 2.0 for Windows comes out, someone makes a TSR for Windows that intercepts VESA calls and uses SciTech's MGL along with the Nucleus drivers. A VESA-Nucleus wrapper, so to speak. Note that I am not at all certain this is possible, but I highly encourage our resident video experts to look into MGL as for its capabilities, etc. It would be worth looking at the license, too, to see if such a project, if open-source, would be legal, either: ftp://ftp.scitechsoft.com/devel/license.txt

3c. OR find a workaround switch for EF2000 not to use the built-in UNIVBE. They do exist, but possibly not all the time. Check the documentation. It could be the popular -nounivbe, like "ef2000 -nounivbe". Or maybe USEOLDVBE, like "ef2000 USEOLDVBE". Or something.

- Stiletto

Reply 53 of 97, by Nigel

User metadata
Rank Newbie
Rank
Newbie

Thanks for that. I've just downloaded the FAQ and modified drivers etc. I'll give them a go and report back.

(How you managed to find those links is pretty impressive! Cheers! I do searches but never seem to find anything useful!)

Reply 54 of 97, by Nicht Sehr Gut

User metadata
Rank l33t
Rank
l33t
Unregistered wrote:

I AM A DUMBA**

No, you're not. But you WILL be if you fail something because you keep doing research for long detailed reports on Vogons instead of your classwork. We appreciate it, but don't mess up your life for the board.

Reply 55 of 97, by Snover

User metadata
Rank l33t++
Rank
l33t++
Nicht Sehr Gut wrote:

No, you're not. But you WILL be if you fail something because you keep doing research for long detailed reports on Vogons instead of your classwork. We appreciate it, but don't mess up your life for the board.

I concur. Stiletto, it's nice to see you, but don't let VOGONS rule your life. At all.

Yes, it’s my fault.

Reply 56 of 97, by Unregistered

User metadata

Hey guys hate to burst your bubbles; as I have some bad news.

EF2000 V2.0 which is equivalent to EF2000 for DOS, upgraded with the Tactcom addon, and then upgraded to Graphics+(G+) will never work with any kind of wrapper.

Both of the 3D acclerated versions of G+ for Voodoo Graphics (Voodoo I) and Rendition Verite (v1100) were coded directly to those two pieces of hardware. (True the Voodoo 2 worked with some different settings and Verite v2x00 worked as well, but they were essentially beefier versions of the same card.) Voodoo 3's/Banshee's/Rush's never worked with G+, different enough hardware architecture that the direct hardware calls did not work.

As G+ doesn't use an API (Glide or DirectX), but makes direct hardware calls there is no way a wrapper will be able to intercept the calls. It's as if the game IS the API and the game all wrapped up into one neat little package.

Why DiD did it that way I have no idea, except for at the time 3D acclerated cards were in their infancy and coding direct to hardware was a surer way to make things worked.

It stinks I know, but you are spinning your wheels here.

Reply 57 of 97, by Nicht Sehr Gut

User metadata
Rank l33t
Rank
l33t

Originally posted by Unregistered

Hrmmm... "Unregistered" again...

Why DiD did it that way I have no idea, except for at the time 3D accelerated cards were in their infancy and coding direct to hardware was a surer way to make things worked.

Grr. So what are the odds that we could convince DiD to release the source code in the name of preservation?

Reply 58 of 97, by Glidos

User metadata
Rank l33t
Rank
l33t
Unregistered wrote:

As G+ doesn't use an API (Glide or DirectX), but makes direct hardware calls there is no way a wrapper will be able to intercept the calls. It's as if the game IS the API and the game all wrapped up into one neat little package.

Why DiD did it that way I have no idea, except for at the time 3D acclerated cards were in their infancy and coding direct to hardware was a surer way to make things worked.

Yes, this isn't uncommon. The original 3dfx Tomb Raider is like that, but later Core released a version that used Glide2x.ovl I think I mentioned in an earlier post that I suspected EF2000 of this.

As far as I know this decision make no changes to the programming of the game: it still make Glide calls. It is the linking stage that is different: they can either link directly with the static Glide library, or with a stub library that will load the ovl file.
More or less all that is involved in releasing a version that uses the ovl file, is to change a linker directive and recompile.

Games like this are not without hope. It may be possible to locate the the Glide library in the game's binary and patch it to use the stub library. However this is difficult enough that I may not get around to looking at it until I retire. 😀 Someone expert in the LE file format might be able to do this sort of thing fairly easily though.