On Wednesday 24 January 2001 00:59, you wrote:
> > I've been reading about SRAM types on a very useful page by Sean Young:
> > http://www.msxnet.org/tech/megaroms.html
>
> I've just amended this page with other ROM mappers/devices I've come
> across (Cross Blaim) and games that came in this (high volume!) thread.
I think I'll translate all mappers on that page to the proposed generic
mapper format. That way:
- we can verify that the generic mapper format is capable of describing all
known mappers
- there is an easy reference for people creating INI files (there could even
be a tool that analyses the ROM and suggests a mapper format)
- we have a formal description of all the mappers
> Also note that Royal Blood is 8mbit (that's 1024Kb, 1mbyte). So the highest
> page is 7Fh; so bit 7 is the only remaining bit. Xanadu is 2 megabit, the
> highest page is 1Fh. In MESS, I've emulated it as "if higher than last
> rom page, select sram", which works fine for the ROMs I have.
Ah, I thought Xanadu was 1 megabit and therefore I dismissed the theory that
the first bit that doesn't select ROM block selects SRAM. But it seems to be
true after all.
What happens when you write #40 to Xanadu's mapper registers? I would expect
to get the first page of the ROM (mirroring) rather than SRAM. On #60 it
would select SRAM.
> I've said this before and I'll say it again: since we are dealing with a
> finite, and very limited set of mappers. If we're already making
> exceptions, then it's not perfect.
There are no exceptions yet to the mapper system, only to the SRAM system. I
do have doubts about generalizing the SRAM system, but I'm convinced the
generic mapper is a good idea.
> Personally I don't feel like using lex/yacc and some relatively complex
> code to emulate about 20 max mappers. I'll add them to MESS as they become
> known, just like it happened with nes emulation.
The code is not that complex. And it will be a lot more compact than the
current code. In fMSX, there are big switch statements to cover all the
mapper types. Using the generic mapper algorith, that would be replaced by a
few lines of code. I was actually thinking of changing the code in that way
before the discussion about the .msx format began.
The format of the INI file is simple enough to write your own parser without
having to use lex/yacc. I'll probably do that and publish the source.
> Also, with
> the direction fMSX is going, I don't see a full implementation happening
> either -- a pop-up box asking for "do you want to put F1 Spirit, Nemesis 2
> or Metal Gear in slot 2, and/or the Game Master 2?" when select Usas?
Those things could be done by a front-end, not by fMSX itself. The front-end
could use the info in the .msx file to show a nice user interface and
calculate the right parameters for invoking fMSX.
> o Usability
> Users surely can comprehend the notion of slot A and B, as I know from
> watching my idiot-brother use RuMSX. He remember the combination of
> Usas + F1 Spirit and selected it without hestiation. He had more problems
> with other options in the program (like memory layout). So, options like
> "can use fm-pac" or "works with Game Master 2" don't have to be automised
> IMHO. That information can be provided with human-readable documentation,
> which doesn't have to be included with the actual download.
Information like "uses PAC SRAM" and "uses MSX-MUSIC" is useful in my
opinion. Sure you can enable them manually, but if it can be done
automatically it's more convenient.
> Also things like "can boot from disk B" is perfectly understandable
> for the average new-be. The notion of "this file is disk A and that
> file disk B", and "this .rom file a cartridge" is easy. So making a
> "unified" format doesn't improve things that much.
Those things aren't as easy as you may think. The notion of a disk image is
rather abstract and confusing to newbies. I've had people mailing me "I put a
disk in the drive, but Solid Snake still refuses to save".
> Usability problems occur: "which mapper is it?" (-rom x), and it
> doesn't run! (It only runs in msx2+ mode, add -msx2+). That can be
> solved with an simple header to the ROM file. Because this is simple,
> implementation on the real MSX should be easy too.
Options like "-msx2+" apply to all media: ROM/DSK/BAS/COM. To create a header
for a ROM file would only solve part of the problem. That's why unification
is a good idea.
> The other frequently occuring problem: "how to play .bas file". That can
> be solved by providing a neat gui, and maybe temporary disks created by
> the emulator.
Since most .BAS games use multiple files, the emulator must know which files
belong together. This is solved by using an archive format like ZIP for .msx
files.
> o Stability
> The idea is that any "new" (or to put it better, previously unknown)
> mapper can be added without modification of the actual emulator
> binary (or source code). Implementing this will cause numerous headaches
> and won't improve stability of the code.
On the contrary: the generic mapper can be implemented in much less lines of
codes than all the mapper types it replaces. The generic code will be more
abstract, but I think it's easier to get rid of bugs in a small amount of
abstract code than in a large amount of more concrete code. Besides, there
will be source code available from both fMSX and BrMSX, so you can always
compare your code to someone else's implementation.
> Over time I've come to appreciate simplicity a lot -- and I'm afraid a
> complex format like this is not going to be all that successful.
If you look at any single advantage of the .msx format, it's probably
overkill to introduce such an elaborate format. But if you combine them all,
I think it is worth it.
I like simplicity as well and I do think the .msx format is not overly
complex. It makes use of existing standards (ROM, DSK, PNG, ZIP, INI, PAC)
wherever possible. Things that don't necessarily belong in the standard are
separated (covers, tips, and packaging too if I can convince the others).
I think it's a trade-off: if we want maximum simplicity for users, then the
emulator must become a bit more complex. And I don't think MSX emulators are
very easy to use right now. Just look at the following page, it tells people
how to run Solid Snake in an emulator; a pretty long description is needed to
describe a rather average task:
http://www.stack.nl/~mth/msx/solideng/howto.html
Bye,
Maarten
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
