Main > Software Forum
My official MAME output wip thread.
headkaze:
So in order to turn on the dip switches you need to simulate the motor test input sequence? So I guess that would have to be the goal, to see if you can get it to past the test?
Howard_Casto:
No they aren't dip switches... they are regular switches. On the game they would be mounted at the beginning and end of the track the motor moves on. They are there just in case the motor got out of sync so that it wouldn't strip the gears trying to move further than it can. I can pass the motor startup test, but the motors still don't have their read pots hooked up. Those need to be hooked up so the game knows the motors are moving, and thus the game will adjust the motor speed accordingly.
It should be noted that now that I'm sure that the hacked up limit switches are the only thing fouling up outputs on the sega games, I would be able to go back and fix the games I couldn't get working on the yboard as well. They would also be more forgiving since they don't have motor startup tests.
Howard_Casto:
Well I hooked them up and what I get is similar to the output I get for gloc. The problem is afterburner didn't really work that way. The joystick resisted your movement when you got hit, that was pretty much it. Of course the y-axis was mapped to the motor that made the cockpit tilt on the deluxe model, but the principal is the same.
Speed and position seem to be mushed together as well. On gloc you would get 4 distinct sets of values... motor 1 speed, motor 1 position, motor 2 speed and motor two position. On afterburner they appear to be the same.
(all the below is in base-10 for readibilities sake)
Left and right direction is determined by a single bit at the "1" speed.... 136 = no movement...... 135 = moving left...... 137 = moving right. This is multiplied by 5 to get the speed, so on speed "5" 131 = moving left and 137 = moving right. So basically to get x-axis data we do a (data & 11)
Up and down direction is determind by 16 bit intervals. 136 = no movement 120= moving down 152=moving up..... again you multiply the 16 bit shift by 5 to get the speed. Making the speed "5" values 56 = moving down and 216 = moving up. So I guess a (data & 161) would give us a y value and speed.
So to get all of our values we would first do a (data & 11), if it's less than 6 we are moving left, more than 6 moving right and then subtract from 5 to get the speed.
Then we would subtract (data & 11) from the main data and compare what's left..... anything less than 81 would be down movement, anything greater than 81 would be up movement.... we'd then divide the difference by 16 and subtract 5 again to get the speed.
Does that sound about right? I'm really good at the other bits but when I have to do math, that's when I tend to make a mistake. ;)
Even if all that is correct, there is still a missing piece of the puzzle. At the end of the first stage the feedback stops for no apparent reason and it never starts again. My guess would be a reset bit is in there somewhere, but I don't have a clue as to how to find it.
Howard_Casto:
Well, after a bunch of tedious math operations I think I finally got the thing to work pretty much like it did in the arcade. The motors follow your joystick movement as you are flying around (which is normal) but when you get hit the x-axis flickers like crazy.... at least if you let go of the joystick.
I'll have to get one of those fancier force-feedback flight sticks to test more, but it looks like the output freeze I mentioned is caused by moving the stick while a "rumble" is occuring. The machine gets confused because on an afterburner machine when the "rumble" happens that stick slings your arm back and forth like you are nothing (or at least it did when i was 8) and there's no way the stick could be moving opposite of where it's moving it.
It also looks like afterburner 1 has a bigger problem with motor freeze than afterburner 2 does.
Again I'll need to get ahold of a true force feedback joystick to do further testing.
But anyway, crisis of conscience over because now that I have the data filtered out, I can see methods for using it with a standard force feedback "rumble" controller as well as a full-fledged ff flight stick.
I'll look into smgp as well. It looks like it sends motor data regardless of the error status, but it's quite a lot of data. I'll have to read up on a smgp manual to see what kind of stuff I'm dealing with.
Howard_Casto:
Early this morning I poked around for limit switches for super monaco gp and managed to get the error messages to stop in the air drive test in the service menu.
As you can see from the attached pic, we are presented with a rather descriptive debug menu. The different motor icons light up as you try them too.
If it were only as simple as that though. Unfortunately, much like power drift, the data values you get in the service menu don't seem to have anything to do with the actual values you get during game play.
This game also strobes/multiplexes it's output data like gloc does. I think I've found about 4 values in there so far, maybe more. Hopefully it'll be lilke gloc in that each motor's data is presented in a range of values, making it easy to determine with bit fo data we've gotten ahold of.
But the good news is, the newly working test menu lets me know how many motors we are dealing with and the things they are supposed to do. Before it was spitting out seemingly non-sensical data, but now that I have something to compare it to I should be able to figure it out.
And that will do it for the xboard!
I can also go back and apply what I've learned to the yboard, which will hopefully get galaxy force and rail chase working, or at least in a state where that they would work with the original hardware.
Also segas32's jurassic park and a few others look very similar to this, so I can probably get them working as well.
In case you are all wondering the key is the limit switches. On sega games buttons are generally active low (1 is off 0 is on), but for whatever reason, the limit switches on all the games appear to be active high. Since the natural state of the driver is to run "1s" through all unmanaged io addresses, if limit switches are not defined they are stuck in the on position, and the game gets scared and sometimes shuts down the motor data all-together.
Fortuantely they aren't terribly hard to find. They tend to be hiding out in "0A" (you'd have to see the driver) and in the lower bits at that. Generally you can just hook up the first 4 or 5 bits to buttons and figure it out that way.
My guess is this is less of a "we don't know how to hook it up" issue as to why they've never been binded to buttons and more of a "why bother hooking them up" one. Well now we have a reason, so I guess it's time to hook them all up. :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version