Custom JVS I/O - MEGA JVS

[winteriscoming]

If you have the Card R/W function turned off, the lamps have a different behavior.

Yeah, I don't have the reader, so have to keep it turned off. I was thinking ID3 has View Change lit during gameplay. For sure WMMT blinks View Change during a race.

Both images on the multikit I have are vanilla. If you have the Card R/W function turned off, the lamps have a different behavior. If it helps with your project I will upload a video to show how and when the lamps light up. Attract mode is just the state of the machine when you're not playing but the game is running. So you'll see your last race or an AI race. Once the race is over the screens being displayed will be that of the Time Attack and Fastest Times for each course. This is when the View Change light will begin to blink. Once you press the View Change button, the left and right arrow keys will begin to flash as well.

I'm not sure what to make of it. Both of these games for me just go right into selecting a car. When a race ends, that's where it goes, too, IIRC. I never seem to be in a game-over attract mode state.

 

[freddiefiasco]

If you have the Card R/W function turned off, the lamps have a different behavior.

Yeah, I don't have the reader, so have to keep it turned off. I was thinking ID3 has View Change lit during gameplay. For sure WMMT blinks View Change during a race.

Both images on the multikit I have are vanilla. If you have the Card R/W function turned off, the lamps have a different behavior. If it helps with your project I will upload a video to show how and when the lamps light up. Attract mode is just the state of the machine when you're not playing but the game is running. So you'll see your last race or an AI race. Once the race is over the screens being displayed will be that of the Time Attack and Fastest Times for each course. This is when the View Change light will begin to blink. Once you press the View Change button, the left and right arrow keys will begin to flash as well.

I'm not sure what to make of it. Both of these games for me just go right into selecting a car. When a race ends, that's where it goes, too, IIRC. I never seem to be in a game-over attract mode state.

I'll verify these for you and I can check ID3 for you as well.

 

[winteriscoming]

If you have the Card R/W function turned off, the lamps have a different behavior.

Yeah, I don't have the reader, so have to keep it turned off. I was thinking ID3 has View Change lit during gameplay. For sure WMMT blinks View Change during a race.

Both images on the multikit I have are vanilla. If you have the Card R/W function turned off, the lamps have a different behavior. If it helps with your project I will upload a video to show how and when the lamps light up. Attract mode is just the state of the machine when you're not playing but the game is running. So you'll see your last race or an AI race. Once the race is over the screens being displayed will be that of the Time Attack and Fastest Times for each course. This is when the View Change light will begin to blink. Once you press the View Change button, the left and right arrow keys will begin to flash as well.

I'm not sure what to make of it. Both of these games for me just go right into selecting a car. When a race ends, that's where it goes, too, IIRC. I never seem to be in a game-over attract mode state.

I'll verify these for you and I can check ID3 for you as well.

I just confirmed on ID5. If I were to leave this game running, it will constantly be in a state of play. Right the end of a race if I choose not to continue, it goes to game over, briefly flashes what I guess would be attract mode and starts a new game in car selection. If I let it go without touching it, this means the timer will run out on all the choices, selecting defaults for car/transmission/race mode, etc and then start a race, lose the race and the cycle starts again... :/ I'm not sure why these games are doing this in spite of free play being off.

 

[winteriscoming]

Interesting: I turn on free play and ID5 boots into attract mode, telling me to press start button.

Alas, no view change lamp. I can see on the screen where it says to push view change to cycle through scores that it shows it flashing. I'll have to play around with this. Maybe I should report Type 3 features.

 

[freddiefiasco]

Interesting: I turn on free play and ID5 boots into attract mode, telling me to press start button.

Alas, no view change lamp. I can see on the screen where it says to push view change to cycle through scores that it shows it flashing. I'll have to play around with this. Maybe I should report Type 3 features.

Awesome. Yes, the Start button remains flashing if you have it on free play. When using coins, it shouldn't flash until you add the appropriate amount of coinage. Glad you can see what I see too.

 

[winteriscoming]

I'll have to play around with this. Maybe I should report Type 3 features.

Ok, so if I report that I have 20 outputs, per a Type 3, I do end up seeing Start and View Change light up in game. I guess the game is set to kill all outputs if not using an I/O that supports all of its ouputs.

View Change does in fact blink during a race, at least in ID5.

What's interesting is that they only have 6 outputs on this game as far as I'm seeing. Only 2 are on the 60-pin header. The other 4 are on the 20 pin header, per the ID4 wiring diagram. I guess they had the Type 3 available and thought it would be best to drive some of the outputs with that extra connector.

 

[winteriscoming]

I'm happy to report that the TeensyJVS author is OK with me using his code as a starting point and sharing modifications. Furthermore he doesn't have an issue with me charging for my boards. I wanted to make sure it didn't look to him like I was trying to use his code to make money.

I think what I'll do is share the code publicly, but probably not the board layouts. If anyone wanted them for a DIY attempt, like for chemical etching, I'd probably be open to sharing.

I really appreciated the TeensyJVS source being publicly available. I doubt I would have progressed very quickly without it, so I kind of want to pay it forward in that regard.

I'm still working on some aspects of the code and generally still testing some things, so I don't know when I'll be ready to post it.

As far as sending plans off for manufacturing a batch, that's something I'll proceed with soon. I started a test design to see if I could successfully get traces to all the pins on the 60 pin and 26 pin connectors in a 2 layer board, and it should be doable.

However, I first need to figure out what needs to happen to get this working with the Arduino DUE, and can't very well finalize the board until I do. I'll see if I can work in dual compatability into the board for those wanting to use a cheaper MEGA and forego using the cabinet's controls as a USB PC controller.

 

[Darksoft]

I'm happy to report that the TeensyJVS author is OK with me using his code as a starting point and sharing modifications. Furthermore he doesn't have an issue with me charging for my boards. I wanted to make sure it didn't look to him like I was trying to use his code to make money.

I think what I'll do is share the code publicly, but probably not the board layouts. If anyone wanted them for a DIY attempt, like for chemical etching, I'd probably be open to sharing.

I really appreciated the TeensyJVS source being publicly available. I doubt I would have progressed very quickly without it, so I kind of want to pay it forward in that regard.

I'm still working on some aspects of the code and generally still testing some things, so I don't know when I'll be ready to post it.

As far as sending plans off for manufacturing a batch, that's something I'll proceed with soon. I started a test design to see if I could successfully get traces to all the pins on the 60 pin and 26 pin connectors in a 2 layer board, and it should be doable.

However, I first need to figure out what needs to happen to get this working with the Arduino DUE, and can't very well finalize the board until I do. I'll see if I can work in dual compatability into the board for those wanting to use a cheaper MEGA and forego using the cabinet's controls as a USB PC controller.

Good news!

 

[winteriscoming]

An issue I'm struggling with is using my I/O in combination with the MIDI FFB unit for steering on OR2SP.

With FFB enabled, the controls get very erratic to the point where not touching the steering wheel usually ends up in the menu selection screens jumping between one option and the next. It's like there's one exact spot that counts as the center and a tiny movement off of it slams the menu selection in one direction or the other.

With FFB off, there are no issues and the menu selection is smooth, as if there is a nice range that counts as the middle, and the wheel has to be turned a bit before the selection changes.

If I wire up the Type 1 again, the issue goes away when FFB is on.

My analog values seem to match pretty well with what the Type 1 is reporting and even the slight jumps in values are present in the Type 1. I don't believe the jumps in my I/O are any worse, but that's all I can think it would be at the moment. I get the same behavior whether or not I suppress byte 2 of the analog data. I guess I'm going to explore some analog smoothing options and see if that helps.

 

[winteriscoming]

My analog values seem to match pretty well with what the Type 1 is reporting and even the slight jumps in values are present in the Type 1. I don't believe the jumps in my I/O are any worse, but that's all I can think it would be at the moment. I get the same behavior whether or not I suppress byte 2 of the analog data. I guess I'm going to explore some analog smoothing options and see if that helps.

Ok, so for analog channel 0 (steering), I'm taking a running average of the current reading with the past 9 values. Doing this, I get very steady analog readings in the I/O test. I can center the wheel, and if I'm suppressing the 2nd byte, I can get a steady unchanging value. If I move the steering wheel, the value changes and it's still very responsive.

I booted up OR2SP with FFB enabled and am getting very good results!

The menu selection works as I expect, with a good range within the wheel before moving to the next item in either direction, and in-game FFB seems to behave just fine.

 

[Darksoft]

My analog values seem to match pretty well with what the Type 1 is reporting and even the slight jumps in values are present in the Type 1. I don't believe the jumps in my I/O are any worse, but that's all I can think it would be at the moment. I get the same behavior whether or not I suppress byte 2 of the analog data. I guess I'm going to explore some analog smoothing options and see if that helps.

Ok, so for analog channel 0 (steering), I'm taking a running average of the current reading with the past 9 values. Doing this, I get very steady analog readings in the I/O test. I can center the wheel, and if I'm suppressing the 2nd byte, I can get a steady unchanging value. If I move the steering wheel, the value changes and it's still very responsive.
I booted up OR2SP with FFB enabled and am getting very good results!

The menu selection works as I expect, with a good range within the wheel before moving to the next item in either direction, and in-game FFB seems to behave just fine.

so what was the problem?

 

[rtw]

May I ask which algorithm you are using for the the moving/running average ?

 

[winteriscoming]

so what was the problem?

I guess the FFB was trying to drive the wheel to the center, but maybe my reported analog value was either too jumpy or too sensitive so that the FFB was never satisfied that it was on-center. I guess that translated to the game believing the wheel was off center so it would scroll through the menu accordingly. When my reported values are smoothed out (much more so than the stock Type 1, mind you), I guess the FFB gets what it needs. It could be that the overly sensitive/jumpy values were too much for FFB initialization, and the established center wasn't correct.

May I ask which algorithm you are using for the the moving/running average ?

I didn't look up specific examples so I may not be doing it efficiently. Basically I start with an array of 10 values. Every time the main board polls for analog, for channel 0 (steering), I shift the values in the array to right, dropping off the oldest, and add the current value to the beginning. Then I take an average of all 10 values and report that as channel 0's value. I would guess a larger array would provide even smoother transitions, probably at the cost of responsiveness. At some point you would hit a threshold for where it would take too long to process the average and you wouldn't be able to respond to the main board in time, but I have no clue what that threshold would be. I am reporting values noticeably smoother than Type 1, so it could be that if I had a running average of fewer values I could more closely align with it, but not sure if that's necessary since I am getting good behavior with the current method.


On a related note, I had a similar issue with ID3 with FFB turned on. However I had to address it differently. It think a lot of this issue is due to the turn radius of the stock ID3 wheel (which I don't have) vs the OR2 wheel (which I do have). I've never played in an actual ID cab, but my understanding is that the wheel has a greater turn radius. Basically in ID3 the movement of the wheel is a much smaller movement on the potentiometer. Basically during initialization, the FFB moves the wheel to the right and then to the center. What was happening is that it would constantly rock back and forth, always moving it past the center. What I had to do was apply some modifier to the analog values to make it so that the wheel is reporting a much lower range of motion. Therefore any movement on the wheel reports less of a change to the analog value than it was before. This seems to have corrected the issue for ID3, and in fact gives me better performance than I was able to get with the Type 1 in my stock setup. I always noticed slightly odd behavior with the FFB on ID3 in my OR2 cab, so I now know to blame the wheel.

I would guess something similar could be done for 18 Wheeler. That game has a giant wheel with a huge turn radius. In that game it would require a lot of movement on the wheel for a very little change to the analog value. With some modifiers in place, I think the OR2 wheel could probably handle 18 Wheeler a little better than it could stock. I'll play around with that when I get a chance.

 

[Dion]

An issue I'm struggling with is using my I/O in combination with the MIDI FFB unit for steering on OR2SP.

With FFB enabled, the controls get very erratic to the point where not touching the steering wheel usually ends up in the menu selection screens jumping between one option and the next. It's like there's one exact spot that counts as the center and a tiny movement off of it slams the menu selection in one direction or the other.

With FFB off, there are no issues and the menu selection is smooth, as if there is a nice range that counts as the middle, and the wheel has to be turned a bit before the selection changes.

If I wire up the Type 1 again, the issue goes away when FFB is on.

My analog values seem to match pretty well with what the Type 1 is reporting and even the slight jumps in values are present in the Type 1. I don't believe the jumps in my I/O are any worse, but that's all I can think it would be at the moment. I get the same behavior whether or not I suppress byte 2 of the analog data. I guess I'm going to explore some analog smoothing options and see if that helps.

the midi ffb is the one like in sega rally?
sega jvs design has many filters. might be that's why they're not affected.

 

[winteriscoming]

the midi ffb is the one like in sega rally?

I don't know if Sega Rally uses the same FFB, but the MIDI one is the one used for Initial D 1-3, 18 Wheeler, OR2/OR2SP, F-Zero AX, and probably a couple more.

sega jvs design has many filters. might be that's why they're not affected.

That's a good point. Maybe that could help smooth out the analog readings from a hardware perspective.

 

[rtw]

@winteriscoming, that algorithm makes sense

Another might be to use an exponential decay filter where you don't have to store the previous value but it takes time to settle!

http://stackoverflow.com/questions/13997106/calculating-moving-average-for-long-period

 

[winteriscoming]

I have an update on the DUE!

The Serial.flush() command apparently has a bug for the DUE in the version of the IDE I have. It cuts off transmission on the last byte and corrupts it, so that's the culprit in my DUE frustrations. At the moment I implemented a 5ms delay after flushing and have the DUE, wired on the breadboard, communicating with the Chihiro successfully. I even tested out a potentiometer on the board reported as analog channel 0 and see the results in JVS test. I'll update to a newer IDE and see if the issue is addressed without a manual delay added in.

I can't plug my existing prototype board into the DUE, though, because DUE's inputs are not 5v tolerant and currently I have 5v analog. My digital inputs are all fine, though, since they're all internal pullup inputs that get grounded, so nothing has to change there when moving to the DUE. Basically the 5v that is currently going to analog and powering the RS485 module needs to be moved to 3.3v for the DUE. I might be able to take care of that with a jumper to allow for both boards to work... OR design it all around 3.3v and assume it will still work on the MEGA. In that case I will need to make sure 3.3v goes to the analog reference input so that the MEGA won't be comparing the analog values to 5v. 5v for the lamps is handled by the cabinet's power supply and is isolated from the Arduino, so that's transferable to the DUE.

Awesome, I just checked and the 5v pin I'm utilizing is right next to the 3.3v pin, and that trace passes right by the AREF pin. This is going to be a super simple change!

 

[winteriscoming]

I think how I want to accommodate both the MEGA and DUE is by way of an onboard switch jumper that you'll have to toggle for either 5v or 3.3v. I looked up using the AREF input and it apparently has some caveats where there's a potential for damage if not handled in the code correctly. The worst of which would be that if the call for reading the analog is not initialized with the external reference, it will short the external voltage to its default internal reference voltage. A resistor can be put in place to address the short, but at the cost of a divided reference voltage, making the readings less accurate.

I would rather use internal reference voltage on both systems and toggle between 5v and 3.3v being applied to the analog devices. That way the main risk is only to the DUE. A MEGA powered on in the 3.3v state would just end up giving bad results on the analog channels, whereas the DUE powered on in the 5v state would likely burn it out. So it will just be a matter of toggling the switch correctly before turning it on.

 

[winteriscoming]

I'm going to skip coin meters and Tilt, but I've got everything else mapped up and I'm finalizing the design.

Hopefully I will be able to submit my board order next week.

 

[Mitsurugi-w]

The ability to spoof the coin meters may not be a bad idea. Some games require them to even boot. My S-JIHP spoofs the meters for that reason.