Home Page Forums MAME MAME Discussion of an XML rom format

Probably the driver should decide whether the <system> information is required or not. <system> is somewhat informational; unlike the other elements, it will probably not change the emulator's behavior when this cartridge is used.

One could use it to automatically reject a module; without, we would leave it up to the user to check whether this program will run on the system or not. As for the ti99 system, this information could be useful, though: The ti99_4 was the predecessor of the 4a, had a slightly other operating system, and had the same slot; the ti99_8 only existed as a prototype, has a slot, but we don't know whether all modules will run there. The ti99_4p is compatible but has no slots at all, similar to the Geneve. So we actually don't have clones here.

IMHO there should not be a direct, automatic connection from the cartridge to the available systems or bioses, but instead let the driver decide.

Michael

The idea of the "system" was that you could give one of these images and MESS would automatically launch the correct driver. (In MAME it would of course have a more obvious 1:1 mapping). We could easily simplify it to only list a "primary" system and then the user could override like they do now.

Thats fine for me, the list with some systems was what make me think about it.

My first computer was a Timex Sinclair 1000 so sometimes i would run software in that driver more than in the Sinclair ZX-81, I know it's a matter of taste but you know we have some bias towards some computes even if for MESS it's the same. ;-).

My 2 cents.

Fernando

Oh, I seem to have misunderstood that. I thought of declaring which systems are capable of running that romset. See below in my suggestion.


Some more thoughts about the ROM format...

Here is another suggestion with slight modifications. I'll start again with my ti99 Extended Basic cartridge and we can then see how to put in the rest.


Some comments:

1. Except for the <item> attributes, this is the minimum information for an unambiguous configuration.

2. The <pcb> element maps the ROM contents (associated to files in the <images> block) to specific sockets. The type of the pcb is interpreted by the driver. The driver will see that some image is mapped to socket 1, which is attached to a specific address. Socket 2 is on the same position and will be mapped in and out (which is controlled by the driver again).

3. The memory regions (e.g. whether the image is accessible in REGION_CPU1) cannot be changed by the cartridge, due to the fact that the wiring at the connectors are fixed (aren't they?). Instead, the driver knows that socket1 and 2 belong to REGION_CPU1 and socket3 belongs to REGION_USER1.

4. I did not include memory locations and sizes because the socket position together with the pcb type already determine the location. If not (address somehow burnt into the ROM), this should be used as attributes: <socket numer="1" uses="somelabel1" address="0x4000" length="0x2000"/>.

5. system attribute in <software>: system="required" uses the following set of <system> as the maximum valid set. system="any" may be default and will allow to provide a set of preferred platforms without limiting the set.

6. The <system> element with default="true" will be the startup default.

7. I think we can merge this with your previous concept with mixed ROM, CHD if we introduce new elements referring to the CHDs, tagging them, and linking in //item/use. Example:


Michael

...The format should contain information about extra HW required or supported by the SW to run.
For example, a N64 cart that NEED the "extra memory pack", and SUPPORT "rumble pack", or a PC games that need a specific video board etc etc

My 2 Cents

We could probably include a requirements element; should this create a warning or rather make the driver refuse the application?


Any more ideas, suggestions, emotions for my recent proposal?

Michael

A bit OT, but here is a related idea. From what I undestand of this proposals, it is an external database of software for systems supported by MESS. Why not backport this to MAME? The reason I think this would be useful is because over the years, a very common petition has been "how do I compile the latest MAME in <insert outdated/underpowered hardware>". Of course you will never get MAME to run the latest systems on hardware that is not 20 times faster; but it would be very nice i.e. to be able to run all the games from pacman.c (with the latest verified romsets) in mame 0.36. I know it would require to backport to earlier versions of mame the xml database code, but I suppose it is easier to do so than to rewrite romset descriptions written in different source files.

What's easier than that is just using ClrMAME to rebuild your sets for the old version. People do it all the time for low-power ports of 0.36 like the GP2X one.

I know it is easier but I think it is a tad unlike MAME to (indirectly) support bad romsets. I know it is a tad perfectionist to ask for the up-to-date romsets in older versions of MAME, but it was worth a shot.

Sure, but updating old MAMEs would easily be a full time job, and we prefer to look forward

Also, in some cases, the old emulation wasn't good enough to deal with new sets and would need a full backport.