Hi!
In this mail I'll list some issues that weren't mentioned yet.
* Name
The standard needs a name. Some suggestions:
- Unified MSX Game Format
- .msx (pronounced "dot em-es-iks")
- MSX Software Format
I prefer the first. Maybe we can drop the "Unified" if you don't like it, but
I think the power of the format is that it's unified in two ways: one format
for ROM/DSK/BASIC/COM and one format for all emulators.
About the second: We can still talk about .msx files, but I don't think this
is a good name for the standard itself.
About the third: The format is not really specific to games. For example, you
could start GraphSaurus from a .msx file. However, games are the reason it
was developed and will also be what it's used for 98% of the time.
* Booting
On a multiple disk game, which disks can be booted? Usually, this is the
first disk. But let's take Aleste 2 as an example (also see Ricardo's mail
that is dated last Tuesday - are you a fortune teller?). Aleste 2 has 3
disks, all of which can be booted. The first disk is the intro disk, which
you should boot if you want to watch the intro. The second disk is contains
stage 1-4, which you can boot to skip the intro. The third disk contains
stage 5-8, which is usually not interesting to boot, but when you activate
the built-in cheat mode to select a stage, it is.
So in the case of Aleste 2 it makes sense to allow all disks to be booted.
But in other games, booting a different disk either crashes the MSX or just
displays an "insert disk 1" message. The emulator shouldn't offer to boot
those disks.
In conclusion, the MSX game info file should contain whether or not a certain
disk is bootable. We could add a description string that tells the user what
to expect when choosing that boot option. Example for Aleste 2:
BootDesc[0][en]=Intro
BootDesc[1][en]=Stage 1-4
BootDesc[2][en]=Stage 5-8
For BASIC and COM games, it's also useful to allow a choice which file is to
be booted. For example, one version starts the original game and another
activates a cheat.
* Error handling
If there is an error in the info file, what should the emulator do? Or in the
case of a front-end, what should the front-end do? I think we need some
directions for this, either rules or guidelines, depending on how strict it
should be. If we don't, things will become a mess (like HTML).
Currently, we have two types of lines:
- comment lines
- statement lines
A line that is neither is an error.
A comment line doesn't have any formal meaning and can therefore never
contain an error.
Statement lines have the form "keyword=value". Unrecognised keywords are
ignored, this allows the format the be extended by introducing new keywords
while not breaking existing emulators. A value can be invalid, for example a
number that is out of range. Some keywords are mandatory, for example the
bank size of a MegaROM, if they are missing it's an error.
Apart from syntax errors, there are configuration errors. For example, you
want to play an MSX2 game in an emulator that only supports MSX1.
I've listed a couple of cases where errors can occur. This list is by no
means complete, but it is useful to create examples.
There are two phases in the "life" of a .msx file. It is first created and
tested by one person, then it is distributed and played by many persons.
After the first phase, the .msx file should no longer contain errors. The
first reason is that it's hard to fix errors once the file is in the hands of
many different people. The second reason is that the person who creates the
.msx file is someone who knows the format and who knows MSX, while the person
who wants to play the .msx file doesn't necessarily have that knowledge.
Because errors should be caught before the file is distributed, I propose
that an emulator should abort on any error in a .msx file. Aborting means it
should abort the starting of the game, it doesn't necessarily mean it has to
abort the emulator program.
* Small remarks
For the MSX1 VDP, it must be possible so specify either a 50Hz or a 60Hz VDP.
Unlike the V9938, the MSX1 VDP comes in different versions for 50Hz and 60Hz.
I think they're called V9918 and V9928, but I'm not sure which is which.
Copy protection emulation was an issue I raised before, but no-one responded
to it. I think it doesn't have priority so it shouldn't be in the first
version. But I would like to get some opinion on whether we should include it
in the future.
There was little discussion on SRAM yet. I think this is an important issue
that should be resolved before the standard is released. It would be nice if
a generalized SRAM implementation is possible, just like the generalized
mapper.
Bye,
Maarten
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
