Hi, I'm Screwtape, and for a while now I've been helping out the multi-system emulator higan, previously known as bsnes. A recent higan forum thread (warning: discussion gets... heated) touched on the difficulty of using games organised by No-Intro with higan. During that thread, Tauwasser suggested that some of the disconnect between the higan and No-Intro conventions is due to nobody in No-Intro feeling particularly passionate about these older systems and not wanting to make sweeping changes without good reason.

So, I decided I should come visit, learn about how No-Intro's cataloguing decisions are made, and provide what advice and background information I can, so hopefully we can come to a compromise that helps both higan's and No-Intro's users.

Note: those of you who are familiar with higan may know it has... particularly strong opinions on how game data should be collected and stored. I'm not going to demand that No-Intro follows higan's conventions; higan already has an importing tool to convert games into its format, I just want to encourage No-Intro to adopt conventions that allow the import tool to work with a minimum of fuss.

ANYWAY.

For my first suggestion I would like to encourage No-Intro to amend the "Nintendo - Sufami Turbo" set so that all the filenames use an extension other than ".sfc", preferably ".st".

For those unfamiliar with it, the Sufami Turbo was made by Bandai, it's a Super Famicom cartridge with two slots in the top designed to accept "mini-cartridges". The idea was that Bandai could develop and publish games on mini-cartridges for less than the price of manufacturing full-size cartridges, and also avoid paying Nintendo to manufacture cartridges on Bandai's behalf.

The reason that No-Intro's convention causes higan problems is that Sufami Turbo cartridges are not valid Super Famicom cartridges - they can't be used without the base unit. higan's import system detects what kind of file it's dealing with based on the file-extension, so No-Intro's use of the .sfc extension tricks it into producing broken games (this issue is not unique to higan; Windows, macOS and many Linux tools also make assumptions about a file's content based on its extension). The workaround is for the end-user to manually rename files from .sfc to .st before importing—although there's only 13 official Sufami Turbo games, that's still annoying to the end-user.

No-Intro already keeps the "Nintendo - Sufami Turbo" set separate from the "Nintendo - Super Nintendo Entertainment System" set, so it seems we already agree they're separate kinds of game. What concerns does No-Intro have with giving them separate file extensions?

Well... I've been wanting to change the extensions for the Sufami Turbo and Satellaview entries for a while now. I want them to be "st" and "bs" respectively. So I think we're on the same page. :3

I just need to actually get around to doing it. Time and effort thing. (and I kinda need to request it) ;P

I thank you for bringing this here. There are a lot of misconceptions about No-Intro (many held by Byuu himself). No-Intro is certainly not perfect, but it isn't an unmoving obelisk. :3 Still, appending DSPs to the ROMs would be a step backward regardless of how other sets (NES and FDS) are still doing things the inaccurate way.

Last edited by C. V. Reynolds on 30 Aug 2017 10:07, edited 2 times in total.

SNES9x doesn't know st file extensions by default, but that can be changed by appending stY to the Valid.Ext file. zsnes knows st already. Both treat the base casette smc as bioses. SNES9x has a special multicard loading mechanism, while zsnes seems to detect Sufami Turbo games no matter what the extension.

EDIT: I'm obviously in favor of changing the extension. This is kind of like the SGB case, but extension cartridges contain native code as opposed to code for another processor.

I put in a request to have the extensions all changed at once for Satellaview and Sufami Turbo. But it wouldn't be hard to manually change Sufami Turbo as well. So few entries. ;P

I'll be cleaning up the tagging of Satellaview games before long, too. No reason for them all to have the "BS" tag. Such a tag should only be necessary if the game also exists on the SNES. "BS SoundLink" can just become "SoundLink". And I'd like to tag the magazines with "Magazine" as well.

One thing I'm unsure about: The BSROM tagged games (the write-protected memory packs). I was thinking that maybe those shouldn't be in Satellaview but instead in SNES. I need to learn more about them.

Huzzah, thanks! Yes, the Satellaview was going to be my next question.

> One thing I'm unsure about: The BSROM tagged games (the write-protected memory packs). I was thinking that maybe those shouldn't be in Satellaview but instead in SNES. I need to learn more about them.

The Satellaview (as you probably know) sits beneath the Super Famicom, connected to the expansion port, and presumably does satellite-control set-top-box stuff.

The Super Famicom cartridge BS-X Sore wa Namae o Nusumareta Machi no Monogatari is the control software for the Satellaview. It talks to the Satellaview hardware and lets you browse information available via the Satellaview service. It also contains a slot that accepts "memory paks", allowing the user to save data downloaded from the service.

Other Super Famicom games that didn't touch the Satellaview also included memory pak slots. This allowed those games' creators to offer DLC via the Satellaview service. You'd put the BS-X control cart and a blank memory pak in your Super Famicom, download data for your favourite game, eject the BS-X control cart and insert the game, add the memory pak you just filled up, and off you go.

So: Dumps of cartridges with a memory-pak slot are ordinary Super Famicom games, so they should be named *.sfc and be in "Nintendo - Super Nintendo Entertainment System" (and I think they already are, so no worries there). Dumps of memory paks (including all the dumps No-Intro tagged "BSROM") are *not* Super Famicom games, and should not be named *.sfc. *.bs is as good a choice as any other.

I'm not familiar with the other entries in "Nintendo - Satellaview" (things tagged "BS" and "BS Soundlink"). If they're dumps of memory paks, they should be *.bs as well, but I know romhackers have patched a lot of games originally published via the Satellaview into working as standalone games, in which case they should be *.sfc.

I don't think it's worth distinguishing BSROM dumps from any other memory pak dumps. A particular copy of "SD Gundam G Next - Unit & Map Collection" might have come from a read-only memory-pak, or the same data might have come from a writable memory-pak that somebody downloaded it to via the Satellaview. At any rate, higan does not emulate any difference between writable and read-only memory-paks. As far as I know, the most advanced Satellaview emulation is in bsnes-plus, which uses a brute hack to guess whether a memory pak is writeable.

xuom2 wrote:there is no batch file, the database was directly mass-changed via query

This is troublesome.. many of my roms now don't match anymore and i've no idea why, like Darius Force.
I get that the [BS] tag was removed and the extension changed to .bs but a complete detailed log of changes would have helped a bunch..

I understand the reasonning behind removing the (BS) tag and changing the extension but now this has become a logistics issue with SD2SNES.
As now the only difference between a BS rom and cartridge rom is the extension itself..
Because SDS2NES stores all save files in its SD2SNES/SAVE folder, save files now have the same name for both type of roms :S
Actraiser (Japan).sfc -> Actraiser (Japan).srm
Actraiser (Japan).bs -> Actraiser (Japan).srm
It's a problem..

Yes, I thought of this too. One solution is to keep the (BS) tag for any game that has an identically named entry in the SNES section. On the other hand, I'd like to encourage emulators to adopt a separate save folder system for Satellaview games (or different extensions for the Satellaview saves, perhaps). So I'm torn. :S