What's new
Ok, so with a combination of what I see in OR2SP and F-ZERO logs, I've put together an init sequence that ends up stopping at the center of the wheel and allows me to issue the centering command for it to self-center without external monitoring. I can even put it into a state where communication can be severed and self-centering still happens. All of this is done without wheel pot monitoring. A variable or two would have to be adjusted according to the unique configuration of a given wheel.

I confirmed that the initialization commands are needed to be able use the center command. In my previous attempts with only a partial init, the center command wasn't doing anything. I would have to do a lot more work to establish which commands affect it, but not sure if I want to mess with that at this point now that I'm on track to meeting my goals. Whether or not I know what all of the init commands do, as long as I have a working sequence that lets me translate Namco commands to MIDI commands, I'll be happy.

I'm kind of optimistic that I can get away without monitoring the wheel pot even for Namco FFB games as I believe my early testing in WMMT indicated that the game would still send a command based on its reading of the wheel pot, not the positional data sent back as an ACK from the FFB board. That means the FFB board can potentially send anything back as a position and the game doesn't use that data, but rather its own reading of the analog value of the wheel position. It remains to be seen whether or not the Mario Karts are ok with this method. I will also need to make sure that movement commands aren't affecting the established center point.

It seems like it would just be necessary to have a specific initialization sequence in place that ends up at the center of the wheel.

My tests with the 83 command make me think this is what establishes the power. I can set it higher and get a high holding force with the center command, and lower values result in less force. I also think it affects the movement force because it is one of the commands in my init sequence and lowering it affected my ability to get back to the center in my previously established hard-coded number of steps.

I believe the 80 0 1 1 command is what establishes the center or holding point to the FFB board. It may be some of the other init commands instead, though, as I have incorporated most of the commands seen at the end of F-ZERO initialization.
 
I'm trying to figure out my best approach to move forward with this. I've got a pretty good grasp on how to center the wheel and get to move left and right with the MIDI FFB. I haven't figured out specifically how to get it to approach one point off center and stay there without going to the extreme left or right. I don't know if having the ability to do this would be integral to Namco FFB translation, but for sure on the Namco FFB I figured out how to set a destination and get the wheel to aim for that spot, so that may come into play when trying to replicate the wheel movements in a Namco game.

While I do have some of the Namco protocol figured out, I probably need to dive a little deeper into that.
 
Well, I think I just figured out how to establish a target point!

87 seems to be the command and the data bytes follow the same standard as 84 for left and right.

As an example:
87 00 4D sets a target point at about 90 degrees right of center.
84 01 00 tells it to go to that point and stay there.

87 01 00 sets target point at center.
84 01 00 tells it to go to that point and stay there.

87 01 1A sets a target point left of center.
84 01 00 tells it to go to that point and stay there.

So with this discovery, 87 establishes the target point and 84 establishes the movement from that point.
 
I'm in the process of doing some more robust logging of the Namco FFB. I currently have a decent log from Mario Kart Arcade GP 2 and am going to use that as a basis for coming up with an Arduino test platform to drive the Namco board and get a better understanding of the commands. I really need to get a good grasp of them before I can figure out a translation.
 
Here is my take on the Namco STR PCB Force Feedback protocol. I wired an Arduino with a MAX232 TTL to RS232 converter chip so that the Arduino could drive the FFB board.

Note that the Mario Karts use a baud rate of 19200 bps while the various Wangan Midnight Maximum Tune 1-3 use 9600 bps, so this will need to be taken into consideration when configuring a final solution to work with either of these games.

--------------------------------------------
ACKs come in the form of 3 byte packets and they simply give positional data as read from the wheel pot that is plugged directly into the FFB board. Note that the analog voltage gets passed through the FFB board to the JVS I/O, so both the FFB board and JVS I/O get to take their own readings of the wheel pot.

An example ACK:
48 01 EA

-The 1st byte is always 48.
-The 2nd and 3rd bytes give positional data from 00 3D to 03 93 (on my test setup where there is a stopping plate impeding movement further in either direction. Theoretically the values could go from 00 00 to 03 FF.

At least on my setup here are the values:
00 3D - Far left
02 EA - Center
03 93 - Far Right
--------------------------------------------

CMDs come in the form of 10 byte packets. The packet consists of all data needed to command the FFB board without the need for alternating command packets for specific instructions. The packet contains within it the target position, holding force, movement speed, and temp movement off of the target.

An example CMD:
FF FF EB 01 28 00 1E 00 81 00

-First and 2nd byte are always FF FF.
-The 3rd and 4th bytes set the target position. Targets from center to the left are FF 01 to 00 01. Targets from center to right are 00 02 to FF 02. When changing target values, they must be sent in incremented steps or the command will result in no movement. In Mario Kart Arcade GP 2, the common value seen in my logs is EB 01 (the center established during analog initialization) in the test menu. Basically the game is mostly keeping the wheel centered with other values in the CMD being changed to affect movement.
-The 5th byte is holding force. There is no force with 00 and nothing noticeable up until about 10. 10 being the weakest and 7F being the strongest. Values >= 80 cause the entire command to be ignored. The common values logged from MKGP2 with normal wheel strength are 2D and 28, but would likely change based on wheel strength set in the test menu.
-The 6th byte is always 00.
-The 7th byte controls movement speed. The lower the value, the faster the speed. Slow movement is 81 all the way up to 00 for the fastest speed. Values higher than 81 result in continued shaking at the target point, which I do not believe is an intended effect based on logs, where I am not seeing high values. MKGP2 gives common values of 1E and 14, which do not result in shaking. These values may change based on wheel strength set in test menu. In a log from WMMT3 made by @Dion here shows that the max value in that game is 3F.

-The 8th byte is always 00.
-The 9th byte is a temporary movement off of the target point. If this value is set to something greater than 0, it results in the wheel moving left or right to a certain point and then returning back to the target until another command is sent. If no other command is sent, the wheel will hold at the target point after the temporary movement is complete. MKGP2 seems to make use of this for most of the FFB effects rather than changing the target position. 00 results in no movement from the target. Movement to the left from slight movement to largest movement is 01 to 7F. Movement to the right from slight movement to the largest movement is FF to 80.
-The 10th byte is always 00.

The command to kill movement/holding force is:
FF FF FF 01 00 00 00 00 00 00

Note that @Dion made some observations on the commands here and they mostly align with my test results.
--------------------------------------------

Note that the Namco STR PCB Force Feedback board makes use of a POWER pin at pin 8 of the 8-pin header labeled J101. It gets wired to an output on the JVS I/O. This pin needs to be driven correctly in order for the FFB board to do its self checks and allow for communication. When wired directly into the JVS I/O, the I/O board grounds the POWER pin when activated. If manually controlling POWER, like I am doing in my Arduino tests, it needs to be grounded (LOW) at or after boot and allowed to go through its quick self test where it barely moves the wheel and passes (no blinking LEDs after passing). Then it get released from ground (HIGH) until no LEDs are blinking. Then grounded (LOW) again and all LEDs go off. At this point commands can be sent.

Using the information provided here, it would be perfectly feasible to drive the Namco FFB board for other games if you translated the protocol. That is not my goal, though. I just need to know how to interpret the commands sent by the Namco games so that I can translate them to the Sega MIDI protocol.

Now that I better understand the Namco protocol, I need to look over logs to get an idea of the intended behavior so that I can think of a decent way to translate that to the MIDI protocol. The nice think about the Namco protocol is that everything is captured in one command packet, whereas the MIDI protocol will require multiple command types to get the desired behavior. For example, if I receive a Namco command that has a temp movement specified, I will potentially have to drive the MIDI board with at least 2 commands: one to move it to the temp position and one to move it back to center.

In my early tests last year with replying to the Namco game (WMMT) with ACKs via my PC, it gave me the impression that the commands received were not dependent on the position replied. I could keep replying with the center position and still get all of the necessary commands for force feedback movement, which is great because that potentially means I don't need to monitor a pot with the Arduino (one less thing for it to have to do and one less thing to wire up). Once the MIDI board is initialized and centered correctly, it will keep track of its own position and I can issue commands that I need to based on movement away from the center.
 
Last edited:
In planning out the translations from Namco to MIDI, I've got the following:

Things to keep track of:
Notes:
Target positionTranslate to MIDI equivalent: 87 to establish position and 84 01 00 to move there. Only needs to be set when there is a change from the previous value, so tracking will be done in a variable and compared to current command. Translation formula needs to determine if target position is right or left of center and then establish a MIDI equivalent, probably through scaling.
Holding forceTranslate to MIDI equivalent: 83 - Only needs to be set when there is a change from the previous value, so tracking will be done in a variable and compared to current command. This should end up being a relatively simple translation where I come up with a scaling formula from Namco to MIDI using my best guess about equivalent force.
Movement speed Need to translate to MIDI equivalent: 84? - Speed for MIDI seems to be a function of how far away from the target point the movement command is specified... Maybe this can be ignored?
Temp destinationTranslate to MIDI move left/right, and then maybe re-center: 84 - I may rely on future commands to re-center, but otherwise the wheel needs to be re-centered after reaching the destination: 84 01 00
The translation formula can be treated the same as the Target Position one. When this value is present in a Namco command, it gets priority over the Target Position.
Kill command:
FF FF FF 01 00 00 00 00 00 00
Translate to MIDI equivalent: 80 0 0 0


Movement speed is the only one I'm not entirely sure I have a clear equivalent for. As noted: this seems to be a function of how far away from the target point the movement is set, which I think is going to be determined by either the Target Position or the Temp Destination. I have identified MIDI command 83 as holding force, but it may also impact speed.

Next I'll come up with the translation logic.
 
I'm going to have run the MIDI board with the Arduino again to confirm some min and max values, but I think I've got a pretty good mapping in place that will inform the translations. Overall this shouldn't end up being too terribly complicated. I'm optimistic that a translation is going to be feasible and get those of us with the MIDI system playing the Namco games with decent force feedback effects.
 
Last edited:
After a lot of testing with some of the unidentified commands in the MIDI protocol, I can't figure out a command that simply sets the speed. I can establish holding force, but the only thing that seems to speed up movement is using the 84 command which specifies left/right movement from the target point. Specifying values further away from the target point result in greater speed of movement. With that in mind, I think I will need to monitor the speed value coming in from Namco protocol as well as the temporary position and try to come up with a translation that captures both of them in the same MIDI command.

Looking at Namco logs, it doesn't look like the target point get changed off center very often and it's when using the 87 command in the MIDI protocol to change the target point from one to another where I'm getting seemingly slow speed, so I think what I can do to speed up the movement is issue an 84 command to move in the appropriate direction at a designated speed and then issue an 87 command to set the new target position. I expect most of what I'll be trying to translate is going to be in the form of 84 commands for temporary jerking left/right off of the center and changing up the holding force with 83 commands.
 
I have made some progress with what will become my NAMCO to MIDI translator, but I'm hitting a wall in my current tests with replying back to Mario Kart Arcade GP 2 with ACKs like those produced by the NAMCO STR board.

I can get through initialization and pass the steering check at boot, but the game never issues any commands for movement beyond its standard default command that doesn't contain any command to move or lock the wheel.

I thought at first that this was due to me replying with a static position, so I wired up the wheel pot and am now reporting that in my ACKs, but still no worthwhile commands from the game during gameplay.

I even went as far as wiring up a simulation of the POWER line as driven by the I/O to tell when the FFB is being told to initialize. I believe I'm replying in those instances with the correct ACKs.

I think I'm going to have to get more logs from the stock hardware to see if I'm missing something.
 
Is this only with Mario Cart GP or with other NAMCO games as well?
 
Is this only with Mario Cart GP or with other NAMCO games as well?
So far MKGP2 is all I'm testing.

As another test I wired up the NAMCO FFB so that it drives its own pot and JVS is seeing the OR2SP wheel pot. In this case where the FFB and JVS pots are never aligned, the FFB still works in game.

I might need to observe and better mimic the NAMCO FFB initialization.
 
Getting expected commands from MKGP2 is still eluding me.

I'm not sure what exactly caused it, but the situation is slightly better than before. I am now seeing varying commands related to events in game, but the holding force is at a constant low value that would basically be equivalent to no holding force at all.

I still need to get some full logs recorded with CMDs and ACKs from stock hardware to see if I'm missing something.
 
Progress!

Things are looking up. I've got MKGP2 communicating with the Arduino and the game issues the expected commands that I see in logs from the stock hardware.

The issue appears to be with the way I was monitoring and responding to the state of the POWER line. POWER is an output from the I/O, driven the same way that a lamp on a button is driven. Basically an output on a JVS I/O sinks current to ground when activated. In the case of a lamp you've got the + lead of the lamp going to power (either 12V or 5V according to the specs of the lamp) and the - lead going to the output on the I/O where it is grounded when the output is activated. The POWER line originates on the NAMCO STR PCB, and I assume it's tied to an input on the PCB and it is sensed as either 5v or 0v. It's normally 5V unless grounded by the I/O. When the PCB is first booted, it's in a state where it hasn't been initialized and does not respond to any RS232 commands. The STR PCB generally replies simply with positional data, but under a few circumstances it replies with status ACKs. Status ACKs appear to be sent twice in a row for a given status. When it senses the POWER line is low, it initializes and starts replying to commands, the first 2 replies being that there is no error and then 2 replies that it senses POWER is off. Error status if a fault is detected would potentially be sent during this time to be generated on-screen to inform the operator of an issue.

I had all of this happening as I was duplicating the ACKs I saw in my logs. However, it appears I was missing the ACKs that indicate when POWER is put back ON, which happens after the wheel check has passed. I suppose the game recognized a fault because of the lack of this status reply, but it's curious why it would send anemic commands for the duration of the game rather than give an error message to the operator. I suppose the chances of a real-world scenario with this happening would be virtually non-existent because if the PCB can sense and respond to POWER OFF, then it should be fully capable of responding to POWER ON. If there were some kind of fault keeping it from sensing POWER correctly, it would likely fail the check on the next boot and indicate an error to the operator.

I want to give credit to @Dion for discovering much of the mystery surrounding operation of POWER and he even documented the status replies here.

Now that I'm getting the CMDs I expect, I am ready to start translating them to the MIDI protocol. I have much of that logic mapped out already, so hopefully I'll have something working pretty soon.
 
I have the beginnings of Namco to MIDI translations in place and mostly working in MKGP2!

The game allows me to finish a race and keep continuing with FFB working, but when I choose not to continue, it gives a wheel error rather than going back to attract mode.

This tells me 2 things:
1. The game allows the player to keep playing even if a fault is detected mid-game - presumably to allow the operator to bring in more money before the game goes into an error state.
2. Something is causing a fault to be detected once a game is started, and it may merely be an issue of not replying with Namco ACKs quick enough after trying to manage translation and MIDI commands.

Things are looking good, though! This will end up working. An absolute worst-case scenario if I can't get the timing down would be to manage it with 2 separate Arduinos where one is mainly devoted to replying to NAMCO and the other is mainly devoted to driving MIDI, with a little communication between them. I'm not going down that path yet, as I think I can program the single Arduino more efficiently to handle this task.
 
You could just reply and ignore the midi translation to test if it still errors out like that.
 
You could just reply and ignore the midi translation to test if it still errors out like that.
I've been doing a few tests with just NAMCO and am still running into the same situation, so I'm going to go back to monitoring stock hardware to see if I can figure this out. I was hoping to avoid wiring up for two-way monitoring, but now I'm going have to because it's too difficult to tell what's happening when I'm only seeing one side of the communication.

Also, a previous test I had done was to have the NAMCO STR PCB wired up to its own motor and pot and JVS wired up to the pot on the OR2SP wheel. I never got through a race and finished in that scenario. I'm now curious to know if it will go back to attract mode without error. If it does, then I know the reported NAMCO position doesn't have to align with the JVS pot. If it doesn't, then I know I'm going to need to work to align the reported values better.
 
I have wired up for 2-way communication monitoring for NAMCO FFB in addition to POWER monitoring.

Now I can better see the complete picture, including behavior as it relates to POWER changes.

It's a little quirkier than I thought, so all previous attempts are failing to mimic the stock hardware exactly. I should be able to use this information to fix that.

One thing I'm going to need to keep track of is the initialization status of the simulated NAMCO STR PCB. I have a timeout built in to tell when NAMCO CMDs have stopped, so I can go back into an uninitialized state at that point and then follow the same initialization procedure each time the game or test menu boots. As it is, the stock board will sit in an initialized state indefinitely and behaves differently when the game boots according to whether or not it's already initialized. It will be easier for me to manage the same behavior every time.

An area where the stock behavior is different than my attempt is with regards to the ACKs when the POWER state changes.

The default state for POWER, which is generated by the STR PCB is HIGH. As mentioned before, POWER is driven by the JVS I/O which sinks it to ground when activated, bringing it LOW. Therefore LOW would indicate that the I/O's output is active and I'm seeing that reported in the STR PCB's ACK as POWER ON. HIGH is reported as POWER OFF. I think I had these reversed.

In an uninitialized state all CMDs are ignored, so no ACKs are sent at all.

If not initialized and POWER goes LOW, then a self-test is initiated and initialization occurs, ignoring all ACKs. This happens during wheel check at boot. In my log I'm counting about 715 ignored CMDs during this period, and then a double ACK of E00 E00 (NO ERROR) [*note that this is the only time this ACK is seen] - still ignoring CMDs. After a couple of ignored CMDs, POWER comes back HIGH with a double status ACK of C06 C06 (POWER OFF) is sent. After this normal positional ACKs resume. The game eventually boots, with constant standard CMDs that have no force and standard positional ACKs. When the game goes into attract mode, it appears to have a little bit of centering force, but when a game is started POWER goes LOW, the board ignores CMDs and gives no ACKs for about 865 CMDs while going through a self test again, after which it gives a double status indicator of C01 C01 (POWER ON) and starts responding to CMDs with positional ACKs. Much later - at the end of the game - perhaps after choosing not to continue - POWER goes HIGH again with an immediate double ACK of C06 C06 and no break in ACKs.


In an initialized state, all CMDs get a positional ACK, unless POWER goes LOW.


These tests were done with the NAMCO STR wired up to its own motor and pot, and JVS seeing a separate POT, so they do NOT have to sync up. In this setup I am able to get through a race, choose not to continue and it goes back into game over mode.


A few things for me to keep in mind:

1. Status ACKs aren't replies to CMDs. They are sent twice in a row without regards to CMDs.
2. When POWER is LOW, all ACKs are ignored (at least initially--during a self test - after which time ACKs resume, even if POWER is LOW)
3. The NO ERROR ACK only comes after the self test during first initialization.
 
Last edited:
Guess who has a working Namco to MIDI FFB translator!

So it wasn't a timing issue at all. I just wasn't handling ACKs to POWER changes correctly.

It's all totally doable with a single MEGA 2560.

I want to make a few changes to the handling of the translations to MIDI commands, but otherwise I'm pretty happy with the results.

The reason I want to make some changes is that some of the jerking left/right commands are pretty quickly overpowered by a centering command to the point where the effect isn't felt as well as I would want it to be, so I need to delay centering.

I eventually want to have this board sit in between the stock MIDI wiring so that it can take over for NAMCO or non-FFB games or pass-through for MIDI games, so I've got some work to do to figure that out.

I also need to do some WMMT tests, making sure to change the baudrate for those games. I'm optimistic it will work without any other changes needed, but we'll see.

At this point I'm very happy with the progress I have made. It makes these games totally different being able to play them with FFB.
 
Back
Top