I don't dislike MESS (some of the recent changes have been very impressive thanks to Judge etc.) but it simply doesn't fit in my development methodology.
Sorry if others disagree, but that's just how I see things.
This is perfectly fair. And as I said, I didn't want to force you to change your mind.
Originally Posted by Haze
I'm willing to bet that if I grab the current Mess code, and unzip it over my current MAME tree / any current SVN build, then all hell will break loose.
If you means: grab current MESS genesis code, you're true. you need a complete MESS tree to test the changes.
if you means: grab the whole MESS tree, you're wrong most of the times (unfortunately, these days you would be right due to the malloc changes)
my point was: if you keep two separate source folders, you make changes to megadriv.c in MAME and you copy it in the MAME part of MESS source, you can compile and test the results without the need of any change in the MESS part of the source (except if you want to change the memory map). earlier, you would have needed to tweak more MESS files.
In general, MESS source is sync'ed right after an intermediate update happens to MAME. this means you have de-sync'ed sources for more or less 7 days and it only greatly affects development when Aaron does huge changes (like the malloc ones). Usually, copying any MAME drivers and/or machine change (like any megadriv.c one) directly into the MAME part of MESS source and recompiling work like a charm.
Originally Posted by Haze
For systems where it's appropriate MESS should have set lists like MAME in addition to the current open ended approach (which is ueful for homebrew & systems where the media isn't really 'fixed')
As a first step in this direction, we could add a warning (a red screen?) when a known bad dump is loaded. We have .hsi files for reasons like these. And adding fixed lists to the current approach (without replacing it completely) is possible as well, it just requires some more coding.
