bsnes v0.038 released

[Nightcrawler]

The way you guys have been talking both here and other topics related seemed to be in the direction of kind of jamming your ideals down the user's throat as the only option.

For the sake of discussion, I was also suggesting removing IPS support. Possibly offering auto-conversion to UPS.

Nightcrawler, nobody likes forcing anyone to do anything. But the current system is broken.

So, you want to render 95% of all existing SNES hacks and translations unplayable on all future versions of all SNES emulators? That idea is just as broken as the IPS patching format in my opinion.

[Panzer88]

why not support both? I agree that there are better formats, and we should start supporting them, but cutting off backwards compatibility isn't going to make anyone happy and people are going to do what they want at the end of the day, you can't force them to do something. I think if there was a better solution to ips that was just as easy for all hackers and users to use, then we would see more results. Just cutting off bsnes support right now is not the solution.

You can do what you want, but that's just my opinion.

[FitzRoy]

but emulators shouldn't need to know what SHVC-FUBAR-12 means. And by allowing the raw mapping approach, emu authors can support the new format much easier, and people can customize them for other uses -- however niche they may be. It's nice flexibility to have at no cost.

I would disagree there, boards and chips need names and the one it was designated by its designer is as good as any. People need names, too, it would be very difficult if everyone was referenced by a story of how their body works. There are plenty of costs with an external format and I haven't seen a single person request such a thing for making games. The costs clearly outweigh the benefits.

You seem to be bothered by the emulator performing scans to determine where the files are located prior to bringing the hardware into interaction. How the program materializes a true-to-life configuration of parts prior to powered interaction is absolutely meaningless, it has nothing to do with the system processes or emulation accuracy. Not everything about the program = system.

So, you want to render 95% of all existing SNES hacks and translations unplayable on all future versions of all SNES emulators? That idea is just as broken as the IPS patching format in my opinion.

Why would they be unplayable if they can be converted to UPS?

[byuu]

So, you want to render 95% of all existing SNES hacks and translations unplayable on all future versions of all SNES emulators?

The alternative is leaving a broken format around eternally. Do you want people trying to figure out how to add or remove headers to ROMs forever?

This wouldn't be that big of a deal. A few versions to support both at best, emulator tools to auto-convert to UPS somehow. And RHDN to manually convert patches over.

A few weeks of difficulty to eliminate the most common headache in the SNES translation scene. Please think of the future benefits, and not just of a few present growing pains.

Apply your argument to IE: do we want to break 95% of all existing web sites (by adding proper CSS support)? Should the two stylesheets per site + browser sniffing model be left alone, since it's popular now?

People need names, too, it would be very difficult if everyone was referenced by a story of how their body works. There are plenty of costs with an external format and I haven't seen a single person request such a thing for making games. The costs clearly outweigh the benefits.

I do agree with your points. A database would be good for a set of information that can never grow again. And PCB labels will make that database much smaller (4000*16 bytes vs 4000*1kb). It'd be easy for emulators to fix incorrect PCB layouts, but improper layout files would need an external utility to recreate them.

As for benefits, again it comes back to fan translations. Many of them expanded games with no consideration for board mappings. The pattern is obvious: if emulators don't care, neither do many fan translators. Nobody's going to be happy if suddenly those cannot be made to work after we remove the old header-based parsing method. Whereas with the UPS suggestion, we have a way forward for them. As for not emulating hardware limitations like VRAM writes -- well, that's where I draw the line, at least.

Not sure who remembers when ToP's translation ROM expansion required emulator updates to compensate. We need a PCB spec to define their layouts in a universally compatible way.

We've also covered using the PCB layouts, and a type of template system for quick references to the known vendor boards (eg 40 files like shvc-1234-56.pcb, the carts then just reference said code rather than explain the whole thing again.)

The method I was discussing is about compromise. Nach has stated good objections in the past against emulators using databases when we've discussed this, and he's compromising a bit by recording the PCB IDs for us so that they're preserved, too.

None of us are going to get exactly what we want here. But can we find a middle ground, or is the SNES scene as hopeless as the NES scene?

[tetsuo55]

About the IPS debate.

It would take a small group of people an afternoon to convert the entire RHDN library(all systems) to UPS.

It took me alone only a couple of hours to do the entire snes translation part. That time includes figuring out how to manually do it.

With some work a program could be coded that does most of the work automatically.

I'm sure UPS is not meant for snes only right? the benefits seem to apply to all systems and media types.

Its really this simple:
Download the current patch + all its information.
Should be like this:
-Patch.Extension(it doesn't matter if its IPS or anything else)
-Licence.Extention(again it doesn't matter what the current format is)
-Readme.Extention(see above)

All these 3 can be combined into the UPS.
Steps:
1.Get a clean original rom
2.Check the licence/readme to see if a header is needed or not, and precicely which version the patch is intended for
2b. If no info is available you will have to guess, start with the newest version of the rom/iso, if it fails headerless add a header, if that fails go to an older version
3.Patch a copy of the rom/iso
4.Tell the ups program to compare the patched and unpatched iso/rom to create a diff/ups patch
5.I'm not sure if byuu's ups program supports this part, but ninja had it, you can copy/paste the entire licence and readme into the patch
6.Create a small standard file, contents are: info is in the patch itself, how to use the program to read the contents, how to hard-patch if emulator does not understand UPS
7. Zip it up, afterwards the zip files can be ultra-zip-compressed using tools, this can be done automatically on the entire zip folder after everything is done.

You could decide to also include the original documentation in the zip file, some patch-creators demand this.
The most important thing is that the information is always available in the patch itself which is the one thing people are least likely to delete(unless they are hard-patching)

If RHDN wants to help, the ups patch could be the main link, and the original IPS(or whatever format) on a backup link for those that don't want the UPS for some reason.
From that point on you can cpmpletely drop support for IPS, and if people use an IPS file you can have bsnes tell them to either redownload it from RHDN or to convert it themselves(with complete instructions)

[FitzRoy]

None of us are going to get exactly what we want here. But can we find a middle ground, or is the SNES scene as hopeless as the NES scene?

I see no reason why we can't have a 3-tier detection system supporting both.

Main. Check for pcb file in declared path. Interpret mapping from format contents.
1st Fallback. Check database file for checksum entry. Interpret mapping from documented serial.
2nd Fallback. Interpret valid mapping from rom internals.

But I don't like the idea of an offsite database. I also wouldn't compromise the format into including things that it shouldn't (special controller support, genres, xyz) just to have the same format as ZSNES. Go proprietary if necessary.

[Nightcrawler]

The alternative is leaving a broken format around eternally. Do you want people trying to figure out how to add or remove headers to ROMs forever?

No, but UPS hasn't addressed this either. All UPS does is refuse to patch if you got it wrong. People will still be figuring out how to add or remove headers from ROMs forever. That's why I haven't used the UPS format for my releases. Instead, I had to do a custom patcher that would patch ROMs with and without headers and validate all. UPS is still broken.

This wouldn't be that big of a deal. A few versions to support both at best, emulator tools to auto-convert to UPS somehow. And RHDN to manually convert patches over.

This is a whole new conversation that I believe has been had on RHDN previously and quite a few pitfalls were brought up. Anyway, RHDN at present is only going to offer what the authors distribute as. After the NINJA debacle, and community sentiment on standard patching formats, UPS, and creating unofficial distributions, RHDN is likely not to enter into the realm anytime soon or devote resources to a patch format that has only one patcher, has not really been adopted yet for current works, and still falls flat in several areas when considered for a patching standard for all ROM hacking applications (based on community discussions).

A few weeks of difficulty to eliminate the most common headache in the SNES translation scene. Please think of the future benefits, and not just of a few present growing pains.

It hasn't eliminated it though... All it does is not let you patch incorrectly. While that's certainly a good thing, it's only half there.

Apply your argument to IE: do we want to break 95% of all existing web sites (by adding proper CSS support)? Should the two stylesheets per site + browser sniffing model be left alone, since it's popular now?

I think MS has the right idea actually to balance this. IE8 will support both a compatibility mode and a standards compliance mode. I'm uncertain if this is a user option, could be toggled in the doctype declaration by the page designer, or both. It's been somewhat unclear to me. Nonetheless, it won't render the Internet broken, but will support doing things right for the future.

I do agree with your points. A database would be good for a set of information that can never grow again. And PCB labels will make that database much smaller (4000*16 bytes vs 4000*1kb). It'd be easy for emulators to fix incorrect PCB layouts, but improper layout files would need an external utility to recreate them.

As for benefits, again it comes back to fan translations. Many of them expanded games with no consideration for board mappings. The pattern is obvious: if emulators don't care, neither do many fan translators. Nobody's going to be happy if suddenly those cannot be made to work after we remove the old header-based parsing method. Whereas with the UPS suggestion, we have a way forward for them. As for not emulating hardware limitations like VRAM writes -- well, that's where I draw the line, at least.

Not sure who remembers when ToP's translation ROM expansion required emulator updates to compensate. We need a PCB spec to define their layouts in a universally compatible way.

We've also covered using the PCB layouts, and a type of template system for quick references to the known vendor boards (eg 40 files like shvc-1234-56.pcb, the carts then just reference said code rather than explain the whole thing again.)

The method I was discussing is about compromise. Nach has stated good objections in the past against emulators using databases when we've discussed this, and he's compromising a bit by recording the PCB IDs for us so that they're preserved, too.

None of us are going to get exactly what we want here. But can we find a middle ground, or is the SNES scene as hopeless as the NES scene?

Why not have a central database (perhaps even this is in a single file that could be user edited if desired) for the known commercial PCBs and use the external pcb text file for any 'new' boards created for hacks or translations? A system where the external text file will both be defaulted to if it can't be found in the database or override the database even if it is found.

That seems like the most logical and simple evolution into this realm.

[byuu]

tetsuo, IPS->UPS would be tricky to fully automate. Need the original ROM, which RHDN may not have. Some readmes may use both terms, eg "Don't not use this with a headered ROM, but do not use a non-headered one."
It also doesn't embed the readme stuff. We had planned to let NINJA handle that plus multiple patches. UPS was meant to be the minimalist patch format, and we wanted it to be more universal. Just a generic text block alone wouldn't be appropriate for displaying in an emulator, either.

FitzRoy, I would like to ultimately kill off the mapper parsing method entirely, at least for bsnes. But we need to make sure all games work with the new method, and that anyone can easily convert them, before we can do that :/

The database wouldn't be queried each time you load a game. It'd be more like an automatic / manual updater that just pulls the latest version off a website. So if there's some game-ruining bug regarding mapping, we don't have to update the emulator version to fix it.

No, but UPS hasn't addressed this either. All UPS does is refuse to patch if you got it wrong.

I've said many times that UPS only works with no header for SNES images, and that's how bsnes treats it.

I know, the current patcher doesn't enforce that rule. I was really hoping someone else would help with a patcher and per-platform definitions (eg Genesis uses no interleaving, SNES uses no header, etc.)
I'll get around to it, though. The important thing is no SNES emu supports headered UPS patches.

People can make headered patches, if they want. It's the downside of having a generic, universal format. They just won't auto-patch. And a central repository of patches could simply only host them without the header.

But even if someone patched with a header, and we wanted to, we could have it patch with and without to see which one matches up the checksums.

I think MS has the right idea actually to balance this. IE8 will support both a compatibility mode and a standards compliance mode.

Standards-compliance is opt-in. So lazy broken web pages stay working as-is, but if you ever want something better than IE7 rendering, you have to add <meta content="praise-microsoft=IE8">.

In other words, they're punishing the people who write standards-compliant code. We'll have to update our meta tag for every future release of IE.

Their justification for that is that requiring broken pages to go back and specify eg <meta content="broken-webpage;engine=IE6"> would inconvenience existing people too much.

I'm telling you now, I won't add their tag, even if it's the only way to get my page working in IE. Many other web developers are pledging to do the same in defiance.

Speaking of which, are you aware RHDN returns a content-type of "text/html", yet claims to be XHTML 1.1? It should be returning application/xhtml+xml to invoke the actual XML parser instead of the tag soup HTML parser in Gecko et al. Of course, IE7 and below won't show anything if you do that. Yet again, the people doing things the right way are getting screwed over supporting people who refuse to upgrade.

Why not have a central database (perhaps even this is in a single file that could be user edited if desired) for the known commercial PCBs and use the external pcb text file for any 'new' boards created for hacks or translations? A system where the external text file will both be defaulted to if it can't be found in the database or override the database even if it is found.

I'd like that. Have to hear more about Nach's plan for the central DB first. Most likely we'll need two formats, unless we generate the individual .PCB files from the database fetch, rather than use a single file.

[FitzRoy]

The database wouldn't be queried each time you load a game. It'd be more like an automatic / manual updater that just pulls the latest version off a website. So if there's some game-ruining bug regarding mapping, we don't have to update the emulator version to fix it.

That's flat out impossible, you can't ditch fallback 2 completely. You'd have to fill up that database with hypothetical boards, include every hack and beta and homebrew known to man, stay completely up to date with new releases... no way. And even if that was possible, it's simply offloading the guesswork to a databased result. It doesn't negate that theft took place to buy stolen goods than to steal them yourself, so there's no use in pretending this is cleaner somehow. You may as well perform the dirty work yourself, it's more efficient.

Second of all, a website database is a terrible idea. That essentially closes the format from personal modification, creates an expectation of constant internet access, and introduces a flurry of maintenance quarrels and dependencies.

You (or Nach) are also manufacturing an advantage here. A mapping typo is so improbable, I wouldn't be documenting these boards if I thought a typo was capable of eluding my double audits. Let me be generous though, let's say once in ten years a typo eludes me and happens to break a game. The one person playing the game at that time reports the problem. They and maybe a few others who were playing that game are given the option of waiting a few months for a new release or perform an 3 second fix to the db file.

That's the huge problem worth inheriting the above costs? Not buying it.

[byuu]

We're getting side-tracked. Forget about IPS<>UPS and online cheat codes for now. PCB mapping is the highest priority at the moment.

That's flat out impossible, you can't ditch fallback 2 completely.

I see no point in making an improved format at all if we're just going to keep the old cruft around forever. Then future authors have two formats to support instead of one.

I fully intend to remove the old system once we have at least 98% of games working out-of-the-box and with exact hardware mappings, by whatever means necessary.

If all the emulators follow suit, then people will create layout mappings for their binary blob hacks and homebrew. Either the original authors, or someone who wants to play it. It won't be hard, use a hirom.pcb or lorom.pcb generic template. If not, then I guess "Zophar's 2nd year anniversary demo" wasn't worth preserving.

But yeah, we're probably talking 3-10 years from now. We can worry about that part later.

Anyway, I'll agree with you on the odds of there being a typo as slim. The main advantage of an updating database will be for the time before we have all known games in the DB. I can't imagine we have more than 50% of all games' PCB codes at present. If we get that to 98% with MD5SUMs for each image, then we can remove / forego an update mechanism and I don't think it'll matter much. If you're meaning to fall back on the header detection during that time ... well I guess that works, too. I don't see harm in offering a download mechanism though, but maybe it's more trouble than it's worth.

[Verdauga Greeneyes]

Standards-compliance is opt-in. So lazy broken web pages stay working as-is, but if you ever want something better than IE7 rendering, you have to add <meta content="praise-microsoft=IE8">.

In other words, they're punishing the people who write standards-compliant code. We'll have to update our meta tag for every future release of IE.

I remember reading they reversed this position and made it opt-out. The special tag will make your website render in 'IE7' mode if you don't have time to update it. Mind you none of that really effects 'quirks' mode ...

[Nightcrawler]

Why not have a central database (perhaps even this is in a single file that could be user edited if desired) for the known commercial PCBs and use the external pcb text file for any 'new' boards created for hacks or translations? A system where the external text file will both be defaulted to if it can't be found in the database or override the database even if it is found.

I'd like that. Have to hear more about Nach's plan for the central DB first. Most likely we'll need two formats, unless we generate the individual .PCB files from the database fetch, rather than use a single file.

I really don't see any need for anything further than adding a database file to an emulator distribution that covers all known game identified PCBs. This file is ideally initially included in the emulator release. The file itself is a version generated by the central database file creator. This way, it can easily be updated by the user in between emulator releases (unless the emulator could auto update). It would also be editable for the user to modify for whatever other reason such as fixing something locally that the central version hasn't updated on yet, or whatever reason they want.

The file would aim to cover known real PCBs or most accurate approximation if unknown for all 'real' carts. For all carts that aren't real, the external pcb text file would be needed.

This way, it's easy for nearly any emulator to support the system and there's minimal extra complexity. I'm not into the whole certificate thing. I think that's trying too hard, adding layers of complexity that aren't needed.

The downside is hack or translation creators would need to create pcb files for all of their works, but it seems like extra work would be required for PCB declaration with all proposed solutions thus far.

Also, you have the problem of what to do for cases like existing hacks or translations that will never be updated again. They don't have pcb files, nor do they use the same exact map as the original game (for all expanded ones anyway.) It's a difficult goal to remove the fallback mechanism. I'd rule continuing to allow the emulator to play the library of hacks and translations available is more important than disallowing them to be played.

I think your emulator would lose a large audience if it no longer played the majority of the library of existing hacks and translations. That goes for the PCB movement, how the emulator treats patching, and anything else that would effect this area.

[byuu]

I remember reading they reversed this position and made it opt-out.

Oh, awesome news. IE8 is supposed to finally support display: table-cell that my site needs.

I'm not into the whole certificate thing. I think that's trying too hard, adding layers of complexity that aren't needed.

That would be completely optional. It's really just a slight extension to allow other tools to utilize NSRT's verifications if they want, and aimed to be more secure than file hashes that continue to be broken or easily spoofed.

For instance, you download "Your Favorite Game Ever (U) [!]" from www.dudeitsfreeromz111.com. The [!] means it's a verified good dump. Verified by whom? Why do you trust this nameless person? How do you trust the CRC32 checksum GoodSNES had (before Nach made his infamous "GoodSet")?

(* note that I'm not that worried about it. I'd be surprised if even one [!] game turned out to be maliciously spoofed, as there's no profit in that. But it's still nice for the sake of eg "game historians" to have more definitive origins and a solid chain of trust. After bit-rot sets in, none of these games can ever be re-dumped.)

We include the cert, the emulator can optionally do something nice like print " (verified)" in the title, show the title in blue instead of red, whatever. It's just a long-term historic archival tool. Not needed for anything else. Better yet, we can instantly reject unverified game bug reports.

The downside is hack or translation creators would need to create pcb files for all of their works, but it seems like extra work would be required for PCB declaration with all proposed solutions thus far.

If LoROM and HiROM can properly map 99% of games now, then we'd only need to distribute two templates. Any ROM hacker can figure out what their game is. Further, we can fork the current emulator mapper detection to an external utility that generates these PCB files automatically.

Also, you have the problem of what to do for cases like existing hacks or translations that will never be updated again.

And again, RHDN is in the prime position to help with this. Worst case, some people don't want the file in their archive (even though it may not work in newer emulators without it) ... put it as a separate link right next to <download patch>.

Sorry, I realize it's your site and you're happy with the status quo. But this can be made near painless, and I'm sure you can appreciate the benefits of fool-proof patching, 100% perfect hardware memory mapping, etc.

I'm not trying to "force (my) format down everyone's throats" or push some sort of agenda. I'm discussing and compromising this openly with everyone who wants to chime in. The current formats suck and I want to improve them. We need everybody's help to pull it off.

I think your emulator would lose a large audience if it no longer played the majority of the library of existing hacks and translations.

Should I add a checkbox option in the GUI to allow VRAM writes during vblank too, then?

That goes for the PCB movement, how the emulator treats patching, and anything else that would effect this area.

I already ignore IPS patches, and that isn't going to change. Sure, it may affect my popularity, but it's not a contest :/

[FitzRoy]

I see no point in making an improved format at all if we're just going to keep the old cruft around forever. Then future authors have two formats to support instead of one.

We can try it, but it's going to take a little while to fill out best guess entries (which would be easily distinguishable by having no dumper). I'm also going to need to add some of the more popular unreleased entries on page 2, like Star Fox 2. You're right about hard-patched games, modifications should generally be distributed as patches and stay as patches. Existing goodsnes hacks that don't have patches can have one created by a file comparison. And if it isn't worth the time to do, then neither is the hack.

I can't imagine we have more than 50% of all games' PCB codes at present. If we get that to 98% with MD5SUMs for each image, then we can remove / forego an update mechanism and I don't think it'll matter much.

What's in my db is what we have, 10%. I do not accept partial verifications or hidden verifications from NSRT. If I ever get my website up, expect a lot more complete submissions from others. The chaos under which other dumping forums operate is going to end.

[Nach]

tetsuo, IPS->UPS would be tricky to fully automate.

I've been working on that problem.
If someone gets me an archive of IPS patches for SNES games, I'll see what I can do.

I know, the current patcher doesn't enforce that rule.

Mine does
You really should I have waited a bit for me to rollout. But I've currently have UPS on the back burner again awaiting a GUI before I release.

That would be completely optional. It's really just a slight extension to allow other tools to utilize NSRT's verifications if they want, and aimed to be more secure than file hashes that continue to be broken or easily spoofed.

As I stated before, I want to completely remove verifications from NSRT altogether, and move it to a community website and use a shared lib. I don't really want to work on maintaining a DB when there are perfectly qualified people out there to do that, and it takes time away from me writing the code we need.

How do you trust the CRC32 checksum GoodSNES had (before Nach made his infamous "GoodSet")?

Prior to NSRT 3 came along, GoodSNES didn't have CRC32s, it just used the SNES internal header checksum, and like the first few bytes of the file, and hoped it was good enough. You could swap any two bytes later on in the file, and still having it appear as the same ROM image.

I'd be surprised if even one [!] game turned out to be maliciously spoofed, as there's no profit in that.

Actually, several were. And there was profit in it, since changing the single byte looked at by the emulator for mapping could make it map differently. So if some game didn't load right because mapping for some new special chip wasn't yet implemented, people tried spoofing the cart as other special chips, finding one where the mapping allowed the game to boot further before it crashed, and then distributed those images.

Back in the day, it was downright IMPOSSIBLE to get a good dump of Metal Combat or Tales of Phantasia anywhere. Every single site only carried hacks of those.
It's actually because of stuff like that that I made NSRT have a fix option for a few known hacks, since they were literally everywhere. Even games like Rockman & Forte were hacked, so the main header show display Capcom, since back in the day, tools which displayed company names didn't know to look in the secondary header for it, and always assumed Nintendo in those cases.

[Nightcrawler]

If LoROM and HiROM can properly map 99% of games now, then we'd only need to distribute two templates. Any ROM hacker can figure out what their game is. Further, we can fork the current emulator mapper detection to an external utility that generates these PCB files automatically.

Yes, but is requiring another required file in the distribution. I wonder how people feel about that. It's also another step for end users to get hung up on. Replace patching problems with can't run hack X in emulator Z. Rinse and repeat. These are the things I think about and bring up because you guys don't really seem to care about requiring more of people such as patch creators, emulator authors, end users, or otherwise. You want the discussion to be open, but this is kind of a closed discussion being available only here to limited people and this topic which anyone not interested in BSNES wouldn't even check. For something that aims to be so far reaching, thus far, gathering input, ideas, and feelings is very short reaching.

And again, RHDN is in the prime position to help with this. Worst case, some people don't want the file in their archive (even though it may not work in newer emulators without it) ... put it as a separate link right next to <download patch>.

You can't rely on RHDN to enforce your desired standards without winning over community support. And I'd have to believe it was an effective use of site resources and my time.

Sorry, I realize it's your site and you're happy with the status quo. But this can be made near painless, and I'm sure you can appreciate the benefits of fool-proof patching, 100% perfect hardware memory mapping, etc.

I'm happy with whatever the ROM hacking community of people want to do and adopt. RHDN exists independently from any single patch format, emulator, or standard. Thus far, I don't believe any special privileges or bias have intentionally been given to any of the three. I like you, you're a nice guy and all, and you have an emulator, but that's still not good enough for special RHDN treatment.

I'm not trying to "force (my) format down everyone's throats" or push some sort of agenda. I'm discussing and compromising this openly with everyone who wants to chime in. The current formats suck and I want to improve them. We need everybody's help to pull it off.

Then you really should make the discussion known to more than the limited few who know about it at present. It certainly has seemed like an agenda which has rubbed me the wrong way with harsh stance on telling people how it's going to be, what they're going to use, and how they're going to do it with little input from them. You've already mentioned you are going to do what you want to do with BSNES regardless. That certainly seems like an agenda to me. I don't really want any part of such a movement. Actually it's a little scary. With ZSNES and BSNES and perhaps even SNES9x under your (you and Nach mainly) control on this issue, you guys seem to be wielding a big stick. You want everybody's help, so get the discussion out to everybody, consider the feedback, and act accordingly in everybody's best interest. The way the proceedings are going so far are not in that direction from my point of view.

Should I add a checkbox option in the GUI to allow VRAM writes during vblank too, then?

We're talking less than 10 patches (if not 5, I don't have the list) there, nearly all are effected here. I would say those are different situations. A few vs. nearly all.

I already ignore IPS patches, and that isn't going to change. Sure, it may affect my popularity, but it's not a contest :/

I was just mentioning it because you have previously expressed the desire to keep the audience you currently have and have re-evaluated some of your positions in order to achieve that goal.

[Rashidi]

2.Check the licence/readme to see if a header is needed or not, and precicely which version the patch is intended for

that bring the old memories back, before the advent of NSRT, i must check wether the patch was intended on INTERLEAVED binary roms or not..., before i can finaly concluded that i got the mismatched patch/roms image.

bsnes doesn't support the interlaved roms, right? (never check, due to low-spec computer i have)

[byuu]

bsnes doesn't support the interlaved roms, right?

No, it does not.

It's also another step for end users to get hung up on.

After seeing a guy download the MOTHER 3 patcher, then try loading it as a ROM in bsnes, and complaining that he's just getting a black screen ... you're right. There's always going to be people who can't figure these things out.

If people can get SRAM or IPS soft-patching, then they can get this working if handled right. Not going to give up because some people are terminally retarded.

You want the discussion to be open, but this is kind of a closed discussion being available only here to limited people and this topic which anyone not interested in BSNES wouldn't even check.

Where would you like me to post at?

You've already mentioned you are going to do what you want to do with BSNES regardless. That certainly seems like an agenda to me.

It was never a gaming emulator to begin with; it's my emulator; and the userbase is much too small to promote any kind of social change (see: UPS support.)

I don't really want any part of such a movement. Actually it's a little scary. With ZSNES and BSNES and perhaps even SNES9x under your (you and Nach mainly) control on this issue, you guys seem to be wielding a big stick.

Again, neither I nor bsnes have any influence.

It scares you how much reach the collaborative ZSNES+Snes9X have? Then start your own SNES emulator and rally for us keeping the IE6 quirks-mode HTML transitional of SNES ROMs around forever.

Agenda this, force that. It's always fascinating how outside people always seem to think hobbyist developers somehow owe them something. Again, I'm doing everything I can to get input from everyone here. Input is obviously valued more from those who understand the problem, of course. But we can consider all approaches.

What would you propose? Should we leave everything as-is? If not, should we support two complicated methods of doing everything? If so, how is that any better for future emulator authors?

I was just mentioning it because you have previously expressed the desire to keep the audience you currently have and have re-evaluated some of your positions in order to achieve that goal.

It's important, definitely. I aim to keep system requirements low enough to run smoothly on current-day top-of-the-line consumer level processors.

But I'm sure the people willing to put up with no savestates and low speed to get that extra little bit of precision won't mind running a "genpcbandups" program inside of their fan translation ROM folder just one time, if it means having an even purer emulator that guarantees 100% correct ROM mappings for all commercially released games and fail-proof patching.

Again, we'll have to see what the future holds. Removing header detection wouldn't be happening anytime in the next few years, at least.

[tetsuo55]

I agree that we need more input from the people who:
-Actually dump/document roms
-Rom hackers/Translators

I think(and hope) Byuu and Nach are basing their ideas on:
-Clean multi-verified roms(no headers, not interleaved or whatever)

This also means that patches will have to be converted to support these clean roms(which most do not).
The result of this is:
-The target of the patch can be clearly identified with something like a sha1 hash, as there will only be one verfied rom sha1hash per unique game(revision). A smart patch format will prevent mispatches.
-The .pcb file can be named the same as the target rom name-version, same goes for the patch file, maybe the pcb file should contain the sha1 hash for the rom too.

There are programs to scan a romset and its add-on files to check their validity, we just have to add the information to a dat file.

We would only have to choose to support one file-naming system as there are several in existence at the moment.


Ideally we would store everything related to the rom with it in its zip file.
The Mame/Mess community has already taken the step to add something like the pcb file to the roms(in their case an .xml file)

[Nach]

You want everybody's help, so get the discussion out to everybody, consider the feedback, and act accordingly in everybody's best interest. The way the proceedings are going so far are not in that direction from my point of view.

I don't want everyone's help - yet anyway.

I think before bothering anybody to do anything and ask for help, a spec should be solidified, along with working test cases to get the ball rolling with.

byuu seems to want to do everything his way (our way in the scheme of things), and doesn't wait for any dust to settle or anyone to be ready, which is a bit of an issue for a team project.

He released his UPS patcher before I was ready to release mine for example, along with all the side tools I made or have planned. Or before I put out new ZSNES and Snes9x releases with support for it.

It is an issue for a community to do anything when the developers of them are presenting them a disjointed front (always an issue when children are told two opposite stories by each of their parents).

With byuu, he's always been a fast moving target with bsnes, which is a good thing in itself. But it's an issue where things need to change in the community. There'd be a lot less griping about our UPS format if it was rolled out to the community when everything was ready, as opposed to only byuu being ready.

I personally have a lot of projects to deal with including:
ZSNES
Snes9x
NSRT
GZip library
Zip library
JMA library
IPS library
UPS library
Hash library
Among a dozen other things completely unrelated to our little SNES community. Aside from ZSNES, Snes9x, and some of my completely unrelated projects, I get no help at all most of the time on a lot of these projects, so I take turns working on them, or work on one of them if someone else is willing to work on them at the same time with me.

If we take UPS as an example, if byuu and I sat down and decided a month or two in advance on a particular UPS rollout date, I would've worked on UPS at that time as opposed to other projects, and you wouldn't be seeing the current situation.

Unfortunately, byuu gave me little notice when he wanted to rollout, and I basically had 2 days notice, which wasn't enough time given all the other stuff on my plate, and projects I'm juggling. I'm sorry that I couldn't keep up with byuu's time table.

If you recall back to when I rolled out the initial version of JMA, I had support in ZSNES and Snes9x for it a good month or two before I released NSRT with JMA, and had SNEeSe updated with JMA support about a week after. There, no one had given me much flack about what to do with JMA files since the newest emulators were all ready. Of course, back then, I decided to hold off releasing NSRT with JMA till I gave the community enough time to have gotten the new emulators.

I'm hoping this time around with our PCB format, that byuu will allow almost everything to be in place, before bothering the rest of the community to have to deal with some bold new initiative.


Regarding public discussion of every last detail, I don't think it's warranted for at the moment. It only scares people. You're being asked to endorse something which you can't really see how it's going to play out, or what side support is going to be in place when it's ready, or current tangible benefits and compelling reasons to do anything.

Also, threads like this take time away from us actually developing what we plan to develop.

We're trying to involve those now that can help the system in general right now, which means byuu, grinvader, and myself discussing some of the foundation principals of the setup, and only asking those who know enough about SNES mapping to contribute their thoughts on whether any of our current drafts are robust enough or not. We (at least I) don't want everyone to join in with all their fear and skepticism without anything to actually judge.

After we're done with the current stage, we'll then involve the people related to the next stage. When we feel it's time where dumpers need to weigh in on the next stage of the project, we'll ask them what methods they prefer, and show them what current structure is being dealt with. So on and so forth which each group (bridge) as we come to it. I don't think we need to be asking the final people now how to attach the roof of the 12th floor when we only have the first floor slowly going up.

Rest assured that I'm not going to in 6 months time (or whenever it's really ready) to be shoving something down anyone's throat which seems dumb and unwieldy, and something the masses are going to dislike so much they'll never use it. Although we're developers, we're end users too, we know what makes playing existing games more annoying or not. I personally have always tried to focus on giving users a set of utilities to upgrade to a new situation cleanly, conveniently, and uniformly without forcing anyone into it. If a community doesn't like what they're presented with, they'll make it known. If I appeared tomorrow with a dumb ZSNES which annoyed absolutely everybody out there, it'd be forked in an instant. Or every website would be distributing "Fixed ZSNES" patched to work like it always did. I'd have no choice but to make this new "Fixed ZSNES" the new main ZSNES code base (look back on history, that's exactly what happened with GCC).

The big issue right now is that TOO MUCH is being discussed in the open, and it's not healthy towards moving in the right direction.

byuu:
Sorry if I offended you at all by this post. I'm really fast at programming, but not fast at juggling all my different projects. I am sorry that I have a bit too many to keep up with everything you do, or would like to do.

[tetsuo55]

The big issue right now is that TOO MUCH is being discussed in the open, and it's not healthy towards moving in the right direction.

For some reason i agree with you on this.

[Nightcrawler]

Alright, well clearly your methods and process for coming up with standards that could affect everyone differ from mine. I'd see what the people it affects most have to say, hear potential alternative ideas, and take a more informed path to balance the interests of all parties affected. Working from there, you can create something that already has some support, is more likely to be adopted, and more likely to receive help on. You can't do that behind closed doors.

The big issue right now is that TOO MUCH is being discussed in the open, and it's not healthy towards moving in the right direction.

It's not healthy toward moving in your direction. It is very healthy in moving in a direction to determine what's best for all involved. You'd rather create your own bold new initiative, then see how people react after the fact.

Don't waste any more time on this thread and go develop what 'we plan to develop'. Part of developing a standard is talking about it, so I don't see how that is a waste of time. I thought you were interested in developing a collaborative solution balancing the interests of all parties, but I appear to have been mistaken. You've got what you want to do, so go do it. I was genuinely interested in seeing the best possible solution to all come to light. Don't get upset at me for using the word agenda when your actions disregard interests outside your circle.

[Verdauga Greeneyes]

I don't think your approaches differ all that much to be honest. The fact is that we still have nothing concrete on how to actually store this PCB data, just a general idea of what we want out of it. Once that has been more defined you can approach the people it affects with real examples and they can give feedback that consists of more than 'but what if I wanted to do this?' I think decisions on how to -distribute- the PCB data is still a ways down the pipeline.

[ZH/Franky]

It's not healthy toward moving in your direction. It is very healthy in moving in a direction to determine what's best for all involved. You'd rather create your own bold new initiative, then see how people react after the fact.

Don't waste any more time on this thread and go develop what 'we plan to develop'. Part of developing a standard is talking about it, so I don't see how that is a waste of time. I thought you were interested in developing a collaborative solution balancing the interests of all parties, but I appear to have been mistaken. You've got what you want to do, so go do it. I was genuinely interested in seeing the best possible solution to all come to light. Don't get upset at me for using the word agenda when your actions disregard interests outside your circle.

Answer this one simple question: who owns bsnes? From what I understand, that's what he designed UPS for initially.

[tetsuo55]

There are several ways to start and finish a project.

One way would be to make a basic framework within the goals and limits of the creator. This is then presented as a working proof-of-concept

The creator would then be open to any and all feedback that would be discussed.

A second way is creating the concept with a cloud of people on the internet(this is what we are doing right now).