What's new

rtw

Champion
Joined
Sep 28, 2015
Messages
1,273
Reaction score
1,261
Location
Norway
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)

240fps_led.jpg



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

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

brizzo

Staff member
Champion
Joined
Jun 21, 2017
Messages
849
Reaction score
2,456
Location
Canada
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

Grand Master
Joined
Nov 19, 2015
Messages
1,193
Reaction score
1,077
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
 
Last edited:
Top