Atomiswave vs NAOMI Conversions

[rtw]

What is really the difference in lag between an original Atomiswave game and the NAOMI conversion ?

The game tested is: Guilty Gear X 1.5

All testing done on the VGA input of an EIZO - EV2450 monitor.

The test hardware is a modified adapter which turns on a high-intensity LED when the joystick is moved down.

The test is done inside the I/O test in the SETUP menu with the LED just to the side of the test entry.

A video is recorded at 240 FPS while moving the joystick up and down. The result is loaded into VLC and the next frame feature (e) is used to count frames.

When the LED lights up frames are counted until a change can be seen in the on-screen menu.

For the Atomiswave a HAS and standard NeoGeo compatible stick was used.

For the NAOMI the fastest JVS IO (SEGA 837-14572) was used.

As an interface Mitsurugi-w's S-JIHP SEGA JVS I/O Helper PCB was used.

S-JIHP: Sega JVS I/O Helper PCB

Using a simple adapter the S-JIHP was interfaced to a standard NeoGeo compatible stick.

Calculations

1 frame at 60 FPS takes: 16.67. ms to draw.

[ 1/60 * 1000 = 16.66666 ]

1 frame at 240 FPS takes: 16.6666 / 4 = 4.167 ms to draw.

The ratio between these two frame counts is: 16.67/4.167 = 4.0

A factor of: 4.0

To convert 240 FPS frame rate to 60 FPS you divide by 4.

Original Atomiswave: 19 frames at 240 fps i.e. 4.65 frames (79.173 ms)

NAOMI conversion: 29 frames at 240 fps i.e. 7.25 frames (120.843ms)

Here are the raw videos, they will be available for one week.

https://we.tl/t-2G2LfwKdwo

 

[brizzo]

Cool to see real world timing figures measured! One of the important points in your post is the JVS i/o board used; that not all i/o boards respond to jvs packet request in the same amount of time.

Anecdotally your results here are why some AW conversion games do not run properly as they are waiting for i/o inputs in the main game loop (or it is a memory timing access problem, nobody has proven it one way or the other).

 

[MetalliC]

Anecdotally your results here are why some AW conversion games do not run properly as they are waiting for i/o inputs in the main game loop (or it is a memory timing access problem, nobody has proven it one way or the other).

not the case here, afair in AW ports comms with JVS MCU was done using async poll command, i.e. MCU does reply to host previous values from JVS IO and then do request JVS IO for new data.
obviously such async poll have little to none host<->MCU comms delay, but produce additional +1 frame input lag.

PS: tbh, I've expected +1 or +2 additional frames lag, and surprised by measured ~+3 value

 

[Hackcell]

interesting result