philhassey wrote:

I would like to help with some of the dosbox development. I've done a fair amount of C coding, including several DOS games a long time ago. I also have some _very_ minimal assembly experience.

There are two specific games I want to be able to play without trouble under dosbox:

1. Star Gunner - At present it works great except for saving games. When I try to "save my game", the game quits out and says "can't open save file ..." with a call stack , etc.

Interresting. Those are the best games to test 😀

So let's help you out. Use a debugger-enabled-version:
go near the the save screen. press - on numeric keyboard. Now you are in the the debugger. With return you activate the input mode:
bpint 21 * (which mean breakpoint on interrupt 21 all calls)
now press f5 to let the game continue and try to save.
with f10 and f11 you can step into /step over.
and help gives you an overview of commands 😀
Good luck

2. Fuzzy's Space Golf - A protected mode game that uses Borlands RTM loader. It will not start at all. (Varied error messages from the loader / crashes dosbox.)

Don't bother

However, I'm not sure where to start to try to fix either of these problems. I've tried running with --enable-debug, but don't […]
Show full quote

However, I'm not sure where to start to try to fix either of these problems. I've tried running with --enable-debug, but don't know what to make of the debug output.

If possible I'd like to help out, however I'll need some pointers on how to get started.

Thanks,
Phil

p.s. Thanks for dosbox. I've really appreciated all the work that has gone into it. 😀

Qbix,

Thanks for the help. I played with things for about 3 hours but was unable to figure out exactly what was going on.

Here's a summary of what happened (when using bpint 21 *, and then trying to save a game)

- Int 21, ah=41 (Unlink file)
- Returns ax=2, (file is missing)
... (does some shifts, and a test)
- calls something

Now if I just continue after the int 21 (with f5), the game quits as usual with it's nice "can't save" with call stack.

However, if I use f10 to step through, it does about 5 more instructions ending with a call to something. This causes dosbox to crash. I've attached the gdb backtrace.

Sorry I wasn't able to figure out what was going on exactly. Having dosbox crash at cpu/paging.cpp/PAGING_LinkPage() while debugging left me a bit beyond my knowledge.

If you want to try to look at this, I'm using the share ware version of Star Gunner 1.1, and the most recent CVS available. (However, this "can't save" problem has been with CVS for about 2 months or more since Star Gunner started to work.)

Thanks,
Phil

hmmm well it's a start. It probably tries to remove the old savegame first. (if it exists) you can check for the filename by issueing a d ds:dx when int 21 ah=41 is issued. The crash is just bad luck.

you could try the following:
bpint 21 *
f5
<breaks>
f10 <to see the result>
f5
<breaks>
f10 < etc etc>

this might skip over the fault and let's you see all filesystem calls.

Btw Are all files in the directory read/write/execute (dosgames really require that)

edited: that game is hard to get for a shareware game.... argh i'm required to login to get it even. 🙁 Well look futher.)

qbix,

I gave it a few more shots, but (with my weak assembly knowledge) I'm pretty stumped. After the first INT 21 (delete the savegame file), it
does a few calls and jumps and stuff. Eventually it does a second INT 21 (opens "error.log"), after which things get wrapped up and the game quits. "error.log" contains a copy of the call stack and error message.

Anyway, with the latest CVS you can step through all commands without dosbox crashing. So maybe you'd have better luck figuring it out.

If you want to give it a shot (greatly appreciated), you can get Star Gunner v1.0 from http://woundedmoon.org/dos/stargnr.zip

If you take PayPal donations, I'll even chip in $10 USD to see save and load working with this game.

Thanks,
Phil

philhassey wrote:

qbix,

I gave it a few more shots, but (with my weak assembly knowledge) I'm pretty stumped. After the first INT 21 (delete the savegame file), it
does a few calls and jumps and stuff. Eventually it does a second INT 21 (opens "error.log"), after which things get wrapped up and the game quits. "error.log" contains a copy of the call stack and error message.

Yeah that's really weird. As it doesn't even try to open the file :?

Anyway, with the latest CVS you can step through all commands without dosbox crashing. So maybe you'd have better luck figuring it out.

Yes that is very helpful.

If you want to give it a shot (greatly appreciated), you can get Star Gunner v1.0 from http://woundedmoon.org/dos/stargnr.zip […]
Show full quote

If you want to give it a shot (greatly appreciated), you can get Star Gunner v1.0 from http://woundedmoon.org/dos/stargnr.zip

If you take PayPal donations, I'll even chip in USD to see save and load working with this game.

Thanks,
Phil

Okay. I found the error and corrected it. I personally don't do in donations but if you want to spread your joy around the world consider donating to this forum. You can find a paypal link in the news section overhere http://www.vogons.org . They host our forum and make it possible for us to give you this support.

The bug:
The game tried to open directories: .\ and full pathname.
This isn't allowed and errorcode 5 should be returned.
We allowed it. (at least under linux you can open a directory. (not that you can do anything with it )

It wasn't easy to find as those calls are quite early in the game. (even before the intro) (in total 1250-1500 doscalls are made before the saving point is reached)

The fix is in the CVS. Just wait till it shows up in anonymous CVS.
The file to watch for: dosbox/src/dos/dos_files.cpp

Have fun.
Peter

Thanks 😀

Anyway, looks like figuring out bugs in games might not be my cup of tea.

However, I've got a good deal of C / SDL experience. I'd still like to help out. Are there any features on your TODO list that I could try to tackle? (If possible, please order them from easiest to hardest so I could start on something fairly straight forward 😉

l8r,
Phil

Oh well this bug was more complicated than expected and I saw it because i considered the opening of .\ weird.

I think You are quite capable. especially if you programming experience.

Well if you state that you've got programming experience with SDL. you could take a look at our sdlmain.cpp and see if we're doing some stupid things to somebody who uses SDL. 😀

I've played Stargunner again a few times. A few things to note:

Only the first game saved really gets saved. After that, save games don't save anymore. (Try saving a few different games. And then quit dosbox, play again. If you save games after that, those games won't be saved. You might be able to tell until you quite and play again though. 😉

Also, when saving a game, the screen gets a lot of weird stuff on it for a second.

Also, sometimes, (and this hadn't happened in the past) the game crashes with another error. I've attached Stargunner's error.log) This crash happens occasionally while playing a level.

As for sdlmain.cpp, I'm still looking around at things to get a feel for the lay of the land before I comment.

Thanks,
Phil

I noticed the graphics corruption myself. But as the savegame loaded fine I decided not to wonder about it. I never tried more than one savegame thought. I found the game quite difficult and never came that far 😀

You can try saving more than one game from the first time you are in the store. (Even before you play the first level.)

Just buy different things before you save, and you'll be able to keep track of different save games.

l8r,
Phil

As far as I can see how you are using SDL is fine 😀

However, I went onto the bug tracker and saw one that looked pretty doable and looked into it -- [ 827575 ] Long command line crashes DOSBox.

I was able to track down a few of the buffer overflows in shell/shell_misc.cpp ... I could try to find them all and send in a patch for those, or I could try to re-do some of the code with C++ strings or something else less prone to buffer overflows.

Any preference?

l8r,
Phil

I Found the bug which caused the savegames not to show up !
(they were saved 😀

It was a very very little bug in the dos.cpp

1retrieving revision 1.60
2retrieving revision 1.61
3diff -u -r1.60 -r1.61
4--- dos.cpp     1 Nov 2003 16:03:42 -0000       1.60
5+++ dos.cpp     20 Nov 2003 10:29:32 -0000      1.61
6@@ -16,7 +16,7 @@
7  *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
8  */
9  
10-/* $Id: dos.cpp,v 1.60 2003/11/01 16:03:42 harekiet Exp $ */
11+/* $Id: dos.cpp,v 1.61 2003/11/20 10:29:32 qbix79 Exp $ */
12  
13 #include <stdio.h>
14 #include <stdlib.h>
15@@ -750,7 +750,7 @@
16                                DOS_CloseFile(handle);
17                                DOS_SetError(DOSERR_ACCESS_DENIED);
18                                reg_ax=dos.errorcode;
19-                               CALLBACK_SCF(false);
20+                               CALLBACK_SCF(true);
21                                break;
22                        }
23                        if (DOS_CreateFile(name1,reg_cx,&handle)) {

With this it works perfect no screen distortations anymore (I think it was the error message written to the screen)

I suggest you aplly it yourself as the cvs isn't usable for while.

This command was used on the stargun.sav file which keeps track of the names of the savegames. So the savegames existed but the names weren't updated as the file didn't open

Anyway.
Have fun.

the buffer overflows in the shell. We'll I don't mind. See why would somebody make a mesage that is longer than the buffer 😉 Well the shell is real tricky when it comes to spaces. But feel free to code it.

I think the easiest thing would be to limit new characters one the buffer is full (don't make the buffer larger as it the same size as DOS)

Just commit a patch http://www.sf.net/projects/dosbox

Thanks, that patch worked great 😀

Any way, good point on the buffer overflows, I'm not sure I care enough to really fix it either.

But if I think of anything else, I'll try to send in a patch.

Thanks,
Phil