Aaron removes xml2info as of u12 (in other words, we are screwed)

[Howard_Casto]

I guess the xml2info code from the old builds are included in mame.  Anyone care to look at the changes aaron has made to the xml output and get it working again??

If not this pretty much means that old frontends/utilites are officially dead. 

Btw, this also means that until further notice, dk and j5 no longer work. 

[SirPeale]

With the latest version of Mame, XML2INFO is now gone.

Who wants a crack at implementing XML into ArcadeOS?

[Buddabing]

If you must have xml2info, just take the code from v0.106, add in the new fields, compile it, and post the result on your utilities page. It's not difficult.

[SirPeale]

There's some talk here.

[Lilwolf]

I have to say... you can also just parse the xml... not hard and its a lot more useful.

It has been the standard for 2 years.  Took me about 15 minutes to parse it... another hour to replace the old parser with the xml parser.  You shouldn't be afraid of XML... just wonder why people use it when speeds on the line.

[krick]

I have the xml2info.c file that I submitted with my patch to 106u11 to work with the new XML changes.

I've built an exe too that should work as long as the XML doesn't drastically change in the future.

You can get them both here...

http://mame.3feetunder.com/xml2info/


EDIT#1:  Oops!, I might have spoke too soon.  I didn't notice that uRebelScum added additional control info to the XML.  I'll have to test it with 106u12 and see if it crashes or not.  I'm assuming it will need a little tweaking.  Stay tuned.

EDIT#2:  Yep.  It's broke real good.  Not sure how to fix this one.  The xml2info code was very fragile and dependent on the order of the items.  The new control tag is nested inside of the input tag and therefore won't get processed until the entire input tag is processed first.  Not good.  I'll keep looking at it but *if* I can get it working, it's gonna be *really* ugly code.  It would probably be faster to re-write it from scratch using a DOM package.  I'm quite familiar with JDOM.  Maybe I'll give it a try in JAVA when I get more time.

EDIT#3: I have something working.  It's not 100% optimal but it works.  See my post further down in this thread.

[Howard_Casto]

I have to say... you can also just parse the xml... not hard and its a lot more useful.

It has been the standard for 2 years.  Took me about 15 minutes to parse it... another hour to replace the old parser with the xml parser.  You shouldn't be afraid of XML... just wonder why people use it when speeds on the line.

I must be dumb or something.  I haven't looked into it seriously but this evening I downloaded several xml parsers and example code.  While I can parse any old piece of xml easily I can't get mame's listxml to parse.  Is mame's output fully xml compliant?


For the record, I don't like xml because it's in-general larger and slower than virtually any format out there.  Mind you the listinfo format is a complete mess, but considering the work was already done I never saw any point in converting.  I still don't unedrstand why mame couldn't have outputted plain old text (think list info without all the stupid tabs and formatting characters). 

[krick]

I must be dumb or something.  I haven't looked into it seriously but this evening I downloaded several xml parsers and example code.  While I can parse any old piece of xml easily I can't get mame's listxml to parse.  Is mame's output fully xml compliant?
 

The DTD at the top of the listxml output is broken currently so the XML doesn't conform.  It's an easy fix.

See this post...

http://www.mameworld.info/ubbthreads/showthreaded.php?Number=80169

[Howard_Casto]

yeah figured that out and promptly deleted the whole mess as it isn't really needed if you know the xml version. 

Even so every other parser I try seems to have some issue with listxml.  I found one that works, but it's a manual parser, so it should.

[krick]

Even so every other parser I try seems to have some issue with listxml.  I found one that works, but it's a manual parser, so it should.

If you find parsers that complain, let me know what they complain about.  It's probably something legitimate that needs to be fixed.

[krick]

Ok, I've got something working.  It's not optimal but it should get people at least playing games.  For the moment, I had to hard code input control to "unknown".  Eventually, I or someone else will figure out how to get correct data in there but for now, this is probably the best to hope for.  Enjoy...

http://mame.3feetunder.com/xml2info/

[Howard_Casto]

Even so every other parser I try seems to have some issue with listxml.  I found one that works, but it's a manual parser, so it should.

If you find parsers that complain, let me know what they complain about.  It's probably something legitimate that needs to be fixed.

I wouldn't know what to tell you.  They don't error out, it's just the parsers choke or enver finish ect. 

 
I think the abandonment of the listinfo format (regardless of how horribly flawed it is) is a mistake. 

The xml format is very simple and easy to understand, the xml parsers available aren't though. 

The list output is supposed to be for fe develpers right?  Then why in the world is the xml format used?  Aaron has to remember, most fe programmers are just hobbists. We shouldn't have to learn a whole new language just to interface with mame.  Xml is exteremelly difficult to parse with some of the older languages, even with tools (msxml, sax, whatever).  After looking at my choices that work with vb6 I am rather dis-heartened.  The official m$ stuff is so convoluted with all of it's classes and sub-classes that it takes knowledge of sql-like queries necessary even for looking up something as simple as a sub tag.  Most of the parsers I tried simply can't load the entire listxml output which is essential as front-ends need to load all the data and convert it to whatever type of list file they use.  The ones that did work took an hour to load it.  And I'm not exaggerating, I mean a whole hour. 


Your efforts trying to fix xml2info are appreciated, but the real solution (as it'll be hard to keep up a converter not officially in mame) is to get everyone off this xml kick and have mame output a real format.  What's wrong with ini files?  The ini format is easy to parse both manually and with help.  It's ascii too, the only difference is the lack of sub-nodes which aren't really needed in mame anyway.  Also it is rather small compared to xml.   

Xml is meant for tiny little storage files, not huge databases like mame generates.

[krick]

I think the abandonment of the listinfo format (regardless of how horribly flawed it is) is a mistake. 

The xml format is very simple and easy to understand, the xml parsers available aren't though. 

The list output is supposed to be for fe develpers right?  Then why in the world is the xml format used?  Aaron has to remember, most fe programmers are just hobbists. We shouldn't have to learn a whole new language just to interface with mame.  Xml is exteremelly difficult to parse with some of the older languages, even with tools (msxml, sax, whatever).  After looking at my choices that work with vb6 I am rather dis-heartened.  The official m$ stuff is so convoluted with all of it's classes and sub-classes that it takes knowledge of sql-like queries necessary even for looking up something as simple as a sub tag.  Most of the parsers I tried simply can't load the entire listxml output which is essential as front-ends need to load all the data and convert it to whatever type of list file they use.  The ones that did work took an hour to load it.  And I'm not exaggerating, I mean a whole hour. 


Your efforts trying to fix xml2info are appreciated, but the real solution (as it'll be hard to keep up a converter not officially in mame) is to get everyone off this xml kick and have mame output a real format.  What's wrong with ini files?  The ini format is easy to parse both manually and with help.  It's ascii too, the only difference is the lack of sub-nodes which aren't really needed in mame anyway.  Also it is rather small compared to xml.   

There's two kinds of XML parsers.  DOM parsers that parse the entire file into memory at once, and SAX parsers that parse it sequentially and fire events as tags are encountered.

DOM parsers are nice when you need the whole file in memory, like when you're editing it.  However, they have the entire file in memory and parsed into a tree structure that is even larger than the original file.

SAX parsers are nice when XML is used for a configuration file and you just need to read it in sequentially and do stuff based on what you find.  SAX parsers are the most memory efficient way to go if you don't need the whole file at once.

You need to find the right tool for the job.

Much more info...

http://www.w3.org/DOM/faq.html#SAXandDOM

Xml is meant for tiny little storage files, not huge databases like mame generates.

XML is meant to be a standardized method of describing non-binary data, especially when there are hierarchical aspects to it.  The benefit is that there are tons of off the shelf XML tools and libraries so you don't need to write custom code for every project.  The obvious drawbacks are what you pointed out, the file sizes are usually much larger than other solutions.  However, with the advent of 3+GHz systems with 2+GB of memory and 500+GB hard drives, the benefits of XML outweigh the size issues.

One could argue that each game should be described in its own XML file and have all the files dumped into the same directory.  That would make it somewhat more manageable chunks for memory limited computers.


Oh, and you might want to check out XPath.  It's awesome for dealing with "huge [XML]  databases like mame generates". 

[Minwah]

I could be re-inventing the wheel (& I haven't tried it yet), but I'm tempted to write my own xml parser...

[headkaze]

I wouldn't know what to tell you.  They don't error out, it's just the parsers choke or enver finish ect. 

Let me guess VB6 custom written parsers? heh dosn't suprise me. If you coded in .NET System.Xml.XmlTextReader would make things alot more easier for you.

I think the abandonment of the listinfo format (regardless of how horribly flawed it is) is a mistake. 

The xml format is very simple and easy to understand, the xml parsers available aren't though.

A very bad mistake for breaking legacy support, I agree, but sometimes you have to go with the new and let go of the old. I know it's a ---smurf---, but it's the way the IT industry will always go. Part of being in this industry is keeping up with standards and keeping your skills up to date. This is the case for homebrew developers as well as professionals.

The registry was never supposed to be used as much as it has been for applications on Windows and .NET has dropped native support of reading & writing ini files because they are moving towards XML. It's a format that is being adopted everywhere.

The list output is supposed to be for fe develpers right?  Then why in the world is the xml format used?  Aaron has to remember, most fe programmers are just hobbists. We shouldn't have to learn a whole new language just to interface with mame.  Xml is exteremelly difficult to parse with some of the older languages, even with tools (msxml, sax, whatever).  After looking at my choices that work with vb6 I am rather dis-heartened.  The official m$ stuff is so convoluted with all of it's classes and sub-classes that it takes knowledge of sql-like queries necessary even for looking up something as simple as a sub tag.  Most of the parsers I tried simply can't load the entire listxml output which is essential as front-ends need to load all the data and convert it to whatever type of list file they use.  The ones that did work took an hour to load it.  And I'm not exaggerating, I mean a whole hour. 

I would recommend looking at some XML parsing code written in C++ and compiled to a DLL that can be accessed through the LoadLibrary API or however else your access a library in VB6. The thing is, as one would expect string parsing functions in VB6 are slow as hell, your really need something written in C++ to get some decent parsing speed.

You comments on hobbiest coders mostly coding in old languages is a little off. Alot of people are moving to .NET, but I agree it is a mistake to take it out for the sake of it.

Your efforts trying to fix xml2info are appreciated, but the real solution (as it'll be hard to keep up a converter not officially in mame) is to get everyone off this xml kick and have mame output a real format.  What's wrong with ini files?  The ini format is easy to parse both manually and with help.  It's ascii too, the only difference is the lack of sub-nodes which aren't really needed in mame anyway.  Also it is rather small compared to xml.

Yeah, the ini file format is being phased out by M$ so I guess it's important for coders to keep up with the times. Vista's XAML is an important part of that OS and will be used to separate the UI to the program code. It's a powerful language for something like that.

Xml is meant for tiny little storage files, not huge databases like mame generates.

Good point, it should be an SQL database file, not data generated by Mame.exe on the fly. And even VB6 can read Access databases using ODBC. So that would be the ideal solution. If the authors sincerely wanted to keep up with the times, then they would put this information into a database.

I suggest another solution; a program written in .NET using it's native XML parsing support to read the XML data generated from Mame.exe and output it to an SQL database. Then re-write your applications to read the database.

EDIT: Hmm it seems the Microsoft Access application can import XML directly.

[Lilwolf]

I know how you feel about XML.  I work for a company who uses it as a network protocol...  and then worries about speed.  We have to optimize the hell out of everything... just to make up for XML's bloat.... plus forcing us to do all those string manipulations to read everything in.

But it is nice for adding things like seperating the controls.  I bet uRebel couldn't have done it in the original -listinfo.... heck, one day I would love to see it seperate the players when possible. 

That... and you should almost always use a SAX parser.  It basically just reads the XML and calls methods based on whats next...  DOM parsers kinda suck because (1) they use a SAX parser and then (2) store everything no matter if your interested in it or not and (3) it stores it in a standard / bloated mannor.... even though its already bloated... 

I think they reason they removed the converter was just that it because broken because people didn't update it... and nobody wanted to maintain it.  Sounds like a perfect side project for someone else though...

I have to say... you can also just parse the xml... not hard and its a lot more useful.

It has been the standard for 2 years.  Took me about 15 minutes to parse it... another hour to replace the old parser with the xml parser.  You shouldn't be afraid of XML... just wonder why people use it when speeds on the line.

I must be dumb or something.  I haven't looked into it seriously but this evening I downloaded several xml parsers and example code.  While I can parse any old piece of xml easily I can't get mame's listxml to parse.  Is mame's output fully xml compliant?


For the record, I don't like xml because it's in-general larger and slower than virtually any format out there.  Mind you the listinfo format is a complete mess, but considering the work was already done I never saw any point in converting.  I still don't unedrstand why mame couldn't have outputted plain old text (think list info without all the stupid tabs and formatting characters). 

[Buddabing]

I rewrote xml2info back in '04 using my own flex/bison based parser. It was way faster than the expat library, and I predict it would be faster than any general-purpose parser.

Once v0.107 comes out, I'll update it for the new fields and it should just drop in.

[youki]

As lot of of you , i hate XML.   Didn't see any interrest in this format except it is something standarized.
Just a fashion effect , in few month a new "standard" will arrive and we will forget progressivly XML,  and same thing few months later..etc..Etc..   Some guys are paid to create standard , so they have to produce a new one each time. And generally the new one is always more heavy than the previous... it is the life... in addition most of these "Standard" creator never even write a line of code.

I'm working for a big professionnal software company , I can say you , they produce new Technology  just to be able to sell new producs and update.  Not because there is a need for.  Just a question of marketing after.

Almost all our lastest sofware uses intanscivly XML and others "new technology" , and believe me , all was far better before. (performance, memory usage, flexibility , required hardware..Etc..etc...).  the only good point for us, is it more standarized than before.

Anyway , AtomicFe is not affected by this kind of problems.  It is a choose i did from start , nothing specific to an emulator.   I assume that lot of others good tools exists to create advanced game list, manage roms , etc..etc..  So it is not the job of Atomic.  Atomic is a Front End, his job is to display a game list  in the  nicest way possible  and run game  on the most possible hardware configuration.

[krick]

As lot of of you , i hate XML.   Didn't see any interrest in this format except it is something standarized.
Just a fashion effect , in few month a new "standard" will arrive and we will forget progressivly XML,  and same thing few months later..etc..Etc..   Some guys are paid to create standard , so they have to produce a new one each time. And generally the new one is always more heavy than the previous... it is the life... in addition most of these "Standard" creator never even write a line of code.

You sound like a bitter old programmer.

XML is derived from SGML (as is HTML).  SGML was an ISO standard in 1986 so it's not exactly a "new standard".

The benefit of a standardized way of presenting data is the re-use of tools and libraries that process that data.

With DOM SAX and XPath, you can do amazing things with data in XML format without having to write a lot of tedious (and error prone) parsing code.

You can also use XSLT to transform the XML data into other formats, even non XML formats like MAMEinfo.

[youki]

You sound like a bitter old programmer.

lol , i'm just consterned of crazy solution and standard they output nowadays.

I'm more nostalgic than bitter.    I'm nostalgic from the time where coders knew coding.

We have machine faster than light , and we have program and technology slower and heavier than a turtle.

So when you combine both , you have softwares that runs at the same speed than a sofwares 15 years ago!

Do an experience,  run windows windows 3.1 and ms word 2.0   , on a modern machine. 

[Howard_Casto]

Gotta agree with the peanut gallery on this one. 

I don't think that learning a "new" standard is what bothers me, what bothers me is it isn't any better than the old one. If anything it's worse.  The dom objects and such are supposed to make xml eaiser to parse, but without the help of sax (which is useless if you are trying to look up a specific record) you can't even load a frikkin file as large as listxml.  All I know is I can load the entire listinfo file in any langauge in less than a second and parse it in less than a minute.  Even with the aid of sax I'd say the speed is going to be considerably slower parsing the xml. 


Like it or not xml is very much a fad.  I just hate to see it  used so heavily in mame because it isn't "future proof" and therefore in a few more years we might see all of this happening again. 



Just for the record even puny old vb6 supports all the major xml parsers, it's just none of them are very good, that's what I'm getting at.  Not vb's fault, it's the parsers fault.  I think my only hope is to look into xsl and convert the listxml into a real ascii format.

[Buddabing]

I think control viewer authors like Howard and myself should be excited about this change in u12:

Added multiple input controls in -listxml output for games with more
than one type. Added pedal control type. Added more info on analog
controls as defined in the driver: minimum, maximum, sensitivity,
keydelta, and reverse. This required the 'control' attribute in the
XML to be moved into an element. There can now be more than one
'control' element in the input secction. [uRebelScum]

[Howard_Casto]

Yeah I'm aware of the new data... I'm always excited about new data.  If it just wasn't presented in such a worthless format we'd be all set. 

[Effayy]

Yeah I'm aware of the new data... I'm always excited about new data.  If it just wasn't presented in such a worthless format we'd be all set.

Howard, I may be off base with this, but I don't consider XML to be all that worthless when taken from the standpoint that the output can then be transformed a myriad of different ways to suit external apps.

Yeah, it takes time to transform that data into an individualized format, but it's at least in an industry-standard format now that is versitile enough to be transformable into whatever you see fit for your external app.

- FA

[Howard_Casto]

So can listinfo.  The difference is listinfo can be transformed into various formats without the use of external plugins and with next to no difficulty. 

As I've pointed out several times in this thread xml is difficult to deal with when the file is as large as this one.  I'm all about industry standards, but only when they make sense to use with the data at hand. 

As much as I loathe msAccess, even it would have been a better base format. 

Or delimeted text files.  Any idiot (myself included) can parse text files. 


There's also the issue of other emulators.  My fe and several of the newer ones treat mame like any other emulator.  We can do this and still have advanced filtering due to clrmamepro files, which are pretty much the standard for getting rom names and descriptions (as well as 5 or 6 other fields). Guess what the clrmame dats are based off of?  You guessed it, listinfo.  So in terms of emulators, listinfo pretty much is the "industry standard".   


Anyway I'm done complaining. 

[cuavas]

I can't believe I'm reading this.  My Mac frontend that I have under development parses the entire listxml output, the mameinfo.dat and history.dat files in 15 seconds on a 1.5GHz PowerBook.  I am using libxml2 to parse the listxml output, which is a slow DOM parser.  I could make it a lot faster if I used expat or something else.  I just use libxml2 because it's easy and included with OSX (and I only parse the data once before storing it in a different format).

My code for processing the XML is tiny compared to the code I had for reading the old format.  With the XML I can lean on libxml2, while the old format required me to do all the parsing myself.  I know which I'd rather use.

If your parser chokes, use a better parser.  If your parser is too slow, use a faster parser.  If your code is too complex, you aren't using the libraries properly.

[Howard_Casto]

I can't believe I'm reading this.  My Mac frontend that I have under development parses the entire listxml output, the mameinfo.dat and history.dat files in 15 seconds on a 1.5GHz PowerBook.  I am using libxml2 to parse the listxml output, which is a slow DOM parser.  I could make it a lot faster if I used expat or something else.  I just use libxml2 because it's easy and included with OSX (and I only parse the data once before storing it in a different format).

My code for processing the XML is tiny compared to the code I had for reading the old format.  With the XML I can lean on libxml2, while the old format required me to do all the parsing myself.  I know which I'd rather use.

If your parser chokes, use a better parser.  If your parser is too slow, use a faster parser.  If your code is too complex, you aren't using the libraries properly.

Your using a mac so your points are invalid.  Mac parsers probably handle it better, I dunno, I never touch the things. 

[cuavas]

Excuse me, but think before you post.  libxml2 is not a Mac parser, it is a cross-platform XML parser.  It was originally part of the Gnome and runs on just about anything.  Try going to http://www.xmlsoft.org/ and reading some of the documentation.  expat is also cross-platform.  I expect both these parsers would perform better on Intel hardware than PowerPC due to the higher clock speeds of the chips.

C is a cross-platform language so my comparison of code complexity is also valid.  I would have to write the same amount of crap in C to parse the old info format on Windows as I do on a Mac.  The API to libxml2 is the same on Windows as anything else, so the code to use it would be just as simple.

The only difference is that I would have to include a copy of libxml2 with the distribution under Windows because the library isn't included with the OS.

[Howard_Casto]

I don't mean to offend but think before you post.  You never mentioned what you were using to parse xml.  How was I supposed to know you were using libxml2? 

Also the interface to said libraries is undoubtedly different on various platforms and languages. 


Regardless, if you'll read above before you started I said "I'm done complaining." I've got a parser setup for myself at this time.  It's cludgy and even with sax's help it's noticably slower than listinfo parsing, but it'll work (for now) so I'm happy. 

Also, due to the new control stuff added by rebel, I can add a new "generic output" feature to j5, so at least something good came out of this bad decision.

[cuavas]

Maybe if you actually read my original post, you'd realise that I said "I am using libxml2 to parse the listxml output, which is a slow DOM parser."  Your assertion that my comments are invalid or irrelevant because I am am using some kind of "Mac parser" is what I was objecting to in the second post.

The thrust of my original post was that the comments in this thread about XML taking minutes to parse and being more difficult to write code to interpret are silly.  There are parsers that will eat it quickly, and because you can use an off-the-shelf parser, you require less complex code - the hard work has already been done in writing the libraries.

[Minwah]

Added multiple input controls in -listxml output for games with more
than one type. Added pedal control type. Added more info on analog
controls as defined in the driver: minimum, maximum, sensitivity,
keydelta, and reverse. This required the 'control' attribute in the
XML to be moved into an element. There can now be more than one
'control' element in the input secction. [uRebelScum]

This does sound good

Going OT but does anyone know if sensitivity etc. can be set (& work) in ctrlr files?  Last time I tried (~v0.101) this didn't work...

As for XML, I don't like it but as we have no choice no point moaning about it...

[Buddabing]

XML parsers don't have to be slow. My XML parser takes 2-3 seconds on my crappy 1 GHz laptop.

Keep in mind that a special-purpose XML parser written just for the -listxml output will always outperform a general-purpose XML parser like expat.

It is important to me that other people's code runs well. Therefore, once v0.107 comes out, I will write some code to make my listxml parser available as a DLL, so that it will be usable to any Windows progam. I will also make it available as a plain library for linux users.

[youki]

Keep in mind that a special-purpose XML parser written just for the -listxml output will always outperform a general-purpose XML parser like expat.

Totally correct ,  that the solution i often choose in my job when i have performance and memory issue with parsers.
But you can really do that, if you are sure that the XML won't change to often.   Otherwize each time one XML object or a property will be added, you will have to update your Parser.  (mainly if you go very far in optimization).

I will write some code to make my listxml parser available as a DLL

Great!

[Minwah]

I will write some code to make my listxml parser available as a DLL

Great!

Ditto!

[krick]

I'm almost finished writing an XLS transform stylesheet that transforms the mame XML output to the info format.

I've never written a single XLS file before and this has only taken me about a day to learn.


You can get windows binaries (DLLs) here for the XSLT transformation processor and other libraries that it's dependent on...

http://www.zlatkovic.com/libxml.en.html


I'll put the XLS on my website when I'm done...

http://mame.3feetunder.com/xml2info/

[Howard_Casto]

XML parsers don't have to be slow. My XML parser takes 2-3 seconds on my crappy 1 GHz laptop.

Keep in mind that a special-purpose XML parser written just for the -listxml output will always outperform a general-purpose XML parser like expat.

It is important to me that other people's code runs well. Therefore, once v0.107 comes out, I will write some code to make my listxml parser available as a DLL, so that it will be usable to any Windows progam. I will also make it available as a plain library for linux users.

It'd be appreciated.  Actually that's what I've discovered myself and it was kind of the point to this whole thread.  The "off the shelf" parsers as it were are crap for parsing listxml. 

What I'm using now is sax with a custom event handling class that ignores trees and nodes and all that crap and just scans the document on a element by element basis.  Since the original listxml grouped things similarly, I can just look for key names and go from there. It gets quicker as I tweak it further, but the fact that you can get good performance just by running listxml through joe-blow's pre-built parser is just plain false.  There are too many branches to our little tree.   



XLS is also compelling.  I looked into it and honestly the syntax to make a template was beyond me.  I got confused and left it.  So good work on that one krick. 


Reagardless, since I've been forced to translate the data myself, I probably won't be converting it back to listinfo just to have it converted for my needs again. I'll just put a special case function in for mame, which isn't what I like to do, but it'll keep things speedy.  I think the other methods are important though, manily because nobody will want to use my crappy code and aside from dat-util, many of the dat managers are going to be broken in the create your own dat dept. 


Minwah, about the ctrlr files, they have had "issues" like this for a while now, and it needs to be addressed.  Something I discovered the other day is that you can no longer re-map the special playchoice 10 buttons anymore via ctrlr files.  Before they werre mapped to service1-service4.  Now they are all mapped to "service" with a different bit mask offset for each input.  This is ok for cfg files, but since ctrlr files don't support bitmasks you can't remap them anymore.  For that matter you can't remap any custom input.  The ctrlr files need to be changed not only to support analog values, but bit offset values as well.  I honestly don't understand why they aren't now as cfg files are basically the same thing and they do.  Regardless, it's a little beyond me in the scope of what I can change in mame.  It's probably something Aaron himself would have to do. 

[krick]

XLS is also compelling.  I looked into it and honestly the syntax to make a template was beyond me.  I got confused and left it.  So good work on that one krick. 

I've got the whole thing working now, except for one game "phrcraze".

One of the dipswitch value names has quotes in it...  Topic "8"  ...GRRRRRR!!!!!!

In XSL, there's a function that replaces any single character for any other character in a string, however, I need to replace a quote character ["] with an escaped quote character [\"], which itself is two characters.

I've found some XSL string replacement code but I'm still trying to understand it.

Incidentally, the whole transformation takes about 3 seconds using the command line tools I referenced in my other post.

[Pi]

I'd like to point out that DatUtil by Logiqx (www.logiqx.com) can transform MAME's XML output to the old datinfo format, keeping most of the attributes. I don't know how well does it currently keep those attributes, but you can try and propose the necessary changes to him.

[krick]

I've finished the first version of the XSL Transformation.
You can grab it with a command line XLST processor from here...

http://mame.3feetunder.com/xml2info/

You run it at the command line like this...

xsltproc xml2info.xsl yourfile.xml > yourfile.info


EDIT:  found a bug already and just uploaded the new version.

[Howard_Casto]

I'd like to point out that DatUtil by Logiqx (www.logiqx.com) can transform MAME's XML output to the old datinfo format, keeping most of the attributes. I don't know how well does it currently keep those attributes, but you can try and propose the necessary changes to him.

Yeah it works, but it seems to only keep data relevant to crc checking.  He's always good about updating it though, the issue comes with the rommanagers themselves, which aren't updated as often.