[target/wswan] Homebrew metadata format

[asiekierka]

For various tools that work with WonderSwan software, it'd be good to define a common format of homebrew metadata (name, author, etc) that can be contained within the ROM.

It'd be good for it to be simple enough to be parseable on-device (but that's not a particularly low bar, the WS does have some power).

I'd say the primary "prior art" here is the SDSC header, but arguably a better solution would be to use a RIFF chunk pointer or Vorbis comments, with a small footer placed just before the official WonderSwan footer. Notes from Maxim/SMS Power on that regard:

I mean, it’s OK and a bit sympathetic to assembler syntax but I think it’d be better to do something more “standard” if possible. Check out the tagging formats used in media, like the Vorbis comment Producing a valid SDSC header in a basic assembler from decades ago is a lot easier than producing a valid Vorbis comment but maybe it’s easier for others to decode if it’s a standard SDSC limits you to nn.nn version numbers, three text fields and a date. The number parts can all have ill-formed values, like version FF.A7 and date AB/CD/DEF0 I recently took the liberty to at least specify the text is UTF-8 now… So yeah, SDSC header is a crappy old-fashioned inextensible format. If we were to extend it we might start putting machine-readable text in the comment I suppose. https://www.xiph.org/vorbis/doc/v-comment.html for reference. It's a bit unclear but basically, followed by many , where each UTF-8 text is in the form KEY=value. You might use the vendor string part to act as a locator or you might make a well-known offset for a pointer to the tag. But this will naturally take more bytes than a more efficient format.

I'd arrange it as follows:

Offset	Length	Description
$...E0	4	'WFHB' magic
$...E4	4	Build day/month/year (4 bytes, BCD)
$...E8	4	Pointer in ROM's physical address space to the RIFF chunk starting point
$...EC	4	Reserved? Got any ideas?

As for the RIFF chunks (or Vorbis comments), they could have an official list of types (name, auth, desc, etc), but also allow people to define custom ones according to their needs.

Do you think this is overengineered? What would you propose?

[ISSOtm]

Imo, a good starting point would be listing out what kind of metadata should be supported, and why—why it should be embedded within the ROM itself, in particular. Then, from that, we can decide how it should be formatted.

[asiekierka]

Thus why I'm asking for feedback: "general text fields" like name, author, description is an obvious one, but is there anything else of note? The console-relevant ROM metadata itself (mapper, bus speed, etc.) is contained in the official header, after all.

[ISSOtm]

I'm not sure about "description", I think some kind of tag list would be more appropriate: genre, series, kind (game, demo, music, languages, ...)

Taking a page from the Game Boy's header, I'd add a version/revision field.

The other thing that I think can be useful to put in such a header, is anything that would trigger emulator enhancements; for example, on the GB, a bitmap to be displayed around the game, SGB-border-style. (Not sure how applicable that is to WS, but I think you get my point. Maybe "default screen orientation"?)

[asiekierka]

The default screen orientation and revision are contained in the official header. What isn't is a game name/author - there are byte-sized "game developer" and "game ID from given developer" fields, but these were allocated by Bandai and they're much too small for the needs of a homebrew community. Here's the Bandai ROM header spec - these we don't need to duplicate.

As for emulator enhancements, I don't really think we have any of note yet.

[AntonioND]

There are some platforms, like the GBA, where the official header doesn't contain all information you need to emulate the game. For example, the save type, or the presence of RTC. Just based on this, it should be possible to specify metadata blocks with technical information about the ROM.

However, I think most of the metadata should be related to the creation of the ROM. Name/Author/Build date are important, but I would even add a field to add a string that describes the SDK used (compiler name, or even the SDK name). The reason to include the SDK is that it may be useful for emulator developers that find some issue with their emulators and want to search across a lot of ROMs looking for more ROMs generated the same way.

Information about additional emulation hacks is secondary, but I guess there is no harm in supporting unofficial blocks that have that information.

But, at the end of the day, the important thing is to make the format extensible, so that new blocks can be defined in the future as they are needed.