I've started to convert my Daytona USA Twins (actually got 3 of em right now, 4th on the way) to PCs without modifying the original wiring.

I got bored of my Daytona Boardsets dying over and over again, so I swaped them with PCs.

I used an Arduino (MEGA 2560) to interface the PC to the cabinet. - None of the original wiring was cut/modified, so I can put a real Boardset back in there at any time.

Big ThankYou goes to BigPanik for the initial idea and "proof of concept" of using an Arduino in the first place

1. - I removed the CPU Board cage by unpluging all the connectors and removing two screws that hold the cage in place. Then I "moved" the cables going to the back of the base to the center.

2. - As the PC will generate the sounds, I disconnected the power cables going to the sound board (1 connector) and audio cables (2 pairs of connectors) from the amp board and pluged in a standard pc audio cable in there.

3. - I disconnected all cables on the sega power supply (1x AC, 1x Main Power, 1x Aux Power) and pluged in a handmade power cord for the PC instead.

4. - I built an adapter board which provides several connectors for the original cabling:

10p (1x10) for AUX power. This line usually powers the I/O board inside the cage, but I will use it to provide power to the drive board instead.

5p (1x5) for video.

50p (2x25) for buttons, lamps, shifter.

26p (2x13) for the pedals and wheel pot.

11p (1x11) for sending commands to the drive board.

Pin-Header for the Arduino Mega2560

VGA for video

5V and GND for power

5. - I put a standard PC in the place the original board cage was located at.

The VGA is connected to the adapter board.

Audio runs from a 3.5mm connector to the RCA jacks on the sega amp board.

One USB line feeds the Arduino Mega2560

5V and GND line to the adapter board.

6. - I unscrewed one of the TOSLINK jacks on the back of the cabinet and used that hole to get a standard RJ45 network cable in there.

7. - The firmware on the Arduino Mega2560 does two things: * read pots, read buttons, read and decode the shifter (3 wires, 5 states) * write commands to the drive board, drive the "lamp driver" IC to switch on and off the lamps etc.

8. - I currently use vJoy to create a virtual Joystick device, which gets updated with the data supplied by the Arduino. A small tool (for the moment) checks which game is currently running, reads the commands and lamp data from memory and feeds them to the Arduino. It also filters out "bad commands" and translates various command types (for example OutRun deluxe movements).

9. - software wise I run XP64 on Core2Duo (2,1GHz), 1GB RAM, ATI HD4650. I use Soft-15kHz to feed the monitors with 25kHz video signal at native resolution of 496x384.

Intersting note: the m2emulator is running too fast! If I run daytona on real hardware and the emulation side by side, the emulator is slightly faster. I suspect that is a 58Hz (original) vs. 60Hz (emulation) thing. Even the music plays slightly faster.

There is also a new version of vJoy in development that does support force feeback on the windows side. So in theory I could translate the windows force feedback commands to the sega drive board and play pc games with force feeback too.

Another interesting fact...4 units are "Daytona USA classic", the 3rd generation released. They are made of steel/plastic and have red seats.2 units are "Daytona USA", the 1st generation released. They are made of wood and have black seats.As far as I know there is another version - I'll call it 2nd generation - which is made of steel/plastic already but still features the "Daytona USA" topper and black seats.

I noticed the wood cabinet and the steel cabinets have a different setup of boards and wiring.At first my adapter seemed to fit both setups perfectly. But I soon discovered some differences.

The wood cabinet for some reason has 4 "split" +5V rails, where the steel cabinet has only 2 rails.This becomes even more strange as the Power Supply only has 2 rails for +5V.V2 = +5V Aux (Sound Board, Drive Board, I/O Board), V4 = +5V CPU (CPU Board, Video Board)

Sadly, the I/O Board and the Drive Board are on different rails - I "hacked" the wiring by connecting both +5V Aux rails.

The other strange difference is the power for the CPU Board FAN.On the wood cabinets the FANs are actually 12V wired (RED @ Pin 5). On the (later) steel cabinets, there are 5V wired (YELLOW @ Pin 5).To "fix" that, I had to remove Pin 5 from my adapter board - otherwise I would have fed +5V on the +12V rail.In conclusion it is NOT possible to swap board cages from one cabinet to another without paying attention to the FAN voltage... You might fry your 5V FANs.

Most of the screen (Nanao MS9-29U) worked out of the box - although they were quite dark.

Problem #1 - Overheating (probably because of fans running slow or dying)Problem #2 - Liquids; some people keep their drinks ON the base...Problem #3 - Shock; some people seem to slam the cabinets all over the place...

Most likely a combination of #1 and #3

---

As for the arduino sketch:Well I'm still tinkering with it on a regular basis. But I should have something available soon.

Problem #1 - Overheating (probably because of fans running slow or dying)Problem #2 - Liquids; some people keep their drinks ON the base...Problem #3 - Shock; some people seem to slam the cabinets all over the place...

Most likely a combination of #1 and #3

---

As for the arduino sketch:Well I'm still tinkering with it on a regular basis. But I should have something available soon.

Agreed on all those points of failure, then the other issue is repairs. Often it's the 3d chip that fails and there are no replacements available

Can't wait for the Arduino sketch, my L2M2 boards have never worked right and i've killed no less than 5 Logitech Driving Force PCBs whilst tinkering with settings!

Problem #1 - Overheating (probably because of fans running slow or dying)Problem #2 - Liquids; some people keep their drinks ON the base...Problem #3 - Shock; some people seem to slam the cabinets all over the place...

Most likely a combination of #1 and #3

Good to know. I'm glad one of the first things I did with my VO cab was replace the fans on the Model 2 boards. Sounds like something I should plan on doing if I ever get another model 2 game.

As for the arduino sketch:Well I'm still tinkering with it on a regular basis. But I should have something available soon.

I'm assuming it's designed specifically to work with Model 2 Emulator, or is it more generic? could it work with a PC game to allow FFB with a Daytona steering setup? It'd be great to have an Arduino based FFB setup that could interface any FFB pc game to arcade controls.

I'm assuming it's designed specifically to work with Model 2 Emulator, or is it more generic?

No. There are actually 4 components involved atm.

1. the arduino sketch itself - it just reads its inputs every 16ms and writes a bitstream to the PC. also, any data send TO the arduino (from the PC) will be used to drive the lamps or the drive board.

3. the "controller" app - this reads the arduino bitstream and feeds the virtual joystick. this also "waits" for feedback and lamp data (actually from anywhere - which is great for debugging)

4. the "feedback" app - this is where the "magic" happens; a rather simple tool that check which processes are running (currently MAME and M2EM are supported); once a known process is found, the active game is checked, and (if supported by this tool), the lamp and/or feedback data gets read out and (if necessary) translated/filtered (i.E. OutRun-to-Daytona).

---

most of the development is currently happening on the "feedback" app, as I have various driving boards (dayonta, indy500dx) etc, which all use a slightly different setup. and behave a little different.

for example:daytona uses an AC motor [running full speed] and a clutch to transfer the powerindy500 uses an AC motor [running at various speeds] DIRECTLY attached to the wheel.

both boards use their own firmware, and both behave differently to various of the feedback commands.

could it work with a PC game to allow FFB with a Daytona steering setup? It'd be great to have an Arduino based FFB setup that could interface any FFB pc game to arcade controls.

there is a new version of vjoy in development that actually does support force feedback on windows side, so it should be possible to translate the win-feedback to a daytona (or anything else).

---

in theory you can drive pretty much anything with that arduino tool. I've added a "jumper" in the sketch, so you can use the "shifter" input as 3 regular buttons or as 5-state sega shifter. (I also use that setup to drive my WingWar which uses the shifter inputs as fire buttons)

Woah... That is some kind of Franken-Twin... Left half is a japanese v3, right half is a european v2, topper is from an old wooden daytona... cables in the back are from a sega rally... none the less... i got my 8 daytona setup complete.expect a software upload later this day. (and images) ^^

Man I bet that song plays in your head on a constant loop at this point. That's 12 pounds of awesome in a 8 pound bag. Those spectators monitors are really big, but thin and 4:3... what the heck are you using?

If you ever figure this out do you think you could take a look at the Model 2 version of CyberTroopers Virtual On?

There is video evidence of a Live Monitor feature shown at old arcade tournaments in Japan, however myself and a few others have tried to get a Live monitor setup working on the actual arcade boards but the feature is no where to be found (tested both both the USA and the Japan rom boards).

Live Monitor Mode is readily available on Model 3 versions of Virtual On Oratorio Tangram... but we haven't yet figured it out for the Model 2 prequel.

Back in the day the arcade I visited that had 8 cars set up had a monitor showing the face of the lead driver. Each cab had a camera fitted and i assume the switch box somehow worked from the race leader lights. That was a pretty cool set up, but it never had the 2 screens like you have demonstrated.

I checked some wiring diagrams and it seems that there are a few common pinouts: - Model 1/2 (at least Daytona and Virtua Racing seem identical) - Model 2A/3 (although small differences on the button mapping)

I need to check the details on the 2B and 2C, most likely they are common to either 2A or 3That means I should be able to design an "interface" board that can be put into any Sega Model-X Racer.

Also someone noted that the "newer" Sega Racers might work too, although with some slight modifications (MIDI and/or RS-442 serial instead of 8bit parallel)

Firmware

I've tinkered around with the arduino part, and most likely will replace them with teensy2++ sooner or later.

For the time being I developed a new firmware for the MEGAs that works as plain usb gamepad (like unojoy does) - it features only the controls provided by the daytona (4* axis with full 10bit resolution, 24* buttons) AND is able to receive lamps and drive commands via usb itself.

Mapping for Button 9-16 will most likely change in the future, as there is no actual need to have both SHIFT- and GEAR- Inputs - And we are currently missing the "special inputs" (EX.START, EMERGENCY, COURSE0, COURSE1).

I plan to add some "dip switch" style options (initial values on hardware, overridable via software).- Currently implemented is a "Shifter Decoder" Toggle - If turned ON, the SHIFT inputs (Buttons 9-11) are always off, and the shifter gets decoded to the individual gears (Button 12-16)[WingWar uses the shifter lines for the fire buttons]

- "alternate axis layout" switch: For cabinets like WingWar it would be better to use X (A0), Y (A1), Z (A2) and RZ (fix value), as many "non arcade" flight simulators have trouble mapping axis correctly.

- "sequencial shifter" switch: For cabinets like Indy 500, to shift up and down in Daytona

- "sequencial views" switch: For cabinets like Indy 500 (or even Sega Rally) with less than 4 view buttons.

SoftwareBecause of "Daytona USB" the software side is getting smaller (and simpler) - No more need for a virtual joystick driver - Just plug in the USB cord and you're done.

The "Driver"-App is starting to become obsolete:- the old version (serial and vJoy) has been updated to fix some weird "invalid handle" errors- the new version (USB) will be merged into the "Feedback"-App soon.

The "Feedback"-App will be extended:- currently still needs a seperate driver app.- I've added support for SuperModel (svn 274 x86 only*) featuring both Dayonta2 (BotE / PE) as well as SCUD (Australia / Export) and SCUD Plus.- user-configurable command translator -> Currently the App will translate anything to a reduced** Dayonta / Indy500 command set.- games to be added: Hard Drivin (just found the drive board controls *yeah*)- ability to switch the "dip switch" settings on the "Daytona USB" board depending on running game.

* as the app is (for now) written in 32bit VB6, I cannot read the process modules of a 64bit application, which I need to calculate the offsets.**(I kill the 0x90-0x9F commands, as they don't work on an Indy 500 drive board; used by Daytona USA for the moving seats)

Other stuffAs far as I know there are only two common motor setups used for the Sega Racers:- "clutched" AC-Motor (Virtua Racing, Daytona USA, Sega Rally)- "direct" AC-Motor (Indy 500 and later)

It seems the "clutched" setup uses springs to center the wheel by itself while the "direct" setup does center by software.

The command (group) 0x10 (to 0x1F) is used to "let the spring do it's job" - which gets done in software on a setup without spring.Now the games designed for the "spring" setup only know one "force" while the games designed for the "no spring" setup have up to 16 different - which I cannot reproduce on a "spring" setup (I'll just let the spring do it's job, no matter what).

I checked some wiring diagrams and it seems that there are a few common pinouts: - Model 1/2 (at least Daytona and Virtua Racing seem identical) - Model 2A/3 (although small differences on the button mapping)

I need to check the details on the 2B and 2C, most likely they are common to either 2A or 3That means I should be able to design an "interface" board that can be put into any Sega Model-X Racer.

Also someone noted that the "newer" Sega Racers might work too, although with some slight modifications (MIDI and/or RS-442 serial instead of 8bit parallel)

Firmware

I've tinkered around with the arduino part, and most likely will replace them with teensy2++ sooner or later.

For the time being I developed a new firmware for the MEGAs that works as plain usb gamepad (like unojoy does) - it features only the controls provided by the daytona (4* axis with full 10bit resolution, 24* buttons) AND is able to receive lamps and drive commands via usb itself.

Mapping for Button 9-16 will most likely change in the future, as there is no actual need to have both SHIFT- and GEAR- Inputs - And we are currently missing the "special inputs" (EX.START, EMERGENCY, COURSE0, COURSE1).

I plan to add some "dip switch" style options (initial values on hardware, overridable via software).- Currently implemented is a "Shifter Decoder" Toggle - If turned ON, the SHIFT inputs (Buttons 9-11) are always off, and the shifter gets decoded to the individual gears (Button 12-16)[WingWar uses the shifter lines for the fire buttons]

- "alternate axis layout" switch: For cabinets like WingWar it would be better to use X (A0), Y (A1), Z (A2) and RZ (fix value), as many "non arcade" flight simulators have trouble mapping axis correctly.

- "sequencial shifter" switch: For cabinets like Indy 500, to shift up and down in Daytona

- "sequencial views" switch: For cabinets like Indy 500 (or even Sega Rally) with less than 4 view buttons.

SoftwareBecause of "Daytona USB" the software side is getting smaller (and simpler) - No more need for a virtual joystick driver - Just plug in the USB cord and you're done.

The "Driver"-App is starting to become obsolete:- the old version (serial and vJoy) has been updated to fix some weird "invalid handle" errors- the new version (USB) will be merged into the "Feedback"-App soon.

The "Feedback"-App will be extended:- currently still needs a seperate driver app.- I've added support for SuperModel (svn 274 x86 only*) featuring both Dayonta2 (BotE / PE) as well as SCUD (Australia / Export) and SCUD Plus.- user-configurable command translator -> Currently the App will translate anything to a reduced** Dayonta / Indy500 command set.- games to be added: Hard Drivin (just found the drive board controls *yeah*)- ability to switch the "dip switch" settings on the "Daytona USB" board depending on running game.

* as the app is (for now) written in 32bit VB6, I cannot read the process modules of a 64bit application, which I need to calculate the offsets.**(I kill the 0x90-0x9F commands, as they don't work on an Indy 500 drive board; used by Daytona USA for the moving seats)

Other stuffAs far as I know there are only two common motor setups used for the Sega Racers:- "clutched" AC-Motor (Virtua Racing, Daytona USA, Sega Rally)- "direct" AC-Motor (Indy 500 and later)

It seems the "clutched" setup uses springs to center the wheel by itself while the "direct" setup does center by software.

The command (group) 0x10 (to 0x1F) is used to "let the spring do it's job" - which gets done in software on a setup without spring.Now the games designed for the "spring" setup only know one "force" while the games designed for the "no spring" setup have up to 16 different - which I cannot reproduce on a "spring" setup (I'll just let the spring do it's job, no matter what).

Are there any other motor setups I need to take care of?

Hey SailorSat,

Thanks for the update and love what you are doing.

Are you able to explain the pros and cons with this USB Arduino adapter vs using a L2M2 interface, please? I see the benefit of being able to use multiple emulators, even PC games with the L2M2 interface, I'm not sure if this USB ardunio can do that?

Are you able to explain the pros and cons with this USB Arduino adapter vs using a L2M2 interface, please? I see the benefit of being able to use multiple emulators, even PC games with the L2M2 interface, I'm not sure if this USB ardunio can do that?

I'll try

Pros

simple plug-in adapter for the cabinets - no need to change any wires (+ you can put your original boards back at any time)

use of the original force feedback controller in the cabinet - this is a close as you can get to the "real feeling"

can handle the lamps .) - l2m2 does not

works with any sega wheel setup

Cons

does NOT support generic force feedback applications (like the L2M2 does)

feedback (either force or lamps) will only work with a list of specific games/emulatores

I think the L2M2 is a nice adapter if you plan on playing basically anything (FlatOut2 anyone? ^^)I actually built 11 of em and tinkered around with the "best" settings for a long time...I even added some capacitors to the CLUTCH-Lines to get a "smoother" feedback.

However I still believe a L2M2 modified Daytona feels "different" from a "real" Daytona.Some effects like a plain "clutch" don't seem to work with a L2M2.

Also if I remember correctly, the L2M2 only works with the original Daytona style setup (free running AC Motor + Clutch).

Are you able to explain the pros and cons with this USB Arduino adapter vs using a L2M2 interface, please? I see the benefit of being able to use multiple emulators, even PC games with the L2M2 interface, I'm not sure if this USB ardunio can do that?

I'll try

Pros

simple plug-in adapter for the cabinets - no need to change any wires (+ you can put your original boards back at any time)

use of the original force feedback controller in the cabinet - this is a close as you can get to the "real feeling"

can handle the lamps .) - l2m2 does not

works with any sega wheel setup

Cons

does NOT support generic force feedback applications (like the L2M2 does)

feedback (either force or lamps) will only work with a list of specific games/emulatores

I think the L2M2 is a nice adapter if you plan on playing basically anything (FlatOut2 anyone? ^^)I actually built 11 of em and tinkered around with the "best" settings for a long time...I even added some capacitors to the CLUTCH-Lines to get a "smoother" feedback.

However I still believe a L2M2 modified Daytona feels "different" from a "real" Daytona.Some effects like a plain "clutch" don't seem to work with a L2M2.

Also if I remember correctly, the L2M2 only works with the original Daytona style setup (free running AC Motor + Clutch).

Well... That outrun is not just shaking - It is using the "move cabinet" information.If you turn the wheel to the right and step on gas, the cabinet would move to the left -> the wheel starts "pushing" to the left.

Hi SailorSat,Great work you have been doing, how far away do you think you are away from being able to supply a turn key/plug in kit? Also do you know a ballpark figure that these kits will cost? I have 4 machines I've been wanting to convert but don't have the tech skills.

Interesting note: the m2emulator is running too fast! If I run daytona on real hardware and the emulation side by side, the emulator is slightly faster. I suspect that is a 58Hz (original) vs. 60Hz (emulation) thing. Even the music plays slightly faster.

Interesting note: the m2emulator is running too fast! If I run daytona on real hardware and the emulation side by side, the emulator is slightly faster. I suspect that is a 58Hz (original) vs. 60Hz (emulation) thing. Even the music plays slightly faster.

Back to topic - Model3 proof-of-concept done. (I guess BigPanik did it years ago )

I visited a friend who happens to own a scud race twin - As expected, the same setup works with Model3 out of the box.

we have a fair share of "wtf" moments though:- we used a SCUD RACE drive board, and for some reason, SCUD RACE in SuperModel does NOT activate FFB in ADVANCED and EXPERT course.[scud sends C6 (mode 6) to the drive board, which the drive board does seem to ignore?? - "translating" C6 to C7 made the feedback work]

- although it does work pretty well, there is flaw. each model3 drive board has a special ROM, and as it turned out, the commands 0x0* (I'll call em "EFFECTS") differ between games (others are fine).scud and dayonta2 use "EFFECTS" when "bumping" into other cars.At first glance they just "feel" different - however in some cases, scud "effects" stop all feedback for a brief moment - this makes daytona2 nearly unplayable as the feedback keep turning on and off when touching anything or drifting.In the end we just filtered out 0x0* - which removed any "bumps" from scud and daytona2, but still makes a very nice experience.

Some day I need to try out every single effect on both drive board setups. maybe we can just translate some effects up and down.

In the end:- model3 works (except effects for now) fine with scud and daytona2 (didn't test the other games yet [need to look up offsets], lemans24 and sega rally2 need to be translated for sure)- the model3 drive boards handle "uncentering" in a different way than model2 drive boards do. [m2 uncentering keeps turning the wheel away from the center until the next command; m3 uncentering turns off after about 2 seconds]- the model3 drive boards have a "vibration" command (0x3*) which model2 drive boards do not have.

Could you use something like Calamity's CRT_EMUDRIVER to set the vertical refresh rate to 58Hz to fix the speed issue?

You'll get sound problems then

Hmmm.

I did a bit of investigating on the vertical refresh rate of model 2 games myself. I plugged in my Extron RGB interface to the video signal of one of my Daytona cabinets and got the following result :

I then tried loading the Daytona rom in Groovymame and that detected the vertical refresh rate at 57.524160Hz (Sega Rally Championship displayed the exact same result too). If the Model 2 Emulator is displaying model 2 games at 60Hz, that is over 4% faster than the original arcade hardware, quite a significant difference in my opinion.

If setting the default resolution and vertical refresh rate of the computer with CRT_EMUDRIVER to 496x384 @ 57.524160Hz causes the game to operate at the correct speed but the sound to be messed up, what are the options to fix this? Would it require the Model 2 Emulator developer to add support for the correct vertical refresh rate so that the game runs at it's original speed?

I then tried loading the Daytona rom in Groovymame and that detected the vertical refresh rate at 57.524160Hz (Sega Rally Championship displayed the exact same result too). If the Model 2 Emulator is displaying model 2 games at 60Hz, that is over 4% faster than the original arcade hardware, quite a significant difference in my opinion.

If setting the default resolution and vertical refresh rate of the computer with CRT_EMUDRIVER to 496x384 @ 57.524160Hz causes the game to operate at the correct speed but the sound to be messed up, what are the options to fix this? Would it require the Model 2 Emulator developer to add support for the correct vertical refresh rate so that the game runs at it's original speed?

Hm... A "hack" to change the playback speed of the audio from 48000hz to 46000hz (48000 / 60 * 57,5) may fix the sounds buffer underrun. However, thats just a hack, not a correct fix

As long as the m2em source code is not available (to the public), we most likely will not see a fix for that issue anytime soon.There are other issues too - at least two in the network code - that need to be fixed

It's quite frustrating because there are things I would like to get in there and fix as well, particularly on the output side of things. I'm even skittish about hacks now. I spent months on troubleshooter 2 finding all the needed memory locations only to get another release of the emulator soon after, which makes the hack incompatible.

I have read through this forum post twice and I just want to start by saying WOW! your talent and skill set in this is amazing SailorSat!

I recently acquired a Daytona USA driver that I want to put a pair of 32" LCDs into and convert it over to a Core i7 CPU so I can play other driving games as well, I have been going over the arduino code and have more than a few questions:

can this be split into two parts, input and output and handled by two atmega328's I was thinking about build a couple boarduino's and having them use v-usb to make calls back to the hardware.

Do I need to have my MEGA turned into an HID device? that isnt clear in the docs anywhere, from translating BigPaniks post on the other forum it would appear that it needs to be but I dont see the code for it in the sketch.

The cabinet's mate that I received was dropped off the back of a truck so I will need to rebuild the whole thing from the base up, I have already started to cleanup of the complete cab and I am wondering if I need to go about reinstalling all the wiring harness can is there a more direct way of putting this all back behind the screen?

The rest is more software related like what is usually heard from the speakers on the control panel and is it possible to isolate the sound from the program to those speakers? can I run two monitors with FFB on both wheels from one PC? can I run two sets of speakers so that each driver has their own experience on one PC? What would be a good replacement speaker setup for this kind of a cabinet with the sub in the seat for the most kick ;-)

SO many questions I know, but to start Im working on setting up the input side from my Arduino, once I can make that work I want to get the lights working, Already have the screen installed and the PC running Model2 as I cannot make the graphics work on MAME (which is better btw, mame or Model2?)

can this be split into two parts, input and output and handled by two atmega328's

that should be no problem. the boarduino should have enough I/O pins for the outputs (16 outputs to be exact)

Quote

Do I need to have my MEGA turned into an HID device?

nope, the default serial mode works too, although you will have to use a virtual gamepad driver (was using vJoy for a long time)It just make the whole thing kinda "plug and play"

Quote

is there a more direct way of putting this all back behind the screen?

mhm... you can basically put the atmegas right behind the dash board and hook up the pots, buttons and stuff directly.but if you wan't to use segas ffb board you should go with the original wiring.

Quote

what is usually heard from the speakers on the control panel

the original cabinet is basically stereo:- the dashboard speakers are tweeters- the speakers next to the monitor are midrange- the subwoofer... you guess it

Quote

can I run two monitors with FFB on both wheels from one PC?

Quote

can I run two sets of speakers so that each driver has their own experience on one PC?

you can absolutely do that. I did it with outrunners once.

however note: running a dual screen setup strongly depends on the software used.the m2emulator cannot be run "fullscreen" on anything but the first screen (sure, there are tools like dxwnd to "fix" that issue).also the m2emulator will run on the "default" audio device, so you'll have to switch the default device before starting the second emulator.

with outrunner that was pretty straight forward, as outrunners is basically dual mono - mame outputs player 1s stuff on the left channel, and player 2s on the right.

I'd rather use two pcs. (for most likely any racing game out there )

Quote

which is better btw, mame or Model2?

for daytona I'd stick with m2emu for the time being.

the m2emu has some flaws (like running too fast - 60hz instead of 58hz) but most people won't notice.the mame driver might mature over time, but currently is kinda unplayable. graphic glitches and a serious speed problem (game is running exactly half the speed it should run at - most likely an irq issue)

the m2emu has some flaws (like running too fast - 60hz instead of 58hz) but most people won't notice.the mame driver might mature over time, but currently is kinda unplayable. graphic glitches and a serious speed problem (game is running exactly half the speed it should run at - most likely an irq issue)

Hey SailorSat. Do you think that we'll ever see the Mame devs do any more development work on the Model 2 emulation? I'd love to be able to play the Model 2 racing games at their original 57.5Hz refresh rate with GroovyMame and I just can't see ElSemi doing any more work on his Model 2 emulator.

the m2emu has some flaws (like running too fast - 60hz instead of 58hz) but most people won't notice.the mame driver might mature over time, but currently is kinda unplayable. graphic glitches and a serious speed problem (game is running exactly half the speed it should run at - most likely an irq issue)

Hey SailorSat. Do you think that we'll ever see the Mame devs do any more development work on the Model 2 emulation? I'd love to be able to play the Model 2 racing games at their original 57.5Hz refresh rate with GroovyMame and I just can't see ElSemi doing any more work on his Model 2 emulator.

Less than a week later since my post (above) and it appears that the Mame devs have done a bit of work on the Model2 driver with the latest release of Mame 0.172! Even though it's only related to an audio bug for Daytona, hopefully this is a sign of further work to come!?!?

One thing I just noticed, the ULN2003 is not in the pinout ^^A8 to A15 would be the ULN2003 lines - A8 and A9 are the CoinMeters, A10 START lamp, A11-A14 would be VR1-4 and A15 LEADER lamp

--- other than that ---1. upload DaytonaArduino.ini to the MEGA2. put the MEGA in DFU mode (there are various guides on the net)3. run TurnIntoAJoystick.bat from the MEGA folder4. un- and replug your MEGA and it should come up as DaytonaUSB "GamePad"

You can't use the Arduino IDE for the "mega" subdirectory, as that is a atme studio project.

The part for the Arduino IDE is one directory up.

Also in Arduino IDE select Board "Arduino Mega or Mega 2560" - It won't work with "Arduino Mini"

--

1. upload DaytonaArduino.ino to the MEGA2. put the MEGA in DFU mode (there are various guides on the net)3. run TurnIntoAJoystick.bat from the MEGA folder4. un- and replug your MEGA and it should come up as DaytonaUSB "GamePad"

I already told you, you cannot compile the "mega" subdirectory with Arduino IDE (and you don't have to compile it anyway)

You only need two files for the Arduino IDE:- DaytonaArduino.ino- DaytonaArduino.h

Hey SailorSat, I have just completed BigPaniks M2Pac using a Daytona Drive board, he is a great guy and very helpful.

I came across your DaytonaUSB and thought I would have a try. I'm only focused on the Steering/Brake/Accelerate and FFB at this stage, is your wiring any different?

What I have done is turned the Arduino back into an Arduino.bat, uploaded your DaytonaArduino.ino, turned the Arduino back into a joystick using your files and it shows up and DaytonaUSB as a HID USB device. I can configure it in Windows as well as Model2 Emu but I can't seem to get any FFB.Is there a certain port it needs to be on? I think I tried forcing the port to COM5 but that didn't change anything. I also made sure to have just the main USB connected as the other one is not needed for yours correct?