VOGONS


First post, by Peter Swinkels

User metadata
Rank Oldbie
Rank
Oldbie

Hello,

I'm having some minor trouble running the game Grand Prix Circuit (by Accolade - 1988) in DosBox 0.73. The game itself actually runs with no problems; however the program gp.exe which displays a menu allowing you to select a graphics mode always freezes immediately after being launched. All I get is a blinking cursor in the upper left corner of the DosBox window and no response whatsoever.

Gp.exe works fine when launched from Windows XP; I also remember it working fine back when I still used MS-DOS. And interestingly, I also tested it in DosBox 0.72 and it worked fine.

This is hardly a problem since I can easily bypass gp.exe (the graphics mode menu) by starting the game directly in a specific graphics mode (by executing gpcga.exe/gpega.exe/gptdy.exe.) I still think this problem is worth mentioning here because if it's a problem in DosBox it might also affect other software executed in DosBox. It's also a bit annoying having to terminate and then restart DosBox because it froze after starting gp.exe.

Steps already attempted to solve the problem:
-I have read the readme file (readme.txt) and tried changing some configuration options as suggested in the trouble shooting section. Without success.
-The readme also suggests using the built in loadfix command, which doesn't help. Gp.exe still freezes immediately
-Running gp.exe in the debugger version of DosBox 0.72. Couldn't find out anything useful.
-Disassembling gp.exe with the Nasm Disassembler (it's only a 1106 byte executable.) Although I learned a lot about how it works, this didn't really help me find out the cause of the freezing in DosBox.

Computer specifications:
-Laptop: Dell Inspiron 6000
-Motherboard: Unknown.
-Processor type and speed: 2.13 GHz Pentium M.
-Amount and type of RAM: 2 GB DDR2 SDRAM (Dual channel, 533 MHz)
-Video board w/ RAM amount and type: ATI Mobility Radeon X300 (128mb video RAM)
-Sound board: SigmaTel C-Major Audio.
-Operating system: Microsoft Windows XP Professional sp3.

See attachment for the DosBox configuration used.

Attachments

  • Filename
    dosbox.conf
    File size
    9.92 KiB
    Downloads
    227 downloads
    File license
    Fair use/fair dealing exception
Last edited by Peter Swinkels on 2010-06-16, 12:04. Edited 1 time in total.

Reply 1 of 8, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

In DOSBox versions after 0.72 there is an issue with GP.EXE regarding an unusually low initial stack pointer specified in the executable header. I have reported specifics of the issue to the devs, and a fix may be made at some point. Thanks for posting about the problem.

Reply 2 of 8, by Peter Swinkels

User metadata
Rank Oldbie
Rank
Oldbie
ripsaw8080 wrote:

In DOSBox versions after 0.72 there is an issue with GP.EXE regarding an unusually low initial stack pointer specified in the executable header. I have reported specifics of the issue to the devs, and a fix may be made at some point. Thanks for posting about the problem.

I see. According to the information in HelpPC 2.10 (by: David Jurgens, 1991) word 0x10 in the .EXE header specifies the stack pointer's initial value. In gp.exe's case this value is set to 2.

When I change it to a value of 128, gp.exe suddenly runs fine in DosBox 0.73.

Any idea as to which change in DosBox 0.73 caused this problem? I couldn't really find anything in the news.txt file.

Reply 3 of 8, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

the news stuff is a selection of what we think is interesting to write down.
It is nowhere complete. DOSBox has lots of changes each version.

Specificly this problem was introduced when the way to start executables was changed from an IRET to a RETF.
One game needed this (this saves a byte on the stack)

Water flows down the stream
How to ask questions the smart way!

Reply 4 of 8, by Peter Swinkels

User metadata
Rank Oldbie
Rank
Oldbie
Qbix wrote:
the news stuff is a selection of what we think is interesting to write down. It is nowhere complete. DOSBox has lots of changes […]
Show full quote

the news stuff is a selection of what we think is interesting to write down.
It is nowhere complete. DOSBox has lots of changes each version.

Specificly this problem was introduced when the way to start executables was changed from an IRET to a RETF.
One game needed this (this saves a byte on the stack)

Thanks for the quick reply. From what I know (looked it up in HelpPC) the difference between IRET and RETF is that IRET also pops the flags register, right? Which game needed the flags register to be saved?

Reply 5 of 8, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

it is the other way around. One game had the stack very close to it's own data and the flags overwrote a part of it's own data. (yes one byte).

Water flows down the stream
How to ask questions the smart way!

Reply 6 of 8, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I wasn't trying to be dismissive if you really want to know why the problem occurs; it's just that not everyone does. 😉

SP=2 causes a 16-bit segment wrap of the stack pointer that DOSBox doesn't take into account. The CPU flags that were lost in the wrap with IRET were inconsequential, but the code segment lost in the wrap with RETF causes execution to transfer to the wrong address.

Reply 7 of 8, by Peter Swinkels

User metadata
Rank Oldbie
Rank
Oldbie
ripsaw8080 wrote:

I wasn't trying to be dismissive if you really want to know why the problem occurs; it's just that not everyone does. 😉

SP=2 causes a 16-bit segment wrap of the stack pointer that DOSBox doesn't take into account. The CPU flags that were lost in the wrap with IRET were inconsequential, but the code segment lost in the wrap with RETF causes execution to transfer to the wrong address.

I didn't think you were being dismissive. It's that I think these things are interesting. If I didn't, I wouldn't try something like disassembling gp.exe, for example....

Any way, thanks for the detailed replies.