Reading MAME as technical reference and historical document: 720 controller

[abaraba]

Quote from: CheffoJeffo
Interesting ... I just had a look at the plans for the 720 controller to see if there was a reason for this particular change and couldn't see a reason why it wouldn't be handled as a spinner.

So, do I understand that it can be handled via "-mouse", so that any of the optical interfaces should work and no changes to MAME are required ?
----------

aba: I tried about dozen binaries from mame60 to mame131 and mouse would be automatically mapped to controls if mouse was enabled, which I believe directly means authentic controller can be used, and so that this functionality was there all along, no changes required. -- Yes, this is completely absurd considering there is 8 years worth of threads on this forum with people arguing about it, so I am too kind of waiting someone will explain what in the world is going on.

Objection still stands that *as a historical document* MAME should be clear actual 720 PCB used spinner.

[BadMouth]

Not really a response to your post, but an interesting read nonetheless:

http://jstookey.com/arcade/720/720-arcadejoy.php
(How to use your original 720 controls with MAME, a bit outdated, but still useful.  Custom compiled mame .110 link still works)

The change to analogue joystick was at this version:
"0.85u1: Aaron Giles changed 720' controls to use an analog joystick instead of a dial so that the original controller motion can be replicated"

The technical section of the history.dat file has:
"The main control is also unique. This joystick moves in a circular fashion, instead of in compass directions like standard joysticks."

I find that a bit misleading as it doesn't mention that the joystick was actually rotating optical encoder discs.
It's not important enough to me to write up a better description, but if you're passionate about preserving the details of the controls,
you can write up a better description and submit it here: http://www.arcade-history.com/index.php?page=status&action=update

EDIT: Direct link to 720 Degrees page on arcade-history: http://www.arcade-history.com/?n=720degree&page=detail&id=23
Click on the "Edit this page" tab to submit your revisions.

[abaraba]

Thank you. I support initiative to turn 'all the talk' into some results and solutions, otherwise it would mean we are just talking about nothing that actually matters, with no good, or particular reason.



Anyhow, there actually is statement on MAME website about it:

http://mamedev.org/devwiki/index.php/FAQ:Games#720_Degrees

"720 Degrees

This game uses a spinner control, right?

The original controller for 720 Degrees was a joystick that was hardware-limited to only travel along the outermost edges in a circle. The internal mechanism for reading this control was similar to a spinner except that it had the additional benefit of knowing which direction the joystick was pointing. Because this knowledge is an important aspect of the game, the current emulation of the controller maps an analog joystick to the underlying controls instead of a spinner."


I read it like this:
- Original game uses spinner, this is important knowledge so we map it to analog stick instead. Whaaaaat!?

The word "instead" automatically makes that sentence logical impossibility, in relation to accuracy. Never can "B" be a better "A" than "A" itself, or as Xiaou2 would say, "Substituting Hotdog for Beef in Beef stew is no longer Beef Stew."

[MonMotha]

Anyone who honestly believes MAME is about "historical documentation" is nuts, in my opinion.  MAME is about working emulation of popular games.  I've attempted to read MAME source code to replicate custom hardware devices before, and you're lucky if there's a single damn comment next to the write-only spaghetti nonsense code.  There are places where one could spend literally hours poring over weird bitmasks, shifts, oddball state machines, etc. all to deduce what a simple, one or two line comment could have conveyed to someone wishing to understand how things actually work (rather than simply emulating it) in about 5 seconds.

That said, this is probably being done because the original controls don't map neatly into MAME's concept of "controls".  The original device appears to be an incremental encoder (aka "spinner") with another output that serves as an index output (but could also be used to count turns, I guess).  I doubt MAME's "spinner" support correctly handles indexes (as most arcade controls don't have one), so that's probably why it was mapped to an analog input, instead - analog inputs are always absolute in MAME's limited view of "arcade controls" whereas encoder/"spinner" inputs are likely always considered relative.

[Paul Olson]

From reading about this, it looks like the analog control scheme is the only way to simulate the feel of the original controller. You can spin the analog joystick around the edges, and the code in the atarisys2 driver will respond to that input in a similar fashion to the original dial controller. It is not possible to simulate that with a mouse. There is no x and y axis to make that work. It uses a dial, which is only one axis. The second encoder takes care of the positional direction of the player. The analog code is great if you have an analog joystick.

If you want to use the real controller, the code in the driver needs to be changed back to what was there before .85u1. The logic needs to be changed, and the LETA0 and LETA1 need to be changed back to dial instead of analog. I think I have this done right, but I don't have a controller to test it. I am going to try to pick one up soon to test it out. Just hacking the driver back isn't what is really needed though. What is needed is a flag that can be set in mame.ini to enable the original controls. I still have a lot to learn before I can make that work, but I think that is what should be done.

[abaraba]

If you want to use the real controller, the code in the driver needs to be changed back to what was there before .85u1. The logic needs to be changed, and the LETA0 and LETA1 need to be changed back to dial instead of analog.

Did we not already discuss this when I said use "mame 720 -mouse" and everything will work just fine with plain unmodified MAME binaries, before and after .85. -- What you are talking about are just SCREEN NAMES, mouse gets mapped together/over, or instead of default input, when you enable the mouse, regardless of whether that input is named "Dial" or "Analog Stick".

E.g. (TAB - "controls document")

Analog Stick X ---- "Mouse X"

First one is just a LABEL, a 'screen name', not reference to how input is handled. It is supposed to be TECHNICAL REFERENCE, it is supposed to be historically accurate - it should describe the type of input signal that goes into PCB. So, if I am trying to repair actual 720 board, MAME should not fool me into trying to make it work with analog joystick. Therefore, for 720 degrees, the first 'label' should say "spinner", "quadrature encoding" or something among those lines, while the second piece of info in that *document* is reference to your current settings and device mapping - can be set to mouse, keys, analog stick and whatever else is there.
 

[Paul Olson]

I realize that it works with a mouse. The issue is whether or not it works with an actual 720 controller. The code that was used for the dual rotary encoder is no longer there...it was replaced with the code for the analog controller. MAME needs that code to handle the positional encoder. It may work fine without, I have no way to test that yet. It shouldn't work right though...that funky second encoder wheel shouldn't work without specific code to handle it.

[abaraba]

Second (calibration) spinner input works too, I also explained how to test it.

This is already all confusing, and you jumped from:
- "If newer versions work with a mouse, what doesn't work with a real controller?"

...to saying "it does not work".


Let's first answer your prior question, lets not try to fix what already works.


Xiaou is saying - authentic controller work no more, it needs to be fixed.

Haze is saying - authentic controller work no more, but that's fine, analog is better.

I'm saying - everything works, everything was working all along, only screen names changed and should be renamed to "spinner", or at least back to "dial", although I'd call it "optical_quadrature_spinner".


So, in other words, I completely agree with what you were saying just before - the true mystery is this:

- If newer versions work with a mouse, what doesn't work with a real controller?

[newmanfamilyvlogs]

The original controller for 720 Degrees was a joystick that was hardware-limited to only travel along the outermost edges in a circle. The internal mechanism for reading this control was similar to a spinner except that it had the additional benefit of knowing which direction the joystick was pointing. Because this knowledge is an important aspect of the game, the current emulation of the controller maps an analog joystick to the underlying controls instead of a spinner."


I read it like this:
- Original game uses spinner, this is important knowledge so we map it to analog stick instead. Whaaaaat!?

The word "instead" automatically makes that sentence logical impossibility, in relation to accuracy. Never can "B" be a better "A" than "A" itself, or as Xiaou2 would say, "Substituting Hotdog for Beef in Beef stew is no longer Beef Stew."

"This knowledge" is referring to the knowledge of the direction in which the stick is pointing, not that it used a spinner. It's not logically impossible, it's ambiguous. There's a difference.

[abaraba]

"This knowledge" is referring to the knowledge of the direction in which the stick is pointing, not that it used a spinner. It's not logically impossible, it's ambiguous. There's a difference.

Ok, I agree.

Still, no need for "instead", it should be "also".

Anyone who honestly believes MAME is about "historical documentation" is nuts, in my opinion.

Perhaps. Can't disagree really.

Hopefully, I am more of --that which squirrels like-- than --that which hangs under penis-- type of naive person.

[BadMouth]

...that funky second encoder wheel shouldn't work without specific code to handle it.

That's the way I see it, but it's all just speculation without a special controller to test it (or being able to tell from looking at the code, which is beyond my ability).
For all the ranting about the mame not working with the original controls, there sure doesn't seem to be anyone with the original controls stepping forward to test it.  

Thanks for taking an interest in it Paul.  

According to the article I linked to earlier, if the code is there, it should move the skater dude to the 12 o'clock position when it crosses those slots.  This should be easy enough to test with an old rollerball mouse; the guy should reset to the 12 o'clock position whenever the Y axis is moved at all since the orginal encoder wheel only had slots at 12 o'clock.

If this is how it works, a more authentic control scheme for someone with a regular spinner might be to have a button press simulate the calibration wheel passing the 12 o'clock position.  (Just mapping a key to that axis might work without changing anything) That way, if you have an indentation or dot on one side of your spinner, you could move that to 12'oclock, press a button to align it, and your skater punk dude should always face the direction of the indentation on the spinner from then on.  Hell, you could even make a 720 handle for a TurboTwist.  If the game resets the center point every time you crash though, like pole position does, it would be too much of a hassle to realign after every crash.

[newmanfamilyvlogs]

Still, no need for "instead", it should be "also".

That's a rather ambiguous statement itself. You cannot directly substitute 'also' for 'instead' in that sentence without rewriting the rest of it to accommodate the change. I'm under the impression that English is not your first language, so perhaps the nuance is lost on you, leading to your original confusion.

[Xiaou2]

I have not fired up 720 for a long time after the change..  so just did so with MameUIFX32, and noted the changes.

 Currently, you can NOT move the guy in a complete circle with a single optical axis.
Meaning... if you want to aim the guy with a spinner... it will only aim him 1/2 or less of his full travel.

 Why is this?

 Because they changed the games optical inputs to act more like a Trackball instead.  You need x & y to make the guy move in a full circle... which leaves out the calibration disc/switch altogether.

 Because of this, its Impossible to make the game control with a spinner, let alone get the guy to calibrate with a stick mounted spinner.

 Ill have to double check official mame to make sure its the same... but Im guessing it is.

[BadMouth]

From that other thread:

Make a system that is handled by the Core UI; Input; Input Port code that can select between real and fake controls. 

Seriously, start MAME and have a look, it's all already there.

There is no need for "real" and "fake", one is simply mapping of input to analog stick and the other is mapping to mouse, just like with all the other games. Piece of code handling input via analog port has nothing to do with keyboard and mouse handling code.

Then change the Input port code in the drivers to use it.  The UI would allow you to select the real control or a fake control that would call a driver function to modify the data.

It's all already there, except it's called "mouse" and "analog", not "real" and "fake".

What control setup did you us to test this?

Just tried this w/v.140 and it doesn't work. 
(I took the ball out of an old mouse and spun the encoder wheels independently by hand)
The guy will not rotate when you only map the x axis, he will only flip back and forth between facing left and right.
If you map both, he will kinda rotate, but only from about 4 t0 8 o'clock.

If you move the mouse in a circular motion, you can control the guy, but you're just substituting mouse x/y input for analogue joystick x/y input at that point.
That has nothing to do with the way the original controller functioned.

I downloaded the mame v.110 build that was recompiled to work with the original controller, but I haven't tried it yet.
I'm not sure if/when I'll bother with it.

[abaraba]

What control setup did you us to test this?

Just tried this w/v.140 and it doesn't work.  
(I took the ball out of an old mouse and spun the encoder wheels independently by hand)

My ROM does not work with latest mame so I only could try it with up to mame 131.

Please you try 131 so we can find some common grounds and start from there.

The guy will not rotate when you only map the x axis, he will only flip back and forth between facing left and right.
If you map both, he will kinda rotate, but only from about 4 t0 8 o'clock.

If you move the mouse in a circular motion, you can control the guy, but you're just substituting mouse x/y input for analogue joystick x/y input at that point.

That has nothing to do with the way the original controller functioned.

I think you found it. It's just that it is not the same problem Xiaou started complaining 8 years ago, this is something new. What you describe clearly tells us what they did there, they made analog hack and then implemented mouse on top of it, instead of separately.

[abaraba]

I have not fired up 720 for a long time after the change..  so just did so with MameUIFX32, and noted the changes.

Please, step by step.

You are complaining about MAME not MameUIFX32, please let's not complicate - get plain mainstream build. Get MAME 131 where I confirmed both spinners work from mouse point of view, and tell me does that work for you or not, we have to have some common reference.

[SavannahLion]

To be fair.....

Why ask us to downgrade when you should make the effort to lock step with us? To put it simply, go upgrade your ROM and MAME versions.

[Paul Olson]

The common reference should always be the latest version of MAME. It makes no sense to test against code that is not current. You should be able to update the roms with clrMAMEpro.

What code did you change in this driver? You said you already made the needed changes.

[Lilwolf]

Didn't analog+ mame run 720 perfectly?

I have a controller, never hooked it up because I was missing the optics and a few parts could have been updated... And it doesn't fit in my home cabinet.  I then got a refurb kit and never installed it. 

I really should get it out...  I love 720.   Great game!  I used to be able to get all gold medals... but with current controls...  I'm lucky to get a bronze

[Paul Olson]

Didn't analog+ mame run 720 perfectly?

I have a controller, never hooked it up because I was missing the optics and a few parts could have been updated... And it doesn't fit in my home cabinet.  I then got a refurb kit and never installed it. 

I really should get it out...  I love 720.   Great game!  I used to be able to get all gold medals... but with current controls...  I'm lucky to get a bronze

Current MAME uses the Analog+ code so the game can be played with an analog joystick. Please test the current MAME with your controller if you get the chance. the original MAME code that worked with the controller was replaced with the analog code. It has been suggested that it still works with the controller, but you are the first person I have heard from that has the controller to test with.

If you get your controller hooked up, please let me know if you would be willing to test a build for me. I went back to the original code and modified it to work with the state system (hopefully correctly). I can send you the atarisys2.c file, or a can compile a binary for you, whichever you would prefer. I have it compiled for MAME64 now, but I should be able to do a 32 bit build if you need it.

I am thinking about getting a controller. How deep is it underneath the panel? I am not sure if it will fit in my cp either.

thanks

[BadMouth]

Didn't analog+ mame run 720 perfectly?

I have a controller, never hooked it up because I was missing the optics and a few parts could have been updated... And it doesn't fit in my home cabinet.  I then got a refurb kit and never installed it. 

I really should get it out...  I love 720.   Great game!  I used to be able to get all gold medals... but with current controls...  I'm lucky to get a bronze

See the link in my first post on this thread.  Everything you need to know about interfacing it there.

[Paul Olson]

That code won't work in the current version. That was before the state system was added. the original driver mapped LETA0 and LETA1 together, both at 30%. The games in the driver are now also all based on the Paperboy settings, and modified from there when needed. If anyone wants to test it, I will send you my atarisys2.c or a binary. I don't know if it will work as is, but I would appreciate the testing if you can do it.

[abaraba]

To be fair.....

Why ask us to downgrade when you should make the effort to lock step with us? To put it simply, go upgrade your ROM and MAME versions.

I'm not asking you to downgrade but to help me narrow down what, where and when went wrong.

BadMouth established it does not work with latest MAME, great.

Next step is to find where it was working last time so I have reference to both, the latest working code and what I should be looking for when I test it. So, can you help me test mame from 131 up to where the mouse stopped working properly, and I will do what you suggested, ok?

[abaraba]

Didn't analog+ mame run 720 perfectly?

I have a controller, never hooked it up because I was missing the optics and a few parts could have been updated... And it doesn't fit in my home cabinet.  I then got a refurb kit and never installed it. 

I really should get it out...  I love 720.   Great game!  I used to be able to get all gold medals... but with current controls...  I'm lucky to get a bronze

Please do me a favor in order to establish latest working version.


Get plain unmodified binary of mame 131 and run:

mame 720 - mouse


And if you can do the same with version 90, see if both of those work, and whether is one anyhow "better" than the other.

[Xiaou2]

# 0.139u3: Aaron Giles moved the old hard-coded EEPROM data out into a file in 720.
# 0.124u3: Aaron Giles removed ancient 720 kludge in the T-11 core. Also added support in the T-11 core for an external vector via irq_callback. Apparently the hardware actually did support this and it is necessary for emulating the BK 0010/11 computer in MESS.
# 0.122u5: Changed M6502 CPU1 clock speed to 1789772 Hz and VSync to 60.096154 Hz.

# 0.85u1: Aaron Giles changed 720' controls to use an analog joystick instead of a dial so that the original controller motion can be replicated. Thanks to MAME Analog+ for the logic.

http://maws.mameworld.info/maws/set/720

 According to Maws, 0,85u1 changed to accept Analog controls as the main way to control 720.  However, Im not sure if the calibration wheel was taken away right at that time.  In fact, it Might have been made as a digital button at one point in time.

 As far as I remember, there was some interesting news about the calibration being added.. but then it wasnt much long after that, the analog stick changes were made.

 Remember, to test the rotation in Any of these builds, make sure to first clear ALL of the mouse inputs to "None".  Then map a single Axis of the mouse to ONE of the inputs (should be X axis).  If the man is not able to rotate a complete 360, then its wrong.  The way it currently works, is that you need to map both x & y to make the gun spin.  Basically acting as a trackball, and not a real spinner.

 Also remember, a lot of people would be upset if there was no way to use the analog stick hack as well... so there should be a way to select either method of control.

[abaraba]

[DELETED]

my testing was lazy and I got fooled by analog hack, I was wrong - it does not work in MAME 131.

It works as BadMouth and Xiaou have described, and that would not work with authentic controller.


MAME needs fixing.

[Paul Olson]

.141 won't spin all the way around. With my modified version, you can spin around fine with one axis of the mouse. I have both encoders mapped to the same input (mouse x) as they were in the .85 driver. It still needs to be tested on a real controller, but it is playable with the mouse (I am testing it on my laptops trackpad). Certainly not as fun as with the controller...The analog hack would definitely make it more playable for those without the controller.

Here is the atarisys2.c file (rename it after download). Please test it with a real controller if you can. Thanks

[abaraba]

Got it, I should know everything about it now.

I was wrong about these, this is the truth:
- it does not work properly with MAME, I was fooled by analog hack
- it never worked properly with both encoders in any version of MAME

Sorry for confusion, analog hack + laptop touchpad indeed can produce illusion that it works. I now got ball-mouse to test axes separately and precisely, and also PS2 controller to test 'analog hack' too.


Paul Olson,

This is how to make it work properly, with encoder wheel too:

Code: [Select]

static READ8_HANDLER( leta_r ){
   static const char *const letanames[] = { "LETA0", "LETA1", "LETA2", "LETA3" };
   atarisy2_state *state = space->machine->driver_data<atarisy2_state>();

if(state->pedal_count == -1)   /* 720 */
{
switch (offset & 3)
{
case 0: return input_port_read(space->machine, "LETA1") & 0xff;
case 1: return input_port_read(space->machine, "LETA0") & 0xff;
case 2: return 0xff;
case 3: return 0xff;
}
}
   return input_port_read(space->machine, letanames[offset & 3]);
}

You do not need to change anything down below, those are just 'labels'.

To make your version work just "open" calibration input too:

  case 0: return input_port_read(space->machine, "LETA1") & 0xff;  <-- calibration encoder input
  case 1: return input_port_read(space->machine, "LETA0") & 0xff;  <-- main encoder input
      

Where can I upload binary for testing?

Analog hack completely sucks, it's unplayable. It would work all right I suppose if I could mechanically restrict my stick to keep maximum angle, but as it is - it's ugly, player orientation jumps all over the place, it flickers and it looks buggy, but funny enough it works pretty good with laptop mouse touchpad, just "draw circles" with a finger.

Can support for authentic controller and analog hack exist together? Of course they can!

[Malenko]

I cant wait until a good game gets this kind of attention

[Hoopz]

I cant wait until a good game gets this kind of attention

You're gonna get deathpunched if you sass this game...

 

[BadMouth]

I cant wait until a good game gets this kind of attention

 

I'm hoping eventually that it leads to an option in the official build to choose how the controls function.
In particular, the option to turn off the toggle hack for the hi/lo shifters on classic driving games.

[abaraba]

I cant wait until a good game gets this kind of attention

 

I'm hoping eventually that it leads to an option in the official build to choose how the controls function.
In particular, the option to turn off the toggle hack for the hi/lo shifters on classic driving games.

I have couple of more days to waste, so I will make work whatever is requested and can be tested. If we could only speed up things a little bit. I mean, if only someone else also tested that bloody version 131, I would not be confusing everyone, and myself, with it for two days.  


So, what's the story with those shifters? Links will do...

[ErikRuud]

Are the links that were posted in the other thread OK?

http://forum.arcadecontrols.com/index.php?topic=107935.msg1151548#msg1151548

 

[abaraba]

Are the links that were posted in the other thread OK?

http://forum.arcadecontrols.com/index.php?topic=107935.msg1151548#msg1151548

 

Ok, I'm gonna look at it. Could you put up a quick summary, few words, so everyone knows what's it about?

[Paul Olson]

Are you using the analog stick the way the original controller is used? Spinning around the outside instead of pointing in a certain direction? I don't think I have ever heard any complaints about how the game works with an analog stick.

I think the code that you posted works the same as what I have. LETA0 shifted 8 bits right is LETA1 (just assuming that from the .85 code). I think this is probably what the devs are talking about when they say they don't want unmaintainable code in the core. You assume that the lower code is just a label, so you just ignore it. What you are leaving it with is no way to adjust the inputs in the game tab menu. All of the system 2 games include the paperboy settings and then are modified on a per game basis. LETA0 and LETA 1 are unused in Paperboy, so you will not have any option to change them for the game. You can also set the sensitivity of the dial device there. Probably more importantly, even with the code changed to support the dial, to everyone who tries to use it, it will look like they are supposed to use an analog stick. Isn't that the original complaint?


If anyone has specific issues for other games that need some work, please start a thread describing it. I can't guarantee that I will be able to fix it, but I will be happy to take a look. Specific tasks will help me learn how MAME works better; left to my own devices, I spend too much time just reading the code. Like I have said before, I just started actually looking at the code, so I don't know much about it yet.

When I get my cab updated to the current MAME version, I want to try to help with Howard's output project. I have wanted that functionality for a long time, so I am really happy to see it being worked on.

[BadMouth]

So, what's the story with those shifters? Links will do...

It's not so much the shifters themselves.
There are older and custom compiled versions of mame that address the issue and make the games function as they should with the original shifter.
It probably wouldn't be that hard to modify the current drivers and make it work, but that is just kicking the can down the road.

What is needed for them as well as the 720 controller, is an option in either the controls menu or ini file to choose between original or "playability"(what you call fake, the perfect term escapes me) control schemes. 

I can't code ---steaming pile of meadow muffin---
But I can tell you, for it to ever have a chance of making it into the main build:
It has to adhere to all current mame coding conventions, whatever they may be.
It has to be systematic, so the options are implemeneted the same way in every affected driver and people who write new drivers in the future know how to use the option.
It can't break anything.
They shouldn't be bothered with it until it's compleete and worthy of inclusion.

That much I understand.

And people, including the mamedevs, have free will. 
They can do whatever they want, including rejecting it for any or no reason.
Given all the grief they've been given over the issue,
the only way to get it into the main build is to present them with something that there is no absolutely no reason to reject.
That's one tall order.

[Derrick Renaud]

I can't code ---steaming pile of meadow muffin---
But I can tell you, for it to ever have a chance of making it into the main build:
It has to adhere to all current mame coding conventions, whatever they may be.
It has to be systematic, so the options are implemeneted the same way in every affected driver and people who write new drivers in the future know how to use the option.
It can't break anything.
They shouldn't be bothered with it until it's compleete and worthy of inclusion.

That much I understand.

And people, including the mamedevs, have free will. 
They can do whatever they want, including rejecting it for any or no reason.
Given all the grief they've been given over the issue,
the only way to get it into the main build is to present them with something that there is no absolutely no reason to reject.
That's one tall order.

 
Wow, someone does understand.
Thanks.
D.

[Hoopz]

I can't code ---steaming pile of meadow muffin---
But I can tell you, for it to ever have a chance of making it into the main build:
It has to adhere to all current mame coding conventions, whatever they may be.
It has to be systematic, so the options are implemeneted the same way in every affected driver and people who write new drivers in the future know how to use the option.
It can't break anything.
They shouldn't be bothered with it until it's compleete and worthy of inclusion.

That much I understand.

And people, including the mamedevs, have free will. 
They can do whatever they want, including rejecting it for any or no reason.
Given all the grief they've been given over the issue,
the only way to get it into the main build is to present them with something that there is no absolutely no reason to reject.
That's one tall order.

 
Wow, someone does understand.
Thanks.
D.

To be fair, I think the vast majority here (and elsewhere) do fully understand and accept Mame as it is.  It's a few bad apples that spoil the bunch. 

My analogy (as opposed to the crazy analogies from others) is that the Mame users are probably split along the bell curve.  You have a few that understand all of the ins and outs of the code and are willing to help make changes, a few that ---smurfette--- because they can't understand the code and demand changes, and the vast majority simply accept it the way it is and don't raise a ruckus. 

Unfortunately, it's the small percentage that act like 4 year olds that get all the attention.

[Derrick Renaud]

To be fair, I think the vast majority here (and elsewhere) do fully understand and accept Mame as it is.  It's a few bad apples that spoil the bunch. 

My analogy (as opposed to the crazy analogies from others) is that the Mame users are probably split along the bell curve.  You have a few that understand all of the ins and outs of the code and are willing to help make changes, a few that ---smurfette--- because they can't understand the code and demand changes, and the vast majority simply accept it the way it is and don't raise a ruckus. 

Unfortunately, it's the small percentage that act like 4 year olds that get all the attention.

Thanks.

Personally I don't mind discussions based on facts.  They lead to progress.  But when they rant on and on using only untested guesses, all the while telling others they are wrong. That is what I have a problem with and would like to clarify for others, lest they mistakenly believe the garbage put forth.

I have even said repeatedly, that a better input system would be accepted if it was properly coded based on MAME coding standards and, well, the points BadMouth made.  I even provided guidelines for adding true shifter support.  It was what I planned on doing before all the negativity in the past year.

But this is always ignored in favour of rants and demands.  Where there time would be better spent on finding someone willing to write the code.

[Derrick Renaud]

Let's make things easier.  I'll try to walk you folks through it so you can learn to write the code.

Goal: make the current fake control and real control exist in parallel with the minimal amount of clean code possible.

Known: current controls are absolute (IPT_AD_STICK_X) and are converted to relative.  This was done in ver 85u1.

Step 1. modify the "INPUT_PORTS_START( 720 )" section to add the relative controls from pre 85u1 back in to exist with the current controls.

Step 2. modify the "READ8_HANDLER( leta_r )" section to check if the new relative ports have changed.  If so return that data.  If not, then return the fake data if it changed.

Step 3. clean up code and add comments as needed.

Step 4.  buy stock in 720 controls for the thousands of cabs that will now use them.

Let's see the code.