bsnes and headers

[Near]

Well, regarding iNES, I think the problem is that with NES games you can't do away with headers because there are multiple ROMs in the cartridge

Splitting the files isn't nearly enough. It's the mapping info you need.

What kind of mapping chips are in there? (74LS chips? MMC-1?) How are the pins wired up? (mirroring? VRC-4 pinout?)

With iNES, the mapper #s are arbitrary enough (sometimes one mapper describes 2+ board types; sometimes the same board type has 3+ mapper IDs) that you basically have a database of boards already. May as well drop the rest, go for a 16-bit ID, and describe every variation at that point.

or you could take the MAME or ZOMG approach and make a ZIP file with multiple files inside, with the filename telling what each file is meant to contain

Basically yeah. A ZIP file to me is just a compressed folder.

The problem with the MAME approach is that the filenames don't describe intent, they describe what was written on the IC. Useful for the three people on the planet replacing bad ROM chips on NES/SNES carts, not useful for anyone else.

Here is Contra 3 for the NSS:

contra3.ic2
contra3.ic3
contra3.ic8
dsp1data.bin
nss-ic14.02
nss-c.dat
spc700.rom

How do you make a standard SFC ROM that plays on most emulators? Why you combine contra3.ic3 + contra3.ic2 in that order, of course.
Why is the DSP-1 data ROM and SPC700 IPLROM included in the ZIP, despite neither being present on this board? Good question!

The idea of a ZIP file representing a game folder is a good one. Then the emulator can extract it and use it. Once extracted to a folder, you can easily store save RAM files without rebuilding the ZIP file all the time, and without damaging the archival, pristine ZIP archive.

I just don't like MAME's handling. The ZIP includes irrelevant files, awful file names, and no mapping information. The mapping is embedded in the emulator in their own proprietary format under a non-GPL compatible license.

Also this discussion reminds me about when once on IRC we were discussing about Chinese bootleg Mega Drive games and how every one of them seem to include copy protection.

Yeah, I was following Haze's progress on that. SFC has a few too, but thankfully not as many. Genesis was easier to program for.

Personally, the way I'd handle that would be to include patch files that hack out the protections. But that's just me

But how far can it reach? Because some things get really tricky.

Yeah, opcode mnemonics only. And even then, you'd have a really hard time doing something like the full amd64 instruction set.
The cool thing is you can use the assembler's macro system to inject new opcodes into the table, so you can build your table using recursive functional programming.

Though even then it may be still useful, where is this tool? Maybe I could just go make a table and use that.

http://byuu.org/files/bass_v08r01.tar.xz

In fact, this concept of an application bundle is so good that Apple uses it for applications on Mac OS X.

Exactly the comparison I use =)

The problem then becomes one of how to change the default intent when such a folder is double-clicked to "Open this game in an emulator" instead of "Open this folder in the file manager".

That's why I made kaijuu =)
[with huge help from OV2, he wrote the initial app, then extended it greatly with icon support]

http://byuu.org/programming/kaijuu/

Works on Windows XP - Windows 8, 32-bit and 64-bit.

Once installed, you can double-click to play a folder that matches your filter (eg *.sfc) in bsnes/higan.
You can still right-click and explore the folder contents. Or you can reverse that, double-click to browse, right-click to play.

It also does many other cool things. You can set a rule to open Makefile in a text editor (Windows can't assign it because it has no extension), and right-click to run make all, make clean, etc. You can associate .htaccess files as well.

The argument passing is really advanced: you can pass in a filename, a folder name, the extension, multiple files and/or folders, etc.

WSZ (Winamp skins), SMZIP (StepMania songs), JAR (Java applications), and APK (Android applications) also use the pattern of a bunch of files in a Zip archive. And when unzipped into a new folder, this becomes byuu's application bundle concept.

Exactly! Once extracted, the core no longer has to deal with recompressing the save files, save states, etc.

ZIP is the conduit to get the folder out there, since web browsers lack the ability to download folders. And it's also good for archival.

The Game Boy Advance, for example, is wonderfully more orthogonal than the Super NES, even though it is missing priority per tile, subtractive blending, and hardware audio resampling and mixing.

Yes, but it gains a substantially more powerful processor that can be targeted with C compilers easily, and it has hardware sprite rotation.

It's really hard to draw a clear winner, but I still like SNES more. It felt like more love went into the games. GBA games always felt like half-assed ports and quick money grabs to me. Only a few real gems there. It had a much better homebrew scene though.

These issues apply to the SNES version of this too. Sik raised the objection that this wouldn't work on the NES because of multiple ROMs, and my point was that multiple merged ROMs in the file don't make it any less feasible for the NES than for the SNES. The same problems occur as on the SNES, with cartridges outside the commercially-released set from the console's life needing additional files with mapper information.

Yeah. The idea is we try and drive all commercial software with a database, so that they're immune to future changes in the markup format, and so that existing games can work without people having to redownload them.

Homebrew/ROM hacks/translations will continue to be produced, and we can't grow our database forever. Plus I really don't want to add games like SM Choukyoushi (lolicon rape dungeon "game" ... I wish I was making that up) to my database ...

Of course, what we really need is a finalized board format with 100% of commercial games working on it.
I think I have it now, finally, after half a decade of trying. But yeah, the last thing I want to do is say it's all done and finalized, then end up unhappy with a missing feature or a flaw in the markup syntax :/

But we can't strongly push ZIP { game file + board file } without the board file being finalized.

Besides we're talking about keeping track of a database the emulator has no reason to know about - it should be part of the dump itself, not the emulator.

I agree in principle. If we could perfect a board format, and get it to be universal across emulators, that would be fantastic.
I just don't know how we can do that. Nobody ever agrees on markup board formats. I have lots of reservations over Marty's markup in Nestopia, for instance. Many people probably dislike mine.

Nobody's interested in board formats, and anytime I do things entirely myself, people seem especially opposed to it.
But yeah, I do have five years of experience working with SNES board layouts. So I am kind of the foremost expert there

As for NES vs. SNES, with the latter you can still make a game that's just the ROM and that's it

Yes, mostly. You do end up with a half-dozen really nasty hacks, but it's possible.
See: http://gitorious.org/bsnes/bsnes/blobs/ ... amicom.hpp

with the former you have no option even for the simplest games, so the concept of raw binaries can't be used at all in that case regardless of situation.

Agreed.

EDIT: which reminds me, NES dumps not only are two ROMs, but also the direction in which the tilemap is mirrored. Fun stuff.

Tilemap mirroring is part of the board wiring. Belongs in a board layout description, along with ROM/RAM size, mapper chips present, mapper chip wiring, etc.

[magno]

If you want 100% accuracy then ditch the emulator and use real hardware. Sorry, but I have learned that emulators shouldn't be trusted at all - even when they emulate things like cycle-level operations and such, they still won't emulate issues like the hardware crashing if you try to access it too quickly (or if they do, they won't emulate in what way this happens) and such. On systems with caches they also won't emulate the caches properly, which can cause issues depending on whether caches are flushed or not (or which parts of the cache). Also different revisions of the hardware have different issues and emulators rarely will emulate them.

Emulators are good to debug game logic - and to be fair, this is what you're going to do most of the time. They are also good to see if you're uploading the right data to memory before you can see anything. But if you need to see if some new code dealing with hardware is working, you have no option but to use real hardware to be sure (and even then you have to be careful - if you're using a flashcart that has a firmware instead of booting directly chances are the hardware initialization done by the firmware will later mess up debugging, I already know of one flashcart firmware that likes to clear RAM upon boot).

I forgot to mention that I am against headers in ROMs even though I DO use copiers (GameDoctor 7) to test my code. But chopping the ROM image in 4 disks, copy them with my USB floppy and then go to the sitting room to load each floppy in the GD7 unit is a pain in the ass to be done each change I made. So I develop all code debugging in Geiger's SNES9x, then I test it all in bSNES and finally, I play the game on the real hardware using GD7.
When release candidate is ready, I put it on my homemade cartridge and play it again on the real SNES.

[Sik]

Splitting the files isn't nearly enough. It's the mapping info you need.

What kind of mapping chips are in there? (74LS chips? MMC-1?) How are the pins wired up? (mirroring? VRC-4 pinout?)

With iNES, the mapper #s are arbitrary enough (sometimes one mapper describes 2+ board types; sometimes the same board type has 3+ mapper IDs) that you basically have a database of boards already. May as well drop the rest, go for a 16-bit ID, and describe every variation at that point.

Wasn't there a new format for NES ROMs that instead of assigning IDs to each mapper it contained information about every single part of the wiring? Including what chips were included, how the ROM gets mapped and such.

The problem with the MAME approach is that the filenames don't describe intent, they describe what was written on the IC. Useful for the three people on the planet replacing bad ROM chips on NES/SNES carts, not useful for anyone else.

You forgot that they have a tendency to make dumps incompatible about every version with the naming scheme =P

But you get the idea, ZOMG would be a better comparison. It's a new savestate format for Mega Drive emulators, where each piece of information (e.g. RAM, VRAM, CRAM, CPU statuses, etc.) is in its own file with a specific name, and the emulator then just figures out what each thing does based on the filename. It also makes expansion extremely easy as you can just add a new file if needed.

In our case the ROMs would be their own files, and the mapping information would just be another file (possibly a text file?).

Personally, the way I'd handle that would be to include patch files that hack out the protections. But that's just me

And then you don't have pure dumps anymore. Luckily in just about every one of those games it's just a mapper, but what about coprocessors? (remember for how long the SVP remained unemulated)

Yeah, opcode mnemonics only. And even then, you'd have a really hard time doing something like the full amd64 instruction set.
The cool thing is you can use the assembler's macro system to inject new opcodes into the table, so you can build your table using recursive functional programming.

Yeah, then it isn't very helpful in my case, the opcodes seems to be the only thing every 68000 assembler agrees on =/

http://byuu.org/files/bass_v08r01.tar.xz

Thanks :v

Yes, but it gains a substantially more powerful processor that can be targeted with C compilers easily, and it has hardware sprite rotation.

Even then the processors are the relatively easy part... The video and sound hardware are usually where Nintendo liked to screw up ^.^; (like how in the original Game Boy DMA won't stop the CPU yet it still wants the bus so the CPU has to run off a dedicated chunk of 128 bytes of RAM just to let the DMA run - oh, and DMA can only overwrite all of video memory, it can't just load small chunks of data)

With the Game Boy Advance it seemed like they finally got back on their senses, it's even easier to program than the Mega Drive and that's assuming you aren't using any help from devkits at all other than the hardware documentation.

Tilemap mirroring is part of the board wiring. Belongs in a board layout description, along with ROM/RAM size, mapper chips present, mapper chip wiring, etc.

Yes I know, WTF was Nintendo thinking on? They literally made the Famicom like an arcade machine, using CHR-ROM and hardwiring lots of stuff instead of providing some leeway to accomodate multiple games.

EDIT: forgot

I forgot to mention that I am against headers in ROMs even though I DO use copiers (GameDoctor 7) to test my code. But chopping the ROM image in 4 disks, copy them with my USB floppy and then go to the sitting room to load each floppy in the GD7 unit is a pain in the ass to be done each change I made. So I develop all code debugging in Geiger's SNES9x, then I test it all in bSNES and finally, I play the game on the real hardware using GD7.
When release candidate is ready, I put it on my homemade cartridge and play it again on the real SNES.

I think the whole point of newer flashcarts is that you don't have to go through all that to test on real hardware =P

[tepples]

With iNES, the mapper #s are arbitrary enough (sometimes one mapper describes 2+ board types; sometimes the same board type has 3+ mapper IDs) that you basically have a database of boards already.

One mapper number describing multiple board types that are not functionally equivalent is exactly the problem that NES 2.0 was designed to fix. For example, among MMC1 boards, SOROM and SXROM have more RAM on the cart than the "normal" versions of those boards (SNROM and SUROM), so NES 2.0 explicitly specifies the amount of RAM on the PRG and CHR buses. And among VRC2/VRC4 variants, there's a "submapper" field that describes how the address lines are wired up.

May as well drop the rest, go for a 16-bit ID, and describe every variation at that point.

And that's what NES 2.0 does: expand to a 16-bit ID. Four more bits are added to the mapper number for a total of 12, and four bits are dedicated to disambiguating incompatible variants of existing mappers.

The problem with the MAME approach is that the filenames don't describe intent, they describe what was written on the IC.

Which is why the board file would describe intent, using "href" attributes or the like to link to the filenames.

They literally made the Famicom like an arcade machine

Seeing as Nintendo was fresh off success with Donkey Kong, Donkey Kong Jr., and Mario Bros., I guess it sort of figures. Nintendo was looking for arcade quality graphics, and it saw that the TMS9918 in the ColecoVision was almost there, with nearly pixel-perfect Donkey Kong. So it set out to make something like the the TMS9918, except with scrolling (a feature useful for things that were becoming common in arcade games at the time) and various ways to keep down the cost of memory (CHR ROM and the attribute table). This is what led to the NES PPU. And yes, it was arcade-like, with a view toward Vs. System releases.

[blargg]

As for NES vs. SNES, with the latter you can still make a game that's just the ROM and that's it, with the former you have no option even for the simplest games, so the concept of raw binaries can't be used at all in that case regardless of situation.

I suppose you're correct for a <=32K SNES ROM, where low versus high ROM doesn't matter. Larger, and the SNES emulator needs the mapper. Perhaps possible on the NES, if you had say a 24K file, which would be an 8K CHR and 16K PRG.

His point stands though, you're hardcoding the data into the emulators and whenever a new ROM comes out

Yes, and I wasn't saying otherwise; I'd make the same point. I just didn't see it useful to inject general criticisms randomly when the focus was on a particular point. To me it reframes the discussion into a battle between things, scoring points for one or the other, instead of exploring something. When you're doing the latter, you're often focusing, not summing.

Since we're fully distracted from the focus, my big objection to a database is that it comes from a place of being all-knowing, and is very centralized. It seems the opposite of the emulation/preservation community, where work is decentralized, and new things are being discovered constantly. This to me calls for self-contained things that ask the cartridge what its features are, and don't presume to know of every one in existence. And yes, I know that the database approach generally has a fallback, but at that point you might as well just use the fallback for everything if it works. If the fallback is separate files, then it's cumbersome and you've made it a second-class approach, when it could be first-class (self-contained).

[tepples]

I guess one of the big draws of a database of commercial ROMs is legality. If you update the database, the updates are lawful to distribute, but if you update board definitions that are included with commercial ROMs, that's not.

[koitsu]

I've been asked by 4 of my peers to continue responding in this thread, focusing specifically on the technical items listed here as justification for modifying all existing SNES ROM images to have their copier headers removed (or for split-images, be joined and have their headers removed). Three of my peers, for what it's worth, are against modification of the existing files; 1 is on the fence. I've also received a PM from a forum member (will remain anonymous) who agrees with me that this is purely a "personal crusade" of some sort, simultaneously agreeing with me that the "issues" can absolutely be addressed without modification of existing ROM files.

IPS patches
- Issue: emulator or front-end is unsure whether to apply patch to the entire image (including header) or just the non-header portion
- Removing the header from the file does not solve the problem -- IPS patch is still likely to fail to "do the right (desired) thing" 50% of the time
- IPS file format is at fault for not providing (bare minimum) MD5/SHA1 of the source file the IPS was meant to be applied to
- People using IPS patches need to provide the filename of the ROM and a MD5/SHA1 of the ROM the patch is intended to be used against
- Issue is not the responsibility of the emulator/library or front-end author -- cannot reliably (100% of the time) be solved with software
- Conclusion: not valid justification for modifying ROM / removing header from file
- Alternate conclusion: emulator or front-end can ignore/skip the header and apply the IPS patch to the rest of the ROM -- effectively same thing as modifying ROM except no modification needs to be done

Third-party tool header support inconsistencies
- Issue: some tools found online are inconsistent with their header support. Some work only with headers, others work only without headers
- Removal of header from file would cause some existing tools not to work. Likewise, for some other tools, keeping the header would cause some existing tools not to work
- Cannot reliably be solved (i.e. some tools are not going to work no matter if header removal is done or not)
- Issue is not the responsibility of the emulator/library or front-end author
- Conclusion: not valid justification for modifying ROM / removing header from file -- issue is irrelevant to topic

Third-party tool behavioural inconsistencies
- Issue: some tools found online attempt to parse headers and reject playback of the ROM if header found to be invalid (criteria unknown/unspecified)
- Issue: some tools found online attempt to add headers themselves
- Irrelevant to issue -- has nothing to do with bsnes or any other emulator or library, nor front-ends to those emulators/libraries
- Issue is not the responsibility of the emulator/library or front-end author
- Conclusion: not valid justification for modifying ROM / removing header from file -- issue is irrelevant to topic

Third-party ROM verifiers (ex. GoodSNES) and complexities
- Issue: some tools used to verify authenticity of a ROM are inconsistent
- Not enough precise detail to reach conclusion -- quote seems to imply that if there was only one "type" of ROM (i.e. headerless), this would somehow make ROM verifiers better or decent or good in some way
- Issue is not the responsibility of the emulator/library or front-end author
- Conclusion: not valid justification for modifying ROM / removing header from file

Online groups creating their own emulator-specific headers
- Issue: some online cliques or groups, quote, "subvert the copier header by creating ZSNES-specific emulator headers"
- Not enough precise detail to reach conclusion -- have not seen this myself -- need more technical specifics please
- Conclusion at this time (may change): not valid justification for modifying ROM / removing header from file

Online ROM distribution groups being inconsistent with which header format they use
- Issue: some online cliques or groups distribute ROM images that, quote, "have copier headers in 20+ differing and incompatible formats"
- If the ROM distribution group didn't exist, the same problem would already be happening, re: FIG vs. SMC vs. SWC vs. GD3 vs. GD7 vs. UFO vs. [0-9][0-9][0-9] (split-image SMC) vs. lots of other formats
- ROM distribution groups, much like romhackers, operate independently of emulators/libraries and front-ends
- Conclusion at this time: not valid justification for modifying ROM / removing header from file -- issue is mostly irrelevant to topic

End-users with limited skill sets
- Issue: many end-users / game players do not know how to properly remove a header (lack of technical knowledge/familiarity with formats)
- Applies only if the individual is attempting to use a tool or an emulator/library which mandates "no headers"
- Conclusion: not valid justification for modifying ROM / removing header from file -- if anything this argument supports not modifying the ROMs (i.e. end-users will mess this process up and make things worse)

SNES copier and file format support
- Issue: some newer SNES copiers support a limited number of file formats, or alternately, too many formats
- Issue: same copiers expect, quote, "interleaved images" -- need more technical specifics on this please; as such I am assuming this means "split image SMC", as in split across multiple 1MByte files
- Conclusion: none at this time; need more specifics as stated

Emulator complexities; ROM/game identification nuances
- Issue: very difficult for an emulator to determine the type of game or features it has
- Issue: checksums (CRC32, SHA256SUM, MD5SUM, etc.) not reliable way to distinguish
- This issue would exist whether copier headers existed in the ROM or not
- Conclusion: not valid justification for modifying ROM / removing header from file

Emulator complexities; ROM (not copier!) header identification nuances
- Issue: emulators/libraries/etc. have to, quote, "do odd math to try and detect internal headers ... not just at $7fc0, $ffc0, $40ffc0; but also at $81c0, $101c0, $4101c0"
- Issue: quote: "you can't even do filesize&0x7fff==512 due to older homebrew that doesn't pad the ROMs out"
- 1st problem described is personal; coder/programmer "does not like doing odd math" effectively. I touched base on this already in my previous posts. Rephrased: the "odd math" annoys the programmers, "makes his code messy". I also offered proper workarounds for this (focus on emulation and stop focusing on the front-end / file parsing bits)
- 2nd problem described is not the fault of the emulator author/etc. -- there are ways to solve this problem other than using said formula, but they may result in the reason for the 1st problem ("makes code messy")
- Recommendation for 2nd problem: don't bother supporting this junk -- yes, that includes my own demo with my old SNES docs! You can absolutely 100% blame me for not padding the ROM and I'll take full responsibility for that. However, give us some credit -- those of us who wrote demos on the console did so back in 1991-1996, where copiers were the only thing we had and disk space mattered more. I ask kindly that folks retain context (time period, etc.) when bitching!
- Conclusion: not valid justification for modifying ROM / removing header from file -- issues are either personal to the programmer/coder (i.e. this is just how it goes, welcome to programming), or are related to "non-compliant" software (demos not padded, etc.) which is not the fault of the emulator author

Copier headers cause annoyances for romhackers
- Issue: romhackers must subtract 0x200 (512 bytes) from their file offsets when working with headered ROM images
- Social problem; i.e. "this hurts me to have to do"
- Workaround: romhackers can remove the header from their images before working on them, to ease their pain, then re-apply header before creating + releasing IPS patch. This is what I do with my own romhacks (i.e. FF2j/e for Neo Demiforce (NES/Famicom however), and private work I've done on Otogirisou (SFC), etc.), so if you're expecting sympathy.... :-)
- Conclusion: partial validation for modifying ROM / removing header -- I will accept this as a valid point but it doesn't hold much ground (with me anyway -- YMMV)

If anyone has other reasons/justifications for removal of copier headers, please provide them, as I will be happy to analyse each one individually. But as you can see, some of the points above are refuted, and in others I see some legitimacy.

Now for the slightly more personal part...

As such, I still have yet to see justification for requiring everyone to modify their ROMs (copier header removal) rather than just ignoring them in software (emulator/library or front-end). As of this writing, I still see this as byuu's personal crusade, and that's justified by his own words. Quoting:

As such, there is no incentive for me to target popular legacy formats that are in wide use. Further, I am strongly opposed to the idea of sticking with inferior file formats simply because they came first. I prefer instead to focus on technical merits and choose the most logical options possible. It is not a matter of the complexity involved in supporting these old formats, it is that I feel a philosophical hypocrisy in eschewing these formats while implicitly endorsing their continued existence by supporting them.

So it's not about the technical benefits at all (despite saying it's about "technical merits" and "logical options" -- there's nothing logical, even remotely, about asking every person with a SNES ROM image to modify it!). It's about philosophy, it's about opinion -- fuelled by one man. It doesn't matter if it's shared by 5 or even 500 people -- quantity does not justify demanding everyone change something that can be dealt with in software. How can a person say it's not a crusade given the above?!

I'm perfectly fine with change -- I advocate changing things all the time (go look at the FreeBSD mailing lists sometime). So don't try and troll me with a bunch of rhetoric and demand I "refute the arguments" when I'm not the one proposing everyone who has a SNES ROM modify it for philosophical reasons. And for what it's worth, I was a poor teenager back when I bought a copier as well (this is back when they were going for US$500-600); so what?! I'm not "clinging to an old format" because I like it, I'm stating there's no reason to demand the world modify a billion files (filecount*person) when it doesn't have to be that way.

[LuigiBlood]

This is what I think about headers and this argument that makes no sense, I don't care about what anyone thinks:

They are useless, and more, they aren't part of the ROM in the cartridge. Why should it be there?
And better yet: Why so many formats? Emulators aren't emulating copiers as far as I know.
There should only be a header if the emulator finds a good use for it. iNES is an exemple. Even iSNS seems more useful than a copier header in an emulator.


I will now quote in no particular order and just say what's wrong to me.

However, give us some credit -- those of us who wrote demos on the console did so back in 1991-1996, where copiers were the only thing we had and disk space mattered more.

I don't care if I'm bothering someone by stating a fact:
We are not in the 90s anymore.

IPS patches
- Issue: emulator or front-end is unsure whether to apply patch to the entire image (including header) or just the non-header portion
- Removing the header from the file does not solve the problem -- IPS patch is still likely to fail to "do the right (desired) thing" 50% of the time

Just this means to me one thing: Why no one thinks about a standard ROM format that everyone should use? It CAN be a justification to change everyone's ROMs.

Emulator complexities; ROM (not copier!) header identification nuances
- Conclusion: not valid justification for modifying ROM / removing header from file -- issues are either personal to the programmer/coder (i.e. this is just how it goes, welcome to programming), or are related to "non-compliant" software (demos not padded, etc.) which is not the fault of the emulator author

Sure, he doesn't feel like it, so why arguing? Especially when YOU make it personal to yourself, as seen here, in this FIRST POST:

Lots of great ideas, anyone here want to test them out on hardware and see?

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, you don't feel like it? That means personal to me. In that case, deal with it. Add/Remove the header yourself. Or just don't use bsnes/higan. And more: byuu still made purify that can run ROMs, headered or not.

Just from this, I'm just saying this argument has no end because of personal stuff. And lazy people.
Or this is a pretty bad joke. In that case, continue. I laughed many times.

[Zonomi]

Headers are vestiges of the past. And they aren't even accurate. Plus there isn't even *one* standard header. Every copier had his own. So, which one would be the "real" header? SWC ? Pro Fighter's ? Doctor's ?
ROM files sent to Nintendo for approval don't have headers. ROMs read using an eprom reader don't have headers (and I don't see any more accurate way to extract a game). ROMs extracted using a Retrode don't have a header. sd2snes doesn't use the header. etc...
So why keep using them ? If byuu doesn't want his emu to support header roms, that's his choice. Geiger's snes9x did the same thing, as Byuu mentionned. NoIntro team releases headerless roms. Most roms sites no longer uses header roms.

They are really useless, and I don't see any good reason to support them. If older softwares don't support them, there is always a workaround.

(I'm glad the 640k limit for PC has been removed )

[3gengames]

ROM files sent to Nintendo for approval don't have headers.

But they did come with a page describing the board the exact same way NES headers are made to do. I hate to say it, but XML is not the future, headered ROMS are here to stay. I won't use an emulator that doesn't support them, simple. What good is an emulator if it can't play everything you throw at it? Audacious plays NSF, SPC, Midi, MOD, etc files. They don't complain it's not a .flac file, they just support it. Not saying most formats don't suck (PasoFAMI, whatever else) but the community has to come down and say THIS is what we're supporting as the main format. Period.

[koitsu]

@LuigiBlood:

The copier headers are useless to someone who doesn't use a copier, but that's not the point. The point is these headers can be safely ignored by software (emulators, etc.). This thread is not discussing whether or not the copier headers are viable -- it's discussing whether or not there is technical justification behind removing them (read: every person with a ROM image having to modify it). Why the need to modify something if the underlying software ignores what it doesn't care about? Not rocket science.

You're right -- we're not in the 90s. I'm sorry that I can't go back in time and change all the demos that were done by all the demo groups, properly padding their size. I'm not asking people to do that either (you intentionally removed the most relevant part of my quote) -- I asked that people at least try to remember the era when these were made / what we had to work with then. It doesn't mean our choices were right (far from it!), but having some historical context + education at least allows a person to say "ah I see, yeah, I understand now".

Regarding "a standard ROM format" -- xkcd covers this quite well.

Regarding "why I'm arguing" -- because the point I was given was that there are technical reasons that justify everyone modifying their ROM images to remove copier headers. However so far that doesn't appear to be the case. All that's been shown far is what I already said: it's an opinion. A "philosophy". I'm all for someone having an opinion/philosophy, but demanding that I comply with that opinion/rule/whatever is unreasonable, especially when the justification for it is presented as "technical" (again, nothing presented so far indicates it's technical). So you're bitching at the wrong guy. :P

Also, you quoting me ("I would except there was this emulator that demanded...") is silly -- that was partially serious, partially a joke. I said this for two reasons, and I already explained what those were. Please go back and read my explanation.

I fully agree with you on this point:

Just from this, I'm just saying this argument has no end because of personal stuff.

...because it's exactly what I said from the beginning. It's purely an opinion, a personal choice. Yet I see crap like this (quote: "There is NO technical reason that currently justifies the use of headers from an emulation") and it's utter nonsense. If people would just say "you're right, it's totally about opinion and it's personal", and stop trying to claim there's technical justification behind their removal, I'd be quite content.

[koitsu]

ROM files sent to Nintendo for approval don't have headers.

You're right they don't -- and do you know how that information is provided to Nintendo? I do: on paper. Do you want proof of my statement? I'm happy to show you the pages of the official SNES developers manual ("SNES Software Submission Requirements") which contain 2 pages of fields/data one has to fill out when submitting a ROM to Nintendo for review. Would you like to see it or will you just trust me?

ROMs read using an eprom reader don't have headers (and I don't see any more accurate way to extract a game). ROMs extracted using a Retrode don't have a header. sd2snes doesn't use the header. etc... So why keep using them ? If byuu doesn't want his emu to support header roms, that's his choice. Geiger's snes9x did the same thing, as Byuu mentionned. NoIntro team releases headerless roms. Most roms sites no longer uses header roms.
They are really useless, and I don't see any good reason to support them. If older softwares don't support them, there is always a workaround.

Good fucking lord people! The topic at hand is whether or not ***REMOVING THE HEADERS FROM THE ROM ITSELF (MODIFYING THE FILE)*** is justified, or if they can just be ignored by software. This isn't about "why keep using them?" or other philosophical/opinion-based shit. I was told there are technical reasons why they should be removed from the file (vs. just ignored) and I have yet to see those reasons. This is not difficult to understand -- I'm sure all of us here are technical and intelligent and can understand this.

Programs can ignore those headers -- that's completely 100% legitimate and I couldn't care less if a program does or doesn't do that. What I'm against is requiring people to mass-modify all their existing ROM images to comply with an opinion, specifically when there's no technical reason the headers can't just be ignored/skipped over.

Capicé?

[tepples]

Let me try to provide a few "more technical specifics" per koitsu's request:

Issue: emulators/libraries/etc. have to, quote, "do odd math to try and detect internal headers ... not just at $7fc0, $ffc0, $40ffc0; but also at $81c0, $101c0, $4101c0"

It's not only emulators but also solid-state copiers (e.g. SNES PowerPak, Super EverDrive) that have to seek into files to detect internal headers. You can see this in the current PowerPak firmware: if you run a game that has a copier header, it has to load the game to determine whether or not a header is present, and then it has to load the game again. Because these newer copiers rely on the Super NES's 2.7-3.6 MHz CPU, which is a thousand times slower than a PC CPU, this increase in loading time becomes substantial. Do I need to provide a video of loading a large HiROM with no header, a large HiROM with header, a large LoROM with no header, and a large LoROM with header?

[blargg]

To anyone arguing that an emulator shouldn't support any representation variations, should only support the latest and best, I simply point you to your web browser or image viewer.

[HJRodrigo]

I'm perfectly fine with change -- I advocate changing things all the time (go look at the FreeBSD mailing lists sometime).

I am glad you are willing to change, but the issue is why is byuu NOT allowed to make HIS emulator do whatever the hell he wants it to? Nobody is forcing you to use his emulator. If people don't want their ROMs modified, then here is a clue... DON'T use a program that modifies your ROMs.

So don't try and troll me with a bunch of rhetoric and demand I "refute the arguments" when I'm not the one proposing everyone who has a SNES ROM modify it for philosophical reasons.

It is called courtesy.
byuu said, "I am genuinely interested in hearing your arguments about why copier headers should be supported". You responded by ignoring him and attacking his personal philosophical stance and implying it is wrong for him to implement what he wants in his emulator. Nobody is forced to use it and if they don't like something about it they are free to change it. If you didn't notice his emulator is OPEN source.

And for what it's worth, I was a poor teenager back when I bought a copier as well (this is back when they were going for US$500-600); so what?!.

Poor, yet you brought a copier when is was going for $500-600?! Only a US American can say such a foolish comment and actually mean it. For regular poor people, spending that kind of money means no food AND place to live for at least two months. As Inigo Montoya would say, "I do not think [poor] means what you think it means."

I'm not "clinging to an old format" because I like it, I'm stating there's no reason to demand the world modify a billion files (filecount*person) when it doesn't have to be that way

I am glad you did reply and clarify that it is the modification of ROMs, that the user wishes to keep headers on, that bothers you and not whether ROMs should have headers or not. Kudos on responding and helping us understand what your issue was. Unfortunately, I think it means we can never come to an agreement. I think byuu is entitled to make his emulator run however he wants as its default. If somebody wants to change something then they have to get off their derriere and actually write the code themselves.

To anyone arguing that an emulator shouldn't support any representation variations, should only support the latest and best, I simply point you to your web browser....

Web browsers are the perfect example of what a cluster f**k a programs code can become when trying to support all the possible web pages out there. I like the new trend towards following standards that has begun to emerge after all these years of web browsers doing whatever they wanted.