On Monday 22 January 2001 06:09, you wrote:
> > > -- 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.
But then no comment could include an "=" character. Also, I think it's easier
if people can tell whether a line is a comment by looking at the start of the
line rather than scanning the entire line with their eyes. From a parser's
perspective you are absolutely right, but this format is supposed to be
human-readable.
> 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.
I think that's the reason why the .desktop format doesn't have quotes around
strings.
> > > 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?
We would limit the choice of characters to lower case latin and digits. Note
that we're talking about the game ID here, the name field can have SJIS
characters, that's no problem because it's never used as a filename or in a
URL.
> 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?
Using CRCs as IDs is only useful for automatically finding IDs of ROMs that
are not in .msx format. I don't think this is important.
> > 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.
I'm not sure whether it's an RFC or an ISO standard. But I'll look for it.
> > 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.
Ofcourse, using Initial is the solution. I was thinking of returning #FF for
memory areas that didn't have a mapper register assigned to them, which is
not a good idea. But any memory area that is not mentioned in an Initial
statement doesn't have any part of the ROM associated with it and therefore
should return #FF.
This also allows non-mapped ROMs to be described in this format. Such a
cartridge simply has no Register statements, but does have Initial
statements, so you can for example mirror a 16K ROM four times.
> > 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
That's all true, but it's not complete. Super Lode Runner writes to #0000 in
slot 0, not in the cartridge slot. But the cartridge does switch banks on
such a write, because it ignores the slot select signal. So writing to #0000
in any slot is a write to the mapper register.
> 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
Does the actual cartridge have this behaviour? (reacting to all those
addresses)
> Register[7000-77FF]=6000
> Register[9000-97FF]=8000
> Register[B000-B7FF]=B000
This should be "=A000".
> Initial[4000]=0
> Initial[6000]=1
> Initial[8000]=2
> Initial[A000]=3
> Extra=SCC
> Extra=MSX2
As I wrote in the very long mail, I don't think one level of "optional" is
enough. There should be an indication of how much the option will be missed.
The emulator can use that info to display warning messages ("game performance
will be lower because of missing feature 'SCC'") or decide how to trade-off
options (embedded systems low on memory may not allow all options to be
enabled at the same time).
> > 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.
Now that I think of it, only cartridges with the mapper registers located at
an address outside of the area it maps the ROM to could read mapper registers
anyway. Most mapper types have the mapper registers located inside the mapped
ROM area (typically #4000..#BFFF). And read-back is more expensive to
implement, so it was easier for companies to make copies of the written
values in software.
OK, mapper register reading will not be supported.
> > > -- 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.
So the list of valid bank sizes is: 1, 2, 4, 8, 16, 32, 64.
> > > -- 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.
I agree, we should be able to emulate the hardware even if the game doesn't
need it.
Should we allow any range, or just ranges that can be formed using a bitmask?
I think those are the only ones used in hardware and they're probably faster
to implement. We could even modify the syntax accordingly:
Register[5000/07FF]=XX
Meaning that the register is written through any memory location L for which
the following is true:
(L & ~0x07FF) == (5000 & ~0x07FF)
Omitting the second value in the Register statement, it is treated as 0,
which means "exact match" (bitwise AND with 0xFFFF).
And should we allow that a single mapper register is accessed through two
separate ranges? For example:
Register[7000]=7000
Register[8000]=7000
I don't know of any hardware that needs this. But I also guess it's not hard
to implement.
Bye,
Maarten
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
