> So maybe there are two issues here. The database, and a new rom-image
> format. Maybe it's O.K. to start building the database and see how that
> goes. When it gets to the point of seeing how an emu might end up using
> that database, we can figure that out later. If it's human readable, then
> it can't be too hard for an emu. But we can use the database to make a
new
> rom image format if we want. There's something I like about the idea of a
> homebrew author being in control of their own information, and packaging
> that information with the product.
I agree. What's so wrong with putting a small header in front of every rom
image file like it has been done with the iNES format? The information in
the header could be derived from a global database. The header should
include only information necessary for an emulator, like bank-switching
type, size of rom-image, checksum, game title and maybe a few else. Using
XML for this case is heading in a completely wrong way! Think of a small dos
tool, that wants to upload a rom image to a cart emulator via serial
interface. It has to parse the XML tags in order to get the information it
needs to do the job properly. This task can be quite complex if you want to
write "good" code. One would need something like a lexer and a parser to
process XML. But I doubt many would really make such an effort, they will
instead do cheap and dirty hacks.
In my opinion, a binary format with a header would be suited best for this
case.
Regards,
Matthias
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
