Main > Software Forum
My official MAME output wip thread.
bdam:
>I think you are confused about limit switches.
Nope, I have always understood them exactly as you describe.
>Motor/ram positions are inputs as well
Ah, that's it, that's where our lines of thinking are different. I have been thinking of these as a machine state, not an input. That the position is a state which changes based on motor output and causes limit switches to trigger. When you put it that way however, I'll agree, they can be thought of as inputs and treated like any other.
That being said, they are not user inputs. So how would the MAME team like them handled? You suggest MAME's goal is to be a 'drop-in replacement for a pcb'. I'm not quite certain that's the case. If you're right then I find it odd that the developers don't already have the limit switches and motor positions set up as inputs. My look through various drivers makes it clear that they knew where most of them were and that setting them up as such would have been trivial to do. They didn't; which makes me wonder why not.
Howard_Casto:
--- Quote from: bdam on June 04, 2011, 03:35:40 pm --->I think you are confused about limit switches.
Nope, I have always understood them exactly as you describe.
>Motor/ram positions are inputs as well
Ah, that's it, that's where our lines of thinking are different. I have been thinking of these as a machine state, not an input. That the position is a state which changes based on motor output and causes limit switches to trigger. When you put it that way however, I'll agree, they can be thought of as inputs and treated like any other.
That being said, they are not user inputs. So how would the MAME team like them handled? You suggest MAME's goal is to be a 'drop-in replacement for a pcb'. I'm not quite certain that's the case. If you're right then I find it odd that the developers don't already have the limit switches and motor positions set up as inputs. My look through various drivers makes it clear that they knew where most of them were and that setting them up as such would have been trivial to do. They didn't; which makes me wonder why not.
--- End quote ---
Well considering Nicola Salmoria, the founder of mame, recently put an article on his website describing how to use mame as a drop in replacement for a pcb and how this is one of mame's goals and primary uses considering many pcbs are tricky to repair I"m fairly sure that it's a goal of mame. ;) Also I talked to Aaron Giles about this when he was implementing the output system and that is along the lines of how the output system was setup.
Limit switches were hacked/turned off to get the games running... it's as simple as that. The mame team got sick and tired of people complaining that afterburner didn't work when all the user had to do was set the dip to upright....ect. At the time it didn't make a lot of sense to hook them up considering there wasn't any sort of output system in place to use them for anything. You'll also remember that in some points in mame's history hack were included for inputs to make some games easier to play on a joystick... and those have been removed over time as well. Long story short, mame evolves.
Also because mame is such a huge project, submissions are given a decent amount of leeway. So long as it doesn't break the game, they might allow a bit of hackery as long as it's understood that it will be removed later.
In terms of handling these sorts of input seperately, the only examples we have to go buy are the very few games in which the output positions are already hooked up (g-loc and a few others) in those they are treated just like any other input, but are hooked up with the labeling macro so that the user knows what they are. This is the method I use. If they have a problem with that then we can use the special "driver configuration" setup used by 720. It allows mutiple control schemes to be used for a single game. We could have one scheme where the limit switches and pots are hidden (and hacked to be on, so that they pass the startup tests) and one where they are exposed.
I'm sorry that I didn't reply sooner, but I'm busy with real-life stuff at the moment. I'm also in a holding pattern atm. BadMouth was nice enough to send me out a wheel and once it comes in I want to get a ff wheel game up and running with mamehooker and see how everything is going to work. Then it should be easier to determine how to go about this.
Howard_Casto:
Ok working on the outrun driver again now that I have some actual hardware to play with.
It looks like I need to do a driver configuration for maximum compatability and that goes for all sega games with limit switches, not just outrun....
Let me explain:
If all the switches are forced to be "ON" (how it is in mame now) then the game errors out of the test sequence quickly, BUT it disables the force feedback signals on the pcb. Obviously they can't be left as-is, but for those not interested in FF, this would be a nice OPTION to leave in.
If all the switches are forced to be "OFF" then the game displays an error BUT if the game can successfully move the wheel/joystick (which if you are using mamehooker it can) it will accept the motor as working anyway and send force feedback signals. This is the best setup for official force-feedback enabled controllers in windows.
If all the switches are hooked up to inputs, and you have all the necessary hardware (e.g. a real outrun deluxe cab and all the driver boards for the motor) the game should run error free. In the case of the actual hardware the limit switches DO serve an important purpose as the motor driver hardware doesn't have any limiting circuitry to stop the motor from going past it's limit. Those switches keep the pcb from shaking the motor to bits!
So I don't really see any other option than to implement all three methods.
I'm looking at how it's done in 720 right now and once I get a handle on how they are manually processing the inputs, it should be fairly easy to do. MAME has made adding menu items and turning on/off items fairly easy, it's just a matter of actually doing something with the settings.
Things in the real world have slowed down for the time being... I'll try to make a new test driver this weekend. I'll also try to release a new version of mamehooker that plays nice with wheels so you guys can help me test.
retrorepair:
I'm tidying up my sega sit down racer at the moment so I can help with any testing you need done.
Any plans to hook up lamp outputs for Virtua Racing? Feedback is probably a bit too complicated for the moment but lamps would be great. Are lamp outputs currently possibly with model 2 emulator?
Also, outrun outputs seem to be missing in the latest mame version?
jurulz:
Do you have any plan for Arm champs 2 ???
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version