720 controls design - wouldn't this be better??

[Ummon]

I was cruising Ram controls site and looking at the 720 controller, wouldn'tve been way better if they'd put the race near the top of the housing?

Not only would there be no wear and tear on the handle/inside of the housing/no need for a bearing up there....it would also be far sturdier in overall construction. And you could reduce the encoder shaft by.....tons....which would mean the whole housing would've been reduced, and, I'd guess, the whole thing would've been way cheaper.

Now I know they had these housings left over from the Battlezone run, but still.

[u_rebelscum]

I hope by "they" you mean Atari; ram controls is doing a reproduction. 

What do you mean by "race"?

The part that made the handle only go around in a circle?  The geared parts that restricted speed & prevented free spin?  The two optical encoder wheels?  And the optical board that reads the wheels?

All of those are on the bottom and work together & share parts.  How can all that be fit above the main pivot ball, at arcade reliablity (or at least not less reliable than the repro'ed design) and arcade servibility?  I don't see it.

[shardian]

The whole original design of this controller is retarded. A chain drive? Seriously?? That just screams bored as hell design engineer to me. 

[Beretta]

lol someone post pictures? link i gotta see this.

720 is one of my favorites but i oddly never seen one in the arcades.

[u_rebelscum]

...A chain drive? Seriously?? That just screams bored as hell design engineer to me. 

Yeah, I understand that view.  But...

Note the chain & gears were only to add resistance & prevent free spin, while giving the player easy small skating direction adjustments.  The design made it easy for operator to adjust / fix rresistance with standard (easy to replace) parts.  Putting the resistance directly on the spinner axle would have made the axle wear faster, and would be more expensive and harder for the operator to grease or replace the axle.

I'm not saying it's perfect.

lol someone post pictures? link i gotta see this.

http://www.720zone.com/720-Joystick-Help.html  Lots of pictures.

[Xiaou2]

 Race?!  What are you talking about?!

 The only think I can Think of, is that you are thinking about moving the bottom mounted
Pivot Holder Arm to the top.   However, the shaft sits at an angle.. and the upper part of the
shaft moves at a greater diameter than the holder does.  If this were reversed, the pivot
ball would wear more on more sides.  It might also have to be much larger to accommodate the
additional angular needs of the larger diameter.

 Also, because the smaller diameter on the bottom, and larger up top... there is more
leverage - thus less friction experienced by the player.  The main center pivot
ball takes most of the abuse, leaving the bottom in decent shape, and less friction
and wear to deal with.

 
 The Chain drive is an Excellent idea.  Not made from Boredom, as the unwitting suggest.
The gears and chains create just the right amount of friction to keep the controls tight.
If you removed the chain... the control would be too loose and sloppy.. and hard to maintain
correct angles... as well as being able to better time the spins.

 If this used something other than a chain.. such as a resistive pad or spring system...
the spring would eventually lose its push.. and the pad/brake would eventually wear out...
all the while spreading debris all over the system, and clogging up & destroying other
parts in the process.

 
 Im not a huge fan of the controller... and yet, I cant see any other way it should or
could work and be better than this.

 Remember... that Atari's designers had to make controls that could take major abuses...
and still keep on working.   They were field tested in busy locations and hammered on by
punk teens, drunks, and children.  Many controllers had to be revisioned several times due
to test-site failures. (or redesigned for better feel/control)

 My favorite control set of theirs being  "Hard Driven" Sit-down.  Nobody has made a better
controller setup... in feel, realism, control, and long lasting lifespan.

 Least fav was Road Riot.. whos steering wheels springs kept eating the assembly up, 
as well as the thin wires kept breaking inside the steering wheel.


 Id love to see you attempt to make a working 720 stick thats superior to the original.

[Beretta]

wow that thing looks complex, i bet this was the only game that ever used it.. right?

i agree about the hard drivin cockpits my favorite arcade driving game, use to always play that when went to the arcade before i had my license and realized driving is'nt exactly "fun"

if i ever get a chanced to do a cockpit thats exactly the kinda controls setup i'd try to recreate.

[u_rebelscum]

wow that thing looks complex, i bet this was the only game that ever used it.. right?

Right.  However many of the parts are shared with other Atari sticks.  You can see a lot of the sharing at Ram Controls site.  So it's not as unique as all that.  Still, some parts are only for this one controller (at least AFA arcade controllers go: the chain is a common non-arcade part for example).

... the pivot ball would wear more on more sides....

I picture the pivot ball more worn all on one side (top half?), vs the fairly even wear of the original forces from both sides design.  But I agree with the more wear part.


More on the "redesign" in general, my biggest question is how could all the stuff moved be anchored securely, so it moves smoothly, and as cheaply.  With the sweaping joystick shaft, there is a cone inside the sweep above the pivot ball than you cannot fix anything; they must be anchored out side the cone. 

The "easiest" way I can see is with another disk sort of like the dust cover disk with the off centered hole.  It would need to be thicker, made of metal, with an angled hole.  The encoder wheels and resistance  stuff would need to be attached outside the radius of the joystick shaft.  The disk would need to be in a strong track of some sort.  With the encoder wheels requirements, that mean either the top half of the holder track would need to be separate from the bottom, or the encoder wheels inside the tracks and read through a gap in the tracks.  And I can easily see the above setup catching too often unless the hole the shaft went though was pivoted also.

The alternate is forget the shaft, and make it an upside dow cone with a "shaft" coming out at an angle near the edge of the cone.  It would need to be held done while able to spin, and the encoder wheels etc attached some how.  Totally unique piece, very fault intolerant, very hard to repair, very expensive to make.  (A shaft out of disk would have many of the same problems, except maybe being cheaper, but have more of the leverage problem Xiaou2 mentioned.


As said, the 720 controller isn't perfect.  But it's pretty well designed (although it did need the one minor revision mentioned at the 720 page I linked above).

[DashRendar]

Wow, it's odd to see something so mechanical in this electronic age!

Reminds me of Steampunk.

[RandyT]

I've never had the opportunity to play with one of these outside of a cabinet, and my last interaction with them was about 20 years ago.  So could someone please tell me if this control is anything more than a spinner with an angled joystick as the "knob"?

I see that the design offers absolute positioning, but that looks about to be all.  Also, about how many rotations can one get out of these things when spun?

BTW, to echo what has already been said, the chain is a very clever idea.  It simply uses the natural energy loss (basically friction) of the chain mechanism to slow and stop the spin, without putting a great deal of resistance into the control.  I'm not sure how that exact effect could be duplicated without doing something similar.

That being said, I think a new control can be made to approximate the action of this one, with a smaller footprint and maybe a lower cost (don't know what the originals went / go for.)  But the feel would only be approximate, as there is no way I would consider using a chain to dampen the motion.

RandyT

[u_rebelscum]

I see that the design offers absolute positioning, but that looks about to be all.  Also, about how many rotations can one get out of these things when spun?

Ehh, it was adjustable, but ~3/4, maybe 1 & 1/2 turn if spun hard with muscle behind it and you counted the fall (next sentence).  If you let it go and the handle was up, it almost should have stayed there, or slowly, very slowly, moved to the bottom 1/4 of circle; it shouldn't make it to the straight own unless left alone for hours.  Yet it was possible to get two full spins (720 degrees) if you were fast enough.

Very, very different than the tt2 spin forever spin feel.

That being said, I think a new control can be made to approximate the action of this one, with a smaller footprint and maybe a lower cost (don't know what the originals went / go for.)  But the feel would only be approximate, as there is no way I would consider using a chain to dampen the motion.

Ram Controls is pre ordering for $150, $200 after preorder.  Rebuilt controllers often go for that range or higher.  Of course, it was cheaper back when it was originally in production: sharing parts and all.

[Xiaou2]

 Well, I really cant comment too much about the thing... cause I was horrible at
the game.   To be fair... the game is a little  "clunky".

 I can say however... that the thing does not feel like a spinner at all.   The angled
stick helps to keep you aware of your orientation.  It changes the timing and control
of how you move because of this.  (wide slower circle, rather than quick center pivot)

 It Might be possible to replicate the control slightly by making an attachment that
fits over an existing spinner.  The main problem however... is that most spinner shafts
would not be strong enough to widthstand the leverages that would occur if someone
applied too much pressure accidentally.

 Im also unsure if applying pressure in only one direction,  -vs-  the upper & lower
pivot system would feel and react the same way.    Maybe a 'counter balance' weight
would correct it...

 Its not exactly the most popular game... and the ones who have played it probably
wouldnt settle for a poor replication, even if its a cheaper option.

 The worst part is... I think Mame disabled the 2ndary encoder disc... which is essential
for re-calibrating the unit on a constant basis.   Without this, the controller will get out
of sync, and while your stick may be pointing upwards... the skater might be skating
down-left.   Which destroys all chance to play it the way its meant to be played.

[RandyT]

Ehh, it was adjustable, but ~3/4, maybe 1 & 1/2 turn if spun hard with muscle behind it and you counted the fall (next sentence).  If you let it go and the handle was up, it almost should have stayed there, or slowly, very slowly, moved to the bottom 1/4 of circle; it shouldn't make it to the straight own unless left alone for hours.  Yet it was possible to get two full spins (720 degrees) if you were fast enough.

Very, very different than the tt2 spin forever spin feel.

Ok, it's coming back to me now.  IIRC, the other noteworthy thing about the controller was the sound it made.  But I do now distinctly recall the interaction I had with the controller while playing the game.

A very convincing home version of the control would not be exceedingly difficult to make, but the audience might be too small for it to be worth doing.  I'm guessing it would be less than $100, plug and play USB, using the latest encoder technology.

Do the newer versions of MAME have an input for the calibration pulse? (I'm guessing it does, otherwise a true controller would be pointless...)  Also, does anyone know what the exact angle of the joystick is?


BTW, X, I wouldn't try to make a spinner attachment for this.  It would be too much of a pain to manually synchronize the shaft direction with the on-screen character, and the leverage would definitely break something.  This would require a special controller design that I already seem to have in my mind's eye.  I think even avid players would be happy with it, if it works like I think it would.

*edit*

I think I need to think about this one a little more.  There was one photo on that site that shows an action that would take it out of the realm of "special spinner-type control".  With a spinner, the knob always turns with the shaft.  This control obviously has a non-rotating grip and shaft, which adds complexity, size, etc.  This is one wheel that may not be worth re-inventing...

RandyT

[Xiaou2]

 As said, they removed it.

Mame version 134  does not have it.

 Very sad that the Mame Team ruins a classic with its poor choice of emulation tactics...
as Usual.


 What is so damn hard about supporting 2 ways to control a game?!  (A fricken SWITCH!)

 Hmm... Lets make it Impossible for Anyone who actually LIKES the game to play it
correctly.   Brilliant.

[SavannahLion]

 As said, they removed it.

Mame version 134  does not have it.

 Very sad that the Mame Team ruins a classic with its poor choice of emulation tactics...
as Usual.


 What is so damn hard about supporting 2 ways to control a game?!  (A fricken SWITCH!)

 Hmm... Lets make it Impossible for Anyone who actually LIKES the game to play it
correctly.   Brilliant.

Because MAME doesn't emulate mechanical hardware and MAME supports lowest common denominator setup, namely keyboard, vanilla joystick and mouse. If someone figured out how to incorporate FUFME into an arcade cabinet, the MAMEDev's would go the extra mile to figure out how to cram said controls into the limitations of your keyboard, mouse or joystick.

Isn't MAMEDev supposed to be constructing some kind of framework to better handle control input, eg 720? Or is that just the messaging system for game feedback?

[RandyT]

Because MAME doesn't emulate mechanical hardware and MAME supports lowest common denominator setup, namely keyboard, vanilla joystick and mouse.

Actually, that has supposedly been a secondary concern.  True emulation of this title requires that there be an input associated with the pulse line for that hardware.  Otherwise, it is incomplete.  Perhaps it wasn't the presence of this input that ruffled feathers, rather the implementation?

I think we need to persuade Derek to figure this one out.

RandyT

[Xiaou2]

 If you have the recalibrate ON  (correct behavior) , and no calibration is taking place
regularly... it probably messes up the games input.    Thus, since they believe nobody
will have, build or buy a proper controller... they Disabled the support.

 In fact, if I recall correctly,  they went so far as to change the game to support
"Analog joystick" instead of true spinner aim.  This really takes the cake.


 While this is an OK solution for the temporary test that a person might want to try...
There should be a way to select the proper input methods.

 
 The "Core Input"  selection system,  Should be used to assign the kind of
control you wanted... to the control that is in game.
The system does not seem to be hooked up correctly... AND, it does not take into
consideration blatant emulation abuses such as in this game.

 Every game should give you the Option of what kind of setup you wish to use.


 Sure, if you want to default to "Hack Mode"  so the non serious players can
try a game out... then Fine.  But Allow a Switch for true "Arcade" mode, so we with
correct controls can use them properly.

 The problem is that the devs couldnt care less... And, no dev wants to Touch the
GUI system.   None of them.   To the Dev, the games are meaningless.  Its the
challenge that makes them happy.  However... the challenge of making a good
proper working GUI - is beyond them... and does nothing for them.

 The few Devs or people that MIGHT want to work on the problems Wont... simply
because they know that Some Dev probably will just ignore or reject their work.

 So, the games will Suffer as a result.


 Edit:

  I can understand why a Dev would have a hard time taking on a proper revamp
of the entire crappy  GUI.   However, there is no reason why a game can not have
a simply  "  /arcade   "  mode switch.. or similar..  so that a real control can be used...
as a temporary solution Until a proper working GUI can be designed and programmed.

[RandyT]

If you have the recalibrate ON  (correct behavior) , and no calibration is taking place
regularly... it probably messes up the games input.    Thus, since they believe nobody
will have, build or buy a proper controller... they Disabled the support.

I'm going to play Sherlock Holmes for a moment, mainly because I don't have a real board to test it with.  I have a strong feeling that the game doesn't care about the calibration pulse.  The main thing that makes me think that is the fact that the default / start orientation of the player seems to be different on different screens.  This would mean that a calibration pulse must occur at some point to align it with the control, but that fact cannot change the fact that the user must be able to turn the player in order for it to happen.  There's really no value in coding timeouts, or other nonsense in a game, that would ultimately do little more than prevent the game from being playable at all, should there be a problem with that part.

I tend to think that the calibration bit is simply ignored.  Anything else would probably mean a major alteration of the input system, just to make it run at all....not that an analog control doesn't fall into that same category .

I don't want to be hard on the Devs.  Without the tireless efforts of those folks, we'd be at the mercy of even worse ports of these titles.  It just seems like it's one more of those "contradictory to the stated goals" types of things that unfortunately pop up on occasion. 

RandyT

[Xiaou2]

The game does count the pulses on the encoder disc.  However, if one or two
of the encoders spokes was bent, broken, or clogged with crud... the games
character would end up facing the wrong way  -  and not be in sync with the
controller.

 This is verified in a picture posted in one of the links in this very thread.  It shows the
test screen, and missed spots in the rotation.

 Its hard to know exactly if the programmer actually put logic into the game to
cause an error if no calibration was sensed in some time.   Maybe you are correct,
that it does not.

 However... since the Devs decided to change the behavior of the game from
Spinner to Analog joystick, without any other options elsewise,
... they then removed the calibration input.    Both decisions: Mind Blowing.

 What the heck good is a classic arcade game without knowledge, documentation,
and functionality of its originally designed controllers?!

 The entire game is a work of art, and all parts of it are equally valuable.

 A  "Lamborghini"  ,for example... is more than just an "engine".   And, you cant, nor
should not... be forced to drive one with a keyboard.

 So, what we have in Mame here is a Lamborghini with no pedals, no shell, and
no steering wheel.   In replace, there is an analog wheel-chair stick in there.
Such a Disgrace...
Such a Shame..

[u_rebelscum]

As one who came up with an analog-joystick-as-the-input hack before one like it was added to mame (aaron's, the one in mame now, is much better, even though he credits me), I can tell you mame currently (partially*) simulates the index quadrature sequence (it's not "a pulse", but a specific on/off sequence of two sensors the game decodes as the index).

The index sequence is used two ways. :
1. On turn on, the stick is not indexed.  No matter what direction the stick is pointing*, the skater always points the same direction (right IIRC).  The first time the index quadrature happens, the skater jumps to the correct direction.  (Initial index)
2. After that, the index sequence seems to correct for up to one missed tooth and one gap (72 teeth = 144 counts per rotation, and the index can correct for 2 out of the 144).  The game know which direction to correct for by the order the index sequence happens.  I assume it can do two per index sequence because there are two gaps in the index wheel.  (constant correction index)  
*Note that the current code in mame only does one count per revolution, however, which is why I say partially.  Mine did the same.

I figured most of this out while trying to add the different inputs (original controller, analog joystick & 8-way joystick) to Mame:Analog+ (and my 720 controller still partially worked  ).  I didn't reverse the original game code, so I could be off on some details (like exactly how does it know which way to correct).


If no one else does, I'll (e)make a hack so mame can use an original controller when ram-controls comes out with the reproduction of the 720 controller.  


FWIW, official mame never used the index wheel correctly back when it was trying to emulate the controller as a single dial.  Aaron and I discussed the analog joystick simulating inputs vs original controller emulation after he switched; I wasn't happy that the "real" controller input was dropped.  However, since ATT there was zero original controllers for sale for PCs, and millions of analog joystick, and the index wasn't emulated correctly anyway, and most importantly mame's policy is to do only one (mame) input per game input, it was either an input that didn't work for any controller, or the analog joystick simulation.

[Xiaou2]

Mames Policy is the Policy of ---smurf-poo---.

 There is No reason whatsoever that there can not be two different ways to
control a game.  None.

 Im not a programmer.. But Ive coded simple 'basic' on a TRS-80
& the c64, and so I understand the concepts very easily... as well as Logically.

 Nobody wants to be bothered to add dual support.  That is the only real reason.

[Ummon]

Mames Policy is the Policy of ---smurf-poo---

Hmmm...maybe the auto-censor is dominating?


Anyways, yeah, I totally forgot it was a chain-driven mechanism an all. Partly, I was caught up with my own idea - which is it being a spinner-type device, with a race/spoke deal at the top that the angled shaft is connected to - kinda like a manual mixer or drill with a slanted shaft, rather than a crank.

The dexterity required to turn the race might be more than enough to compensate for the slickness of the spinner element. Even re-designing it further by putting in a crank with a spinner handle could be cool (I've actually presented this idea in years past), and the race set-up still possibly present enough resistance.

Regardless of design, the handle should be a spinning top - it should've been on the game, and I thought so the first time I played it in '86. I really thought they missed the cherry on that sundae.

[SavannahLion]

u_rebelscum & 720. I didn't realize it, but I read about that work on jstookey's page and the hack to support the 720 stick.

...and most importantly mame's policy is to do only one (mame) input per game input, it was either an input that didn't work for any controller, or the analog joystick simulation.

Doesn't this ideology go against the ideology of accurately emulating the hardware?

Oh well... At least the consolation prize is we have the actual source. I recall jstookey created a patch for just such a purpose.

[u_rebelscum]

There is No reason whatsoever that there can not be two different ways to control a game.  None.

As one who hacked multiple ways to control one input in a few games for mame:Analog+, I disagree.  The headaches trying to explain the differences between the player 1 dial & dialV (the "original" 720), the analog joystick, and the 8-way joystick inputs, and how they all controlled the same thing was a Major pain, and one reason I really don't like doing game specific hacks.  (The other multiple input types example was the dial vs impulse buttons vs 12 buttons inputs for the rotary part of rotary stick.)  Add to that, if mame did what you want, mame would output (listxml), and romlister would incorrectly think, that those games had way more inputs than they really did.  Incorrectly documenting the inputs in either case.

If someone could change mame's input handling/mapping, and someway say "720 controller" and have two totally different input mapping (analog/8-way stick and original controller), I'd agree with you.  In fact, mame's "positional" input type was originally projected to combine the three inputs I listed above in the second example.  However, it only combined two (dial and pulse inputs), and it's beyond my skills to add the third, twelve switches aka original raw data.  And doing the same to cover 720 is even harder.*

So the question is use a simulation that works for 99.9% of the users and document it correctly in the source, or add code so the original controller that noone uses works but also adds to the headaches of coding, helping users, garbage in garbage out, and document it in the source.

MameDev IMO smartly & correctly has chosen the first.  We are free to add hacks to the the code to support more inputs.  But I see no reason for me to do so yet, until ram-controls actually starts selling the controllers.



*I can picture it though: For all spinner (dial type) inputs, you could have seven "translations": normal spinner (no translation), indexed spinner (two axes or one axes + index buttons),  analog joystick (two axes), analog joystick (one axis absolute), analog joystick (one axis relative), direction buttons, and X switches.  Positional type does two of these already.  however, the whole input code would have to be redone, probably breaking all current cfg and ctrlr files, and overall be a pain.  To help fix less than 1% of the the games (720 & rotary games) for less than 1% of the users (those with 720 controllers & original mechnical rotaries)?  MameDev won't waste the time, and would take one of that 1% of 1% (ie: one of us) to code it cleanly and for better documentation.

[RandyT]

After that, the index sequence seems to correct for up to one missed tooth and one gap (72 teeth = 144 counts per rotation, and the index can correct for 2 out of the 144).  The game know which direction to correct for by the order the index sequence happens.  I assume it can do two per index sequence because there are two gaps in the index wheel.  (constant correction index)  
*Note that the current code in mame only does one count per revolution, however, which is why I say partially.  Mine did the same.

Ehhh...talk about overkill.  It's hard to understand why it was done like this, considering there are far more possible positions reported by the encoder than the 16 possible angles programmed for on-screen character.  Considering that, I'm really surprised they didn't just tie a single break (rising edge) in the index wheel to a specific character position.  The tiny error would have been unnoticeable, and it could have tightened it up even more with this method if it corrected based on the current direction.

Regardless, since the code doesn't seem to care whether the index wheel transitions ever occur, why not emulate the hardware by simply tying one of the inputs to the index?  If you have the real hardware, it modulates the input (button, keypress, etc) and MAME can act on it.  If not, leave the input hanging (assigned to "none") and it never comes into play.  Should offer the best of both worlds without the specific need to support two different types of controls.

Or have I missed something?

RandyT

[u_rebelscum]

...and most importantly mame's policy is to do only one (mame) input per game input, it was either an input that didn't work for any controller, or the analog joystick simulation.

Doesn't this ideology go against the ideology of accurately emulating the hardware?

Mame is about emulating the CPU and other processing units.  (About the only things mame can control how well it emulates.)

Mame can't emulate a physical yoke.  It takes the limited input data for the OS, and translates into the data the game expected.  IOW, on the software emulation side, food fight analog stick = I robot hall effect = hard drivin (sitdown) gear shift = term 2's gun = star wars yoke.  So no matter how much us people who know the physical difference whine to MameDev, they can't do anything about it.  So remember that

720 is a little different in that mamedev has three choices:
- use the spinner code (old or patched for original controller) that didn't work well enough to play with normal spinners, and had a FAQ "why doens't my joystick work in 720?"
- use the currently analog code and document the hack in the source like it does now, causing not true data in listxml output, ubt working for 99.9% of the users
- put both in, so that you have all the problems of both: not true listxml output & normal spinners won't work well enough to play, while adding: the issues of a spinner and a joystick fighting for the same input, more code in the game driver level to upkeep over the years.
(- or make that major input revision I talked about above.)


As one who came in when mame had the first, pushed for the third, and got the second instead... ... I'm not totally happy with the current state, but it's better than it was IMO, and the state I was pushing for isn't as good as I was hopping for (as I found out when it was in mame:Analog+).

[u_rebelscum]

Regardless, since the code doesn't seem to care whether the index wheel transitions ever occur, why not emulate the hardware by simply tying one of the inputs to the index?  If you have the real hardware, it modulates the input (button, keypress, etc) and MAME can act on it.  If not, leave the input hanging (assigned to "none") and it never comes into play.  Should offer the best of both worlds without the specific need to support two different types of controls.

Or have I missed something?

That's how it was done in analog+.  The normal wheel was "player 1 dial" the index was "player 1 dialV" (aka vertical dial).  If you had an original controller, and the index was wired to the Y axis, it worked great.  With a normal one axis spinner it worked (but without the joystick direction = player direction, so play suffered).  Problems occurred with TBs, though: the game getting "index signals" way out of proportion.  With an analog joystick, this wouldn't work at all.

So that's what the diff for supporting original controller would have.

[u_rebelscum]

u_rebelscum & 720. I didn't realize it, but I read about that work on jstookey's page and the hack to support the 720 stick.

Yeah, jstookey wrote most of the actual code that did the analog joystick to spinner + index format the game wants, with only some help from me.  I started the support original controller code before talking to him, but jstookey did a lot more testing than I was able to.

[Xiaou2]

No Offense Urebel... but your being a total Brown nosed (and lipped) Suckup.

 You make it sound like its So darn hard to make a simple switch, which
disables the hack mode, and allows True mode.  Its not.

 AND, its Not confusing either.   Anyone with a REAL controller, can simply go in
and edit or click:


==========
#
# CORE INPUT OPTIONS
#
coin_lockout                  1
ctrlr                    
mouse                           1
joystick                          1
lightgun                         1
multikeyboard               0
multimouse                   1
steadykey                     0
offscreen_reload           0
joystick_map                 auto
joystick_deadzone        0.3
joystick_saturation       0.85
720 Arcade Controller   1
2 Way Arcade Shifter     1
4 Way Arcade Shifter     1

=======

As for that Ridiculus listxml argument... you should be ashamed you even mentioned it.
The idea that a game does not fit into the POOR AS HELL game listing of controller
types is a Joke.

 Not only can you make it so that Mame can send whatever data it wants to
a database...  Its completely irrelevant to the argument.

 The controller list is complete garbage.  Everyone knows it.  It does not correctly
classify a good number of games.   The purpose of Mame SHOULD be to correctly
document and preserve games in every detail.   Not to fit a unique game into a
False catagory... because somoene is too lazy, stubborn, or too stupid to make
correct documentation. (IE: A correct database format)

 
 I believe I actually came up with the idea and argued for the Analog joystick
support long ago.  And yeah,  Im glad that it was put in.   But I was shocked to see
support for the real deal removed.  Its Not the correct thing to do.

 
 David is a rare breed... that will make correct hardware regardless if Mame
supports it or not... merely because he is making them for the actual machines.
Nobody else is going to waste time designing and selling units for a game(s) in mame that you have to make a custom complie just to get it to work.
Would You risk your money on an expensive project that isnt even supported
by the software you want it to run on ? ? ! ! !   Get real man.

 The more Mame EASILY supports... the better chance more arcade control
repos will be made.

 And, if something isnt done to properly document controllers...  Nobody is
going to know what the heck the original game was controlled with.  Nor
will they be able to re-fabricate them if they Did know.

 Heck... If you start a game up in mame... you dont even know what the
buttons you are using are for.   When you walk up to a Real machine, they
are listed:  Punch, Fire.   Yet In mame.. its Button1, Button2.   It should not
be like that.   If the game lists button 1 as SuperFreezeBlaster... then that
is exactly what mame should list it as.

 Allowing any number and type of input is great... but, there should be a way to
know for sure... easily, exactly what the game used as a default.

 The system needs a huge overhaul... with good thought put into it before just diving in.
However... there again, is no reason why a few extra switches such
as the ones I listed can not be instituted as a temporary fix, until that day may happen.

[RandyT]

That's how it was done in analog+.  The normal wheel was "player 1 dial" the index was "player 1 dialV" (aka vertical dial).  If you had an original controller, and the index was wired to the Y axis, it worked great.  With a normal one axis spinner it worked (but without the joystick direction = player direction, so play suffered).  Problems occurred with TBs, though: the game getting "index signals" way out of proportion.  With an analog joystick, this wouldn't work at all.

So that's what the diff for supporting original controller would have.

Ok, but you kind of missed what I was referring to.  If the index was attached to a digital input, like a gamepad button, there would be no interference with the trackball.  If one were using the Joystick, the user could just not assign it (I.e. set it to "None"), or it could be coded so that the "index input" is ignored unless control is assigned to a spinner.  Really, it would just be an addition to the current scheme that shouldn't really negatively affect the other aspects.  No?

RandyT

[u_rebelscum]

Ok, but you kind of missed what I was referring to.  If the index was attached to a digital input, like a gamepad button, there would be no interference with the trackball.  If one were using the Joystick, the user could just not assign it (I.e. set it to "None"), or it could be coded so that the "index input" is ignored unless control is assigned to a spinner.  Really, it would just be an addition to the current scheme that shouldn't really negatively affect the other aspects.  No?

"Raw" input from the sensors, with the two sensors hooked up as two buttons?  Hmm...  I'm not against it, but...

PCs do not let apps see the raw quadrature (aka raw mouse sensor) data, while (most of) the original arcades had a quadrature-to-digital counting chip on the main or I/O board.  Add that PC mouse device have different CPR (and optical doesn't even have a revolution anymore) than the original arcade hardware.  Giving 720 access to the raw data would be, umm, exceptional.  Like access to the raw 12-positions of a rotary stick, hard to work out.  A cool idea, yes, but...

But it would still require the two parallel input methods (analog stick 2 axes & spinner + 2 buttons).  So I think it'll need to be done in a diff file.  Unless you're talking about dropping the analog stick, which might make it acceptable, but ... trading an input that works for 99.9% of the users for one that doesn't work well for 99.9% (works poorly for those with spinner or TB) ... I think the status quo will win.

[u_rebelscum]

Xiaou2, I'm not saying mamedev is right.  I'm explaining their point of view.  I share some of it, disagree with others.  But even if I disagree, I can't do anything about them besides write code, and I'm not good enough to code what I want.

Remember, mame is written by by coders, maintained by coders, and so the whole project is coder oriented.  Something I totally agree with Aaron is that if you don't enjoy what you're doing for fun, you wouldn't be able to continue doing it: for the mame project to continue, it has to be fun for the coders.

#
# CORE INPUT OPTIONS
#
   ....
720 Arcade Controller   1

You're talking about adding a one game option to mame's Core Input Options?  I'm not a mameDev, but I know this:
  Never going to happen.

Mame will never add a game specific option.  Code bloat, code support, code maintainance, code upgradability, option bloat, help support, modularity, all point at not doing it.  So your "solution" is not valid for official mame.

As for that Ridiculus listxml argument...

I'll give you this: mame's listxml outputs what's in the emulation code, and the emulation code doesn't care if it's a star wars yoke or a food fight analog stick, so of course the listxml output reflects that indifference.  It's predecessor was not meant as a database, but people used it as one; listxml is far improved over the prior but as we both agree, it's not perfect.

Still, adding as you suggest don't help fix the listxml, but makes it more confusing.  And people will use it as a DB data source whether it was designed as one or not.

I believe I actually came up with the idea and argued for the Analog joystick
support long ago.  And yeah,  Im glad that it was put in.   But I was shocked to see
support for the real deal removed.  Its Not the correct thing to do.

I didn't say I came up with the idea.  I helped implement it, and messed with the code, so know how it works.  And know how much a pain it is to have multiple mame inputs combined to one game input, and it's not easy.

David is a rare breed...

yeah, glad he's doing what he's doing.

The more Mame EASILY supports... the better chance more arcade control
repos will be made.

Not mame's scope.  (ie: mame.exe doesn't care about repos )  <-- incase not clear, I'm not happy about this.  And individuals within mameDev probably do like repos.

And, if something isnt done to properly document controllers...  Nobody is
going to know what the heck the original game was controlled with.  Nor
will they be able to re-fabricate them if they Did know.

There is no way to completely document the controller within mame's scope.  So mame isn't going to try.  Just like it doesn't do pong.

... you dont even know what the
buttons you are using are for.   When you walk up to a Real machine, they
are listed:  Punch, Fire.  

A) Not all machines had labeled buttons. 
B) Mamedoesn't have a control panel.
C) If the buttons were labeled as fire & bomb in mame, how would you know which button was fire and which was bomb.? IOW, was button 1 fire, or was button 2?  There is more info on that CP than just the name: button position, instruction card, graphics.

I'm not saying I wouldn't like the labels in mame.  I'm just saying this is a feature outside of mame's scope.  I believe the current design is far better setup to be labeled without messing up everything, unlike it was a few years ago, so this might be a possible goal, except back when labeling effed things up, too many people tried submitting labels, and so a good-at-the-time policy was put in place not to accept label changes.

We might want to propose the labeling again, but gently, not insultingly.

The system needs a huge overhaul... with good thought put into it before just diving in.

Yes.  With lots of good thought.

[Xiaou2]

Something I totally agree with Aaron is that if you don't enjoy what you're doing for fun, you wouldn't be able to continue doing it: for the mame project to continue, it has to be fun for the coders.

 Thats all good and stuff... However, remember that many of the games the Devs
work on, come from funds and donations from fellow collectors, and us poor pocketed -
but passionate arcade enthusiasts.

 At very Least, we should be able to play the games properly.  Especially when certain
things that would make a ton of people happy (and very willing to donate even more),
are simple as pie for a Master Dev to add.

 Remember also,  Mame is more than donations.  There are plenty of people
preserving artworks, making samples, scanning in schematics, buying various
hardware, art, schematics, laser discs, hard drives, and more.
 
 Mame can and would still continue if nobody else supported it.. however, its pace
would be a heck of a lot slower.

You're talking about adding a one game option to mame's Core Input Options?

 No.  Im talking about any and all games which have similar problems.  Such as
the problem with not being able to use a real arcade shifter in all racing games in mame.

Mame will never add a game specific option.  Code bloat, code support, code maintainance, code upgradability, option bloat, help support, modularity, all point at not doing it.  So your "solution" is not valid for official mame.

 Never?  I didnt realize I was speaking to the Leader of the band...

 Every few releases... Mame has done some extensive changes which for the most
part, are not all that necessary, and do not do much to change anything.
Its simply more palatable and cosmetic than actually useful.  (OCD?)   Im not
saying its a bad thing... but if mame can take time to change everything for the
smallest of reasons,  why not an actual change that has a deep impact?

 Be honest man.  You are stretching the Excuses / reasoning's.
The add to the core wouldnt have a need for a ton of maintenance.  Set it,
and forget it..  Until that day when someone decides a better way.

I didn't say I came up with the idea.  I helped implement it, and messed with the code, so know how it works.  And know how much a pain it is to have multiple mame inputs combined to one game input, and it's not easy.

 I also found your older builds confusing.. as with so many options.. a person would have
a hard time figuring out how the heck the actual game was supposed to be controlled.

 However, this is Not that case.   Its dead simple.   You click arcade control if you have
a real controller.   Its not 55 ways to control a game all in one menu.

 You know I appreciate the hard work you put in to adding multiple mice... as well
as the rest of the work you have done.    If only the other Devs had the same passion
for actually using the games they work on... 

 Code ease and OCD related 'Order' should not take pressidence over correct
historical functionality.

yeah, glad he's doing what he's doing.

 He does what he does because he has passion for the games.  Not
because of Mame.  Though, he is Mame friendly.. which is great.

 If David comes out with the 720 controller, and only invested in it because of mames
wide base...  Would mame suddenly support it?   What about the people who
cant afford the controller? 

 And, do you really think hardware developers are going to invest in software that
does not support it natively?   

 Its just plain sad, this state of mind and choices being made.

 

Just like it doesn't do pong.

 Mame is:   Multiple ARCADE Machine emulation.
 
 Excuse me... But wasnt Pong an Arcade Machine?

 What about Ninja Gun?  Contains electronics, And mechanics...  And Yup,
was an Arcade Machine.

 Just because some things might lose some accuracy through simulations means
Nothing.   They cut the balls off 720, and Simulate the controller... but cant simulate
something else?   What about all the samples that have been used?  Simulated
sound chips.  And now mame supports Discrete sounds...?   What the big deal
in supporting the discrete video as well?  Or simulating the mechanics thru scanned
art and actual 3d dimensions?

 To this day, nobody has made a decent version of Monaco GP.  How sad is that?
That game is a pure Classic... a huge part of Arcade gaming history. 

[SavannahLion]

Ok, but you kind of missed what I was referring to.  If the index was attached to a digital input, like a gamepad button, there would be no interference with the trackball.  If one were using the Joystick, the user could just not assign it (I.e. set it to "None"), or it could be coded so that the "index input" is ignored unless control is assigned to a spinner.  Really, it would just be an addition to the current scheme that shouldn't really negatively affect the other aspects.  No?

"Raw" input from the sensors, with the two sensors hooked up as two buttons?  Hmm...  I'm not against it, but...

PCs do not let apps see the raw quadrature (aka raw mouse sensor) data, while (most of) the original arcades had a quadrature-to-digital counting chip on the main or I/O board.  Add that PC mouse device have different CPR (and optical doesn't even have a revolution anymore) than the original arcade hardware.  Giving 720 access to the raw data would be, umm, exceptional.  Like access to the raw 12-positions of a rotary stick, hard to work out.  A cool idea, yes, but...

Well.... I don't keep up with enough to really make a definitive argument but....

What's to stop MAMEDev from defining raw input, allowing us to leverage that raw input and then let people like Randy develop the hardware to go with it? Isn't that exactly what 255 USB class is specifically for? For situations just like this.

Obviously, a lot more thought would need to be put into developing something like that and the first hurdle that comes to mind is Windows ---fouled up beyond all recognition--- up driver certification ---smurf-poop---. In any case, as much as it sucks that PC's dropped legacy support for the Serial and Parallel ports (thus crippling an entire legacy of DIY projects in one fell swoop) the USB replacement is nearly as pleasing. Not nearly as simple as interfacing to a parallel port, you still have a huge number of people developing peripherals right and left and you have countless companies offering up USB enabled ICs. The USB stack is very well documented. USB is going to stick around for awhile.

But alas, the MAMEDev will do what they want. Suggestions be damned.

edit: fixed typo

[Ummon]

Um, all that stuff ain't really what this thread is about. Hence, I'm bumping my last post:

Anyways, yeah, I totally forgot it was a chain-driven mechanism an all. Partly, I was caught up with my own idea - which is it being a spinner-type device, with a race/spoke deal at the top that the angled shaft is connected to - kinda like a manual mixer or drill with a slanted shaft, rather than a crank.

The dexterity required to turn the race might be more than enough to compensate for the slickness of the spinner element. Even re-designing it further by putting in a crank with a spinner handle could be cool (I've actually presented this idea in years past), and the race set-up still possibly present enough resistance.

Regardless of design, the handle should be a spinning top - it should've been on the game, and I thought so the first time I played it in '86. I really thought they missed the cherry on that sundae.

[RandyT]

Anyways, yeah, I totally forgot it was a chain-driven mechanism an all.

It's not really "chain driven", rather it's driving the chain.  The chain is specifically there to burn off momentum, and probably add some resistance as well.  I think it was mentioned earlier that the operator could adjust the screw to make it not free spin.

Partly, I was caught up with my own idea - which is it being a spinner-type device, with a race/spoke deal at the top that the angled shaft is connected to - kinda like a manual mixer or drill with a slanted shaft, rather than a crank.

The dexterity required to turn the race might be more than enough to compensate for the slickness of the spinner element. Even re-designing it further by putting in a crank with a spinner handle could be cool (I've actually presented this idea in years past), and the race set-up still possibly present enough resistance.

I'm having trouble with the terminology.  What are you referring to when you say "race"?

Regardless of design, the handle should be a spinning top - it should've been on the game, and I thought so the first time I played it in '86. I really thought they missed the cherry on that sundae.

The spinning top wouldn't work (well), due to the angles.  It would need to be something like a ball pivot, which would probably pinch the hell out of your hands.  I think this is why they went with a shaft that was decoupled from the encoder shaft.  This way, it feels like regular joystick in your hand in that the stick shaft can be turned, and it can still be spun.

There might be another approach that gives the same effect, but I can't think of one at the moment that wouldn't drastically alter the feel and appearance of the control.

RandyT

[u_rebelscum]

I hate it when I'm put in a position defending points that aren't mind.

Something I totally agree with Aaron is that if you don't enjoy what you're doing for fun, you wouldn't be able to continue doing it: for the mame project to continue, it has to be fun for the coders.

 Thats all good and stuff... However... (good points removed for space)
 
 Mame can and would still continue if nobody else supported it.. however, its pace would be a heck of a lot slower.

That's what some MameDev want: slower development, less visible, less side issues.  Which this (inputs) is to most mameDevs, sad to say.  IOW, some mameDev say "so what" to your points.

If you want to spend some time (~1 hour total) on seeing how Aaron thinks on how mame should (& is) be run, you can catch his talk on how to keep a project running for many years ( of 5).  He addresses your points far better than I can, and is the head of mameDev, so far better authority on it than me.

You're talking about adding a one game option to mame's Core Input Options?

 No.  Im talking about any and all games which have similar problems.  Such as
the problem with not being able to use a real arcade shifter in all racing games in mame.

You showed three new options, one that effects one game, the other two effect at most 236 parents (that number from all "driver" genre parents at Maws), or 5.5% of all parents in mame. (slightly higher percentage than if I included clones).  The latter two option have a (very very small) chance, the one game option doesn't.

Mame will never add a game specific option.  Code bloat, code support, code maintainance, code upgradability, option bloat, help support, modularity, all point at not doing it.  So your "solution" is not valid for official mame.

 Never?  I didnt realize I was speaking to the Leader of the band...

Prediction that will be true as long as Aaron or Haze lead mame.  After that, who knows.

Every few releases... Mame has done some extensive changes which for the most
part, are not all that necessary, and do not do much to change anything.
Its simply more palatable and cosmetic than actually useful.

Almost all the changes you're alluding to as "not changing much" is for cleaner code, better modularity, better expandability, and preparations for further changes that many people (including you) here want (linked cabs, for instance).  As you say, almost zero changes for the user.  Not necessary for the current status quo, true.  But it's necessary for future changes, future viablity, and the future of mame.

I didn't say I came up with the idea.  I helped implement it, and messed with the code, so know how it works.  And know how much a pain it is to have multiple mame inputs combined to one game input, and it's not easy.

 I also found your older builds confusing.. as with so many options.. a person would have
a hard time figuring out how the heck the actual game was supposed to be controlled.

 However, this is Not that case.   Its dead simple.   You click arcade control if you have
a real controller.   Its not 55 ways to control a game all in one menu.

Again, you're looking at the user's point of view.  The bigger issue, AFA mameDev cares, is the from a coder's point of view.

Code-wise, what does the switch do?  Is the difference in the core level, or in the driver level, or a mix?  (Looks like 90% driver to me, which is the harder side, as each driver has to be updated, and if the driver is WIP this addes another thing that might break.)  How does the user remap the two different (real vs PC) input?  How is it coded?  How does mame save the mappings?  What other game "specific" "real options" are we going to run into (qbert & roadblaster OTTOMH)?

The way I see it, the code is going to be just as mixed as mine was.  Driver level if real_option then do this with these inputs, else do that with those inputs.  Expanded input define MACRO sections.  Either expanded info.c resulting bigger listxml, or the "real" inputs not ducmented in listxml.  Either the hacked mess I had with fake player 2 & 3, or new input type(s) to cover the special "real" ports, or somme radical new way of doing it.

I very well could be wrong on the details, but it looks hard to code to me.  If someone doesn't love inputs as much as you or me, and doesn't know more about coding than I, they aren't going to do it.

Just like it doesn't do pong.

 Mame is:   Multiple ARCADE Machine emulation.
 
 Excuse me... But wasnt Pong an Arcade Machine?...
[/quote]

You -> Preacher
Me ->  Choir

All you said on this is valid, and won't convince someone not already in the choir.   
Which is why I said "Just like pong".

[u_rebelscum]

What's to stop MAMEDev from defining raw input, allowing us to leverage that raw input and then let people like Randy develop the hardware to go with it? Isn't that exactly what 255 USB class is specifically for? For situations just like this.

255 USB class?  I'll have to look that up.  But...

AFA mame goes, a few things.  First, the same thing that's stopping the spacenavigator from working: someone needs to write extra code for mame to reconize the non-game-control / non-pointer class input.  Second, for mame to use the info, it either has to behave like the other classes (like the spacenavigator would) or mame has to setup special ways of storing and translating the data.  Third, the same thing I've been saying above: aaron's policy is to avoid multiple ports for a single input.  Some clean way to have the two ways (raw original & PC standard) to be there without confusing the source code, confusing the coders, and lastly and least importantly confusing the user more than needed.

[Ummon]

It's not really "chain driven", rather it's driving the chain.

Technical bast. But, yeah.

I'm having trouble with the terminology.  What are you referring to when you say "race"?

Flat, roller-type ball bearing assembly - that would either support the hub the crank/stick was mounted to, or as an all-in-one unit. Make more sense?

The spinning top wouldn't work (well), due to the angles.

I think it'd give a hell of a lot more relief than having to ease up on your grip. I hated that. Hell, go for broke, and put a crank assembly on it. I thought it was way weird as a 'stick' back then, but this is not surprising.

[u_rebelscum]

What do you mean by "race"?

I'm having trouble with the terminology.  What are you referring to when you say "race"?

Flat, roller-type ball bearing assembly - that would either support the hub the crank/stick was mounted to, or as an all-in-one unit. Make more sense?

I'm still not picturing it, of at least not seeing it like you probably are.  Very rough pic below.  Is the "race" the thing holding the lower disk?  If not, could you draw a rough pic of you're talking about?