On Tue, Jan 23, 2001 at 08:12:43PM +0000, Maarten ter Huurne 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.
In any case, whatever we decide for the .msx format; it would be nice
to have a list of all mappers that exist (or we know about). Please,
have a look, and if you have anything to add please let me know and
I'll add it to the page.
> The question I had in mind was: Is a generic SRAM possible? And if it is,
> what would it look like?
>
> An important type of SRAM is the PAC SRAM. I don't think this one is a good
> target for generalization:
> 1. The access method is very exotic.
> Read the page and you'll know what I mean.
> 2. The contents will be saved in the .PAC format.
> This is the format used by the FM-PAC ROM to save the SRAM contents to
> disk. Sean suggested using this format in emulators as well and I agree.
As a side note, a .pac file is simply the string "PAC2 BACKUP DATA" followed
by 1FFEh SRAM data. The string is not zero-terminated, and although the
SRAM is 2000h bytes, two bytes are unusable because of the way it is
selected.
> Then there is the GM2 SRAM. It is possible to generalize this one. But unlike
> the other types of SRAM, the GM2 SRAM is divided into banks (8K in 2 banks of
> 4K). I'm not sure whether generalization is useful here.
Also the way you select data is a bit weird; in binary, xx01xxxxb for the first
page and xx11xxxxb for the second. (x = don't care). Any other value is
a normal rom page: xxxxPPPPh (P being the bits for the page).
> That leaves the following SRAM types:
> 1. ASCII/8K with 8K SRAM
> 1A. SRAM in page #20 as used in Xanadu
> 1B. SRAM in page #80 as used in Royal Blood
There are more: a couple of Koei games, Ultima, Wizardry, War of the Dead.
Anyone else know any more?
> Then there is the GM2 SRAM. It is possible to generalize this one. But unlike
> the other types of SRAM, the GM2 SRAM is divided into banks (8K in 2 banks of
> 4K). I'm not sure whether generalization is useful here.
Also the way you select data is a bit weird; in binary, xx01xxxxb for the first
page and xx11xxxxb for the second. (x = don't care). Any other value is
a normal rom page: xxxxPPPPh (P being the bits for the page).
> That leaves the following SRAM types:
> 1. ASCII/8K with 8K SRAM
> 1A. SRAM in page #20 as used in Xanadu
> 1B. SRAM in page #80 as used in Royal Blood
There are more: a couple of Koei games, Ultima, Wizardry, War of the Dead.
Anyone else know any more?
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.
> 2. ASCII/16K with 2K SRAM
> as used in Hydlide 2
>
> These types do look a lot alike. We could decide not to generalize them
> because there are only 3 of them, but I think that if new SRAM cartridges are
> discovered, there is a pretty good chance they will look like these.
As far as I know, this is the only on of it's kind. Of course, who knows..
> That leaves the following SRAM types:
> 1. ASCII/8K with 8K SRAM
> 1A. SRAM in page #20 as used in Xanadu
> 1B. SRAM in page #80 as used in Royal Blood
There are more: a couple of Koei games, Ultima, Wizardry, War of the Dead.
Anyone else know any more?
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.
> 2. ASCII/16K with 2K SRAM
> as used in Hydlide 2
>
> These types do look a lot alike. We could decide not to generalize them
> because there are only 3 of them, but I think that if new SRAM cartridges are
> discovered, there is a pretty good chance they will look like these.
As far as I know, this is the only on of it's kind. Of course, who knows..
> So I'll
> present a way of generalizing them. I suggest you open Sean's page in your
> browser to understand the descriptions below.
-snip-
> To Sean: Did I interpret the contents of your page correctly?
Yes you did. :-)
> I'd like some comments on the generic SRAM type. Also, if there is a
> cartridge using SRAM out there that wasn't covered above, I would very much
> like to hear it.
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.
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 fMSX development cycle
has speeded up quite a bit the past year, and I don't think it will hinder
emulation as much as a complex format as is being proposed here. 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?
Sounds cool but it's overkill.
The goal was to improve:
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.
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.
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.
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.
Disk space can be saved by adding transparent gzip or zip support to
emulators. IIRC gzip support is already in fMSX Unix/X.
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. Adding a new mapper is much
easier, and because fMSX is open-source (fMSX still is the main
emulator as it's the best -- or not?) any good programmer can add it
and provide patch files. Although I'm working on MESS, if time allows
I'd like to add more mappers to fMSX.
It would be nice to have an open-source Windows port of course.
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.
A simple format that contains: type of msx it needs to run on, what
model (jap/int/kor), mapper, manufacturer, title, year, uncompressed
rom data would be fine -- the extra info could of course be in an
.inf/.ini file, but it's going to be read by humans anyways -- so there's
no point in a strict format for that. Maybe a few other fields, but
not too much.
iNES files (.nes) also does it this way but has way more mappers than the
msx rom cartridges, and works fine. MESS runs, as far as I know, all of them,
and that's 1600+ cartridges. That's about the same amount for the MSX,
I assume (wild guess, but won't be far off). Also I don't think there
are that many "unknown" mappers, specially if we put all our heads
together. Support for all them can be added to fMSX in a good nights'
coding, but implementing this funky format will be another year or two.
Sean
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
