Check the higans changelog

[FitzRoy]

If No-Intro ever does gain the ability to append firmware, I'd suggest that appended versions get named "Super Mark Kart (USA)[+Firmware].sfc", for example. This will make it easy to differentiate between files that have it or not. You probably don't even need to remove unappended versions if you do this, they can coexist.

I hope all of this gyration on what to do with extra roms makes it clear why higan moved to a container format. Some games have more pieces than others, and old methods don't account for it, preferring to see everything as some single elegant thing. But gluing them together in some arbitrary order just obscures the parts. Going to such lengths to reduce files doesn't even make sense when you consider that any SRAM game is a two-file game as soon as you play it.

[Tauwasser]

But gluing them together in some arbitrary order just obscures the parts.

So gluing different ROMs together in arbitrary manner is a Bad Thing™. And that's what you advocate for? As I said on byuu's board, it's not likely going to happen as long as key members don't grow tired and give up on no-intro altogether.

[FitzRoy]

But gluing them together in some arbitrary order just obscures the parts.

So gluing different ROMs together in arbitrary manner is a Bad Thing™. And that's what you advocate for? As I said on byuu's board, it's not likely going to happen as long as key members don't grow tired and give up on no-intro altogether.

I'm not even close to arguing for No-Intro to go to containers. Several things would have to happen before I did. I simply typed a paragraph to explain why appending is annoying compared to containers.

[Screwtape]

In a recent thread on byuu's forum (in the private WIP area so I can't link to it), it was pointed out that all SNES emulators will automatically ignore the first 512 bytes of a file as a copier header. So if (like me) you're a bit uneasy about just concatenating blobs of data without any kind of container format, you could stick a of table-of-contents in there without affecting compatibility with higan or any other existing SNES emulator.

For example, a 4-byte type and a u32, little-endian length for each block of data in the file. Pictured here is Super Mario Kart:

Code: Select all

00000000  53 4e 45 53 00 00 08 00  44 31 50 20 00 18 00 00  |SNES....D1P ....|
00000010  44 31 44 20 00 08 00 00                           |D1D ....|

Pad out to 512 bytes with NULs, and you're done. I feel such a scheme would at least be on a level with iNES... which is no great praise, but without some kind of header I fear it would be worse.

Of course, there are other objections to concatenated firmware, like No-Intro's "can't verify only part of a game's data" problem, and this doesn't address those. But I figured I'd mention it here anyway, in the hope that it inches closer to an acceptable solution.

[Screwtape]

Another heads-up: in preparation for the next higan release, byuu has updated his "icarus" importer tool to search for firmware files in a dedicated "firmware" directory.

I'm wondering if I should make icarus support a firmware concatenation inside ZIP archives to entice No-Intro a bit with a proof-of-concept.