New Product: 49-Way USB Interface - The GP-Wiz49 with DRS Technology (TM)

[dema]

While it sounds like a neat idea to me, I most likely won't purchase it, cause I don't want my wife calling me at work complaining that pacman won't let her go left and right cause I was playing stargate last night and forgot to reset it.

[Flinkly]

as for all this software switching mumbo jumbo...

i'm going to make a book of all the unique games that my cabinet can play.

[Grasshopper]

The difficulty in writing drivers for Windows/Linux/MSDOS/Mac etc is another reason why I think a ps/2 mode would be useful.

The Ipac has drivers for all of the above operating systems (plus an interactive mode that will work with any OS) and I suspect this might be because it is easier to write drivers for devices connected to the ps/2 port than USB drivers.

[SirPoonga]

I understand you most likely can't do this with out a driver for the device and you want to stick to a HID device that requires no driver, but why?

[SirPoonga]

Anyway,

[tetsujin]

Thanks for providing an answer to my question.  Personally, though, I feel that putting that control over the device's behavior on the PC side (where it belongs) is very important, as I want to build my cabinet without assuming the people playing it will know things like the button layouts for a game, the type of joystick it uses, etc. beforehand.  Where possible the 8-way/4-way/2-way/49-way selection should be taken care of for them.  (I say "where possible" because I don't have a way to do that with T-Stick+'s because I have no way to control the mechanical slider with software - but as this is a problem of controlling software behavior it seems very possible)

The hard part would be coming up with software that is cross platform, not the hardware. 

Edit:  I just realized you were talking about changing modes.  simular thing applies however the software to program the hardware or change the mode would have to have an API (be it commandline or whatever) that a FE can use.

That's true, about the cross-platform software.  Being on Linux, it's not an issue I could necessarily ignore if someone rolled out a device with Windows drivers.  There doesn't seem to be a good cross-platform way of interfacing directly with HID devices.  If the relevant information were available for a given device I don't think it'd be too hard to do it on Linux.  Just a matter of sending the right report to the right device.  But for the feature to be generally useful the driver to do that would have to be supplied on Windows at the very least.

This is why I think interfacing the encoder to another circuit could be a good middle-ground solution for people who want this control but aren't up to the technical challenges of doing the software (or hardware) to do it over USB.  It's something that could be done with the encoder as it is, and then the "API" would consist of sending bytes to a serial port or toggling lines on a parallel port.

Randy: The above isn't a proposal for a product change or a new product.  I'm not a business guy and I have no great ambition to become one.  More a suggestion for people who, like myself, want the ability to control this behavior through software with the existing hardware.

And believe me, I know the T-Stick+ and similar joysticks are a compromise - if I could control the toggle with software I would.  The reason I can't is a practical one: controlling the mechanical parts with software requires an actuator that can do the job, and I don't know where to get such a thing or whether it would fit in my CP.  The best I can manage is to use switches to monitor which state the joystick is in, and feed that info to the front-end so it can block people from running games that need 8-way when the stick is in 4-way mode.

The limitation with the '49 is more artificial.  There's no practical limitation keeping that feature from being software-controlled.  And from a UI standpoint the situation is bad: the front-end or the CP need to tell people how to set the mode, and there's no provision for letting people know what mode is active.  In a more perfect world I'd prefer the encoder to have software control already - but in practical terms, the encoder provides enough button inputs that the ones that control mode could be dedicated to that purpose, and I could add that feature externally without worrying about what buttons are being pressed on the CP.  I guess that'll have to do.  When I build such a thing I'll be sure to share the design.

[SirPoonga]

I know when I get one of these I might have encapsulate my mame exe in a bat file and make a program that will control the modes and possibly LED indicators around the joy indicating which directions are enabled.

Now I really want those glow ball tops, translucent buttons, glow tball, now just need a glow spinner....  Mmmmmm, lights...

[sWampy]

I understand you most likely can't do this with out a driver for the device and you want to stick to a HID device that requires no driver, but why?   

You know how nice it is to just plug something in and it works?  I do that with my zip drive.  No drivers needed.  It just works.  Same with mouse and whatever.

The biggest reason is someone would have to write the driver.  If RandyT doesn't have this knowledge he has to outsource it.  Like oyu said though, he could give the specs to someone and have them make the driver for him.  I'm sure if he looks around someone will volunteer their time and effort.

Yes, plugging something in and needing no drivers is nice, but this isn't a jump drive, you will take from machine to machine, this is a controller you are going to put in an arcade cabinet once and leave there, loading a driver once is trivial.   

I think it's possible to have HID devices that also have drivers where you get some function with no driver and added features if the correct driver is load.  More advanced mice do this all the time, with no driver the buttons work, with correct drivers, all buttons and force feed back/etc work.  It mostly seems that not having a 2 way interface available on this thing where you could send it a 0-7 to set it to a certain state was/is a big oversite.

I have 3 cabinets all with mini-pacs in them, if I could just replace  one of the joysticks and add this, I'd at least try it on one of my cabinets.  But as it stands, I'd have to replace the joystick, and rewire at least player 1 buttons so I could set modes, and reprogram my minipac's shifted keys to other buttons where I could still get to coins/volume/etc.   A lot more work than it should be.

[SirPoonga]

I think it's possible to have HID devices that also have drivers where you get some function with no driver and added features if the correct driver is load.

[ripzone]

RandyT, try to implement the Software change modes solution.

That would be the best option for most of us, or in alternative, only one button to change modes.

Thanks!

[Flinkly]

sorry, i've got to say this...

not to poopoo on anyone, but randy is providing us with this product.

[RandyT]

Yes, plugging something in and needing no drivers is nice, but this isn't a jump drive, you will take from machine to machine, this is a controller you are going to put in an arcade cabinet once and leave there, loading a driver once is trivial.   

This is exactly the opposite from the sentiments I have been hearing.  One of the major concerns people have had is whether they can take a control panel they build based around one of these interfaces to a friends house and plug it in and play without a lot of hassle.  i.e. Thumbdrive like transportability. 

And speaking of which, a client brought a thumbdrive into our offices a short time ago that worked great on his laptop and said it was supposed to be "plug and go".  We spent half the day trying it on a half dozen systems, and couldn't get it to work.

Saying something and making it so are two different things and with USB, it's just not as simple as it sounds because of the number of variables involved.  The examples you give on the behaviour of other devices fail to take into consideration the 12 people that worked for 3 months straight developing firmware and supporting software, or the potential market of millions for the device to pay for it.

So yes, lots of things would be nice.  How many are willing to fund the development of them?  Far less than wish to have a say in the products design, I'm sure.

RandyT

BTW, Thank you Flinkly for the words of support.  I'm sure there are a lot of folks like you out there that feel the same way, but don't want to get involved in the "trial by fire" that all new developments go through on the board.  I've been through a few of them and now that the scar tissue is starting to build up I can't feel it much any more 

[dema]

Randy, I'm with Flinkly. I'm just happy you're offering a product like this. I'm not knowledgable in these sorts of things, nor am I that adept in cabinet building, so this is a great benefit to me. For a guy who was going to go with an 8 way and a 4 way and hope for the best, I'm just thrilled to hear that this great alternative is available. The other stuff people want would just be a bonus, and there is a lot of time in the future for people to build upon this and make it happen. Until that time, just know that I (and others like me) are very excited about the product and I'll be buying two of them.

[Hoagie_one]

This is exactly the opposite from the sentiments I have been hearing.

[1UP]

For everyone asking to have this redesigned to have software mode switching--sounds like a good BYO project to me.  Surely one of you can write this into an FE, and rig up a simple parallel port interface that would consist of a few resistors and transistors.  The FE sends a commandline to the parallel port when a certain game is run, the board makes the connection to send a button press to Randy's encoder, and you're done.

BTW, it would be great if Randy could make something like this, but I think it should be an addon rather than standard.  I'm sure lots of people would rather keep it cheap and push the buttons themselves.  If you look at all the complicated routes people will go to avoid spending $30-$40 for a good spinner, you'll see what I mean.

[u_rebelscum]

Thanks for the heads up, but it was unnecessary . 

Didn't think it was, but just in case. 

I just have a misgiving about the possibility of stuff being lost in translation:
1) 49-way 8 pins -> USB analog ("raw", "Progressive", "linear", "exponential")
2)    -> mame internal analog
3)    -> gamedriver 49-way 8 pins. 
editted: layout and numbering

Actually, the hardware removes one level of translation. 

  Which one? I don't see how that could be possible.   If anything, I've left out translation steps ('cause usually those steps aren't used or are skipped).

Compare with the straight path the original controllers followed: 8 output pins on joystick -> 8 on the PCB.  Zero translations, and processing was done by game's ROM.

Of course, normal analog joystick games don't do the processing in their ROMs; that's what your wiz49 does, so the stick can work on those games (& official mame).  (Translation 1)

Now it's in "analog stick" format.  Mame reads it and translates it to it's internal format.  (Actually, mame reads, saves in directInput format in OS specific part, passes info to core applying mame's analog acceleration, and saves in core's different format.)  (Translation 2)

For 49-way games, then the driver gets the mame core formated data, and translates it back to 8 bits that match the 8 pins on the joystick.  IOW, it's translated to back to the original format, so the ROM can do the processing.  (Translation 3)

I'm skipping some stuff like device driver acceleration, deadzone and other "cpoint" translations, and combining mame's acceleration into the second step when it could be seperate, all which would effect the final play.  I know steps 2 & 3 (above) are mame's "fault", but they will effect how much I like your product.  (You've tested this and probably adjusted for them, so probably okay, but...)

But I think what you may be questioning is whether the Raw and Progressive output is the "correct" output for the software to translate from.  The two 49-way datasets should pretty much  cover the future possibilities, but interestingly enough, both of them are seen as three  separate levels of force by the software.  So Progressive mode really only helps on true analog applications and may also provide some "future-proofing" for revised translations.

That's exactly what I'm wondering.  Heck, it's because of normal analog controllers and normal analog games I'm wondering.  Some joystick/gamepad drivers let the user adjust the analog curves, dead zone, ect, and almost always I don't like the defaults.  Some drives let the user set different settings per game, and I have needed to do that.  Other controllers I've tossed in the closet because I don't like the movement-to-output ratios and can't change them.  At least you'll have two and a half ("raw", progressive, and 8-way) I can try.

I'm wondering how your "grid'ing" and "value'ing" feel to me.  [shrug]  I'm not singling your product out; it's basically the same question as all input products I buy.

Actually, I have to look at the analog+ source or ask urebel on what he is doing with the 49way data.  Is he converting the data to an analog signal and letting the driver convert it back or sending it directly to the driver.
If sending directly to the driver you couldn't do something like the Wiz49 two 49way modes.

For the three games, analog+ sends the 8 pins pretty straight to the game.  (They might be bitwise NOT'ed, depending on the game & happs vs williams controller.)

Other than the three games, analog+ has no extra support for 49-way joysticks that official mame doesn't have.  (IOW, none except by remapping)


<off=chest>
Oh BTW, and just my opinion (you can ignore if you want, Randy ), I don't like the term "raw" used as the name for one of the modes.  "Raw" 49-way to me means 8 bits, one bit per output pin on the controller, matching exactly what the respective pin is outputing, four 4 bits per axis.  Wiz49's "raw" mode sounds like SJC's "linear" mode, which is very different than the raw output of the 49-way stick (IOW it is processed data).  And to me, that's not raw anymore.  [shrug]  Not that it really matters at all, and "What's in a name, a rose [blah][blah][blah]..", but everytime I see "raw" I think "data as if direct from stick" and then need to readjust to Randy's mode naming.  Sorry, please ignore this paragraph, not important. 
</off=chest feel=better>

[SirPoonga]

BTW, it would be great if Randy could make something like this, but I think it should be an addon rather than standard.  I'm sure lots of people would rather keep it cheap and push the buttons themselves.  If you look at all the complicated routes people will go to avoid spending $30-$40 for a good spinner, you'll see what I mean.

Maybe it would be better to design it as an addon.  I mentioned that it could be a keywiz replacement in a cabinet just because it has 23 extra inputs.  That's more than enough to have a 49way and any extra buttons one would need.
But if it is aimed to be an add on all that isn;t used and maybe the resources could be used to implement a new feature?

Randy, it's not that we don;t like the product.  I for one think it's one of the best things to come by.  I don't think anyone is getting that point.  Many of us are just wondering why you didn't go that extra step that could possibly be feasible.  It's how products improve when customers ask about it.  It's like when the keywiz came out all of us that wondered why there isn't keyboard led support...

[sWampy]

Yes, plugging something in and needing no drivers is nice, but this isn't a jump drive, you will take from machine to machine, this is a controller you are going to put in an arcade cabinet once and leave there, loading a driver once is trivial.   

This is exactly the opposite from the sentiments I have been hearing.  One of the major concerns people have had is whether they can take a control panel they build based around one of these interfaces to a friends house and plug it in and play without a lot of hassle.  i.e. Thumbdrive like transportability. 

And speaking of which, a client brought a thumbdrive into our offices a short time ago that worked great on his laptop and said it was supposed to be "plug and go".  We spent half the day trying it on a half dozen systems, and couldn't get it to work.

Saying something and making it so are two different things and with USB, it's just not as simple as it sounds because of the number of variables involved.  The examples you give on the behaviour of other devices fail to take into consideration the 12 people that worked for 3 months straight developing firmware and supporting software, or the potential market of millions for the device to pay for it.

So yes, lots of things would be nice.  How many are willing to fund the development of them?  Far less than wish to have a say in the products design, I'm sure.

RandyT

BTW, Thank you Flinkly for the words of support.  I'm sure there are a lot of folks like you out there that feel the same way, but don't want to get involved in the "trial by fire" that all new developments go through on the board.  I've been through a few of them and now that the scar tissue is starting to build up I can't feel it much any more 

Ok, Randy, I'll believe you, I bet as many people want to take their arcade cabinet control panel out, lug it across town and plug it into their friends cabinet and play sinistar, ranks right up there with the number of guys who carry a round a toilet seat cover in their billfold, or women that carry around P-Mate in their pruses so they can piss in a urinal if all the stalls are full, but it's your product.

http://www.p-mate.com/eng/intro.html

[mahuti]

Whatever dude. There are lots of examples of people building hot-rod style control panels... rather than full-fledged arcade cabs. Those CPs ARE portable, and I can see the value that this product could hold for them. It's not unheard of for someone to take a CP to somene elses house...

[sWampy]

Whatever dude. There are lots of examples of people building hot-rod style control panels... rather than full-fledged arcade cabs. Those CPs ARE portable, and I can see the value that this product could hold for them. It's not unheard of for someone to take a CP to somene elses house...

Yeah, I'm sure a few do, and a few guys wear their little brothers panties.

[mahuti]

[RandyT]

Whatever dude. There are lots of examples of people building hot-rod style control panels... rather than full-fledged arcade cabs. Those CPs ARE portable, and I can see the value that this product could hold for them. It's not unheard of for someone to take a CP to somene elses house...

Yeah, I'm sure a few do, and a few guys wear their little brothers panties.

Yeah, but we won't hold that against you

RandyT

[RandyT]

I just have a misgiving about the possibility of stuff being lost in translation:
1) 49-way 8 pins -> USB analog ("raw", "Progressive", "linear", "exponential")
2)    -> mame internal analog
3)    -> gamedriver 49-way 8 pins. 
editted: layout and numbering

Actually, the hardware removes one level of translation. 

  Which one? I don't see how that could be possible.   If anything, I've left out translation steps ('cause usually those steps aren't used or are skipped).

In the sense of what the computer has to deal with. The first level translation is no longer necessary.

For 49-way games, then the driver gets the mame core formated data, and translates it back to 8 bits that match the 8 pins on the joystick.  IOW, it's translated to back to the original format, so the ROM can do the processing.  (Translation 3)

This is the part that is most important.  It also seems to be the part that is the most forgiving.  All that needs to happen here is that the game sees 3 distinct levels of force in each of the primary directions.  Anything beyond that is governed 100% by the joystick mechanics.

The analog operation is a nice bonus, and it can make some games playable that never had a chance on an 8-way.  But it will never be ideal with something that has only 1/29th the resolution (typically).

<off=chest>
Oh BTW, and just my opinion (you can ignore if you want, Randy ), I don't like the term "raw" used as the name for one of the modes.  "Raw" 49-way to me means 8 bits, one bit per output pin on the controller, matching exactly what the respective pin is outputing, four 4 bits per axis.  Wiz49's "raw" mode sounds like SJC's "linear" mode, which is very different than the raw output of the 49-way stick (IOW it is processed data).  And to me, that's not raw anymore.  [shrug]  Not that it really matters at all, and "What's in a name, a rose [blah][blah][blah]..", but everytime I see "raw" I think "data as if direct from stick" and then need to readjust to Randy's mode naming.  Sorry, please ignore this paragraph, not important. 
</off=chest feel=better>

Yeah, but you brought it up, so now we have to talk about it

By your definition, the "raw" outrput from a 49-way is binary data.  Things are either on or they are off in combinations that mean something to the application looking at them.  These combinations essentially form this "grid" that everyone likes drawing on.  The grid itself is actually the raw output of the stick.  Now, each one of these blocks can be assigned a number, or you can look at the grid and assign a range in each of the 2-axes and divide it into pieces.

The computer has no way to think about the binary data as it has no native 49-way interface, but it can assign a range to each axis or set of opposing primary directions.  Just as the circuit generates binary data based on the linear spacing of the optical sensors, it's "raw" progression, so too are the values selected along the range the computer understands. 

The digital form of output on the 49-way is mostly irrelevant when connecting it to the PC.  It's the "raw" spacing of the sensors that is important because this must always be translated into a usable form for the PC.  And if you don't perform the translation based on the spacing of the sensors, it is no longer "raw"

Raw49 =  Unmodified 49 way operation.  It is only "linear" by the coincidence that the sensors are spaced as such.

RandyT

[Landstander]

Hi Randy

Thanks for coming up with such an awesome product. I have a few questions which I don't think have been answered yet.

What is your impression of using a 49-way plus your device in place of an analog stick? Good enough to ditch analog completely?

Have you tried 720 degrees with the 49-way?

Thanks!

[Lotus]

Just have to de-lurk at this point..
I think we need to remember that it is conventional wisdom that the definition of an 8-way and 4-way stick is mechanical not electronic. The feel of the stick, ie not allowing the corners and being able to slide over the restrictor plate is why the sticks are different and why the T-Stick and even GGGs own 4-8 stick exist. So logically locking the diagonals does not gain much over what MAME already does.
I suspect that in this case the switching is necessary not to add any "feel" but because the 49-way stick is emulating the regular stick through an analog interface. So it's an extra hassle which does not result in an overall gain.
I suspect that if this was simply aimed at being a 49-way stick interface for anyone who wants such a stick, for games that use one, then it would have been accepted here with less of the "trial by fire". It's a great product for this basic purpose.

[RandyT]

Just have to de-lurk at this point..
I think we need to remember that it is conventional wisdom that the definition of an 8-way and 4-way stick is mechanical not electronic. The feel of the stick, ie not allowing the corners and being able to slide over the restrictor plate is why the sticks are different and why the T-Stick and even GGGs own 4-8 stick exist. So logically locking the diagonals does not gain much over what MAME already does.

Andy, is that you? 

I suspect that in this case the switching is necessary not to add any "feel" but because the 49-way stick is emulating the regular stick through an analog interface. So it's an extra hassle which does not result in an overall gain.

Wrong as wrong gets. The 49-way, is a very cool piece of equipment, but it has a unique mechanical dynamic.  The GP-Wiz49 compensates for that dynamic in a special way for each of the modes presented.  Gaming software will offer only a very generic translation of the analog grid and it does not suit these sticks well at all.

For example, there is a very marked difference in the way the 49-way plays in Raw49 mode and 4-way DRS mode.

I suspect that if this was simply aimed at being a 49-way stick interface for anyone who wants such a stick, for games that use one, then it would have been accepted here with less of the "trial by fire". It's a great product for this basic purpose.

And to present it as such may have caused less of a "stir" from those like yourself who don't understand the concept, but it would have failed miserably at giving the product the credit it deserves.

RandyT

[tetsujin]

Perhaps you should dedicate some space on the product page to explaining what the '49 does, and exactly why the GP-Wiz49's approach works?  I think for some people (like myself) it was something of an educational issue.  Not suggesting going into a lot of technical detail but answering in broad detail some of the questions that have come up several times (and been answered) in the thread:

- Why is it better than typical host-side A-D conversion?  (Better-fit solution, less setup work)
- Why is it better than playing 4-way and 2-way games on an 8-way? (Smaller dead zones, better responsiveness)
- What are the limitations relative to true 4-way/2-way/diagonal sticks, and how important are they?  (No restrictor plate, basically...)

and so on...

I don't think using a 49-way as an all-purpose joystick is a perfect solution (there is no "perfect", everything is a compromise when trying to make something all-purpose) but it sounds like it may be a very good one.  I think if you can help people to understand the product better that will help you to sell it.

[RandyT]

What is your impression of using a 49-way plus your device in place of an analog stick? Good enough to ditch analog completely?
Thanks!

As I wrote earlier, the 49-way may get you by on some of the analog games, but it can never be a perfect replacement for a true analog stick.

The 49-way has only...well,  49 possible locations that it can distinguish.  An analog stick can theoretically distinguish an infinite number of locations, but to be managable they usually resolve to 65536, or 256 x 256.

So, as you can see, in a game that expects true analog controls to work properly, the 49-way will only get you part of the way there.   Whether it's enough will depend on the game (and you), but it will certainly be better than an 8-way possibly could.

RandyT

[Tommy Boy]

My head is starting to hurt from trying to follow all of the "deep thinking" in this thread.  Frankly, I think I spent a lot less time buying my last car than many here are spending on ruminations for a $35 device.

For all those that think this is bunk or a burning mystery, why not buy one and test it yourself or wait for someone else to post their results.  Personally, I'm going to buy two just to support the effort.  I hope Randy and others continue to develop and take chances on this stuff. 

He has A LOT more patience than I do...

[SirPoonga]

Have you tried 720 degrees with the 49-way?

That could be interesting.  I know they put code in mame to convert analog stick to spinner.   Someone will have to try.

[dema]

I have a few questions about setting things up...

You mention that there are 23 additional inputs available on the device. Does this mean that there is the possibility of connecting up to 23 buttons once the 49 way joystick is hooked up? It looks like the Happs 49 way has a bunch of pins jutting from its board. How is that connected to the encoder? I'm guessing that daisy chaining buttons that would be repeated on a rotating control panel wouldn't be a problem?

And finally, how would I go about hooking a trackball and spinner up using a mini-pac? I wasn't sure if the two encoders were able to be linked so a single signal was sent to the PC from the players, or if I had to run them to the PC separately through the USB cable. If separately how does MAME read the two USB cables correctly so that the trackball and spinner can work along with the KeyWiz 49. Because if I need to use the trackball or spinner  at the same time as the KeyWiz buttons, won't there be a conflict? If I hooked the trackball/mouse and spinner buttons all to the mini-pac, while leaving the KeyWiz plugged in on another panel, wouldn't that create conflicts with the PC? I'm just not sure how I'd integrate the spinner/trackball with the KeyWiz49.

[SirPoonga]

And finally, how would I go about hooking a trackball and spinner up using a mini-pac? I wasn't sure if the two encoders were able to be linked so a single signal was sent to the PC from the players, or if I had to run them to the PC separately through the USB cable. If separately how does MAME read the two USB cables correctly so that the trackball and spinner can work along with the KeyWiz 49. Because if I need to use the trackball or spinner

[u_rebelscum]

I just have a misgiving about the possibility of stuff being lost in translation:
1) 49-way 8 pins -> USB analog ("raw", "Progressive", "linear", "exponential")
2)    -> mame internal analog
3)    -> gamedriver 49-way 8 pins.

Actually, the hardware removes one level of translation. 

  Which one? I don't see how that could be possible.

In the sense of what the computer has to deal with. The first level translation is no longer necessary.

So the translation still happens.  It's the translation I'm worried about, not who does it.

And since the computer has never done this step (not in official mame nor in mameAnalog+), your product is not removing it.  You even say below the computer can't understand this raw, err, original unmodified data.  Heck, the whole reason for your product is to do this step (unless in a different mode of course).

For 49-way games, then the driver gets the mame core formated data, and translates it back to 8 bits that match the 8 pins on the joystick.  IOW, it's translated to back to the original format, so the ROM can do the processing.  (Translation 3)

This is the part that is most important.  It also seems to be the part that is the most forgiving.  All that needs to happen here is that the game sees 3 distinct levels of force in each of the primary directions.  Anything beyond that is governed 100% by the joystick mechanics.

Well, the way the mame drivers for those three games are set up is pretty dumb.  The levels have to be far enough apart so the division won't hide the difference, but not too far so the division will skip one of the levels.  And this is after mame applies it's OSD to core translation + acceleration.  Which are after the first step.  So not any three levels, but three levels that pass the above criteria.

Forgiving, yes; any, no.

The analog operation is a nice bonus, and it can make some games playable that never had a chance on an 8-way.  But it will never be ideal with something that has only 1/29th the resolution (typically).

Definately, never said differently.

<off=chest>
Oh BTW, and just my opinion (you can ignore if you want, Randy ), I don't like the term "raw" used as the name for one of the modes.  "Raw" 49-way to me means 8 bits, one bit per output pin on the controller, matching exactly what the respective pin is outputing, four 4 bits per axis.  Wiz49's "raw" mode sounds like SJC's "linear" mode, which is very different than the raw output of the 49-way stick (IOW it is processed data).  And to me, that's not raw anymore.  [shrug]  Not that it really matters at all, and "What's in a name, a rose [blah][blah][blah]..", but everytime I see "raw" I think "data as if direct from stick" and then need to readjust to Randy's mode naming.  Sorry, please ignore this paragraph, not important. 
</off=chest feel=better>

Yeah, but you brought it up, so now we have to talk about it

By your definition, the "raw" output from a 49-way is binary data.  Things are either on or they are off in combinations a) that mean something to the application looking at them.  These combinations essentially form this "grid" that everyone likes drawing on.  b) The grid itself is actually the raw output of the stick.  c) Now, each one of these blocks can be assigned a number, or you can look at the grid and assign a range in each of the 2-axes and divide it into pieces. edit: added strike through and italic lettering

The lines I struck through are your assumptions, not mine.   The grid is not the raw data, the raw data is the 8 bits, period.  I gave each sentence a letter and are addressed below.

a) The raw data doesn't always mean something to the app looking at it; I can't read polish and need it translated for it to mean something to me, possibly losing something in the translation.  The translated polish is not raw data anymore.
b) The gird is not the raw data, it's an abstract vision of what the raw data represents. 
c) I guess you can do whatever you want with the grid, but the only way to make it close to raw is to put the raw data (8 bits, in binary, hex, or other number) in the square that combination represents.  Anything else is a translation or abstraction, aka not raw.

The computer has no way to think about the binary data as it has no native 49-way interface,

Yup, that's one of the main reasons I call this "raw", and your "raw49" not raw.  Sort of like people shouldn't eat raw meat, the computer can't understand the raw 49-way info.  You have to cook it to a different form so the computer understands it.

... but it can assign a range to each axis or set of opposing primary directions.  Just as the circuit generates binary data based on the linear spacing of the optical sensors, it's "raw" progression, so too are the values selected along the range the computer understands. 

In my books, that's called "cooking", aka "changing from original format", aka "not raw". 

And the binary data from the controlller is not "based on the ... spacing", and almost not "generated": 6 pins come straight from the six sensors (3 per axis) and represent if that sensor is blocked or not, the other two (one per axis) are generated from the corresponding 3 to store which side of center the stick is (note that center is considered on one of those sides since it's only one bit per axis).

The digital form of output on the 49-way is mostly irrelevant when connecting it to the PC.  It's the "raw" spacing of the sensors that is important because this must always be translated into a usable form for the PC.  And if you don't perform the translation based on the spacing of the sensors, it is no longer "raw"

Cooked is cooked to me, whether breaded and deep fried (your "progressive49") or plain steamed (your "raw49"). 

Raw49 =  Unmodified 49 way operation.  It is only "linear" by the coincidence that the sensors are spaced as such.  italics by urebel

RandyT

That's your definition.  My def of raw is "unaltered data", since your product is about sending data. 

Like I said, it's just semantics, but I'm afraid you'll get into the same problems that happen with disscussing mice if you use "Raw" (with more people than just me ).  "Mouse" means "physical device moved on pad" and/or "any physical device that sends like data" and/or "the cursor on the screen" and/or "object/instance that applications get the mouse data from.  It's those dang "and/or" that causes problems in some discussions as one person may be talking about parts 1-3, another is talking about part 4, and the rest think all things mentioned apply to all parts 1-4.   Confusion, misunderstanding, and false data come out of the different meanings with the same word. 

Just out of curiousity, what do you call the raw, err, data direct from the joystick, before it goes through your controller?  Maybe I could just use that and forget this whole raw/not raw part. 

[Hoagie_one]

I think we are arguing the symantics of vocabulary now. 

[NoOne=NBA=]

I think we are arguing the symantics of vocabulary now. 

Actually, they are DEBATING the symantics of vocabulary, not ARGUING them.

And including yourself in the statement "we" above is a little presumptuous, in that YOU haven't actually contributed to the current debate regarding symantics.
You have COMMENTED on the fact that it is occurring.

[mahuti]

more symantics

[NoOne=NBA=]

more symantics

Yes.

But MINE are more entertaining.

[Zero_Hour]

semantics   

[mahuti]

Yeah, I knew something didn't look right. Monkey see- monkey do.

[RandyT]

So the translation still happens.  It's the translation I'm worried about, not who does it.

There's really nothing much to worry about.  Either it works, or it doesn't. In this case it does.

And since the computer has never done this step (not in official mame nor in mameAnalog+), your product is not removing it.  You even say below the computer can't understand this raw, err, original unmodified data.  Heck, the whole reason for your product is to do this step (unless in a different mode of course).

Well, yes and no.  The computer has been doing the analog stuff for quite some time.  The interface steps along the analog range in the same manner the joystick actuates the sensors.  I have a hard time believing anyone responsible for writing the Analog to 49-way driver code in a game is going to screw it up so badly that it bears little semblance to the original hardware.

Well, the way the mame drivers for those three games are set up is pretty dumb.  The levels have to be far enough apart so the division won't hide the difference, but not too far so the division will skip one of the levels.  And this is after mame applies it's OSD to core translation + acceleration.  Which are after the first step.  So not any three levels, but three levels that pass the above criteria.

Forgiving, yes; any, no.

Again, not only does it work, but my testing shows that it works properly in both 49-way modes.

The lines I struck through are your assumptions, not mine.   The grid is not the raw data, the raw data is the 8 bits, period.  I gave each sentence a letter and are addressed below.

The grid exactly represents the position of the stick based on the actuation of the sensors.  It is not translated, altered or modified in any way.

How about this:  You call what is present at the pins of the stick "raw data",  and I'll refer to the GP-Wiz49 mode as "Raw49 operation"....oh wait, I already did.

a) The raw data doesn't always mean something to the app looking at it; I can't read polish and need it translated for it to mean something to me, possibly losing something in the translation.  The translated polish is not raw data anymore.

Right, but a better comparison is not a translation, merely the same words written in a different font that is perhaps more legible.  Same words, slightly different form.

b) The gird is not the raw data, it's an abstract vision of what the raw data represents. 

A chart showing actual correlations to physical things (actuations of optical sensors)  is not "abstract" .  There is no theory here, as my digital calipers will attest to.

c) I guess you can do whatever you want with the grid, but the only way to make it close to raw is to put the raw data (8 bits, in binary, hex, or other number) in the square that combination represents.  Anything else is a translation or abstraction, aka not raw.

Not true.  Grid = actuation of sensors through a given range. 

Consider this:

The actuation of the sensors is quite linear in nature, at least as linear as possible given the physical properties of the sensors and the blocking mechanisms.

So lets say they are each 1 "unit" apart from one another.  I.e. Center=0, level 1=1 , level 2=2 and level 3=3.  The range being 0 to 3.  Please tell me how setting a range of 300, with the levels 0, 100, 200, and 300 respectively differs from the first example.  Now 3000, 30000 300000 and so on.  More zeros added to the numbers alter nothing as the relationships remain constant.

Yup, that's one of the main reasons I call this "raw", and your "raw49" not raw.  Sort of like people shouldn't eat raw meat, the computer can't understand the raw 49-way info.  You have to cook it to a different form so the computer understands it.

I happen to like raw meat.  But you are glossing over the very things that this supposed "raw data" is reflecting, and that is the method used to create it.  If I just gave you the following:

1: 5v
2: Ground
3: Ground
4: 5v
5.......etc through 8

What possible use is that?  It's meaningless.  It doesn't become "data" until you understand what it pertains to.  At this point it is just "voltage"

And the binary data from the controlller is not "based on the ... spacing"

Sure you don't want to think about that one some more?  If I spaced the sensors beyond the reach of the the parts blocking them, would the voltage put out by the pins on the control circuit not change?  This is the "mechanical range" I was referring to and also the mathematical relationships that remain constant in Raw49 mode.

Just out of curiousity, what do you call the raw, err, data direct from the joystick, before it goes through your controller?  Maybe I could just use that and forget this whole raw/not raw part. 

I believe it is called an electronic "signal", which, btw, needs to be translated before it can become data

This is obviously academic, but if nothing else, there's no mystery about the what the "Raw49" mode does anymore.

RandyT