What's new
Here's another interesting observation about Lindbergh vs Chihiro and NAOMI.

Chihiro/NAOMI do not give up when requests for switches/coins/analog are ignored for a short period of time. I can swap profiles without any negative consequences and they'll pick right back up with communicating once the I/O is ready again.

On the Lindbergh, even the slightest break in replying results in a JVS communication breakdown from which you cannot recover without a reboot. This means realtime profile swapping is not advisable because controls will lock up and you won't be able to get back to the test menu or game selection menu on the multi to reinitialize JVS communication (unless there's a keyboard sequence I'm not aware of?). I have found that on the multi game it doesn't care about JVS communication halting on the game selection screen, even though JVS is initialized when entering that screen. Choices on that screen are made with the keyboard, and JVS is reinitialized once a selection has been made (i.e. go into test menu or start a game). Anyway, the game selection screen is the time to swap profiles on the Lindbergh. Ideally you'd have a display of some sort or Serial over USB communication set up so that you know which profile you're changing to.
 
Ok, I think I have a solution in place that's compatible with Lindbergh, Chihiro and NAOMI. Lindbergh was doing well with 1ms delays prior to responding to all initialization commands. Chihiro didn't like that so much. Reducing the delays to 500us seems to be the happy medium and I can boot on both Chihiro and Lindbergh, with both MEGA 2560 and DUE.
 
Ok, I think I have a solution in place that's compatible with Lindbergh, Chihiro and NAOMI. Lindbergh was doing well with 1ms delays prior to responding to all initialization commands. Chihiro didn't like that so much. Reducing the delays to 500us seems to be the happy medium and I can boot on both Chihiro and Lindbergh, with both MEGA 2560 and DUE.
Your the man!

Does it mean that you are good to start production?
 
Ok, I think I have a solution in place that's compatible with Lindbergh, Chihiro and NAOMI. Lindbergh was doing well with 1ms delays prior to responding to all initialization commands. Chihiro didn't like that so much. Reducing the delays to 500us seems to be the happy medium and I can boot on both Chihiro and Lindbergh, with both MEGA 2560 and DUE.
Your the man!
Does it mean that you are good to start production?
I still have a couple more things I'm working on in the code, and I'm considering a new board design.
 
Ok, I think I have a solution in place that's compatible with Lindbergh, Chihiro and NAOMI. Lindbergh was doing well with 1ms delays prior to responding to all initialization commands. Chihiro didn't like that so much. Reducing the delays to 500us seems to be the happy medium and I can boot on both Chihiro and Lindbergh, with both MEGA 2560 and DUE.
Your the man!Does it mean that you are good to start production?
I still have a couple more things I'm working on in the code, and I'm considering a new board design.
I'd definitely look at making your own PCB as a whole without any arduino. Just your complete PCB.
 
I'd definitely look at making your own PCB as a whole without any arduino. Just your complete PCB.
I don't think that's something I want to do. It would increase the cost and complexity. I can buy a complete Arduino MEGA 2560 for like $10 shipped. If I look at Digikey or Mouser, for small quantities for just the ATMEGA2560 it is $16-$17 plus shipping. Add in the rest of the parts and surface mount soldering, and it's no longer an easily accessible/cheap DIY option.

If I keep the MEGA JVS as a shield for plugging right into a stock Arduino, and stay with through-hole parts, the costs and complexity stay down. If you burn it out by wiring improperly you're only out a low cost Arduino that can be replaced.

If I were buying this from someone else, I'd prefer the 2nd option.

I think China made it an easier choice when they can manufacture and sell me something that has everything in it that I need for cheaper than I can get the parts to build the the very same thing. :P
 
which of the arduinos will i need to grab before you board release? like the most compatible etc
 
which of the arduinos will i need to grab before you board release? like the most compatible etc
If I can get HID controls working on it, the MEGA 2560 will be my recommendation, since they're cheaper. It will be a little more of a hassle flashing the firmware to turn on HID functionality, but it shouldn't be too bad. If you don't care about HID functionality, then definitely go with the MEGA 2560.
 
You could replace that RS485 module and only use the chip and the components from it. This wouldn't complicate your pcb design much and would make you less dependent of a specific module that could become absolete.
It's probably not very expensive, but you might be able to reduce the price a little.
Hobbyking sells some cheap arduino clone devices, but maybe you are already shopping there.
 
You could replace that RS485 module and only use the chip and the components from it. This wouldn't complicate your pcb design much and would make you less dependent of a specific module that could become absolete.
It's probably not very expensive, but you might be able to reduce the price a little.
Hobbyking sells some cheap arduino clone devices, but maybe you are already shopping there.
That's the same deal. I can get the full module cheaper than the parts on it. A search for MAX485 module yields a lot of results for this same module.

I have purchased my Arduinos on Amazon and get the MEGA 2560s for $10-$12 shipped.

Edit: Regarding the RS485 module: I was looking at it and other than the screw-in header and the header pins on either side, it's about as compact as it can be using single sided surface mount parts with traces on both sides of the board. In an effort to avoid surface mount parts in my board, I'd have to figure out placement of through hole parts and have a hard time imagining I'd fit into a smaller footprint. The added bonus of using the module is that I can pass traces on both sides of my board through the space under the module.

The only risk involved with being married to this module would be if the MAX485 chip goes into obsolescence. That's the same chip I'd have to use if I incorporated it into the board design, so I'd still be married to a part with the risk of obsolescence. Keeping it all off the board on a module means a future solution could be developed with the same pinout, if needed.

That's kind of the same argument I can make for the Arduinos. So far I'm compatible with the 2 Arduinos that use have the same footprint and pinout. I'm seeing at least one forthcoming Arduino board that has the same footprint, so future Arduinos should be able to be used, even if they require some re-coding.

There are actually very few components on my board, so it should be pretty future proof, as long as through hole components continue being made. Even then, a through hole module with surface mount parts could conceivably be made to replace each through hole component. :P
 
Last edited:
I still have a couple more things I'm working on in the code
I forgot to include this on my to-do list, but I've incorporated steering wheel analog scaling into profiles. The idea is that you can input your min and max value for your steering wheel and then scale the reported values according to the game you're booting. So now if I want to boot up 18 Wheeler, I can have my wheel report a larger range of movement.

If you had an ID3 wheel with a larger range of movement than OR2, then you could scale it down and make is so that the steering is more in line with ID3, if that's desirable, where a greater turn of the wheel would be needed while drifting in OR2.

In my OR2 cab, I can scale the outputs a get a bit better performance on ID3.

The last bit of software I want to complete is the HID functionality on the MEGA 2560, and I think I'll be ready to get some boards out to a few people for testing and feedback prior to a full release.
 
I am volunteer for testing but only if you're looking for a newbie.

I've got 1 NUC, a Jambo safari upright cab I'll restoring soon, a full gun system, 1 Naomi 2, 2 Triforce Type 1, 1 Lindbergh yellow multi and a midi board.
I've bought all those during the last months and want now to restore my cabs and make them kind of versatile.
Your Mega JVS is the perfect tool for that.
So, if you're looking only for techie, I'll wait the full release. And I won't be upset because I know for sure that there are many members that would be way more useful for full and trustful feedback. Otherwise, I'm totally in!

That being said, you're doing an amazing job!

Two thumbs up!
 
I am volunteer for testing but only if you're looking for a newbie.

I've got 1 NUC, a Jambo safari upright cab I'll restoring soon, a full gun system, 1 Naomi 2, 2 Triforce Type 1, 1 Lindbergh yellow multi and a midi board.
I've bought all those during the last months and want now to restore my cabs and make them kind of versatile.
Your Mega JVS is the perfect tool for that.
So, if you're looking only for techie, I'll wait the full release. And I won't be upset because I know for sure that there are many members that would be way more useful for full and trustful feedback. Otherwise, I'm totally in!

That being said, you're doing an amazing job!

Two thumbs up!
We can talk when I get to that point. Thanks!
 
I think I'm mostly down to figuring out HID controls on the MEGA 2560 before releasing this.

The main challenge is the firmware flashing. There's some firmware for the onboard USB controller (ATMega16U2) called HoodLoader and Hoodloader2 that enable a MEGA 2560 or UNO to show up as a HID device.

HoodLoader can be loaded via a DFU process that's pretty easy using a simple DFU utility called Flip, though disables programming over USB, necessitating flashing the stock firmware back before loading up any other sketches. The DFU upload process is easy though. You just momentarily bridge 2 pins on the MEGA2560 to get into DFU mode and use Flip to upload the appropriate firmware file (either HoodLoader or stock firmware as needed). So you upload your sketch, flash HoodLoader, and you're good to go. When you need to upload another sketch, flash the firmware back to stock first.

HoodLoader2 allows sketches to continue being loaded up over USB, but loses DFU programming functionality, so it's considerably more difficult to flash, requiring some wiring adapters in every one of the 3 flashing options available for it.

What I haven't experimented with yet is if the original HoodLoader is sufficient, or if the more complex to load HoodLoader2 is going to enable features that are more preferable.
 
I think I'm mostly down to figuring out HID controls on the MEGA 2560 before releasing this.
I'm ditching the HoodLoader stuff in favor of something much easier. I read over both HoodLoader and HoodLoader2 documentation and don't think it actually does what I want.

But I found something more appropriate and pretty simple. It doesn't need any fancy libraries and it uses the DFU programmer to upload the firmware and makes the MEGA2560 recognized as a HID gamepad with 8 analog axes and 40 buttons. Guess what? That fits in with what we need for a Type 1 I/O. I'm not going to screw around with trying to relabel the axes. It doesn't matter what it reports itself as. All that matters is that it's usable in a PC program, like MAME.

Mega 2560 HID Gamepad.png

It will be up to someone else to make it more advanced, if that's needed, like making it report as 2 gamepads, etc. It will do what I want as-is and I'm kind of tired of messing with figuring out HID stuff on the MEGA 2560. :P (KISS: KEEP IT SIMPLE, STIPID!)
 
making it report as 2 gamepads
Not a problem for MAME and most emulators but this is vital for a lot of PC games. A lot games will only allow you to map one player per device.
I may dig into this further, but not sure what's even possible on the MEGA 2560 in regards to customizing the reported HID devices. I doubt I'll get into making up my own firmware, so MEGA 2560 might not be the way to go if this is a requirement and I can't eventually find a working example. I *THINK* the DUE has options for that in the HID libraries available for it, but it isn't done that way in my current implementation on the DUE.
 
Now I've got a Triforce and it throws a wrench into my established timing. It doesn't like the 500 microsecond delays for the initialization ACKs... it seems to like 300 better. I'll eventually go back and test the others. I know there's a common value that will work with all of them because a stock Sega Type 1 can work with all of these motherboards and it doesn't have any idea what it's plugged up to to be doing anything that would change timing per motherboard.
 
Now I've got a Triforce and it throws a wrench into my established timing. It doesn't like the 500 microsecond delays for the initialization ACKs... it seems to like 300 better. I'll eventually go back and test the others. I know there's a common value that will work with all of them because a stock Sega Type 1 can work with all of these motherboards and it doesn't have any idea what it's plugged up to to be doing anything that would change timing per motherboard.
Hmm just thinking loud, maybe there is some kind of feedback from the host telling you that it's ready. It looks kind of weird that Sega would be doing trial and error with the timings IMHO.

In any case if 300ms works, so be it :)

If I can help PLMK.
 
Wouldn't it be possible to measure it on the real thing with a memory scope or logic analyser?
 
Back
Top