Feature Idea: ROM pre-processing

[Jipcy]

Ok, so I've been reading various stuff about interleaved roms, headers, blah blah blah. Basically, all the crazy formats that copiers spit out and make it hard for ZSNES to play the rom.Also, apparently ZSNES no longer supports interleaved SuperFX games. Is this correct?

So here's my idea. How about we change ZSNES so that it pre-processes all roms, by deinterleaving them, removing headers, and otherwise cleaning a rom until it is in a format that is easiest to correctly emulate?

Details:
1. Determine what "format" (deinterleaved, un-headered, etc, etc) that is easiest for ZSNES to correctly emulate.
2. Remove support from ZSNES for all other rom formats.
3. Add NSRT code to ZSNES so that it can read whatever rom someone loads.

What happens in the program:
1. User starts ZSNES normally.
2. User "loads" a ROM.
3. The NSRT code in ZSNES copies the ROM from its original location to a ROM temp directory (default within ZSNES directory, also user-selectable).
4. NSRT code determines what format the ROM is in.
5. NSRT code makes its best effort to change the ROM into the correct format for ZSNES. Optionally, NSRT code can also try to trim overdumps and fix hacks on a rom, as well as possibly add an NSRT header with controller information.
6. After NSRT code is finished making changes, ZSNES loads a clean, deinterleaved, un-headered ROM.

Why? I'm not sure, but perhaps it would result in more accurate emulation, if the main ZSNES code only has to deal with one type of ROM. Moving the code that deals with weird ROMS farther away from the central ZSNES code might make it easier? Basically, if NSRT code is added to ZSNES, then it can attempt to make any given loaded ROM as clean as possible for ZSNES, so that ZSNES doesn't have to deal with as much crap itself.

Other benefits: the ZSNES preprocessing would never edit the original ROM file. It would do all its work on a copied ROM contained in a working directory. The user could choose to turn off pre-processing altogether, if he or she wants. But ZSNES still won't be able to load a screwy ROM. The user could also choose whether the NSRT code adds an NSRT head or not. The user could also set a cache size, so that maybe the 10 most recently loaded roms would be kept in the rom pre-processing temp directory. This would decrease loading time after the first time.

Well, that's all I can think of for now. What do you think?

[Noxious Ninja]

Or we could just tell people to run their ROMs through NSRT.

[Jipcy]

Yes, I know. But people are lazy. I was trying to find a middle ground between the perfect world where everyone has perfect rom dumps and ZSNES has to only deal with one flavor of rom, versus the current situation, where many people don't have much of a clue and ZSNES has to deal with a buttload of weird shit.

For the people that know how to use NSRT and have clean roms, then they can disable the rom pre-processing altogether. But by default, the average user who downloads ZSNES probably has roms in all different interleave and header forms. So perhaps preprocessing would help.

[Agozer]

I don't think ZSNES should cater über-lazy users.

[snkcube]

Wasn't this brought up? Or was I imagining...

[Stifu]

I'd rather have the developers fix bugs and stuff rather than adding features that aren't directly related to the emulation of the SNES, and that other programs have already.

[Jipcy]

Answer me this one of the developers:
How does ZSNES currently deal with the various formats of interleave when it loads a rom? Does supporting different interleave formats make it more difficult to accurately emulate the rom? Does it make it more difficult to program ZSNES in general? Would it be easier if ZSNES had to deal with only one or a couple different types of ROMs?

That's the main benefit I'm thinking might result from something like this. It's not about catering to lazy users. I'm not saying that whenever ZSNES loads a rom that NSRT will automatically scan all their roms. Hopefully, adding this feature would be mostly invisible to the average user. Hopefully it wouldn't change the out-of-box use of ZSNES. But maybe it would make ZSNES easier to program, and maybe more games would be supported, and maybe more games would be emulated correctly.

[Stifu]

Would a real SNES be able to run interleaved ROMs ?
I don't know the answer myself, but if not, then the fact ZSNES doesn't either is all good and makes it more like the real thing.

By the way, if ZSNES supported interleaved ROMs again, that'd mean supporting the spread of bad dumps... while if they don't, interleaved ROMs will probably disappear from the net, eventually.

[Nach]

Basically, you're asking for NSRT or a good chunk of NSRT to be put into ZSNES. Not happening.

[Noxious Ninja]

Because you don't think it's worth the effort, or you don't want to release the NSRT source code?

[AspiringSquire]

Basically, you're asking for NSRT or a good chunk of NSRT to be put into ZSNES. Not happening.

Not that I'm supporting the idea, but couldn't ZSNES just send the command instructions to NSRT so it can deal with a ROM separately?

[Nach]

Because you don't think it's worth the effort, or you don't want to release the NSRT source code?

It's not worth the effort to put part of NSRT in another program.
I and and some other NSRT devs aren't fans of the GPL.

Basically, you're asking for NSRT or a good chunk of NSRT to be put into ZSNES. Not happening.

Not that I'm supporting the idea, but couldn't ZSNES just send the command instructions to NSRT so it can deal with a ROM separately?

That could be done, but I for one have no interest in having ZSNES do that.

[Jipcy]

Is there ANY added benefit from implementing an idea like what I said? It appears that, if there is any benefit, it is not enough to justify the coding changes necessary.

[ipher]

Is there ANY added benefit from implementing an idea like what I said? It appears that, if there is any benefit, it is not enough to justify the coding changes necessary.

There is an added benifit to what you are asking, it just requires alot more work than its worth, and merging a large part of a closed-source program (NSRT) into an open source one (ZSNES).

So in short: It would be nice, but its never going to be done

[xMetaRidley]

Maybe you could start including NSRT with official ZSNES releases? You could also include some "romfixer.bat" file that people could drag roms into to automatically fix them (since most people wouldnt know how to use the command line and the GUI is probably complicated for them too. or it could just search through directories when ran and fix them with NSRT). I don't think ZSNES itself should do any type of ROM editing. If you put a bad rom image onto a cart and put it in a real SNES, it isn't going to fix it for you so I don't think ZSNES should either.

[Jipcy]

I don't think ZSNES itself should do any type of ROM editing. If you put a bad rom image onto a cart and put it in a real SNES, it isn't going to fix it for you so I don't think ZSNES should either.

I agree with this. So, obviously directly including NSRT rom-preprocessing code into ZSNES is not going to work. How about you remove support for all rom interleave formats (etc), and make it very clear to ZSNES users both within the program itself and in the documentation how they can fix their roms to work with ZSNES? And by fix I mean "clean" with a tool of their choice, to get the ROM back into a form more closely matched to the data that is on the cart. As in, not screwed up by copiers and hacked by release groups.

[xamenus]

Removing support for all interleaved formats might actually have some pluses:

+The ZSNES code will probably be cleaner.
+"Authentic" emulation.
+ People will be forced to use NSRT.
+Interleaved ROMs probably wouldn't be distributed on ROM sites as much.

Maybe the other major SNES emulators could remove support, too.

EDIT: Heck, why not try it in a WIP or 1.43? If it doesn't work out, it can be re-added.

[Noxious Ninja]

It will probably elicit a bunch of bitching from the "I've got to have every single ROM GoodSNES recognizes, even if it's Super Mario World [b1] [h1] [o1] [f1]" crowd.

c.f. http://aseigo.blogspot.com/2005/02/perv ... tence.html

[badinsults]

Matthew Kendora would not really like this idea. :p

Personally, I think it would be just as well to let the de-interleaved roms get out of circulation.

[Jipcy]

Let them bitch. If we make it very clear to ZSNES users, by telling them on the webpage before they download, in the program itself, and in the documentation, then users can take the initiative and organize/clean their rom collection themselves. Perhaps we can include an NSRT package with ZSNES, or to keep download sizes small, put a link to an NSRT package next to ZSNES. Improving useabality for NSRT would help too.

Does anyone have any experience writing Windows batch files? Could you make a batch file that went something like this:

COPY "%1" "(user defined ROM working directory)"
nsrt -deint -trim -remhead "%2(=copied file)"
nsrt -addnsrt "%2"
zsnes -load "%2"

The function of this batch file copies the user's original rom to a working directory. Second line de-interleaves, trims, and removes and headers from the rom in the working directory. The third line adds an NSRT header. The fourth line loads the ROM into zsnes (can zsnesw load a rom from the command line?). Anyway, you could associate this batch file with the file types of your choosing, so that the same basic functionality in terms of rom-cleaning would happen.

The only problem with all of this is that copier users that play this stuff on their copiers would maybe have to keep two versions of a rom, one for their copier, one for zsnes. But they could also run JMA compression on their zsnes rom-set so there's less of an impact.

[Jipcy]

That could be done, but I for one have no interest in having ZSNES do that.

Why no interest? Here's what I envision if ZSNES was able to manipulate NSRT:
New rom-preprocessing option selection on menu.
Within dialog:
1. Check box to turn on/off pre-processing altogether.
2. Check boxes for the various NSRT switches.

User loads rom, ZSNES checks to see if pre-processing is enabled. If no, ZSNES attempts to load rom. If yes, ZSNES copies rom to ZSNES directory, sends copied rom to NSRT with selected switches, waits for NSRT to finish, loads edited rom.

I would assume ZSNES would delete any processed rom as soon as it is unloaded, or alternatively when ZSNES is closed. You could get a little more advanced and keep track of what roms have been preprocessed, to avoid preprocessing again.

Also, NSRT need not be included with the ZSNES package. There could be a user-selectable path box in the congif dialog. Pre-processing would be disabled by default, unless you wanted to package NSRT with ZSNES.

[Nightcrawler]

What the heck is the point of all this?

This isn't going to help the emulation any. It may allow some code cleanup in ZSNES, but that's about it, and it isn't worth the wealth of code that would have to be added.

People shouldn't be 'forced' to do anything or use any other program.

What happens if you are hacking a game and you want to run it on ZSNES? What then? You don't want to allow anything but an NSRT validated ROM to run?

What if you're making your OWN ROM.. NSRT isn't going to know what that is. You don't want ZSNES to allow any homebrew development?

You also realize depending on how this would be handled, it would break many existing hacks and translation patches.

You want anyone who has a copier that uses an different format to keep two copies of their ROMS? That's asking a little much isn't it?

I would quickly abandon using ZSNES if such constraints were enforced.

[ipher]

That could be done, but I for one have no interest in having ZSNES do that.

Why no interest? Here's what I envision if ZSNES was able to manipulate NSRT:
New rom-preprocessing option selection on menu.
Within dialog:
1. Check box to turn on/off pre-processing altogether.
2. Check boxes for the various NSRT switches.

User loads rom, ZSNES checks to see if pre-processing is enabled. If no, ZSNES attempts to load rom. If yes, ZSNES copies rom to ZSNES directory, sends copied rom to NSRT with selected switches, waits for NSRT to finish, loads edited rom.

I would assume ZSNES would delete any processed rom as soon as it is unloaded, or alternatively when ZSNES is closed. You could get a little more advanced and keep track of what roms have been preprocessed, to avoid preprocessing again.

Also, NSRT need not be included with the ZSNES package. There could be a user-selectable path box in the congif dialog. Pre-processing would be disabled by default, unless you wanted to package NSRT with ZSNES.

Sure, thats cool and all, but do you realize the TIME it would take? Real ZSNES bugs need to be taken care of first. I for one would rather have emulation and other various ZSNES bugs taken care of before we spend months on a feature that just helps lazy people run bad roms.

[Jipcy]

Well, it seems this idea is pretty unpopular. My last suggestion is maybe we can have something like what IceFox said, by just flat-out removing all support for interleaved roms, and post it in a WIP.

By the way, when I say "we" I dont mean to suggest that I am actually doing the hard work of coding ZSNES. I really kind of mean "we" the community here on the boards. "We" can provide input to the developers that someone who just comes to the main site and downloads it cannot. So in that sense, we have control over ZSNES more so than the person who just downloads it and never comes into the forum.

[Nightcrawler]

Ok.. that's a bit more reasonable, but still.. what's the need here? How would disabling the loading of interleaved ROMS add any benefits?