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.
 

[abaraba]

Are you using the analog stick the way the original controller is used? Spinning around the outside instead of pointing in a certain direction?

Yes. Even when I do it very slowly rotation is not smooth, it jitters and flickers, plus rotation step itself is much more coarse than with mouse, for some reason.

When I try just to point some direction it sometimes works, diagonals hardly where I want it to, and sometimes orientation gets mixed so when I point up it faces left, huh?! It looks like cos/sin & sign/overflow issue, but it strangely does not happen with circling mouse.

Anyone else with analog joystick around here?

I don't think I have ever heard any complaints about how the game works with an analog stick.

I would be surprised if anyone would even care to play it like that. If you try to spin it fast you can't help but let it off the edge a bit, and every time you do so it flickers and jitters even more. -- With arcade trackball or spinner, you could perhaps go for some pretty high-score, but with analog stick - no way.

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).

You can test it pretty well with a ball-mouse, if you take it apart and spin encoder wheels separately.

 
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.

Yes, there are some adjustments to be made, what I mean is this...

   PORT_MODIFY("LETA0")   
   PORT_BIT( 0xffff, 0x0000, IPT_DIAL ) PORT_SENSITIVITY(50) PORT_KEYDELTA(10)

   PORT_MODIFY("LETA1")   
   PORT_BIT( 0xffff, 0x0000, IPT_DIAL_V ) PORT_SENSITIVITY(50) PORT_KEYDELTA(10)


I call my calibration input "DIAL_V", it could be just "DIAL" but with both of them set the same name it leaves tab menu bit unclear, so what I'm saying is that you can replace "IPT_DIAL" with "IPT_AD_STICK_X", "IPT_TRACKBALL_X", "IPT_POSITIONAL", "IPT_POSITIONAL_V"... and it would work just the same. -- Now, I am not testing this extensively, so there may be some unapparent differences.

You can also set the sensitivity of the dial device there.

Yes, those I call "small adjustments", for that we need someone with authentic controller.

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?

Yeah, I think for the moment it's best to set it to "dial", like with other spinner games.

[abaraba]

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.

Problem here is that authentic controller routine seem to work just fine whether this is initialized to relative or absolute, but 'anal_hack' routine requires absolute initialization.

So, if we set them to "DIAL" (relative) either anal_hack needs modification, or we need to branch code in initialization routine too. The easy way out would be to leave this initialization to "ANALOG_STICK", or maybe even better change it to "POSITIONAL" and "POSITIONAL_V" (also absolute).


Are you aware that analog hack, as it is, also makes it unplayable for keyboard?

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.

"new relative ports" - what variable(s) are you talking about?

I was thinking either to do it in real-time by checking some variable that contains info saying from which device signal originated,

or

...to simply to check whether analog joystick is plugged/enabled or not. So, if analog joystick is plugged in and MAME started up with "-joy", then enable analog hack, any other case go normal route, but do this at initialization time and forget later about it.



================
Shifters, let's start with the game people are actually interested to test.
  -- What is the game? What it does currently? What should it be doing?

[Gray_Area]

...but 'anal_hack' routine requires absolute initialization.

Umm.

I thought the reason for changing the code to analog stick support was that it also allowed it to be played by anyone with a digital joystick.

[abaraba]

Shifters
--------

The problem is most arcade 2-way (HI/LOW) shifters use only one switch, when held down it's one gear and when depressed it means it is shifted to the other gear.

When playing it with keyboard people do not want to hold down a key just so to stay in HI gear, so MAME implemented it with two switches, which then ruins it for authentic 1-switch interface.


Hardware solution: hack the shifter by placing second micro switch somewhere, while waiting on software solution.

Software solution: make it work with only 1 switch (toggle) so it works with authentic shifters, and tell people to map that input to 'Caps Lock' if they want to play it with keyboard.

[BadMouth]

Lets stay on 720 until the modified driver has been tested and verified to work properly with the original controller.
(This is the 720 thread)

Can you attach your modified driver as a text file, like Paul did?

Xiaou2, you seem to be the only one with an actually controller.
You were the one who started this mess.
Now it's time for you to do your part and do the testing.

Please try Paul's driver and report back.
Please try abaraba's driver if he uploads it.
(maybe you guys could upload an already compiled build to megaupload or somewhere?)

There are some sensitivity settings at the bottom of this page that might be helpful:
http://jstookey.com/arcade/720/720-arcadejoy.php

Having a driver that works with both input devices is the first step.
If it's not done, nothing will ever follow.

[Derrick Renaud]

blah, blah

Your continual incorrect info has still not produced any coexisting code.  Where is it?  To that matter, why has not anyone done so yet, seeing how it is such a demanding issue for the MAMEdevs to tackle.  You would think someone else interested would take the challenge.  No, they would rather waste their time ranting that others should do their bidding.

Keep trying.

BTW, as for 720 not being playable with the keyboard, it would not be playable with the original controller either.  So the point of that statement is?

That gets us back to my original statement that some kind of fake/real selection in the UI is needed.  This could call separate routines for real/fake analog joystick/fake digital joystick/etc.  But again you do not seem interested in creating the code .  And no MAMEdev is interested in it either.

[BadMouth]

ugh, I can't help myself...have to correct you.

so to stay in HI gear, so MAME implemented it with two switches, which then ruins it for authentic 1-switch interface.

Not two switches, one switch that toggles between hi & lo with each press.  Even if you have two switches on your shifter, both mapped to the toggle, it can get out of phase with the game and then your shifter works backwards.

That's just one of many shifter types.  They are 4 speeds with 3 switches that default to 1st when no switches are closed, there are 4 speeds with 4 switches, there are sequential shifters.  Some of the old games even had analogue joystick shifters.  I'm gonna start collecting/organizing information and think about how it should be implemented, so if anyone who can add it to the UI comes along, at least they'll have a little bit of a roadmap of what needs done.

Honestly, I don't want you working on it.

[SavannahLion]

ugh, I can't help myself...have to correct you.

so to stay in HI gear, so MAME implemented it with two switches, which then ruins it for authentic 1-switch interface.

Not two switches, one switch that toggles between hi & lo with each press.  Even if you have two switches on your shifter, both mapped to the toggle, it can get out of phase with the game and then your shifter works backwards.

That's just one of many shifter types.  They are 4 speeds with 3 switches that default to 1st when no switches are closed, there are 4 speeds with 4 switches, there are sequential shifters.  Some of the old games even had analogue joystick shifters.  I'm gonna start collecting/organizing information and think about how it should be implemented, so if anyone who can add it to the UI comes along, at least they'll have a little bit of a roadmap of what needs done.

Honestly, I don't want you working on it.

Thank you.

[abaraba]

Honestly, I don't want you working on it.

You do not want me working on it? Can you explain your concern?

[BadMouth]

You do not want me working on it? Can you explain your concern?

I can, but I choose not to take the time to do so.

[Derrick Renaud]

That's just one of many shifter types.  They are 4 speeds with 3 switches that default to 1st when no switches are closed, there are 4 speeds with 4 switches, there are sequential shifters.  Some of the old games even had analogue joystick shifters.  I'm gonna start collecting/organizing information and think about how it should be implemented, so if anyone who can add it to the UI comes along, at least they'll have a little bit of a roadmap of what needs done.

Read this thread, for my thoughts on adding shifter controls:
http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Board=news&Number=232699&Forum=news&Words=IPT_GEARSHIFT&Match=Entire%20Phrase&Searchpage=0&Limit=25&Old=allposts&Main=231686&Search=true#Post232699

The thing to remember for it to be a usefull submission is that it should make things easier, not just more per game hacks.  That is why IPT_GEARSHIFT needs to be defined to have a common interface for all shifters.  Then the UI code allows you to select what type of control you want to map to the original control.  The input code would then translate between the selected type and the original control.

Code along these lines would follow MAME conventions.

[abaraba]

Your continual incorrect info has still not produced any coexisting code.

What do you imagine is incorrect?

Code is produced, I'm waiting for place to upload it and someone to test it.

Where is it?

I have several versions of it. All you had to do is to pick one.

But sure I can also do it YOUR way, as you requested in Step 2:
- modify the "READ8_HANDLER( leta_r )" section to check if the new relative ports have changed.  

So, please explain what do you mean by "new relative ports" - what variable(s) are you talking about?

[Derrick Renaud]

So, please explain what do you mean by "new relative ports" - what variable(s) are you talking about?

Did you even read step 1 where you add the new relative ports?

If you have to ask what variables then you are not up to the task.  Sorry.

[newmanfamilyvlogs]

Code is produced, I'm waiting for place to upload it and someone to test it.

http://tinyurl.com/9k9f5m

[BadMouth]

Read this thread, for my thoughts on adding shifter controls

already bookmarked the first time it was mentioned 

[abaraba]

If you have to ask what variables then you are not up to the task.  Sorry.

No my friend, I want to show everyone you are talking nonsense.

"new relative ports" means NOTHING! That's why cat got your tongue, hehee!


You came up with your guidelines not only for me but everyone interested, like Paul, and we never said we are familiar with MAME code, but you offered to teach us and walk us through, did you not? So, please tell us what the hell did you mean by "new relative ports", what is it we should be checking for?

[abaraba]

Code is produced, I'm waiting for place to upload it and someone to test it.

http://tinyurl.com/9k9f5m

Thank you. I uploaded it there for you.

[CheffoJeffo]

Code is produced, I'm waiting for place to upload it and someone to test it.

http://tinyurl.com/9k9f5m

Thank you. I uploaded it there for you.

 

[SavannahLion]

Code is produced, I'm waiting for place to upload it and someone to test it.

http://tinyurl.com/9k9f5m

Thank you. I uploaded it there for you.

 

I don't normally click tinyurls but....

Damn... that was good. 

[newmanfamilyvlogs]

Code is produced, I'm waiting for place to upload it and someone to test it.

http://tinyurl.com/9k9f5m

Thank you. I uploaded it there for you.

[ErikRuud]

A double is insufficient!

[Derrick Renaud]

No my friend, I want to show everyone you are talking nonsense.

"new relative ports" means NOTHING! That's why cat got your tongue, hehee!

More rambling nonsense.  Too lazy to look up the definition of relative?  How about the word absolute?  Strangely a mouse produces relative data as does the real 720 control.  Step 1 (which you can not seem to read/understand,) says to add the real 720 ports.  An analog joystick produces absolute data.  The fact that I have to point this out to you means you are to lazy to do any work yourself.

Being arrogant is fine.  Spouting nonsense while pretending to be arrogant is pointless.

Trying to solve the coding question I asked and being wrong is fine.  It shows someone is trying.  No laughter from me, just helpfull hints.

Spouting nonsense is fine.  Bizarre, but fine.

Spouting nonsense while telling others they do not know what they are doing is not fine. I will call you out on it, just like I have been doing.

For others, I will post later some hints for step 1 code.

[abaraba]

 

m720.zip: http://www.mediafire.com/?x6l9szig4sekb12

I suppose you do not have authentic controller, so could you test it with arcade trackball and/or spinner, if you have them?

[abaraba]

More rambling nonsense.  Too lazy to look up the definition of relative?  How about the word absolute?  Strangely a mouse produces relative data as does the real 720 control.  Step 1 (which you can not seem to read/understand,) says to add the real 720 ports.  An analog joystick produces absolute data.  The fact that I have to point this out to you means you are to lazy to do any work yourself.

Being arrogant is fine.  Spouting nonsense while pretending to be arrogant is pointless.

I'm talking about context, not individual words, of course. I'm talking about Step 2:

- modify the "READ8_HANDLER( leta_r )" section to check if the new relative ports have changed.


You are talking about changes that needs to be done within the code at compile time, as if it is some change in some variable that can be checked at run-time, this is nonsense. Perhaps I misunderstood you, but your failure to simply explain your meaning for the forth time certainly does not help anyone.

So again, can you explain what is "check if the new relative ports have changed" supposed to mean? What is changing, when is it changing? What piece of code does those changes we need to check?

[abaraba]

Spouting nonsense is fine.  Bizarre, but fine.

Spouting nonsense while telling others they do not know what they are doing is not fine. I will call you out on it, just like I have been doing.

You are not saying anything really, afraid to make a statement?

I'm calling you out, mate. Do you accept the challenge?


You first claimed I said something "incorrect". I asked what is it, you failed to answer.

You now claim I'm spouting nonsense, but you again failed to actually articulate your objection.


What do you imagine is incorrect? What do you believe is "nonsense"? Can you articulate, what say you?

[Paul Olson]

If the controller is moved, the code added to the READ8_HANDLER will detect it and use the input code for the dial instead of the analog stick.

[abaraba]

If the controller is moved, the code added to the READ8_HANDLER will detect it and use the input code for the dial instead of the analog stick.

That sounds good, but what are you talking about exactly... what do you mean "code added"?

Did you make it work like that, or is it just suggestion? Can you copy/paste the code you are talking about?

[Derrick Renaud]

If the controller is moved, the code added to the READ8_HANDLER will detect it and use the input code for the dial instead of the analog stick.

That sounds pretty good, but can you please explain it a bit. Does that mean we can initialize it with whatever absolute or relative type of controls and later still obtain data in either format? Does it mean we can know at run time from which device data originated?

Wow, this says it all.  You truely want everything given to you when the goal was to actually learn something for yourself.

I see no need to reply to your nonsense any more.  Though Paul seems to be able to grasp the concept, so there is hope still to be found in all this.

[Derrick Renaud]

Let walk through the challenge posted here:
http://forum.arcadecontrols.com/index.php?topic=108516.msg1152192#msg1152192

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.

using the 720 code here:
http://mamedev.org/source/src/mame/drivers/atarisy2.c.html

How do we accomplish this?  We need to know how MAME handles input ports.  All input ports are defined inside the INPUT_PORTS_START() macro.  Now because games can have similar input ports, one game's definitions can be resused and modified by another game.  This is what happens with 720.  It uses the definitions from paperboy and modifies them as needed.  These are the paperboy ports/code we are interested in at line 818.

Code: [Select]

PORT_START("LETA0")
PORT_BIT( 0xff, IP_ACTIVE_LOW, IPT_UNUSED )

PORT_START("LETA1")
PORT_BIT( 0xff, IP_ACTIVE_LOW, IPT_UNUSED )

PORT_START("LETA2")
PORT_BIT( 0xff, IP_ACTIVE_LOW, IPT_UNUSED )

PORT_START("LETA3")
PORT_BIT( 0xff, IP_ACTIVE_LOW, IPT_UNUSED )
You can see that they are not defined as anything.  720 then modifies them at line 884 as follows:

Code: [Select]

PORT_MODIFY("LETA0")    /* not direct mapped */
PORT_BIT( 0xff, 0x80, IPT_AD_STICK_X ) PORT_SENSITIVITY(100) PORT_KEYDELTA(10)

PORT_MODIFY("LETA1")    /* not direct mapped */
PORT_BIT( 0xff, 0x80, IPT_AD_STICK_Y ) PORT_SENSITIVITY(100) PORT_KEYDELTA(10) PORT_REVERSE
Notice "LETA2" and "LETA3" are still left undefined.  So to recap, "LETA0" and "LETA1" are defined as the current fake joystick.  "LETA2" and "LETA3" are not being used for anything.

This brings us back to the original goal of adding the 2 new relative ports needed to use a real 720 control and make them coexist with the current fake control.  I've already mentioned in the past that the info was in a link given by someone who refused to read the info provided on said link of http://www.jstookey.com/arcade/720/720-arcadejoy.php . Bonus points to anyone who can tell me why I do not agree with the sensitivity settings given there.

So what do we need to do/code for step 1?

[ErikRuud]

Wow, this says it all.  You truely want everything given to


I see no need to reply to your nonsense any more.  Though Paul seems to be able to grasp the concept, so there is hope still to be found in all this.

[CheffoJeffo]

Or, perhaps more appropriate to this conversation ...



 

[BadMouth]

If anyone tests this, keep in mind there is a calibration screen in the service menu that will show you movement better that the skater dude flipping around will.

[abaraba]

Notice "LETA2" and "LETA3" are still left undefined.  So to recap, "LETA0" and "LETA1" are defined as the current fake joystick.  "LETA2" and "LETA3" are not being used for anything.

So what do we need to do/code for step 1?

We were already discussing this, you stated obvious, said nothing new.
If you want to say LETA2 and LETA3 can be used for this, then just say it.  


This can be solved in many ways and I already told you about it in reply #41.
You failed even to comment on my proposals and you refused to explain your proposal.


You only need to make clear what is it you actually want and it will be done, explain your Step 2:

- modify the "READ8_HANDLER( leta_r )" section to check if the new relative ports have changed.


What do you mean by "check if the new relative ports have changed"?
When and where they get changed? What variable are you talking about exactly?

[abaraba]

If anyone tests this...

Not you though, you are too busy blabbering about it, eh?


CheffoJeffo, you too. Were you not upset when you couldn't google where the download was? Well, you got direct link following your objection, but did you test it or you only care about your trolling?

[Haze]

You still seem to want the dev team to do all the work for you.

Do it yourself.

[abaraba]

You still seem to want the dev team to do all the work for you.

Only if you can not differentiate DO from SAY. I already DID it, in several ways, and you only need to PICK one or simply SAY what is "your way", what is mystery variable in Step 2? -- Whether "my way" or "whatever way", all that needs to be done boils down to this:

if [mystery_variable? == something?] goto ANAL_HACK;
else goto PROPER_WAY;

[CheffoJeffo]

CheffoJeffo, you too. Were you not upset when you couldn't google where the download was? Well, you got direct link following your objection, but did you test it or you only care about your trolling?

If you have paid any attention to my posts in these threads, then you would know that I don't currently have a MAME machine.

 

And I wasn't upset, I just thought it was stupid not to actually post a link.

[SavannahLion]

You still use gotos?

[Derrick Renaud]

Ignoring all forum noise, now and in the future....

Let's say a fake/real system is implemented in MAME.  One thing that comes to mind is what to do with the XML output you folks use for your front end.

What should be displayed?  The real controls only? That would be the accuracy people are demanding.  But wait, what if you don't have the real controls and want to sort by the fake control?  Should it then list both which goes against this demanded accuracy?

Hmmm, what say the masses?

[Paul Olson]

I want to be able to use the real controls on my cab, but most people won't. I also think that of the people who do want to use real controls, it will be a huge minority who will use more than a few. I have probably spent a couple thousand dollars over the years just on controls, and there are still a bunch to buy. The shifter issue (discussed in another thread) is a good example of this. I have 6 shifters, and there are many more out there. Most people will probably want to use one for all of the games. There will also be the vast majority who will want to use keys or joysticks to simulate the shifter.

I don't know what the best solution is to make sure everyone is able to use the controller they have. I think that it is important to have all of the originals working first (and I admit to being biased). The other solutions can then be set up to simulate the real controls.

It might be best to add support for all of them in MAME, and then let the Frontends handle customizing to the controls that the user has.

I still think the first step is figuring out which controls need to be worked on. I still haven't heard of any besides the 720 controller and the driving stuff. I just bought a 720 controller, so hopefully that will arrive this week. I also ordered a rebuild kit for it so I can make sure it functions correctly. I hope to have everything working before the weekend so I can test the changes to the driver. I left the original sensitivity settings in mine. If the original was accurate, it should work without any further tweaks.

Just bouncing an idea here: Since MAME is transitioning to C++, it might be beneficial to create controller objects, and then we could let the user pick the controller in the ui. This might be way beyond what anyone wants to do, but I think it might solve the issue. The behavior of each controller could be determined in the controller class, then the drivers could apply the behavior as needed. What do you guys think of that idea? I am not really suggesting it at this point; just looking for opinions.

[abaraba]

I want to be able to use the real controls on my cab, but most people won't. I also think that of the people who do want to use real controls, it will be a huge minority who will use more than a few.

I think the number of people using authentic controller would be 1 (you), and the number of people using analog stick to play 720 is 0 (zero).

I think that it is important to have all of the originals working first (and I admit to being biased). The other solutions can then be set up to simulate the real controls.

Of course, and there was a point in time when it was like that, but when they decided to set up other solutions, i.e. simulation of controls for different types of devices aka 'hacks', they placed it INSTEAD of the original one. -- The guy responsible seem to be that funny ignorant human person trying to hijack my thread by playing some silly games with 'masses, thinking everyone has the next eight years free to blabber about the most simple of problems while not actually solving it.

I don't know what the best solution is to make sure everyone is able to use the controller they have.

You do know, you just said it:
- "solution is to make sure everyone is able to use the controller they have"

Sure, there are many ways to *actually* do (write) this, to translate English to C, but whatever the "wording" you choose, if the translation is to be valid, it is the "meaning" that must remain the same:


switch [ MAPPED_DEVICE_ID ]

  case KEY: goto KEY_HACK
 
  case ANALOG: goto ANAL_HACK

  case MOUSE: goto PROPER_WAY


Fake/real scheme is in one-to-one relation with PC input devices. There will always be only ONE type of input that directly translates to authentic arcade signal, all the other devices, having incompatible signal/data between each other, will be unsuitable for authentic input handling, hence requiring signal conversion/simulation (hack).

So, by simply using what we already have we can absolutely define distinction between "fake" and "real" control scheme, hence solving the problem with the minimum amount of changes and user involvement, no additional command line switches or new menus required - it's the simplest, least intrusive, and most elegant solution, thus it's the "best solution".