While the biggest talking point of 0.144 might be the decision to not include the driver for the Cave SH3 based hardware after what can only be described as a polite request from Cave to not include it just yet this is not something which bothers me especially.
As a result of the work on this driver, even with it removed, MAME has gained significant improvements to the SH3/4 core (over double performance on many of the most common opcodes and a number of bug fixes making it more suitable for other applications), an audio core (the YMZ770) which could lay the groundwork for the eventual decoding of the MPEG audio in games like Star Wars Arcade (it’s very similar) as well as emulation of a number of peripheral chips such as the RTC9701 which combines a Real Time Clock and EEPROM. By comparison the actual gains made to MAME far outweigh the decision to not include the actual driver, the majority of the work I did there was these reusable parts (the SH3, the RTC) and to me it’s the basic component emulation which gives MAME it’s value as a project.
Despite this, I’m once again subject to very personal attacks from a member of the development team for even looking at the driver, calling it irresponsible and stupid, which is really hypocritical when you consider that the very same developer still has a ‘4 Bitcoin’ page offering to write a MAME driver for said system if people pay him! That doesn’t both me too much either, because said developer, despite clinging on to how he’s worked on whatever AAA console games has still only ever made minor contributions to MAME/MESS.
What does bother me is the loss of another feature in 0.144, far distant from the Cave stuff.
In 0.141u1 the Megatech driver was updated to work with the Softlist support from MESS (which is also in MAME by default), in turn this allowed a very clean implementation of the multi-slot technology used by the system in MAME using a standard of code which has been developed over the last few years to a high standard. This was around 10 months ago, and that support has been there ever since.
For the release of 0.144 I was working on the same thing for the NeoGeo MVS, I’d converted the driver to use a software list (with help from the MESS driver for AES which was already ahead of the curve by having support for a software list for many months)
I was coding to an established standard, for something nobody has complained about in 10 months, inline with the way another copy of the same driver already works to facilitate some source level cleanups, and give the option to run the MVS in proper multi-slot mode, with MAME now being the only reputable NeoGeo emulator lacking that feature.
At the last minute, after my submissions were accepted, that’s ALL been ripped out, but not just the NeoGeo list, the entire MegaTech list, the STV list, everything, gone, with only the internal database remaining. The very foundations which I was going to use for Multislot, gone. The existing support for Multislot in Megatech, gone.
Working for Mame lately is like talking to a three headed monkey, one says one thing, the other says another, then the third disagrees with all of that and puts your contribution to waste.
The reason given, apparently the software list standard isn’t good enough for MAME, it should *all* be internal. In essence I’ve been told that MAME/MESS need a *3rd* standard for ROM loading, a sort of pseudo soft-list internal hybrid. Given that this doesn’t exist yet, that means the 5 hours of work I put in already has gone to waste, and there is no actual way forward.
I don’t even think this makes sense, the MESS lists are getting to the stage of being mature, the technology works well, they were ugly at first but as things stand they work well, they’re effective, and for systems with removal media like home consoles, and the MVS they represent an absolutely ideal way of representing the cart content, with better documentation value than hiding stuff in a MAME source file and greater flexibility on top of functionality, for example, you get free namespacing which really helps make things more manageable.
The reasons just seem to come down to superficial stuff, the XML is ‘ugly’ (I agree, most XML is, but it’s a standard) or some false illusion that a list which isn’t hardcoded into the MAME binary has less ‘value’ than one which is, which is utter nonsense because they’re all distributed as part of the same package anyway.
So, the wheel is going to have to be reinvented again, which not only seems insulting towards the MESS developers who have spent 2 years developing and maturing the softlists, but incredibly frustrating to me, because it’s now a progress blocker, and IMHO senseless anyway, the two standards we already have are mature and suit specific use cases well, introducing a third one would just be a step back 2 years and instead of concentrating on improvements to the existing softlist system to allow dynamic adding of CPUs or Dipswitchs functionality is going to have to be added back from scratch and maintained together with the rest.
Such decisions just baffle me, if people had issues with the software lists there has been ample time to raise them, 10 months of the MegaTech driver using them, even longer in MESS, yet now, when real progress is being made, they get pulled?
I absolutely wouldn’t advocate using Software lists for the majority of the MAME drivers, because in the majority of cases it doesn’t make sense, but in some it really does, and considering the developer involved has come out and stated he’s in favour of the project unification between MAME and MESS I can’t really think of many moves which could actually be deemed more damaging than this one in terms of not showing support for the technology developed in MESS.
Maybe all this will blow over, and things will get reinstated, or reconsidered. I certainly hope so, and do have a great deal of respect in general for the developer who has vetoed this, even if I really can’t understand the reasons. The problem is when you consider that the message coming from the top of Mamedev is ‘More Action, Less Talk’ and more action just ends up being greeted with apparent contempt and culling of progress I’m getting very mixed signals which are off-putting and end up making it feel like a risk to write code for MAME, even when things seem like a dead certainty.
The other irony here is that around 13 years ago there was a MAME build I was promoting and helping with called KBMAME implemented ‘softlist’ style loading for NeoGeo in MAME, in a non-xml format which seems to be what some people would rather see anyway. At the time it was met with open arms by the community, and yet 13 years later just trying to do the same thing manages to turn into a huge commotion even when there are clear benefits to be had.
At the end of the day I need a standard I know I can work to, with confidence and that’s not something I consider unreasonable.
*edit* The lists have been restored for 0.144, alongside the internal ones. While I’m not a big fan of the duplication this leads to it’s definitely a more amicable solution until something else is worked out. My frustrations at the original handling of this remain, but I’m glad to see some sanity has been restored ;-) From the looks of things this will be worked out further between 0.144 and 0.145 but in the meantime progress can continue. I do think that this is putting the MAME / MESS merger type stuff at a critical point tho because a solution which is fair to all needs to be found, and applied appropriately and consistently across the drivers of both projects to avoid creating further divides in standards.