etabeta's playground

As of late there seem to be a lot of whines over the interaction between MAME and MESS, so let me add my point of view here, since elsewhere comments are not possible.

1. Should the MAME/MESS sources get merged?

In my opinion, yes. Ideally we might want a src/emu/ folder containing all the shared components needed for a sort of universal emulation core (i.e. all CPUs, sound devices, screen devices, I/O devices, etc.), a src/mame/ folder with arcade drivers and a src/mess/ folder with console and computer drivers (and calculator and chess computers too, of course 😉 )
And many devs are continuously working in this direction since two years, as you can very openly and easily see if you check for most Micko’s and Curt Coder’s references in MAME whatsnew.txt (and their work is only an example: many more contributions in this direction has been given over the time).

2. So what was wrong with 0.142u3 changes?

Almost everything. In the sense that most changes simply consisted in moving *some* arbitrary file from mess/ to mame/ just to make some more drivers to compile inside the MAME tree. No plan for the needed structural improvements, just pointless and whimsy reshuffling of source files (and I cannot even understand the reason for this… some unclear powergame?)

Someone could think that some changes are better than no changes at all and that cleanups might follow. But this is not true for at least two reasons.

First, there is no proof of any kind that cleanups will follow anytime soon.
Just look at the MAME history: Haze rewrote MegaDrive code for HazeMD and updated Megatech/Megaplay/Sega C2 in MAME to use his new code. One would have expected that the next natural move would have been to update MegaDrive bootlegs (Aladdin, Super Street Fighters 2, etc.) to use the new video code as well, since they simply were hacked up MegaDrives in a cabinet and since such an update would would have allowed to remove hundreds of useless lines of code from the source…
And instead nothing has happened for almost two years (for the record, I was the one ending up to update MD bootlegs to use the new code, but that’s just a minor detail).
And after two more years, we are still using the original MD code for System 18 (but this is fine to some extent, because the rest of System 18 emulation makes very hard the update at this stage).

*edit*: actually, I have been imprecise about this bit of MD video code: MD bootlegs got the video updated by Haze, it was the CPU memory maps and the inputs which remained in a poor state for a couple of years with a lot of redundant code (and got updated by myself after 0.134u2). this changes nothing of my point: cleanups do not magically happen if you leave the code there and old code can remain untouched for years if no one does the job in the right way since the beginning.

Second, such a kind of changes make development harder when not done properly (e.g. after an abrupt change of location without cleanups). And let me clarify a bit this point, which seems unclear to many.
If I decide to do some changes in a driver and I break something, in the current source structure it is not that difficult to track down where breakage can be. I can simply ask to myself:
– am I doing development for an arcade or an home system? if the former check emu/ + mame/, if the latter check emu/ + mess/.
Now, say that the answer to the first question was “home system”. How to decide between emu/ and mess/? I can simply ask to myself the following
– is the chip I’m changing only used in home system or also in arcade? if the former then chances are high that I have to look into emu/, if the latter then I have to look into mess/
That’s all. Easy, isn’t it?
And once I know which directory I have to look into, it’s easy to search in drivers/, machine/ or video/ depending on which component can cause my problems.
Well, in 0.142u3 (and situation was even worse in the original commit, which have been later rectified by Micko and Kale) this was not possible anymore.
Some floppy format files got moved from mess/ to mame/ even if *NO* arcade system was using them and some code for serial communications got moved to emu/ even if at the current stage only minor non-arcade systems use it (but the move was required to allow proper compiling). So what if the computer I’m developing for has an issue with its floppy controller or its serial comms? Where in the hell should I look for the corresponding source file?

In conclusion, outdated files got moved arbitrarily in locations which made no sense and which made development harder. And the only justification was “They can be cleaned up later”, even if history says that most of times the opposite happens. Guess why these changes have been reverted?

3. Is there any better solution?

Of course there is: it consists of studying the code used for specific components that are shared for real across more systems, of untangling these components from the specific drivers that use them and of moving them in their proper location *without* bringing the whole old code with them… And this is exactly what several MESS devs have done in the past months/years.
But this proper solution requires time, so it’s not something you can do in a night, as someone stubbornly claims.

Then, there is the completely unrelated problem of merging svn repository. It’s a different topic, that for some reason gets confused with the source reorganization, so I guess I have to give my opinion on this too: I hope the svn can be merged (better sooner than later) and, ideally, I would go for the MESS model (public svn and private mailing list) rather than the MAME model (both svn and mailing list private). But there seem to be bandwidth problems and access problems, plus some of the involved persons have also a real life, so no changes have been done yet. Anyway, let me stress it once more, it is a different issue and I’d like discussions can be kept separated.

4. Where is politics in all this?

In the above arguments politics and egos are nowhere to be found. Maybe some specific member of the mailing list might have had additional reasons to shot down the change, but you cannot confuse some single person with the whole list (generalizations are so dangerous).

What I hate most is that the above objections could have been the starting point for a meaningful and fruitful discussion on the best way to make progresses in the whole project. So the real question is: why has this discussion not happened?

Because there are people which refuse to be part of the discussion lists and prefer to whine and rant in their blogs. And people which cannot stand in discussions when other people disagree with them, prefering to insult rather than trying to find a common solution which can make everyone (or at least the majority) happy.

But of course, again, discussions take time and it’s oh-so-much-easier to play the role of the victim of a conspiracy against openness of the project than to defend personal ideas when others point out that your shortcuts are a *BAD* solution and that a better one has to be looked for.
Because even if we can agree about which direction we want to move, there is a good way to do the steps and there are many wrong but easier ways… and seldom the right way can be found by imposing one side’s point of view over the others without even the grace to sit down and discuss a bit with the other side.