nesdev.org

In [url=http://forums.nesdev.com/viewtopic.php?p=101718#p101718]this post[/url], byuu wrote:Lots of great ideas, anyone here want to test them out on hardware and see? :D

I would, except there was this emulator that demanded I remove the SMC header from all of my images, so they no longer work on my SWC DX/32.

Oh no, how stupid! I hope that you and everyone else will loudly protest that change everywhere. Maybe the developer will see the logic in supporting the dozens of incompatible floppy disk copiers from the early '90s at the expense of file size/checksum and patching verifications.

If only it were possible to write a two-line batch script to copy to disk and then add a header with uCON/inSNESt.

Although it's not as complicated as programming SNES homebrew and setting up/managing online networks, it's probably above our abilities, sadly.

Can anyone here help out me and koitsu with something like that? I can start a Kickstarter project for it if that helps.

I'm agreeing with byuu here. If you want to add a header that a particular copier needs, add it just before you put the game onto the copier. For example, the ROM builder for the PocketNES emulator expands each 16-byte iNES header into a 64-byte PocketNES header.

Losing the sarcasm ...

I get that many SNES coders are still rocking their copiers. I'm not saying you have to get rid of them. But you have to realize you're a minority. I have an old Win9x box that I use for older Falcom games. When the RAM died, I had to go out of my way to find SDRAM for it. My GDSF7 has a parallel port, my comm cable uses serial, and yet my modern computers don't have serial/parallel ports, or even floppy connectors. If you want to fight change for 20+ years, expect to be inconvenienced. Don't expect the right to inconvenience everyone else for your benefit.

Most people now have flash carts for the SNES, where you can put 100% of your games on a single SD stick and load them in two seconds. And they're mostly cheaper than copiers were, and far more readily available and still made. And smaller, and don't need another power brick, and they don't need copier headers because the designers weren't lazy, and some can even run DSP-{1-4}, ST010, Cx4, etc.

Copier headers are hurting -everyone-. Many ROM hacking tools only work with headers (Lunar Magic), many tools work only without headers (mosaic), some emulators auto-remove copier headers (Geiger's Snes9X debugger) or don't support loading them at all (bsnes) or try and parse them and will fail to play the game if they are malformed (Super Sleuth), some tools auto-add copier headers (Lunar Magic), many ROM hackers make IPS patches against headered ROMs, and many do not. Every patch release on RHDN deals with patching errors due to this. End users don't know how to add and remove these. Sets like GoodSNES are inconsistent where half the ROMs have headers, and half do not. Groups like No-Intro and Zapatabase remove headers entirey. Groups like NSRT subvert the copier header by creating ZSNES-specific emulator headers. The images distributed have copier headers in 20+ differing and incompatible formats. Later SNES copiers support 5+ formats, but never all of them. Many, many, many copiers won't work with just a copier header, anyway: they expect interleaved images. No emulator supports widescale interleaving of image data. Floppy disks are limited to 1.44MB, so you can't play 2MB games without doing work on your end anyway. You can't rely on the CRC32 of a file inside a ZIP to identify a game, file scanning tools can't detect duplicates because you might have the same game in two copier formats, sha256sum/md5sum/etc tools are useless. Everything has to be aware of copier headers. Emulators have to do odd math to try and detect internal headers now not just at $7fc0, $ffc0, $40ffc0; but also at $81c0, $101c0, $4101c0. You can't even do filesize&0x7fff==512 due to older homebrew that doesn't pad the ROMs out. ROM hackers that use hex editing tools have to manually add and subtract 512 in their heads or with a calculator constantly. And on and on ... I have had to deal with ALL of this. Literally.

I've even made this easy. A simple tool will purge all headers in two clicks. My cross assembler easily supports an ifdef statement to include a copier header. That's how I used to test my own stuff while still running it in my emulator. bass -DHEADER -o a:/test.smc test.asm && bass -o test.sfc test.asm. Now all you need is a batch file to drag your games onto to play them. The same work you'd have to do -anyway- for the 80% of your games that are >=12mbit and/or HiROM.

I don't know why so many highly intelligent individuals are so hellbent against any change at all. I'm not out to be the Grinch who Stole Copier Headers. I'm really trying to help make it easier for everyone, but I have to constantly be fought tooth and nail. I wish it were just the usual nobodies with no experience or knowledge complaining. That wouldn't bother me nearly as much. But you should know all of the above very well. Having such highly regarded individuals as yourself oppose this is exactly why we can't get the traction to make real progress.

I took a jab at you 70% serious / 30% in jest because (IMO) you deserved it. You're too busy to test something on real hardware, but you're not too busy to kill two birds with one stone.

I'm trying to keep this as terse as possible, but the more I write more I realise it has to be verbose (I can't cover all the angles in a single paragraph) and I don't want to get verbose in this thread because it's unrelated to the DMA register topic.

We can talk about it in another thread if one is started. But if you start that thread, I strongly suggest you go back and read what you wrote me in PM circa February 2011 then compare it to your words + actions of today. TL;DR -- it's very hard for me to believe someone who talks one way but walks another, and that's coming from a guy (meaning me) who has a well-established history of being an absolute jerk.

I could care less about BSNES not loading SMC, SWC, FIG, etc files with copier headers or interleaved ROMs. But it is annoying that atleast last I heard it had dropped support for loading Zipped ROM files. I forget whatever reason there was for dropping support but it's annoying to waste space like that.

Dealing with Copier formats and headers couldn't be easier with UCON64 around.

We can talk about it in another thread if one is started.

If you or tepples want to split this thread, that's fine.

I am genuinely interested in hearing your arguments about why copier headers should be supported, without bringing in "because that's the way things used to be done."

You're too busy to test something on real hardware, but you're not too busy to kill two birds with one stone.

The IRQ/IO->read cycle finding took me two weeks of full-time work to fully understand. The HDMA->MDR update issue took me another two weeks. The DMA/HDMA<>CPU bus sync took three or four weeks. Figuring out this DMA crash is easily a 2+ week job. It's easy when you know the answer, but to find the answer you have to test -every possibility ever-. Writing the iSNS post took me ten minutes. Which is probably the same amount of time Marat put into iNES.

I strongly suggest you go back and read what you wrote me in PM circa February 2011 then compare it to your words + actions of today

I really dislike the insinuation that people can't change their positions over time without it being a problem. Reflection and admitting when one is wrong is a sign of character development. But that said, let's take a look ...

02-2011:
"I have basically begged people for several years to take over the bsnes GUI. I definitely want someone to make a bsnes GUI that supports all the copier extensions and interleave formats and nonsense in the world. Hell, I tried to do it myself, bsnes v073 is the ONLY SNES emulator to load multi-archive 7-zip ROMs."
"As I said, it is a philosophical contradiction to me to say "I hate SMC and copier headers" while implicitly endorsing them by supporting it. I don't want that shit in my codebase."
"The only proper way to do it is to score ${ 7fc0, 81c0, ffc0, 101c0, 40ffc0, 4101c0 } and pick the most likely candidate."
"Your code would not boot your own iNFINITY demo ROM, nor a bunch of older PD ROMs. I believe Cowering manually padded many of them for compatibility with ZSNES."

10-2012:
http://board.byuu.org/viewtopic.php?p=76050#p76050
"The thing is, I don't care if it's modified to load ZIP files, remove copier headers, deal with SMC/SWC/FIG/BIN, etc. I just don't want to write and maintain the code in my codebase."
"Emulators have to do odd math to try and detect internal headers now not just at $7fc0, $ffc0, $40ffc0; but also at $81c0, $101c0, $4101c0"
"You can't even do filesize&0x7fff==512 due to older homebrew that doesn't pad the ROMs out."

But it is annoying that atleast last I heard it had dropped support for loading Zipped ROM files. I forget whatever reason there was for dropping support but it's annoying to waste space like that.

To reiterate, my issues were that it required a 300+KB dependency on zlib, and infighting with Debian upstream over using system zlib on Linux despite Windows not having a system zlib, having to accept zlib's license, as forgiving as it is, and with losing the association between extension=system, meaning you'd get false-positives so that every .zip shows up as a possible game to load, even though few ZIPs are actually SNES games.

You may be in luck there. I wrote a ZIP implementation based on miniZIP that's <10KB in size. It's just a matter of whether or not I can parse the ZIP headers, find the SFC images inside, and show them in a file browser quickly enough without lagging the emulator out.

The harder part will be finding ZIP files with .sfc extensions inside and no copier headers. It's a done-deal for No-Intro and Zapatabase sets, at least. NSRT pushes JMA, and GoodSNES pushes SMC+cointoss copier headers.

I do want to point out that there are, at best, 4000 SNES games, including all revisions and all countries. That means you are talking about a space difference of ~1GB, which costs approximately 5 cents/mechanical, and 50 cents/SSD. Modern file systems like NTFS can natively compress folders too, in a way that's transparent to the application.

The only advantage I see to supporting ZIP is so that people don't have to extract their illegally downloaded ROMs (and noting that some browsers force decompress your archives, like Safari.)

I remember some good arguments against supporting .zip archives:

• HDD space difference is small compared to sizes of current drives and media people store.
• It's a drain for a developer who doesn't care about archives.
• The OS should do this, not every program.

My argument for supporting (skipping) ROM headers is that it makes the program handle a very common situation that many people have (having lots of headered ROMs) with zero effort, and the implementation is only a few lines of code (I'm only referring to merely skipping them, not things like interleaving etc.). This is the bread-and-butter of what programs do: take on slight costs that benefit the user many times over and eliminate wasting time on routine tasks.

There's a larger picture as well, that of each user's machine being a unique environment within a unique process they use for all the activities they do. With ROMs, they might use lots of tools that need headers, and prefer to use headered ROMs for this purpose. Supporting the user's choice makes sense to me in this case.

As for encouraging adoption of headerless ROMs, I'd prefer approaches that give users new options that are preferable to headered ROMs, rather than leaving support limited where it could be added trivially.

I guess you tried the approach of having someone else manage the GUI, and add all these things that people want but that don't interest you in the least. I don't know the specifics and the reasons for the way things are done. I take it nobody took you up on making a front-end that satisfies more people. I find this the most compelling argument that there's not much to come back with: nobody wanted to help with the GUI and I personally don't care for headered ROMs, so it doesn't support it.

My argument for supporting (skipping) ROM headers is that it makes the program handle a very common situation that many people have (having lots of headered ROMs) with zero effort

True. My arguments against it were above, but most poignantly:
* the entire ROM hacking scene won't move on from IPS. 50% of patching fails and requires users to add or remove copier headers and try again.
* some tools force you to have headers, some tools force you to not have headers, some forcefully add them, some forcefully remove them.
* it's not just two lines of code if you want to support unpadded homebrew ROMs, soft-patching, and file hash verifications.

Yes, killing off copier headers is painful. But we -can- do it, and everyone will be better off after it's done. We killed IE6, people said that couldn't be done too.
We just need pessimistic leaders in the community to stop acting like it's their Second Amendment right to bear copier headers.
Honestly, I know this sounds arrogant, but it really feels like there are many people who are against things solely because I'm involved.

I refuse to believe we can't make progress. No-Intro dropped SMC and copier headers, and they're the predominant set. All we need is Snes9X to seal the deal.

I've gone out of my way to help. I wrote a launcher/DLL thread injector that forcefully modifies the closed-source Lunar Magic to support headerless ROMs, since its author refuses to. And then jumped through hoops to get around his inane license rules. I even wrote it generically enough that it'll work on any Windows application.

This is the bread-and-butter of what programs do: take on slight costs that benefit the user many times over and eliminate wasting time on routine tasks.

That's true, and look at Microsoft. They can't abandon Win32 and its 50,000 undocumented "bugs" because old programs rely on it. Wine is a hopeless project that has been trying to replicate those quirks for decades. Do we want our emulation scenes to be supporting copiers 30 years after the last physical copier has died?

I take it nobody took you up on making a front-end that satisfies more people.

Correct. SSNES/RetroArch was almost there, but then went on to support as many emulators as possible, puts more focus on Snes9X these days, and won't support the formats I am proposing at all. In fact, they've even extended my shader format so that half of them no longer with with my emulator. The features are nice, but extending a spec that isn't yours is not.

nobody wanted to help with the GUI and I personally don't care for headered ROMs, so it doesn't support it.

Pretty much. I've said time and time again, it's a personal project. The only reason I keep it going is because I can maintain interest. The only way I can maintain interest is to be true to myself and what I want to see. I'm not looking for popularity (although it's of course nice for furthering goals), integrity matters more. Yet at the same time, I recognize that I can't force everyone to do what I'd like them to. So I'm just going to keep espousing my views when provoked, keep doing what I want with my codebase, and let people do what they want with my open source code.

One use I can see for supporting ZIP files would be what I did with Project MD, which was distribute both the binary and the source code in the same ZIP. These are the side effects of such a move:

• If you just want to play the game in an emulator, make the emulator open the ZIP.
• If you want to mess with the source code, you can extract the ZIP file.
• If you distribute the ZIP, you're automatically complying with its license, without even needing to know about it (which can matter if somebody decides to upload it somewhere without caring about it, then at least downloaders won't have to worry about it).

Of course, given most homebrewers only want to release binaries, maybe it isn't worth it... And it'd be nice if operating systems allowed access to archive files as if they were directories - and by this I don't mean in the shell, but rather the file I/O functions themselves (including the C standard library), then this wouldn't be an issue at all.

From the romhacker point of view, I really prefer the header not to be supported and I really don't care about ZIP support. Why?

1) When reverse-engineering the code in a ROM, I prefer the ASM code to be referred to address $0 in the file, not $200 or whatever: easy to make calculations without calculators (even for LoROM, I did all calculation in my head).

2) Headers are useless when running on debuggers or emulators so, why preserving them till the end of time? Evolving is inherent to mankind, and when we talk about emulation, it makes sense too.

3) ZIP files are hard to handle when it comes to romhacking: if the ZIP contains several versions of the same code, you may choose the wrong ROM inside it when you open it from time to time. It's pretty more secure to unzip the required ROM and keep it as the "master source code".

4) I don't use bsnes for gaming, I use it for accuracy issues. My laptop even can't run bsnes faster than 35fps, so it's impossible to me playing games. But when it comes to test hombrew code, it is the best emulator, just like running the code on the SNES. From my point of view, bsnes is aimed to developers like me, and I don't need ZIP files or headers or anything else but 100% accuracy.

I think byuu's work deserve our admiration since it will be a reference in the future: whenever somebody needs to know how the SNES worked internally, he will check bsnes source code to get the answer.

The below is my viewpoint, and it is shared by multiple peers of mine who have equal "stance" or "seniority" (as if that somehow means something -- it damn well shouldn't!) in the community.

The situation is this:

The author of a SNES emulator doesn't like headers which are intended for copiers (ex. SMC, FIG, split-SMC files, etc.). I'm going to reiterate this for folks with a slight rephrase: one man who happens to be an emulator author doesn't like them. This one individual has some kind of personal vendetta against them, even taking jabs at them, as well as other emulator authors in the process (hence my two-birds-one-stone comment).

The technical reasons are nil -- there is absolutely no technical reason that has been presented so far that justifies this stance. The headers can technically (with software) can be ignored. The files do not need to be changed for the sake of one man's crusade. This therefore implies that a person who has a copier (SWC DX, etc.) would need to keep two copies of their ROM set around -- one with headers, and one without -- all because of one person.

Since there is no technical justification or merit to this, we can only conclude that the reasons are personal. This conclusion is also supported by facts (keep reading).

The author himself has stated repeatedly that he finds the headers to be difficult to deal with from a software perspective. Again: this is not a technical limitation, but rather a personal one -- the author is annoyed by them, is annoyed by having to deal with them, doesn't like writing the code to deal with them (keep reading, these are not assumptions, they are accurate statements). The reasons behind why he feels that way don't matter either -- it's his opinion, and he has a right to it (and I fully support his right to have an opinion).

These reasons are backed by his own words, in which every single statement made to justify the removal of these headers involves the use of the word I. As in "me", as in "it affects me", as in "it upsets me". Him. Just him. So we have further proof that this is purely just one person's opinion -- and again, having that opinion is just fine.

It's not the opinion that is offensive -- it is the fact that the opinion turns into a crusade. A mission. A witch-hunt of sorts. The opinion becomes something forced upon other people, almost in a political or lobbyist fashion.

Phrased less eloquently: "To use my emulator you must modify all of the existing files you have. I do not care if they are 30 years old and hold nostalgia value. I do not care if you own hardware copiers that rely on these headers. I do not care if from a technical standpoint these headers can be ignored, because writing the code that deals with that bothers me. You will adhere to what my requirements are, even if those requirements (changing all your existing files) will impact other programs (emulators, etc.) or impact your ability to enjoy these on a real console (sending SMC files to a SWC/DX, for example)."

Historically the standpoint has been "it's my emulator and I will do what I want" -- which is fine. The problem becomes when what one person wants mandates everyone else comply with what that person wants as well, especially when there is absolutely no technical justification for it (if you've forgotten this fact, re-read my post from the beginning).

So from this we can conclude that the author does not like something, therefore he feels everyone else must comply with his lifestyle/choices/issues/demands. Rather than focus on the negative, let's ask the question: what does the individual like?

The author appears to enjoy one thing: writing a decent SNES/SFC emulator. He likes working on the emulation part of the console, he likes getting his hands dirty with regards to that aspect. He does not enjoy dealing with file formats. He enjoys emulation. And that is something he does amazingly well (better than most others out there, hands down, no argument).

Thus we can conclude that the author should be doing that: focusing on the emulation part. Not file formats. Not going on religious anti-header tirades. Not arguing or insulting other emulator authors. Not forcing people to adhere to his standards / his opinions / his likes and dislikes, thus modifying their entire ROM sets to comply with his views.

The author has even admitted privately to me (it's excluded from the quote set above) that his libsnes library doesn't even require a file handle nor does it interface with the filesystem at all -- you just hand it pointers to linear pieces of memory and it takes care of the rest. So on a technical level he has already begun (and continues to work on) the part that he enjoys and does not frustrate him. This also does not require the rest of the world adhere to his beliefs (i.e. changing all of their ROMs to remove headers).

The author has also been adamant in admitting that the "front-end" part (GUI, file format handling, etc.) he would much rather leave in the hands of someone else so he can focus just on what makes him happy. This statement in itself should make any intelligent reader wonder why the author is on a crusade at all -- there's nothing forcing him to work on the "front-end" part especially when it makes him so miserable. (This is also justified by the removal of many GUI and visualisation options in bsnes, which is something that peers of mine have complained about for months (years?) -- specifically when those features were removed "just because they were annoying to deal with").

The answer and solution then becomes quite obvious and simple:

1. The author should stop the tirade/crusade and stop forcing people to adhere to his demands/standards/opinions while making two-faced comments (quote: "I'm really trying to help make it easier for everyone"),
2. The author should focus on his emulation library and emulation bits, as that makes him happy, and it's something he does amazingly well,
3. The author should leave the "file parsing" bits (for lack of better term) and "front-end" (GUI, etc.) to someone who isn't bothered so much by the complexities of dealing with them, supporting multiple file formats, etc..

Leave the front-end to someone else. Can't find someone else? Doesn't matter -- not your problem (honest!). Focus on what makes you happy and stop forcing everyone (through your emulator) to comply with your beliefs.

I won't be responding to this thread past this point. I've covered every single base and have stated the facts as well as interwoven my own opinions. But just in case it's not clear: there's no technical merit behind the removal of the headers (requiring everyone to modify their files). It is purely personal. And because it's personal, byuu should focus on his library and leave the "messy stuff" that he doesn't like (which is his right/opinion and that's fine!) to someone else.

Why are you acting like this is only byuu's personal stance? byuu has little to do with the fact that headers have fallen out of favor (Hardly anybody listens to him anyway ). I hated headers back in 1996, before byuu was on anybodies radar. I didn't use a copier then and don't use one now. Back then headers were an annoyance for us to work around and only served a purpose for the elite that could afford a copier (Being a poor teenager back then prevented me from getting one). Let me use your own words against you... There is NO technical reason that currently justifies the use of headers from an emulation, rom hacking/translation or preservationists stand point. byuu challenged you to state one and you failed to do so and proceeded to make a long drawn out argument about how it is byuu's personal crusade against headers.

Most of the current ROM preservation community doesn't like headers. People want purity in their ROMS and this has existed BB (Before byuu), evident by cowerings creation of the (!) years ago to signify a "pure" ROM. I obviously appreciate the work of the people back then that used copiers, but I see no reason to continue passing around ROM images with headers on them. I doubt the old timers with copiers are still regularly using them anyways. Everyone that I know with a copier tells me that it is in a closet somewhere collecting dust.

It sounds like you are taking this personally... The community has evolved and you are being left behind. Are you basically against evolution/change and want things to remain as they were back in the 90s for no logical reason (other than you might use your copier sometime in the future if you have time to dig it out of the closet )?

P.S. Nobody is forcing you to update your emulator, just continue to use an older emulator with your aging ROM set .

As a developer of both homebrew software and ROM-handling tools (the Forbidden Four and Action 53 builders) for a closely related console, let me add my two bells:

byuu wrote:it's not just two lines of code if you want to support unpadded homebrew ROMs, soft-patching, and file hash verifications.

Another thing I would be in favor of requiring is that homebrew be padded to the next 32 KiB (for LoROM) or the next 64 KiB (for HiROM), just as the iNES format requires it to be padded to the next 16 KiB.

byuu wrote:look at Microsoft. They can't abandon Win32 and its 50,000 undocumented "bugs" because old programs rely on it.

Microsoft has used the introduction of the Surface tablet to deprecate Win32 in favor of WinRT and at the same time grab its $99/yr + 30% pound of flesh from anybody who distributes an application compatible with Surface.

byuu wrote:The features are nice, but extending a spec that isn't yours is not.

Netscape extended a spec that wasn't its (tables, forms, and JavaScript added to HTML), and web pages became interactive. Microsoft extended it further (XMLHttpRequest), and web pages became applications.

Sik wrote:If you distribute the ZIP, you're automatically complying with its license, without even needing to know about it (which can matter if somebody decides to upload it somewhere without caring about it, then at least downloaders won't have to worry about it).

You make a good point. What's a better way to encourage end users to comply with a copyleft license?

koitsu wrote:The headers can technically (with software) can be ignored.

At a fairly substantial cost in time in the case of running on a modern CF- or SD-based copier that understands the internal header, such as the SNES PowerPak: the copier has to load the first 65536+512 bytes and check for the internal header in four places as opposed to two.

So perhaps the best compromise, given that byuu doesn't want to deal with headers or front-ends, is to give the front-end the job of formatting ROMs correctly for bsnes: copy a ROM with a header to the temporary folder without a header before running it.

I want to be clear. I am not 100% opposed to copier headers. I get the pragmatic approach of not breaking things that already work.

But I am weighing their good versus their harm, and believe it's in our best interest to remove them from the general circulation.

one man who happens to be an emulator author doesn't like them

Why do you assume it's only me? Just in this very thread: tepples, magno, Mottzilla, and HJRodrigo don't seem to like or care about them.

even taking jabs at them, as well as other emulator authors

I wasn't aware Marat Fayzullin invented SNES copier headers.

there is absolutely no technical reason that has been presented so far that justifies this stance

I listed over a dozen reasons. Many of which were technical.

"Copier headers are hurting -everyone-. Many ROM hacking tools only work with headers (Lunar Magic), many tools work only without headers (mosaic), some emulators auto-remove copier headers (Geiger's Snes9X debugger) or don't support loading them at all (bsnes) or try and parse them and will fail to play the game if they are malformed (Super Sleuth), some tools auto-add copier headers (Lunar Magic), many ROM hackers make IPS patches against headered ROMs, and many do not. Every patch release on RHDN deals with patching errors due to this. End users don't know how to add and remove these. Sets like GoodSNES are inconsistent where half the ROMs have headers, and half do not. Groups like No-Intro and Zapatabase remove headers entirey. Groups like NSRT subvert the copier header by creating ZSNES-specific emulator headers. The images distributed have copier headers in 20+ differing and incompatible formats. Later SNES copiers support 5+ formats, but never all of them. Many, many, many copiers won't work with just a copier header, anyway: they expect interleaved images. No emulator supports widescale interleaving of image data. Floppy disks are limited to 1.44MB, so you can't play 2MB games without doing work on your end anyway. You can't rely on the CRC32 of a file inside a ZIP to identify a game, file scanning tools can't detect duplicates because you might have the same game in two copier formats, sha256sum/md5sum/etc tools are useless. Everything has to be aware of copier headers. Emulators have to do odd math to try and detect internal headers now not just at $7fc0, $ffc0, $40ffc0; but also at $81c0, $101c0, $4101c0. You can't even do filesize&0x7fff==512 due to older homebrew that doesn't pad the ROMs out. ROM hackers that use hex editing tools have to manually add and subtract 512 in their heads or with a calculator constantly. And on and on ... I have had to deal with ALL of this. Literally."

You have not refuted a single statement. This is not how you debate someone.

The headers can technically (with software) can be ignored

So if I am applying an IPS patch to a ROM: do I remove the header and then patch; or do I patch and then remove the header?

If the ROM is not padded to a multiple of 32KB, how do I know if there is a header or not?

This therefore implies that a person who has a copier (SWC DX, etc.) would need to keep two copies of their ROM set around

As you already have to do for games >=12mbit that need to be split onto several floppies (unless you have a working SPP parallel port), and for games in HiROM format that need to be interleaved (which no emulator supports.)

Of course, you don't have to do this for any games. You just have to make a simple batch file to transfer games to your copier with the same amount of work it'd take to copy an unmodified file.

it is the fact that the opinion turns into a crusade. A mission. A witch-hunt of sorts. The opinion becomes something forced upon other people, almost in a political or lobbyist fashion.

What gun am I holding to peoples heads, demanding they use my emulator?

I do not care if they are 30 years old and hold nostalgia value

Is that a serious statement? Are you nostalgic for 512 bytes of garbage at the top of your files?

Should I emulate the layering issues that caused trees to poke through text boxes and sprites to disappear underwater? Should I emulate the wind sounding like a seal being clubbed to death? You know, for nostalgia to the good old days of SNES emulation?

I do not care if you own hardware copiers that rely on these headers.

Cost/benefit analysis requires one to take in account how many people use SNES images (100%) versus how many use oldschool copiers (LESS THAN 1%.) Seriously, in all my years, I've met about 30 people with SNES copiers. My last software release has had over 40,000 downloads. And I am the underdog.

Should they all deal with patching issues to appease copier users?

Even the few I've known with copier headers are moving on to flash carts. They are infinitely superior. They can still be purchased new, they are usually cheaper, they can hold the entire game library, they don't require copier headers nor interleaving, and they can load games almost instantly.

I do not care if from a technical standpoint these headers can be ignored

This is untrue. Patching and unpadded ROMs.

those requirements (changing all your existing files) will impact other programs (emulators, etc.)

Every public emulator supports headerless ROMs. Geiger's Snes9X Debugger requires it.

I wrote a Win32 API hooking library to allow any tools that require headers to work without them. Without having to make hidden copies of files. It hooks right into the file read/size commands to offset them by 512. I even made a bundle just for the most popular tool, Lunar Magic.

The problem becomes when what one person wants mandates everyone else comply with what that person wants as well

The 02-2011 and 10-2012 quotes show this is untrue. I am fine with people adding copier header support to my emulator if they want to.

But I'm going to share my opinion on why they shouldn't, and hope I can convince more people. That is what human beings do: they advocate their beliefs.

especially when there is absolutely no technical justification for it (if you've forgotten this fact, re-read my post from the beginning).

Now who's acting like the politician? Do we need a counter for how many times you've said the same thing? Saying it again and again doesn't make it true.

Try re-reading my posts, and addressing my technical justifications instead of pretending they don't exist.

therefore he feels everyone else must comply with his lifestyle/choices/issues/demands

Another repeated statement. I hope that everyone will follow suit and drop copier headers, but I'm not forcing anyone to.

Not arguing or insulting other emulator authors.

I haven't insulted anyone over copier headers.

I haven't even insulted Marat, as you seem to think I have. It's called a sense of humor.

Not forcing people to adhere to his standards / his opinions / his likes and dislikes

Another repeated statement.

The author has even admitted privately to me (it's excluded from the quote set above) that his libsnes library doesn't even require a file handle nor does it interface with the filesystem at all

I see you're not above quoting things written to you in private.

Yet this is no secret. I did this to allow Ryphecha to implement bsnes into Mednafen. I've had months of discussion on my forum about this API.

This statement in itself should make any intelligent reader wonder why the author is on a crusade at all

So because I don't like GUI programming, I shouldn't be allowed to discuss why I dislike copier headers?

there's nothing forcing him to work on the "front-end" part especially when it makes him so miserable

If I don't have a front-end, nobody can use my work. There is no front-end that puts bsnes front and center. They're all multi-emulator paradigms, mostly defaulting to the faster, less accurate cores. Make a really fantastic emulator that can be called "bsnes", and I will happily stop releasing binaries.

This is also justified by the removal of many GUI and visualisation options in bsnes, which is something that peers of mine have complained about for months (years?) -- specifically when those features were removed "just because they were annoying to deal with"

Please tell me what it is I owe you and your friends. Why I am required to implement and maintain features you want.

Did you all pay me? No. Did any of you donate money to me in return for a favor? No.

Was helping improve the accuracy of ZSNES, Snes9X, SNESGT, SNEeSe, Super Sleuth and no$sns not enough for you?

Was spending $15,000 of my own money to buy and verify the dumps of all US games (I've already found a few hacked images) not enough for you?

Was raising $2,500 and burning all the goodwill donations I've raised over the last eight years to get all of the SNES coprocessors decapped and dumped, allowing SNES emulation to finally reach 100% compatibility, not enough for you?

What will be enough? When did I become your indentured servant?

while making two-faced comments (quote: "I'm really trying to help make it easier for everyone"),

Two-faced? What does that even mean in this context?

Ask any ROM hacker how sick they are of dealing with patching problems.

It really will make things easier. Less complexity (one format instead of two) = easier. It's a basic axiom.

The author should focus on his emulation library and emulation bits

"The author should shut up and do what I like."

stop forcing everyone (through your emulator) to comply with your beliefs.

Another repeated statement.

I won't be responding to this thread past this point.

"I'm getting the last word in here."

I've covered every single base

"by ignoring every single argument byuu presented against copier headers completely."

But just in case it's not clear

"I'll repeat another statement."

HJRodrigo wrote:It sounds like you are taking this personally... The community has evolved and you are being left behind. Are you basically against evolution/change and want things to remain as they were back in the 90s for no logical reason (other than you might use your copier sometime in the future if you have time to dig it out of the closet )?

What really surprises me is just how amazingly centered it is on the SNES devs (homebrewers, ROM hackers, translators.) Casual gamers don't even care. They run purify, and three seconds later they are gaming. My download count hasn't taken much of a hit at all.

But the ROM hackers, holy shit do they ever hate change. Most are still using ZSNES, IPS, xkas v06, copier headers ...

In koitsu's case, it's basically the backfire effect:

http://youarenotsosmart.com/2011/06/10/ ... re-effect/

The last time you got into, or sat on the sidelines of, an argument online with someone who thought they knew all there was to know about ... how did it go?

Did you teach the other party a valuable lesson? Did they thank you for edifying them on the intricacies of the issue after cursing their heretofore ignorance, doffing their virtual hat as they parted from the keyboard a better person?

No, probably not. Most online battles follow a similar pattern, each side launching attacks and pulling evidence from deep inside the web to back up their positions until, out of frustration, one party resorts to an all-out ad hominem nuclear strike. If you are lucky, the comment thread will get derailed in time for you to keep your dignity, or a neighboring commenter will help initiate a text-based dogpile on your opponent.

What should be evident from the studies on the backfire effect is you can never win an argument online. When you start to pull out facts and figures, hyperlinks and quotes, you are actually making the opponent feel as though they are even more sure of their position than before you started the debate. As they match your fervor, the same thing happens in your skull. The backfire effect pushes both of you deeper into your original beliefs."

(And you know, maybe it's true for me too here. I like to think I am sympathetic to all logical arguments. And I admit there is a pragmatic benefit to just removing the headers where you are able to. I am trying my best to weight it all logically. To make a big column of pros versus cons. So far, I have 2 pros to copier headers (established practice/convenience and in some cases copier users), and 19 cons.)

It's a very well understood phenomena. When peoples' beliefs are challenged, they double down. It actually becomes even harder to convince them that they are wrong.

koitsu doesn't have a single poster in this thread agreeing with him, and yet he thinks it's just big-bad-byuu out to take away his rights unilaterally.

He's a smart guy, though. I just need him to seriously consider my arguments without emotion being brought into this.

I'll give you a side story.

Long ago, I was really huge on hating Cowering because he was including fan translations that got propagated to ROM sites. I joined the hate bandwagon with every other ROM hacker.

But I was wrong. Translating a game without the author's permission is a violation of the Berne Convention (of which the US and many other nations are signatories.) Distributing the original games pre-translation is a violation of copyright *no different* than distributing the fan translation is also a violation of copyright. There is no honor among thieves. To wantonly disregard copyright when it suits you, and then demand it in turn, is the height of hypocrisy.

You couldn't convince me I was wrong back then. Eventually though, all the people pointing this out to me stuck in my head. Eventually, I reflected on things, and realized how arrogant I had been. And I reversed my position. Earning me the scorn of the ROM hacking community. IST went apeshit on me over it just recently even.

But if I could re-evaluate my deeply held beliefs, I'm confident koitsu and others can do the same.