Need a little help, my game is freezing.

[Citan]

I'm having an issue with Super Mario RPG... Well, a couple actually, but one is certainly more important than the others. When I try to select new equipment in the Equip screen, the game freezes. I haven't had much luck in fixing the issue by messing with the video settings, so I'd appreciate any suggestions. I'm using version 1.51 of ZSNES, and here are my computer specs (I'm running Windows Vista):

AMD Turion 64 X2 processor
2 GB RAM
NVIDIA GeForce 7150M grapics card
Conexant High Definition SmartAudio 221 sound card

The lesser issue has to do with sound. Some of the sound isn't quite right, so I was wondering what the optimal sound settings for this game would be.

Thanks.

[Gil_Hamilton]

Mario RPG just doesn't emulate well right now.


ZSNES doesn't need per-game settings. Optimal for one game is optimal for all.

[Agozer]

Use an earlier version, like ZSNES 1.42.

[Citan]

Thanks, I switched to 1.42 and it's not freezing up anymore.

[Cobra951]

In some important ways, 1.51 is a step down from 1.42, with poor SMRPG emulation perhaps being the most prominent example. Make sure to keep 1.42 handy. With updates so infrequent, it will remain the definitive version of ZSNES for quite a while longer.

[Deathlike2]

You realize Super Mario RPG is one game, and uses a special chip at that.

1.42 is uncompilable by modern Linux distros to boot (due to libs that existed at the time that allowed faulty, if not poor behavior).

[Cobra951]

You realize Super Mario RPG is one game, and uses a special chip at that.

1.42 is uncompilable by modern Linux distros to boot (due to libs that existed at the time that allowed faulty, if not poor behavior).

The ZSNES development team has my respect and admiration. I had to get that said up front.

Yes, it is just one game, but it is a very important one. We're not talking some obscure mediocrity here, but a signature game for the SNES. As for specialty chips in the cart, that became almost a common practice late in the console's life, didn't it? Yoshi's Island, Star Fox, and Stunt Race FX immediately spring to mind--all properly emulated for a number of years, along with SMRPG.

I wasn't aware that 1.42 was a bad boy under Linux. I still use Windows, so it has never affected me. Did the need to make the ZSNES code behave under Linux play a role in the new problems with SMRPG? That would at least explain the loss of compatibility better than a simple bug getting by.

[Deathlike2]

You realize Super Mario RPG is one game, and uses a special chip at that.

1.42 is uncompilable by modern Linux distros to boot (due to libs that existed at the time that allowed faulty, if not poor behavior).

The ZSNES development team has my respect and admiration. I had to get that said up front.

Yes, it is just one game, but it is a very important one. We're not talking some obscure mediocrity here, but a signature game for the SNES. As for specialty chips in the cart, that became almost a common practice late in the console's life, didn't it? Yoshi's Island, Star Fox, and Stunt Race FX immediately spring to mind--all properly emulated for a number of years, along with SMRPG.

I wasn't aware that 1.42 was a bad boy under Linux. I still use Windows, so it has never affected me. Did the need to make the ZSNES code behave under Linux play a role in the new problems with SMRPG? That would at least explain the loss of compatibility better than a simple bug getting by.

Absolutely not. Those are separate issues and one has nothing to do with the other.

[Cobra951]

OK, thanks for the replies. Nothing beats firsthand knowledge.

[Gil_Hamilton]

Yes, it is just one game, but it is a very important one. We're not talking some obscure mediocrity here, but a signature game for the SNES.

And you're saying that improvements in emulation accuracy should be passed up if they break a game in the process?

As for specialty chips in the cart, that became almost a common practice late in the console's life, didn't it? Yoshi's Island, Star Fox, and Stunt Race FX immediately spring to mind--all properly emulated for a number of years, along with SMRPG.

A. Those are all SuperFX games, not SA1 games.
B. They AREN'T emulated properly. Not even close. Maybe Yoshi's Island is all right, but gameplay speed issues in StarFox and StuntRace are long-running problems(both games run too fast, though the TIMER in StuntRace runs the right speed).

Did the need to make the ZSNES code behave under Linux play a role in the new problems with SMRPG? That would at least explain the loss of compatibility better than a simple bug getting by.

Nope.
If I recall, there were emulation improvements that exposed issues in the SA1 emulation.

Someone correct me if I'm wrong.

[Deathlike2]

Did the need to make the ZSNES code behave under Linux play a role in the new problems with SMRPG? That would at least explain the loss of compatibility better than a simple bug getting by.

Nope.
If I recall, there were emulation improvements that exposed issues in the SA1 emulation.

Someone correct me if I'm wrong.

IIRC, there were timing changes, and there's huge tendency that other stuff (like special chips that clearly rely on timing) will not work correctly.

[Cobra951]

Yes, it is just one game, but it is a very important one. We're not talking some obscure mediocrity here, but a signature game for the SNES.

And you're saying that improvements in emulation accuracy should be passed up if they break a game in the process?

I don't know how to answer that question because it's contradictory. If a game worked before and now doesn't, the emulation got worse in its case, not better. If the purpose of the emulator is academic, then you might have a point. But to my knowledge, its purpose is to be fully functional and used by the public. Most importantly, SMRPG already worked. If it had never worked before, then again you might have a point. Improving theoretical accuracy without regard for games that never worked is harmless.

[Gil_Hamilton]

Yes, it is just one game, but it is a very important one. We're not talking some obscure mediocrity here, but a signature game for the SNES.

And you're saying that improvements in emulation accuracy should be passed up if they break a game in the process?

I don't know how to answer that question because it's contradictory. If a game worked before and now doesn't, the emulation got worse in its case, not better.

Or emulation got better, but the game only worked due to hacks that were no longer valid.

Core system emulation has improved since 1.42.
Sadly, it broke a single SA1 game in the process.
...
Well, broke it worse than it already WAS broken. Mario RPG's never run RIGHT, just... less wrong.



Speaking of emulation improvements... the bug in (the coprocessor-less) Super Robot Wars 4 where the bottom dialog bar in battle sequences rolled and flickered is fixed in 1.51. Hooray!

If the purpose of the emulator is academic, then you might have a point. But to my knowledge, its purpose is to be fully functional and used by the public.

Most importantly, SMRPG already worked. If it had never worked before, then again you might have a point. Improving theoretical accuracy without regard for games that never worked is harmless.

As they say, you can't make an omlette without breaking a few eggs.
The changes made for 1.51 fixed known bugs in games that didn't work properly before.

Sadly, SA1 emulation was never right in the first place.
As the core emulation was improved, the SA1 code built to interface with the less-accurate base system was broken further. Enough to break Mario RPG.


If they developed based on your standards, ZSNES would've stopped a long time ago. In fact, it would've stopped before Mario RPG ever worked in the first place.

There've been many instances in the past where emulation improvements broke games. FF3/6 broke a few times on the way.

[adventure_of_link]

As for specialty chips in the cart, that became almost a common practice late in the console's life, didn't it? Yoshi's Island, Star Fox, and Stunt Race FX immediately spring to mind--all properly emulated for a number of years, along with SMRPG.

A. Those are all SuperFX games, not SA1 games.

Not to mention that one of those games listed, star fox, was made in 1993. Well during the life of the SNES.

[Gil_Hamilton]

As for specialty chips in the cart, that became almost a common practice late in the console's life, didn't it? Yoshi's Island, Star Fox, and Stunt Race FX immediately spring to mind--all properly emulated for a number of years, along with SMRPG.

A. Those are all SuperFX games, not SA1 games.

Not to mention that one of those games listed, star fox, was made in 1993. Well during the life of the SNES.

Yeah. I skipped the DSP-1 history lesson.
SNES had coprocessors from day 1.

[Cobra951]

I seem to have hit a nerve here. Sore spot, guys?

It wouldn't be the first time an emulator needs a special hack for a special game. That didn't happen here, hence this conversation. You can call SMRPG an egg which didn't make it to the omelet if you want. To some people, what broke was the frying pan. Fortunately, an older pan is hanging on the rack, and can still dish it out.

I missed the point about Star Fox. It works, even if the speed is off. (I didn't notice that when I tried it, though I have no problem believing it.) Even so, speed tweaks are a molehill to the mountain of emulating the onboard processor in the first place. The hard work has been done successfully.

[grinvader]

This pan and eggs analogy is good. Let me further it:
The older pan makes omelets that gives cancer. Have fun with it.

And no, the raw emulation is fairly easy compared to the timing... else we wouldn't be where we are.
Remember, kids. Everything easy has already been done. This applies to most things in the world.

So we tried hammering the pan a bit to get it better, but it was only revealing more cracks and bends in the material. So we're forging a new pan, from a better alloy and kitten blood.
About where we're at.

[Cobra951]

OK, fair enough, except for the cancer. 1.42 doesn't corrupt save files, does it? That would be scary. I use 1.51 in the general case anyway. The topic was SMRPG to begin with, and sort of devolved into breakfast.

[sweener2001]

and the fact that you're wrong

[Cobra951]

Wrong? No. I was perfectly willing to be gracious, given my appreciation for ZSNES development. Nothing I said is fundamentally wrong. If the only game you care about is SMRPG, 1.42 is the superior version. That is readily apparent to anyone who plays the game.

[Gil_Hamilton]

Wrong? No. I was perfectly willing to be gracious, given my appreciation for ZSNES development. Nothing I said is fundamentally wrong. If the only game you care about is SMRPG, 1.42 is the superior version. That is readily apparent to anyone who plays the game.

The "if you only play Mario RPG" exception is a significant difference between what you said before and now.

Now for reference.

Make sure to keep 1.42 handy. With updates so infrequent, it will remain the definitive version of ZSNES for quite a while longer.

Wrong. The definitive version is the most recent one. Or perhaps one of the vintage builds. I'm partial to 0.800a, myself.

As for specialty chips in the cart, that became almost a common practice late in the console's life, didn't it? Yoshi's Island, Star Fox, and Stunt Race FX immediately spring to mind--all properly emulated for a number of years, along with SMRPG.

Wrong. Not a single one of the titles you listed has ever been properly emulated.

And you're saying that improvements in emulation accuracy should be passed up if they break a game in the process?

I don't know how to answer that question because it's contradictory. If a game worked before and now doesn't, the emulation got worse...

Wrong, though this may require more explanation.

The game in question only ever worked due to a hackish coprocessor routine(no offense to the coders) that expects inaccurate base system emulation.
Improving the emulator will break hacks that are dependent on inaccuracy.


If I recall, that was part of why FF3 kept breaking. There was a forgotten hack for it in the code, and the hack was still "correcting" the now-accurate emulation.
It was then tweaked until FF3 worked again, then adjusted to make everything else work.
Then tweaked until FF3 worked, then adjusted to make everything else work.
Then tweaked until FF3 worked, then the FF3 hack was rediscovered and removed and emulation was adjusted to make everything work.

[Deathlike2]

It's FF6 that had the bug, particularly because it was exposed by the translation. Since the hack detection was via the internal game name (data), and that data was modified by the translation.. well it broke hard.

The timing had to be readjusted to fix that, as FF3 (SNES) and FF6 (original Jap version) have slight timing differences IIRC, even though both are NTSC versions.

[Gil_Hamilton]

It's FF6 that had the bug, particularly because it was exposed by the translation. Since the hack detection was via the internal game name (data), and that data was modified by the translation.. well it broke hard.

The timing had to be readjusted to fix that, as FF3 (SNES) and FF6 (original Jap version) have slight timing differences IIRC, even though both are NTSC versions.

Ah. I remembered something in the family broke hard and repeatedly, but not which one.
Honestly, I'm surprised I remember ANYTHING some days.


US and J have different timing on that game? Just when you think that one can't get any wierder, it goes ahead and does it.

[Deathlike2]

Probably have to ask pagefault to remember what was done... if you have any of the SVN logs between 1.50 and 1.51, you should find many different messages regarding getting (HDMA) timing correct on both.

[Cobra951]

I'm happy to get everyone's juices flowing here. With all this passion, maybe the next revision will come out sooner than I expected. If all goes back to love, peace and happiness with it, we can put this whole debate behind us. At this point, there's nothing more to say, and it can only degenerate into a swearing match, right? Yes it is! No it isn't! YES IT IS! NO IT ISN'T! Like something out of Monty Python. Flame on if you must. (Well, only some of you, really. Most of what I've read has been reasonable and informative.) I'm done.