Maarten ter Huurne wrote:
>
> Actually I now think that a single extension is better. An emulator
> can register the .msx extension, so that file managers like Explorer
> and Konqueror will know what to do when you open a .msx file. With
> for example .msx.zip, the program registered for ZIP will open the
> file instead.
I agree with that. Sean already showed us how to solve
the problem in the server side, so bad downloading shouldn't be
a problem anymore.
> > -- start of msxgame.ini
> We could use ";" for comments instead, I think that's more of a
> standard. It's also a bit easier to parse (some people will want to
> write their own parser, instead of using lex & yacc). Unix formats
> often use "#", but that's not familiar to DOS/Windows and MSX users.
If we're going to stick with INI-style syntax (where
every sentence have the form XXX=YYY), then there's no need
to define which character indicates a comment. If a given
line doesn't have a XXX=YYY syntax, then it is a comment.
VHDL programmers can use "--", assembly programmers can use ";",
C++ programmers can use "//" and so on.
There's one drawback with this approach: XXX=YYY strings
must fit on one line. I think that's ok, all multi-line information,
such as the Comment field, was thrown to the .msx database server.
We can even remove the quotation marks, Machine="MSX" can
safely be replaced by Machine=MSX in this new syntax. Strings
now begin at the "=" and end at CR or LF.
> > GameID=1.0
> Why not use strings instead? Penguin Adventure could be "penadv".
This could be done, but what if a japanese user submit a game
to the database, whose only Name entry is:
name[jp]=²å¤Ahx`[
What six-letter string should the manager give to this file?
Patriek suggested using CRCs as GameIDs, but I don't think
this is a good idea. It works fine for ROMs, but what about
multi-disk games? Should use the CRC from the first disk? From the
last? Should we append all the disks and take the CRC of the result?
In this case, in what order should the disks be appended?
> It is a good idea to have a major ID and a minor ID. Most uses of
> the game ID do not depend on the minor ID. For example, save games
> for the Japanese and English Solid Snake are exchangable.
It also saves space on the server. For instance, I could
scan the entire manual of Penguin Adventure and place it in the server,
wasting about 5 MB. We don't want to waste another 5 MB for every
variant of the game.
> By the way, I think "us" is not a valid language code. It's probably
> "en_US" or something like that. After all, the language is still
> English (although some UK people will deny this ;), US specifies the
> "dialect" (it's not really a dialect, but I don't know the proper
> word).
I made a search on the web and couldn't find the RFC.
If it is not available anywhere, we should make our own
language codes.
> One thing that isn't documented yet, is how to handle memory that
> is not controlled by the mapper. We could say it is filled with #FF
> (the data bus pulled up), but I'm not sure if that's correct for all
> MegaROMs.
I can't see anything wrong with that. Every part of memory
not initialized with a Initial[XXXX]=Y statement should answer
with FF when read.
> Another thing is how to specify that a cartridge ignores slot
> select (like Super Lode Runner does). This is bad design from the
> cartridge manufacturer, but it has happened so now we have to deal
> with it.
Can you please explain in details what is the problem
with Super Lode Runner? I thought its mapper was just:
Banksize=16
Register[0000]=8000
Initial[0000]=0
Initial[4000]=0
Initial[8000]=0
Initial[C000]=0
> Is it useful to allow I/O ports for writing to mapper registers?
I think not. I/O extensions should be defined in a
tag called "Extra". The Extra tag would include everything that is
not required by the game to run, but can improve gameplay. The
generic mapper for Nemesis 3 would be:
Banksize=8
Register[5000-57FF]=4000
Register[7000-77FF]=6000
Register[9000-97FF]=8000
Register[B000-B7FF]=B000
Initial[4000]=0
Initial[6000]=1
Initial[8000]=2
Initial[A000]=3
Extra=SCC
Extra=MSX2
> Is there any game that reads the mapper registers, or is it
> always write-only?
BrMSX-dos does not implement reading of the mapper registers,
and all the games I have run fine with it.
> > -- select a banksize with 8kb
> > Banksize=8
> Is any bank size allowed, or just 8kB and 16kB?
8 and 16 would be enough, but we can extend the format
to all powers of 2, just for completeness. We never know when
a strange cartridge will appear, and the format should be flexible
enough to support an new, unknown mapper.
> We could also specify banks by using the address the bank starts at.
> So instead of "3", we would write "6000".
Your approach is better than mine, let's adopt it.
> > -- if we wanted to define multiple registers,
> > -- like in fmsx mapper 3 (konami with scc)
> > -- we could make Register[5000-57FF]=2
> I think that's just a hack to allow more than one actual mapper to
> be emulated using a single fMSX MegaROM type. AFAIK, there is no game
> that writes to more than one address to switch. If that's true,
> there is no longer a need for this feature now that we can specify
> the exact mapper for each game.
Even if the game uses only one address to change banks,
the mappers inside the cartridge can work with more than one address.
Since the purpose of the generic mapper is to specify the hardware
inside the cartridge, I think we should allow multiple registers
definitions like Register[5000-57FF]=XX.
Ricardo Bittencourt
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
