ZSNES crashes when ROM name is specified on the command line

[Dr DOS]

I have encountered a problem that seems to be present in all recent WIP versions of ZSNES (the original one for DOS).

If I start ZSNES and load the ROM from within the emulator, it works; however, if I specify it on the command line instead, ZSNES crashes. I am still in the process of testing, but it looks like the last version that did not have this problem was the WIP dated 24.10.2004.

The problem seems to be independent from the actual ROM I try to load.

I had some luck trying to load it with no default config files, but it crashed the next time I tried after exiting and restarting ZSNES.

This is what I get when I start ZSNES with a ROM name as argument (In this example, I used "ZSNES shiren.smc" to start the game Shiren no Fuurai):

Creative ViBRA16X PnP card detected (support coded by Peter Santing)
High-DMA is below dma #4

you have now full 16-bit stereo sound with the surround option!
File opened successfully!
Exiting due to signal SIGSEGV
General Protection Fault at eip=00200107
eax=00000000 ebx=00d39ac8 ecx=00096000 edx=00d49a88 esi=009405d3 edi=00000000
ebp=00000000 esp=00988594 program=E:\EMU\ZSNES2\zsnes.exe
cs: sel=0117 base=100a1000 limit=0136ffff
ds: sel=011f base=100a1000 limit=0136ffff
es: sel=0000
fs: sel=0107 base=00051350 limit=00003fff
gs: sel=012f base=00000000 limit=0010ffff
ss: sel=011f base=100a1000 limit=0136ffff
App stack: [00988680..00948680] Exceptn stack: [009485d4..00946694]

Call frame traceback EIPs:
0x00200107

I do not know whether this info is particularly helpful, though.

If you need more info, please ask.

[adventure_of_link]

post NSRT info of the ROM

also, system specs

[Dr DOS]

post NSRT info of the ROM

also, system specs

Okay, here it comes:

Code: Select all

NSRT v3.3 RC2 - Nach's SNES ROM Tools

---------------------Internal ROM Info----------------------
 File: shiren.smc
 Name: FURAI NO SIREN Company: CHUN Soft
 Header: None Bank: HiROM
Interleaved: No SRAM: 256 Kb
 Type: Normal + Batt ROM: 32 Mb
 Country: Japan Video: NTSC
 ROM Speed: 120ns (FastROM) Revision: 1.0
 Checksum: Good 0xE5CA CRC32: AF5703EE
--------------------------Database--------------------------
 Name: Fushigi no Dungeon 2 - Fuurai no Shiren
Country: Japan Revision: 1.0
 Port 1: Gamepad Port 2: Gamepad
Genre 1: RPG Genre 2: None

System specs:

MB : IBase MB800H
CPU: Pentium4 3.06 GHz
GA : GeForce FX 5200 128 MB (AGP)
SC : ASound Gold (ISA)
Mem: 256 MB
HDD: 2 Samsung SP2514 (232 GB)
(on Promise Ultra133TX2)
OS : DR-DOS 7.03 with QEMM 9.0

Anything else that might be useful?

[Nach]

I just tested it with Mega Man 7. All was well.

So either that one game has an issue (I don't have that game, so can't test it). Or DR-DOS has a bug.

[Dr DOS]

I just tested it with Mega Man 7. All was well.

So either that one game has an issue (I don't have that game, so can't test it). Or DR-DOS has a bug.

Well, both the game Shiren and DR-DOS work with the WIP dated 24.10.2004, and also most games work with older versions in DR-DOS, so it is the emulator that must do something differently. Beginning with ZSNES 1.42, games do not work for me when I load them from the command line. Whether this is due to a bug in DR-DOS, I cannot say, but *something* in ZSNES has definetely changed between these two versions that caused this.

I will try to find Mega Man 7 to see if it makes a difference...

This is the NSRT info for the Mega Man 7 ROM I have found:

Code: Select all

NSRT v3.3 RC2 - Nach's SNES ROM Tools

---------------------Internal ROM Info----------------------
 File: megaman7.smc
 Name: MEGAMAN 7 Company: Capcom
 Header: Exists (type?) Bank: HiROM
Interleaved: No SRAM: 0 Kb
 Type: Normal ROM: 16 Mb
 Country: USA Video: NTSC
 ROM Speed: 120ns (FastROM) Revision: 1.0
 Checksum: Good 0xF199 CRC32: 2D947536
--------------------------Database--------------------------
 Name: Mega Man VII
Country: USA Revision: 1.0
 Port 1: Gamepad Port 2: Gamepad
Genre 1: Action Genre 2: Shooter

With ZSNES 1.36 and WIP 24.10.2004, it works in DR-DOS from the command line.

With ZSNES 1.42 and later, it doesn't work from the command line, but still works when loaded from within the emulator.

So what now? It is easy to say that it is a bug in DR-DOS, but I have been using ZSNES in DR-DOS for many years and never encountered a problem like this.

[Nach]

Same Mega Man 7 that I have.

A lot of old and messed up code was removed from ROM loading. I'm not sure what change is screwing up DR-DOS, but it works fine in MS-DOS and DOSBox. If I knew how to fix it for DR-DOS without screwing up anything else, I would happily commit such a fix.

[Dr DOS]

Same Mega Man 7 that I have.

A lot of old and messed up code was removed from ROM loading. I'm not sure what change is screwing up DR-DOS, but it works fine in MS-DOS and DOSBox. If I knew how to fix it for DR-DOS without screwing up anything else, I would happily commit such a fix.

Well, if I would provide a bootable disk image with the necessary files on it to reproduce the problem, would you be willing to give it a try and find out which change in ZSNES makes DR-DOS choke?

[Nach]

If DR-DOS can run GDB and I have the time, yes.

It crashes before the emulator image loads with the 3 lines of info on the bottom, right?

Also, can that read FAT32?

[Dr DOS]

If DR-DOS can run GDB and I have the time, yes.

It crashes before the emulator image loads with the 3 lines of info on the bottom, right?

Also, can that read FAT32?

That would be great!

Yes, the emulator crashes even before it can show the ROM info, so I assume it does not get much farther then opening the file.

DR-DOS 7.03 does not support FAT32, so I uploaded a boot disk image with Enhanced DR-DOS 7.01.08 WIP instead, which also has the same problem with ZSNES.

I had trouble uploading the file to Rapidshare, though, since my browser does not support file uploads, so I used CURL instead which seems to have worked.

Here is the link I have got:

http://rapidshare.de/files/17542361/drd70108.zip.html

If DR-DOS can run GDB and I have the time, yes.

It crashes before the emulator image loads with the 3 lines of info on the bottom, right?

I did some debugging myself today, and traced the problem to the line

MOV BYTE[ES:EDI],0

in the cscopyvesa2... routine which seems to cause a GPF. But I still have no clue how this relates to DR-DOS or why it would work in one DOS but not in the other.

I just tested it with Mega Man 7. All was well.

So either that one game has an issue (I don't have that game, so can't test it). Or DR-DOS has a bug.

Hi Nach, are you still reading this thread?

I just tried with an MS-DOS 7.1 (Win98SE) boot disk and the result was just the same; ZSNES 1.42 crashed when I tried to load Mega Man 7 from the command line.

So probably we can rule out both OS-specific and game-specific problems. It might be a problem with either the machine (not very likely, since I tested it on three different ones) or with the default configuration of ZSNES.

Any suggestions what to try next?

I just confirmed that this is indeed a problem related not to DR-DOS but rather to using one of the VESA2 graphics modes.

I started ZSNES without any config files and megaman7.smc as the sole argument - it worked. However, after setting the graphics mode from MODEX to one of the VESA2 modes, it would crash on the next attempt to start a game from the command line.

Changing the graphics mode while ZSNES is running does not make it crash; it only crashes if a VESA mode is set when it is started with a ROM file parameter on the command line.

It did not matter whether I used DR-DOS or MS-DOS 7.1; only the graphics mode (VESA or not VESA) made a difference.

I think the real problem is that when a ROM is loaded from the command line, the cscopyvesa2 routine tries to write to the linear framebuffer by using the selector in [VESA2Selec], but this has not been initialised because the InitVesa2 routine has not been called so far. So the value in [VESA2selec] is null, resulting in a General Protection Fault when cscopyvesa2320x480x16b is called to clear the screen.

To solve this, dosinitvideo would have to be called before trying to call ClearScreen.

Of course I could be mistaken, since I am not familiar with the ZSNES source code.

[Clements]

Thread cleanup.

[Nach]

Thanks for doing the detective work. I'll look into when I get a chance.

[Dr DOS]

Thanks for doing the detective work. I'll look into when I get a chance.

Thanks, but that is no longer
necessary, since I already
submitted a fix for this bug.

Finding it was the hard part,
fixing it was much easier.