Cant go further in some games
Moderator: ZSNES Mods
-
- New Member
- Posts: 6
- Joined: Wed May 27, 2009 6:17 pm
Cant go further in some games
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
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
-
- Locksmith of Hyrule
- Posts: 3634
- Joined: Sun Aug 08, 2004 7:49 am
- Location: 255.255.255.255
- Contact:
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.
also, post NSRT output of both ROMs.
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
NSRT here.
-
- New Member
- Posts: 6
- Joined: Wed May 27, 2009 6:17 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?
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?
-
- New Member
- Posts: 6
- Joined: Wed May 27, 2009 6:17 pm
Evil Rom. Roger that. But i will w8 for zsnes 2.0 anyway.escapee wrote:Star Ocean will freeze up in ZSNES, use something else.
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
Make sure you have this patch, read and follow Application Instructions in the readme. That should be it.sir_herrbatka wrote:So what should i do with Rudora no Hihou?
-
- Trooper
- Posts: 535
- Joined: Wed Jul 28, 2004 3:26 am
The nsrt info says his rudra is interleaved, and isn't interleaved roms no longer supported? He has to de-interleave gis rom.
[code]<Guo_Si> Hey, you know what sucks?
<TheXPhial> vaccuums
<Guo_Si> Hey, you know what sucks in a metaphorical sense?
<TheXPhial> black holes
<Guo_Si> Hey, you know what just isn't cool?
<TheXPhial> lava?[/code]
<TheXPhial> vaccuums
<Guo_Si> Hey, you know what sucks in a metaphorical sense?
<TheXPhial> black holes
<Guo_Si> Hey, you know what just isn't cool?
<TheXPhial> lava?[/code]
-
- Locksmith of Hyrule
- Posts: 3634
- Joined: Sun Aug 08, 2004 7:49 am
- Location: 255.255.255.255
- Contact:
sir_herrbatka wrote:Evil Rom. Roger that. But i will w8 for zsnes 2.0 anyway.escapee wrote:Star Ocean will freeze up in ZSNES, use something else.
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.
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.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.
In both cases, I'd pick up a CLEAN, un-hacked ROM (search Google) and download the appropriate translation patches.
<Nach> so why don't the two of you get your own room and leave us alone with this stupidity of yours?
NSRT here.
NSRT here.
-
- New Member
- Posts: 6
- Joined: Wed May 27, 2009 6:17 pm
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
*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.
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.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- New Member
- Posts: 6
- Joined: Wed May 27, 2009 6:17 pm
It couldn't be more clear BTW But what the sfx-interleaved roms are?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.
THX, I will keep this in my mind.Still, it is a good habit to keep your dumps clean. Use softpatching preferentially.
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
Dumped ROMs of SFX games that aren't supported anymore.sir_herrbatka wrote:BTW But what the sfx-interleaved roms are?
Plain as that.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
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.
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.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
-
- New Member
- Posts: 6
- Joined: Wed May 27, 2009 6:17 pm
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
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.creaothceann wrote:Correctly dumped ROMs have all parts in the correct order ("1 2 3 4 5 6 7 8 ...").
Which is, once again, why we support those interleaves.
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.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").
Nice redundancy there.Nach's NSRT SNES tool for ROMs
Not an error. You still need to load up the (properly) interleaved ROM in a copier for it to work right with it.detect and fix this error
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.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
With "correctly dumped" I meant "the contents of the ROM chips extracted and all copier-induced issues fixed".grinvader wrote: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.creaothceann wrote:Correctly dumped ROMs have all parts in the correct order ("1 2 3 4 5 6 7 8 ...").
Which is, once again, why we support those interleaves.
Just a random, simplified example.grinvader wrote:That kind of interleave isn't really common, if ever.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 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.grinvader wrote:Not an error. You still need to load up the (properly) interleaved ROM in a copier for it to work right with it.detect and fix this error
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).
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
-
- Buzzkill Gil
- Posts: 4294
- Joined: Wed Jan 12, 2005 7:14 pm
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
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.Gil_Hamilton wrote:So with individual files for each ROM chip, right?creaothceann wrote:With "correctly dumped" I meant "the contents of the ROM chips extracted and all copier-induced issues fixed".
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.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
-
- Buzzkill Gil
- Posts: 4294
- Joined: Wed Jan 12, 2005 7:14 pm
It's more convenient to support interleaved dumps, too.creaothceann wrote: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.Gil_Hamilton wrote:So with individual files for each ROM chip, right?creaothceann wrote:With "correctly dumped" I meant "the contents of the ROM chips extracted and all copier-induced issues fixed".
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.
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?
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
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.Gil_Hamilton wrote:It's more convenient to support interleaved dumps, too.
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?
It simplifies things. It would be similar to replacing all GoodSNES sets with NSRT sets.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?
I'm not against support for interleaved formats - by specialized tools, as the last/first step when transferring ROMs to/from dumpers.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
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.
The interleave layout itself is pretty crazy.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- Buzzkill Gil
- Posts: 4294
- Joined: Wed Jan 12, 2005 7:14 pm
But less convenient when many ROM image formats exist in the wild, and there's no bias for any given format.creaothceann wrote: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.Gil_Hamilton wrote:It's more convenient to support interleaved dumps, too.
You mean like ZSNES currently does with ROM iamges in ZIP files?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?
I think this is more like a paint program supporting both GIF and JPEG.
Yes. It simplifies things to break some 50% of all good ROM images on the internet, and compatibility with many copiers.It simplifies things.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?
Just against copier owners being able to use the same files on their copiers as their emulators?I'm not against support for interleaved formats - by specialized tools, as the last/first step when transferring ROMs to/from dumpers.
NOT seeing the convenience or simplicity here.
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
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.
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.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding