MAME parser

[ghost]

Hello

I try to make a parser for the XML file.

Some things I can't find in the XML File:

• where is upright/cocktail of the machine specified?

• there is a "rotate" attribute of the <display> tag that can have values 0, 90, 180 or 270
  Which of those represent horizontal or vertical screen?
  A question about the rotation of the screen. This gives us a clue on the orientation although it is not known why you would rotate a screen 180 or 270 since this places the screen up-side-down while 0 and 90 would be enough to change the orientation.

MutantXenu

[cuavas]

where is upright/cocktail of the machine specified?

It isn’t. Some machines support both depending on settings, others support only one or the other.

there is a "rotate" attribute of the tag that can have values 0, 90, 180 or 270
Which of those represent horizontal or vertical screen?

It’s more complex than that. Individual screens can have rotation attributes which are applied before the system rotation attribute. This is particularly important for systems with multiple screens in different orientations (e.g. some Jaleco rhythm games).

For systems that used standard monitor electronics where the screens themselves do not have rotation attributes, 0° and 180° will result in horizontal screens while 90° and 270° will result in vertical screens. However, there are some systems that had vertical screens scanned from top to bottom (e.g. Apple’s Macintosh Portrait Display and the Xerox Alto).

A question about the rotation of the screen. This gives us a clue on the orientation although it is not known why you would rotate a screen 180 or 270 since this places the screen up-side-down while 0 and 90 would be enough to change the orientation.

For 0° rotation, the raster is scanned left to right, top to bottom, like a conventional CRT TV. Some systems have the display inverted so the raster is scanned right to left, bottom to top, corresponding to 180° rotation. Similarly, with vertical screens may scan bottom to top, left to right, or they may scan top to bottom, right to left.

[ghost]

where is upright/cocktail of the machine specified?

It isn’t. Some machines support both depending on settings, others support only one or the other.

So MAME only knows this in the source code but it isn't exported to the XML, correct?

there is a "rotate" attribute of the tag that can have values 0, 90, 180 or 270
Which of those represent horizontal or vertical screen?

It’s more complex than that. Individual screens can have rotation attributes which are applied before the system rotation attribute. This is particularly important for systems with multiple screens in different orientations (e.g. some Jaleco rhythm games).

For systems that used standard monitor electronics where the screens themselves do not have rotation attributes, 0° and 180° will result in horizontal screens while 90° and 270° will result in vertical screens. However, there are some systems that had vertical screens scanned from top to bottom (e.g. Apple’s Macintosh Portrait Display and the Xerox Alto).

Can we see in the XML if a monitor uses rotation attributes or not? I ask this in order to know if I can use your guideline for hor/vert screen on standard monitor electronics.

[cuavas]

where is upright/cocktail of the machine specified?

It isn’t. Some machines support both depending on settings, others support only one or the other.

So MAME only knows this in the source code but it isn't exported to the XML, correct?

No, MAME does not know this in the source code.

there is a "rotate" attribute of the tag that can have values 0, 90, 180 or 270
Which of those represent horizontal or vertical screen?

It’s more complex than that. Individual screens can have rotation attributes which are applied before the system rotation attribute. This is particularly important for systems with multiple screens in different orientations (e.g. some Jaleco rhythm games).
For systems that used standard monitor electronics where the screens themselves do not have rotation attributes, 0° and 180° will result in horizontal screens while 90° and 270° will result in vertical screens. However, there are some systems that had vertical screens scanned from top to bottom (e.g. Apple’s Macintosh Portrait Display and the Xerox Alto).

Can we see in the XML if a monitor uses rotation attributes or not? I ask this in order to know if I can use your guideline for hor/vert screen on standard monitor electronics.

The rotate attribute on the display element has the per-screen rotation as well as the system rotation applied. See stepstag for an example of a game with multiple screens in different orientations.

[ghost]

where is upright/cocktail of the machine specified?

It isn’t. Some machines support both depending on settings, others support only one or the other.

So MAME only knows this in the source code but it isn't exported to the XML, correct?

No, MAME does not know this in the source code.

How was it once possible then to export "cocktail" to XML even if it's NOT known in the source code? How could it be exported then in older MAME versions?
This tool seems to have a way to read upright/cocktail from the XML (of older MAME versions), see screenshot.
In the source code you can see they search for 'cocktail="1"'

https://www.waste.org/~winkles/ROMLister/

I was also wondering what changed in MAME so it's not in XML at current version anymore?

there is a "rotate" attribute of the tag that can have values 0, 90, 180 or 270
Which of those represent horizontal or vertical screen?

It’s more complex than that. Individual screens can have rotation attributes which are applied before the system rotation attribute. This is particularly important for systems with multiple screens in different orientations (e.g. some Jaleco rhythm games).
For systems that used standard monitor electronics where the screens themselves do not have rotation attributes, 0° and 180° will result in horizontal screens while 90° and 270° will result in vertical screens. However, there are some systems that had vertical screens scanned from top to bottom (e.g. Apple’s Macintosh Portrait Display and the Xerox Alto).

Can we see in the XML if a monitor uses rotation attributes or not? I ask this in order to know if I can use your guideline for hor/vert screen on standard monitor electronics.

The rotate attribute on the display element has the per-screen rotation as well as the system rotation applied. See stepstag for an example of a game with multiple screens in different orientations.

So can I use 0° and 180° to determine the screen is horizontal and 90° and 270° for vertical for all machines of the complete XML file or is this not always true? I don't understand it 100%.

So the example stepstag has 3 horizontal screens (rotate 0) and 2 vertical screens (rotate 270)? Can you confirm this is correct?

<display tag="lscreen" type="raster" rotate="270" width="352" height="240" refresh="59.940060" pixclock="27000000" htotal="858" hbend="0" hbstart="352" vtotal="525" vbend="0" vbstart="240" /> <display tag="mscreen" type="raster" rotate="0" width="352" height="240" refresh="59.940060" pixclock="27000000" htotal="858" hbend="0" hbstart="352" vtotal="525" vbend="0" vbstart="240" /> <display tag="rscreen" type="raster" rotate="270" width="352" height="240" refresh="59.940060" pixclock="27000000" htotal="858" hbend="0" hbstart="352" vtotal="525" vbend="0" vbstart="240" /> <display tag="screen" type="raster" rotate="0" width="320" height="224" refresh="59.410646" pixclock="6000000" htotal="384" hbend="0" hbstart="320" vtotal="263" vbend="0" vbstart="224" /> <display tag="jaleco_vj_pc:pci:10.0:screen" type="raster" rotate="0" width="640" height="480" refresh="53.178707" pixclock="25174800" htotal="900" hbend="0" hbstart="640" vtotal="526" vbend="0" vbstart="480" />

[cuavas]

How was it once possible then to export "cocktail" to XML even if it's NOT known in the source code? How could it be exported then in older MAME versions?

You’re misunderstanding what that flag meant. That flag only indicated whether screen flipping was incorrectly emulated in cocktail mode for games that have this feature. The two possible states were:

• Game has cocktail mode feature, MAME does not emulate it correctly.
• Game lacks cocktail mode feature, or game has cocktail mode feature and MAME emulates it correctly.

There was never a way to distinguish between correctly emulated cocktail mode and lack of cocktail mode.

I was also wondering what changed in MAME so it's not in XML at current version anymore?

Largely because people were misinterpreting it the way you have, but also because the way emulation status flags work had to be expanded to work with slot devices.

So can I use 0° and 180° to determine the screen is horizontal and 90° and 270° for vertical for all machines of the complete XML file or is this not always true? I don't understand it 100%.

It isn’t 100% true because there are systems with “tall” displays. These could be CRTs with unconventional raster patterns, or dot matrix displays (LCD, plasma, LED) that are taller than they are wide.

So the example stepstag has 3 horizontal screens (rotate 0) and 2 vertical screens (rotate 270)? Can you confirm this is correct?

Yes, that is correct for that example.

[ghost]

I also had a question about the possible <control> tags.
I found following values:

• dial: ? (what control is it)
• doublejoy
• gambling
• hanafuda
• joy
• keyboard
• keypad
• lightgun
• mahjong
• mouse
• only_buttons
• paddle
• pedal
• positional: ? (what control is it)
• stick: ? (difference between joy and stick?)
• trackball
• triplejoy: ? (see example?)

Questions:

• Could you explain what the controls indicated with "?" are and especially between brackets?

• example for triplejoy: the game wizzard has a triplejoy like this

<control type="triplejoy" player="1" buttons="2" ways="16" ways2="vertical2" ways3="vertical2"/>

Can you explain the ways2 and way3? What does it mean exactly?

• Then I also found an example of a machine that seems to have both a mahjong and a hanafuda control. It's the machine sc4winspy, a fruit machine.
  Can you explain how it can have those 2 controls at the same time? Neither of them apply to a fruit machine... but in XML both of them seem to be present.
  I was not sure how to understand this and maybe it's a bug?

[cuavas]

dial

Single axis incremental encoder without limit stops and without detents. Typically a dial or wheel that can be rotated infinitely in either direction (e.g. some driving games, Tempest, Arkanoid).

positional

Some kind of multi-position selector. Dials or sliders with detents are examples. These don’t work very well with MAME’s current input system.

stick

stick is for displacement-sensitive sticks (e.g. joystick using ADC, Gray code encoder, incremental encode with limit stops, 49-way joysticks). `joy' is used for sticks that have at most one switch for each cardinal direction.

triplejoy

Happens when a system has JOYSTICK, JOYSTICKLEFT and JOYSTICKRIGHT inputs for a single player position.

Can you explain the ways2 and way3?

Exactly what it says – a stick with a gate that limits it to two or three cardinal directions.

Then I also found an example of a machine that seems to have both a mahjong and a hanafuda control. It's the machine sc4winspy, a fruit machine.
Can you explain how it can have those 2 controls at the same time? Neither of them apply to a fruit machine... but in XML both of them seem to be present.

It’s using arbitrary unique unique input types.

[ghost]

I also have something I don't understand of the <control> tag with type="joy".

• The game a51site4 has a joy with following specs:

<control type="joy" player="1" buttons="9" ways="5 (half8)"/>

How exactly can a joystick have 5 ways and what does "(half8)" mean? Where is the 5th way located then on the joystick?

• Another example is armwrest which has this joy

<control type="joy" buttons="1" ways="3 (half4)"/>

How exactly can a joystick have 3 ways and what does "(half4)" mean? Where is the 3th way located then on the joystick?

I thought a joystick only could have a multiple of 2, like 2-way, 4-way, 8-way or 16-way (which are the case in all other machines).
The numbers 3 and 5 is strange here and I can't imagine how this works (technically since the different ways are on a circle opposed to each other)
Can you explain please?

In addition I also wanted to know what these "strange" joy ways mean:

• game bmcpokr

<control type="joy" player="1" ways="strange2"/>
What does strange2 mean?

• game 500gp

<control type="joy" player="1" buttons="3" ways="vertical2"/>
What does vertical2 mean?

[cuavas]

How exactly can a joystick have 5 ways and what does "(half8)" mean? Where is the 5th way located then on the joystick?

Think about what would happen if you had an 8-way joystick and removed just one of the microswitches.

How exactly can a joystick have 3 ways and what does "(half4)" mean? Where is the 3th way located then on the joystick?

Think about what would happen if you had a 4-way joystick and removed just one of the microswitches.

In addition I also wanted to know what these "strange" joy ways mean:

Two directions that are not diametrically opposed to each other.

[ghost]

@cuavas : do you think there is a way to filter out all games that support cocktail mode by looking at the dipswitches values in the XML?
If yes, what should I look for?

[cuavas]

do you think there is a way to filter out all games that support cocktail mode by looking at the dipswitches values in the XML?

No, there is not. Some games only support cocktail mode, some have cocktail mode enabled by some mechanism other than DIP switches.

[ghost]

do you think there is a way to filter out all games that support cocktail mode by looking at the dipswitches values in the XML?

No, there is not. Some games only support cocktail mode, some have cocktail mode enabled by some mechanism other than DIP switches.

Can I ask a final question here?
The other mechanism to enable cocktail mode: is it in the service menu (F2 in MAME) of the game?

[cuavas]

I think I’m going to stop reading this discussion. You need to take the time to look at the inputs for the systems yourself and see what arrangement of inputs each one has. Besides that, the input information in the XML is really just informative, it doesn’t give you detailed information on the arrangement of controls or how they’re used.