Laurens Holst wrote:
> > Indeed, this is even more intuitive than numbering.
> > Let's them make the strings be "MSX", "MSX2",
> > "MSX2+" and "MSX turboR".
>
> What if I write MSX 2+ and MSX turbo R??? No, a number is much more clear I
> think.
Then you write a syntax error. That is always possible, in the case of
numbers you could write a "5" which is not defined, or an "A" which is not
even a number.
No matter whether we choose numbers or strings, you still need a
documentation file when writing the INI. But strings are more readable. It's
hard to remember what "1" means, is it MSX1 or is it MSX2 (as in the #002D ID
byte)?
> And if you use my 'system' I proposed in my prev. message, you can
> define a seperate 'option' named 'altered CPU speed'.
That option is a good idea, but it can be used in a text-based info file as
well.
> I don't like the idea of AND a seperate file AND those seperate files
> compressed again in one file, it can be done the way I described too which
> is much more transparant and easy, the emulator doesn't need difficult
> unzip routines for example.
Unzip consists of two parts:
- decompression
- archive directory handling
You can avoid decompression only by not compressing the data. This choice is
independant of the choice between single file and archive.
About archive directory handling, this is similar to the chunks system you
described. Archive directories are more complex, but also more powerful.
So there is really not that much of a difference. The advantage of using a
known archive and compression format, is that there are no new tools needed
to create such files.
> You can edit it through emulators and/or an
> external tool. Like editing the ID3 information in MP3's through Winamp. I
> don't think that's a pain...
Adding this functionality to the emulator is not a good idea, because it
hardly has any overlap with existing emulator functionality. A separate tool
is possible, but it's easier to use existing tools like a unzip and a text
editor.
Consider what has to be done when the format is extended. A new specification
document must be released. In the case of a text-based info file, that's all
there is to it. But if there is a separate tool, the tool has to be upgraded
as well.
> And I DO think files with lots of text in it
> are suited for configuration files etc, but they are an awful waste of
> space when they are used for every ROM file on your computer's hard disk.
How large are those files anyway? Probably a couple of hunderd bytes. Since
they are stored in an archive file, they don't use an entire cluster on a FAT
filesystem, which is the main reason why many small files eat up a lot of
space.
> There is a big difference between what you describe and what I describe.
> Your idea is dedicated to emulator use (including preview images etc.), and
> mine is, as the title describes, an extended ROM format, purely about the
> ROM information, to which as well useful (ROM mapper type) as unuseful
> (release date) can be added. It can easily be extended, and it doesn't need
> a lots-of-work unzip routine and a harder-to-code parser (from an MSX
> perspective).
If ROM mapper type is all you care about, just write a good auto-detection
algorithm. The one in fMSX is pretty simple, but I haven't seen it guess
wrong yet.
The power of a unified MSX game format comes from combining a number of
different features:
- losing the distinction between ROM/DSK/BASIC/COM
- info like full name, company etc
- a screen shot to easily recognise the game
- knowing the system requirements
- generic mapper algorithm
- finding related info on the web
Note that most of those features are independant, for example a screen shot
can be used for both ROM and DSK games. If we made an extended ROM format,
we'd have to duplicate all the work when we want an extended DSK format.
> I think it's essential to keep it all in one file, 'cause multiple files
> mess up your directory and make it less simple to copy (imho lots of
> seperate sram and save game files in your game directory are a crime). I
> also think it's not the task of this file format to compress the file (it's
> an extended ROM format, not an emulator-optimized "ROM in a zip-file"
> format, which actually is two formats in one).
Why do you consider keeping it in a single file a task of the file format,
but not compression?
> The user can decide if he
> wants to compress the file or not, it should be seperate from the file
> format.
That's the philosophy of .tar.gz, separating the archive directory (tar) from
the compression (gz). But we would actually need the opposite order (.gz.tar)
for optimal performance, so that a single file could be decompressed. The
info file and the screenshot have to be decompressed before the rest. In the
case of large ROMs or DSK images, this makes a difference. And if the
screenshot is a PNG, it could be stored in the archive with zero compression
to allow fast extraction (it wouldn't compress well anyway).
> And if you want your emulator to be able to read compressed games,
> then simply let it read the first ROM file when a user opens a ZIP file
> (just like zSNES, Winamp, and some arcade emulators do).
Since ZIP has an archive directory, why not use it and put multiple files
inside?
There is no way were going to agree on a single design if we have
incompatible goals. So it's better to realise that and separate them. We can
create the MSX game format just for emulators and distribution. For running
those files on a real MSX, intermediate steps are necessary.
Create an MSX ROM loader (or extend LoadROM) and give that it's own extended
ROM format. Then write a converter for the MSX game format. That way, you'll
combine the advantages of both approaches: there is a format optimized for
real MSX (single file, no screenshot, no compression) and there is a format
optimized for emulators (more complex and more powerful).
Bye,
Maarten
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
