Cant go further in some games

sir_herrbatka · Post by **sir_herrbatka** » Wed May 27, 2009 6:24 pm

hi all this is my first post

After instalation of Linux i wanted to play some jrpgs, good that there was emulator in synaptic

Everything seemes to work just fine but for a some reasone i cant play in Rudra's Treasure and star ocean - the game just stops at some point and everything is completly static. :/

If only someone could help me

adventure_of_link · Post by **adventure_of_link** » Wed May 27, 2009 6:45 pm

first off, what version of ZSNES are you using? Either way (having the latest or some old version), it'd be for the better to get the official sources, compile them, and try again.

also, post NSRT output of both ROMs.

Johan_H · Post by **Johan_H** » Wed May 27, 2009 6:53 pm

Might be the translation patches (which I assume you're using). Make sure you have the right ROM and latest version etc.

sir_herrbatka · Post by **sir_herrbatka** » Wed May 27, 2009 7:26 pm

I'm using zsnes 1.510

Well rudora is hacked. Orginally this game was translated and there was patch but nvm... Now i have this:

File: Rudra's Treasure (Rudora no Hihou ).smc
Name: TRERA AGTP V2.0 RUDRA Company: Square
Header: SWC Bank: LoROM
Interleaved: GD Deinterleaved SRAM: 64 Kb
Type: Normal + Batt ROM: 32 Mb
Country: Japan Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Bad 0x5B91 != 0x4CE6 Game Code: AORJ

I really dont know what should i do with this next

Star ocean was actualy hacked as well by DeJap team. No patch.

---------------------Internal ROM Info----------------------
File: Star Ocean (English Translation).smc
Name: Star Ocean Company: Enix
Header: None Bank: LoROM
Interleaved: None SRAM: 64 Kb
Type: S-DD1 + Batt ROM: 48 Mb
Country: Japan Video: NTSC
ROM Speed: 120ns (FastROM) Revision: 1.0
Checksum: Bad 0x20F2 != 0x13B8 Game Code: ARFJ

Well that is it. I used to run Star ocean on other emulator (i really cant tell is it was snes9x or older zsnes). Now i have a problem but generally guys over internet knows everything anyway so...

I assume that runing hacked roms is not so smart? I never used patches. Is there reason to do it this way?

escapee · Post by **escapee** » Wed May 27, 2009 7:37 pm

Star Ocean will freeze up in ZSNES, use something else.

Nothing wrong with patches, assuming they're properly applied.

sir_herrbatka · Post by **sir_herrbatka** » Wed May 27, 2009 7:51 pm

escapee wrote:Star Ocean will freeze up in ZSNES, use something else.

Evil Rom. Roger that. But i will w8 for zsnes 2.0 anyway.

So what should i do with Rudora no Hihou? Well i can tell that this is my second problem with emulator ever (i couldn't run (cinematics was not working) xenogears on psx). I used to expect that it just works... never wondering about this whole stuff so i guess that i'm newbie in emulation

Johan_H · Post by **Johan_H** » Wed May 27, 2009 8:25 pm

sir_herrbatka wrote:So what should i do with Rudora no Hihou?

Make sure you have this patch, read and follow Application Instructions in the readme. That should be it.

Starman Ghost · Post by **Starman Ghost** » Wed May 27, 2009 8:46 pm

The nsrt info says his rudra is interleaved, and isn't interleaved roms no longer supported? He has to de-interleave gis rom.

adventure_of_link · Post by **adventure_of_link** » Wed May 27, 2009 9:19 pm

sir_herrbatka wrote:
escapee wrote:Star Ocean will freeze up in ZSNES, use something else.
Evil Rom. Roger that. But i will w8 for zsnes 2.0 anyway.

The original star ocean game had these bugs, even on real hardware. Use Snes9x, since it seems to have the bugs fixed (:?).

Also, I forgot to say, by official sources, I meant the latest version. My apologies.

Starman Ghost wrote:The nsrt info says his rudra is interleaved, and isn't interleaved roms no longer supported? He has to de-interleave gis rom.

As far as I know, they're unsupported for Super FX games, but I'd say it's best to de-interleave it, just to be sure.

In both cases, I'd pick up a CLEAN, un-hacked ROM (search Google) and download the appropriate translation patches.

sir_herrbatka · Post by **sir_herrbatka** » Thu May 28, 2009 6:51 am

thx guys. Now it seems to be just fine

Rudra finaly works

Post by **grinvader** » Thu May 28, 2009 11:26 pm

*sigh*
It's pretty annoying when even veterans spread incorrect rumours.

SO's "native" bugs aren't anything like what happens in zsnes. The worst that happens in a real SO cart is the infamous talent get freeze.
The music channel mute bugs and consequent lockups stem from timing issues.

SFX-interleaved ROMs are stupid dumps made by stupid people using stupid copiers who jumbled the data to get the header in the right position. This level of stupid reaches nesticle rank, so it was decided to stop supporting it.
Other interleave formats do not concentrate that amount of stupid and are supported.

Still, it is a good habit to keep your dumps clean. Use softpatching preferentially.

sir_herrbatka · Post by **sir_herrbatka** » Fri May 29, 2009 8:12 am

SFX-interleaved ROMs are stupid dumps made by stupid people using stupid copiers who jumbled the data to get the header in the right position. This level of stupid reaches nesticle rank, so it was decided to stop supporting it.

It couldn't be more clear

BTW But what the sfx-interleaved roms are?

Still, it is a good habit to keep your dumps clean. Use softpatching preferentially.

THX, I will keep this in my mind.

Post by **grinvader** » Fri May 29, 2009 9:00 pm

sir_herrbatka wrote:BTW But what the sfx-interleaved roms are?

Dumped ROMs of SFX games that aren't supported anymore.
Plain as that.

creaothceann · Post by **creaothceann** » Fri May 29, 2009 10:24 pm

Correctly dumped ROMs have all parts in the correct order ("1 2 3 4 5 6 7 8 ..."). As far as I know, interleaved ROMs were dumped with an incorrectly configured dumper, so that the dumped parts are interleaved (in mixed order, e.g. "1 2 5 6 3 4 7 8").

Nach's NSRT SNES tool for ROMs can detect and fix this error, so that maybe some day emulators can remove support for these ROMs.

sir_herrbatka · Post by **sir_herrbatka** » Sat May 30, 2009 9:38 am

Correctly dumped ROMs have all parts in the correct order ("1 2 3 4 5 6 7 8 ..."). As far as I know, interleaved ROMs were dumped with an incorrectly configured dumper, so that the dumped parts are interleaved (in mixed order, e.g. "1 2 5 6 3 4 7 8").

I see. Thx for answer.

Post by **grinvader** » Sat May 30, 2009 2:16 pm

creaothceann wrote:Correctly dumped ROMs have all parts in the correct order ("1 2 3 4 5 6 7 8 ...").

Not really. Assuming 'correctly dumped' means you extracted all the data needed without redundancy (i.e. not over/underdumped), most copiers would interleave stuff for hirom due to the differences in mapping.
Which is, once again, why we support those interleaves.

As far as I know, interleaved ROMs were dumped with an incorrectly configured dumper, so that the dumped parts are interleaved (in mixed order, e.g. "1 2 5 6 3 4 7 8").

That kind of interleave isn't really common, if ever. The classic one would be 12345678->51627384. And there's no "incorrectly configured dumper". You dump the memory blocks of your copier, that's all. Underdumps happen when your copier is too small to hold the data. Overdump happen when they are larger and don't look at the internal ROM size field. Copier interleaves exist because they often tried to support LoROM efficiently (i.e. not wasting half the space) before attempting to look at HiROM.

Nach's NSRT SNES tool for ROMs

Nice redundancy there.

detect and fix this error

Not an error. You still need to load up the (properly) interleaved ROM in a copier for it to work right with it.
Why stop supporting something that's still needed for some people to actually run the ROM images on real hardware ? Ok, ucon64 is there, but they might want to use the same copy for their emu and realconsole (especially romhackers who test on hardware).

I'll ask Nach for more details on how worse SFX interleave was regarding that, but it was clearly not a case of simple copier interleave.

creaothceann · Post by **creaothceann** » Sat May 30, 2009 6:37 pm

grinvader wrote:
creaothceann wrote:Correctly dumped ROMs have all parts in the correct order ("1 2 3 4 5 6 7 8 ...").
Not really. Assuming 'correctly dumped' means you extracted all the data needed without redundancy (i.e. not over/underdumped), most copiers would interleave stuff for hirom due to the differences in mapping.
Which is, once again, why we support those interleaves.

With "correctly dumped" I meant "the contents of the ROM chips extracted and all copier-induced issues fixed".

grinvader wrote:
As far as I know, interleaved ROMs were dumped with an incorrectly configured dumper, so that the dumped parts are interleaved (in mixed order, e.g. "1 2 5 6 3 4 7 8").
That kind of interleave isn't really common, if ever.

Just a random, simplified example.

grinvader wrote:
detect and fix this error
Not an error. You still need to load up the (properly) interleaved ROM in a copier for it to work right with it.
Why stop supporting something that's still needed for some people to actually run the ROM images on real hardware ? Ok, ucon64 is there, but they might want to use the same copy for their emu and realconsole (especially romhackers who test on hardware).

I just think it shouldn't be an emulator's job. The most a emulation/romhacking tool should have to worry about is if the ROM is LoROM or HiROM (ignoring other mappers for the moment). Headers and interleaving formats are copier-specific and could be handled by copier-specific tools. The most it'd take would be calling a batch file.

Gil_Hamilton · Post by **Gil_Hamilton** » Sat May 30, 2009 8:52 pm

creaothceann wrote:With "correctly dumped" I meant "the contents of the ROM chips extracted and all copier-induced issues fixed".

So with individual files for each ROM chip, right?

It seems to me that the monolithic file is a lie generated by the copiers.

Deathlike2 · Post by **Deathlike2** » Sat May 30, 2009 9:43 pm

I'd just smack the idiot that demands that the files "mirror" the way internally copiers/catridges stored the data. Yes, it was mentioned before by some moron.

creaothceann · Post by **creaothceann** » Sat May 30, 2009 11:04 pm

Gil_Hamilton wrote:
creaothceann wrote:With "correctly dumped" I meant "the contents of the ROM chips extracted and all copier-induced issues fixed".
So with individual files for each ROM chip, right?

Not necessarily. It's more convenient to separate the ROM data from the SRAM data, but not to separate the bytes of a ROM that is stored in two chips. I'm looking at this from the user/application point of view. If you have to guess where the data is, then the file format is a failure. Even storing one cartridge in one XML or INI file is much better than that.

These file formats don't even have to "mirror the way internally copiers/catridges stored the data". They just need all the info required for hardware-accurate emulation, i.e. preserveration.

Gil_Hamilton · Post by **Gil_Hamilton** » Sun May 31, 2009 6:57 am

creaothceann wrote:
Gil_Hamilton wrote:
creaothceann wrote:With "correctly dumped" I meant "the contents of the ROM chips extracted and all copier-induced issues fixed".
So with individual files for each ROM chip, right?
Not necessarily. It's more convenient to separate the ROM data from the SRAM data, but not to separate the bytes of a ROM that is stored in two chips. I'm looking at this from the user/application point of view. If you have to guess where the data is, then the file format is a failure. Even storing one cartridge in one XML or INI file is much better than that.

These file formats don't even have to "mirror the way internally copiers/catridges stored the data". They just need all the info required for hardware-accurate emulation, i.e. preserveration.

It's more convenient to support interleaved dumps, too.

Since we're ALREADY lying about the original data layout, I see no reason to stop supporting all but one type of dump without a good reason.

You can't use the convenience argument when you're advocating the removal of a convenience feature.

(Note that I'm NOT saying that console emulation should start requiring individual chip dumps like arcade emulation. It's merely for illustrative purposes.)

Deinterleaving is a trivial task. Why disable it?

creaothceann · Post by **creaothceann** » Sun May 31, 2009 8:29 am

Gil_Hamilton wrote:It's more convenient to support interleaved dumps, too.

If you'd write a level editor, what would be easier: writing one simple loading function, or writing one/several complicated ones? (The same goes for saving.) Supporting only one simple ROM format is easier and less error-prone.

If you'd write a Paint-like program, and a user says "hey, some of my BMP files are enclosed in LHA archives, please support them transparently!", what would you do?

Gil_Hamilton wrote:You can't use the convenience argument when you're advocating the removal of a convenience feature.

Deinterleaving is a trivial task. Why disable it?

It simplifies things. It would be similar to replacing all GoodSNES sets with NSRT sets.

I'm not against support for interleaved formats - by specialized tools, as the last/first step when transferring ROMs to/from dumpers.

Post by **grinvader** » Sun May 31, 2009 11:39 am

After a talk with Nach, sfx interleave comes from the fact that pcb traces on these carts point to unusual romchip pins coupled with copiers' inaptitude to deal with that.
The interleave layout itself is pretty crazy.

Gil_Hamilton · Post by **Gil_Hamilton** » Sun May 31, 2009 12:21 pm

creaothceann wrote:
Gil_Hamilton wrote:It's more convenient to support interleaved dumps, too.
If you'd write a level editor, what would be easier: writing one simple loading function, or writing one/several complicated ones? (The same goes for saving.) Supporting only one simple ROM format is easier and less error-prone.

But less convenient when many ROM image formats exist in the wild, and there's no bias for any given format.

If you'd write a Paint-like program, and a user says "hey, some of my BMP files are enclosed in LHA archives, please support them transparently!", what would you do?

You mean like ZSNES currently does with ROM iamges in ZIP files?

I think this is more like a paint program supporting both GIF and JPEG.

Gil_Hamilton wrote:You can't use the convenience argument when you're advocating the removal of a convenience feature.

Deinterleaving is a trivial task. Why disable it?
It simplifies things.

Yes. It simplifies things to break some 50% of all good ROM images on the internet, and compatibility with many copiers.

I'm not against support for interleaved formats - by specialized tools, as the last/first step when transferring ROMs to/from dumpers.

Just against copier owners being able to use the same files on their copiers as their emulators?
NOT seeing the convenience or simplicity here.

Post by **Nach** » Sun May 31, 2009 12:39 pm

Super FX games don't run on unmodified copiers. No reason to allow users to keep their images in formats that don't work on copiers.

The main reason I removed the code though is that ZSNES's deinterleave code in that case was tied to a lot of other dumb code which was deleted. I could replace it with the self contained straight foward deinterleave code from NSRT, but the author of that code hasn't given me permission to do so.