In article <2p7kcs$1ee@melbpc.org.au>, tonym@melbpc.org.au (Tony Molina) writes:

> G'day,
> 
> I've been reading all the messages going backwards and forwards in 
> regards to the GUS card's ease of use.
> 
> As one of the first Australian GUS owners I have to say that while the 
> card has been getting easier and easier to work with most games, there 
> still quite a bit of room for improvement.
> 
> Being personally pretty DOS literate I've never had a problem with having 
> many multiple configs, batch files for different games etc but I can see 
> how a lot of people out there would.
> 
> My solution, and I'm surprised nobody has yet suggested or done it 
> themselves, is for Gravis (or some other interested party), to program 
> some sort of *user friendly* front-end for using the GUS with all games 
> except those already with built-in GUS support.
> 
> Using the information from sources such as the G-List etc, all the common 
> (and even not so common) PC games could be stored in this front-end's 
> database with associated recommended SBOS, Mega_EM, AIL etc settings.
> 
> This database should be in a format that can be easily updated by the 
> user him/herself at any interval required.
> 
> As an example of what I mean, say somebody has just bought Red Barons. 
> They would fire up the GUS game front-end, type Barons (keyword search), 
> find the relevant entry which would spell out what the best way of 
> running this game with the GUS is. The program would perhaps ask where 
> the game is located and should already know where all the various GUS 
> utilities, emulators are on the system, so with this information should 
> be able to prompt for the creation of a CONFIG.SYS and AUTOEXEC.BAT to 
> run this game, reboot the machine and ta da!
> 
> The important things are that this program should be *easy* to use and 
> the database of games and their settings should be updated frequently and 
> made *widely* available.
> 
> Unfortunately, I am not a programmer myself, otherwise I'd write this 
> myself but I am sure that there is enough programming skill out there to 
> write such a front-end. Can't be that hard, and it would be an extremely 
> useful feature to add to what is IMO the best music/games card around at 
> the moment.
> 
> Comments anyone?
> 
> Cheers,
> 
> = Tony =
> 
> tonym@melbpc.org.au
> 

I have had a utility to do just that, and have been using it, well, forever.
It is done as a batch file (DOS 5 or better), to make it very easy to update.
I have asked on several occasions for a list of the executables which go with
the GLIST games, but did not get a single reply.

However, since it was requested, and since I am losing my internet access 
tomorrow, I may as well post it "as is".  Perhaps Marc will pick this up, and
distribute it with the GLIST.

Basic assumptions:  1)  No two games have the same executable filename.
                    2)  ACD is in the path (Or, with a bit of modification,
                        LCD or NCD.  I chose ACD because it's freeware)
                    3)  For fastest response, games should be kept in a
                        directory called \games\filename , where filename is
                        exactly the same as that of the game (no extension)
                    4)  Otherwise, ACD will find it if it's not under \games
                        or if the directory name is only "close" to the 
                        game's name.
                    5)  If there's no good match, ACD will bring up a menu.
                   
SYNTAX:  go filename [path]


Once a unique match is found (less than 1 second), it runs the proper emulator
and then the game.  Afterward, it unloads the emulator, and changes back to the
starting directory.

I'll post it later on this evening, after I "generalize" it, e.g. change all the 
c:\ultrasound to %ultradir%   , etc.  I'll also put it on epas.

Bruce Dodson













