MiSTer FPGA Forum

I've been trying to use the lag tester core from https://github.com/misteraddons/inputlatency and I'm getting some unexpected results.

At first I thought I'd try testing a DaemonBite Arcade Encoder (lite? clone?) built as per https://github.com/MickGyver/DaemonBite-Arcade-Encoder as a baseline before trying anything interesting. But instead of the expected 0-2ms of lag, I'm measuring a variable 0-18ms of lag. Which still isn't terrible I guess, but it's high enough that I assume I'm doing something wrong...?
It keeps looping around like that, with slight variations, I've seen 0.36 and 17.20 with 1ms USB polling.

Have tried to follow the instructions at https://docs.google.com/spreadsheets/d/ ... =369482991 but found that if I just close the OSD I don't get any results. I have to load a NES ROM, and then it will work. Do the instructions assume a boot1.rom? Are there any particular ROMs that should be used?

One odd part of my setup is I don't have an IO board, so for the step connecting the lag tester Arduino pin 2 to MiSTer User IO TX line, I've used a breadboard mimicking parts of the IO board. Most notably the breadboard has a 100 ohm resistor between what would be P7 pin 2 and the User IO TX line, and also a 10k pull-up. (With a few level converters this setup works well enough for NES SNAC but I don't know if it's good enough for lag testing.)

So far, I've tried various combinations of

• u-boot.txt containing "v=loglevel=4 usbhid.jspoll=1 xpad.cpoll=1" for 1ms polling
• u-boot.txt containing "v=loglevel=4 usbhid.jspoll=0 xpad.cpoll=0" to try turning off 1ms polling
• u-boot.txt containing "v=loglevel=4 usbhid.jspoll=8 xpad.cpoll=8" to try 8ms polling (this changed the variable lag to 0-24ms, still looping around)
• unmapping mouse emu/sniper as per viewtopic.php?t=3775
• renaming the config directory (where all the mappings are stored) to be absolutely sure the mouse emu/sniper buttons are not mapped
• renaming my MiSTer.ini in case there's something in there that's causing trouble (like vsync_adjust?)
• DaemonBite debouncing enabled
• DaemonBite debouncing disabled

but no matter what I try, it didn't seem to make a noticeable difference in the measurements, still looping from 0 to 18ms or so; 8ms USB polling increased the upper bound a bit but otherwise no major change.

Using

• Main MiSTer_20211214,
• Linux/zimage/uboot from SD-Installer release_20211112,
• lag tester core + arduino code 2a7df6cbd6b9ab80d5c0358d0168edeb3b8e794e,
• DaemonBite cec29cdf09a91f889f50e65c15c69d66fb2edc06.

It looks like the lag tester core in its "about" page claims to be based off NES v191112; something I haven't tried is an older Main and older Linux/zimage/uboot to match. Might give this a try. Anything else I should be trying?

Ok, I figured out at least part of it and have a solution that works well enough for me.

Most NES ROMs poll the controller a small number of times per frame, at about 60.1Hz. The arduino code is recording the time, grounding (pressing) the button, sleeping 16ms, setting the button to floating (releasing), sleeping 16ms, sleeping a random amount of time between 0 and 1ms, and repeating; this is pressing the button at roughly 30-ish Hz with some variation due to the randomness and the operations taking a non-0 amount of time and so on. Assuming the ROM polls at about the same time each frame, the arduino is pushing the button about once every two frames, it almost lines up but not quite... it seems reasonable that one frame the NES ROM polls the controller shortly after the arduino grounds the button, and we get a small delay... then by the next grounding later they've drifted a bit further apart, and so on until it wraps around and they're close again. Or something like that.

I tried finding a NES ROM that repeatedly polled the controller faster than normal, but didn't try very hard. Instead I used this as an excuse to start learning ca65 and made some test ROMs that do exactly that, they poll the first controller many times (I think 50-100x) more often than most ROMs. One plays a sound whenever a button is pressed (just to demonstrate that it's doing something), the other doesn't (and in theory should poll ever so slightly more often but in practice the numbers seem to work out about the same). With these, I get min/max/average readings close enough to the input latency spreadsheet that it's good enough for me. Now to start testing other things!
What I still don't understand is why I need to load a ROM at all, the instructions in the spreadsheet don't indicate that anything like that is needed. So maybe I've done something wrong, but I'm not planning to investigate further.

This was with Main MiSTer_20220131 and the same controller + lag tester core + arduino version as my previous post.

Definitely something wrong if you need to load a ROM. Obviously it wouldn't make sense to rely on a ROM polling the controller for this

Maybe you connected the wire to the wrong USERIO pin or maybe you have SNAC enabled which is interfering.

SNAC not enabled, "Serial Mode" is set to "None".

I may very well be using the wrong pin, I don't have an IO Board so I looked at its schematic as per https://github.com/MiSTer-devel/Hardwar ... rd_6.1.pdf, and I think the User IO TX line referred to by the lag tester instructions to connect to arduino pin 2 is connected to pin 2 (SDA) of the 10 pin connector on the DE-10, with a 100 ohm resistor in series and a 10k pull-up to 3.3v. (I'm wiring arduino pin 5 to the joystick button mapped to NES A, if it matters.)

If I try plugging in the arduino without loading a ROM I get the "read, delay" header over the serial port, and then nothing. Can sometimes open the MiSTer menu at this point, but navigating is usually unresponsive (sometimes buttons/directions work, often they don't). Other times attempting to open the menu in this state activates auto-fire? Unplugging the arduino returns control to normal.

I guess I'm also using shoddy pro-micro clones for both the lag tester arduino and the DaemonBite clone, maybe that has something to do with it... But given the other things I've tried and the different results given different ROMs loaded, I was kind of assuming that the newer Main disagrees with something in the older lag tester core, some config I somehow didn't manage to set/reset/clear is affecting it, I'm missing something put in place by one of the update scripts, and/or I'm missing some boot*.rom?

You should probably try pin 1 of the P7 connector on the IO board. The instructions say pin 2 of the Arduino should be connected to the User IO TX (D+) line. On the P7 connector TX is pin 2 but D+ on the USERIO(USB) connector is connected to pin 1 of the P7 connector so the instructions don't make sense.

I can't find the source for the NES lag tester core to confirm the pin used for the lag test but pin 2 is normally the controller clock signal with SNAC which would only toggle when the controller is read by the ROM so your current results would make sense.

That did it! Pin 1 of the P7 connector is the way to go. Thanks paulbnl! Now I feel dumb for looking at the TX part of the instructions and not the D+. But I can get numbers without loading a ROM, which makes a lot more sense.

So with a DaemonBite Arcade Encoder clone, ID 1b4f:9206, after a run of testing I get count/avg/max/min/stdev 3392/0.7/1.36/0.25/0.292 which seems roughly comparable to the spreadsheet's 2002/0.758/1.264/0.236/0.289, though the spreadsheet has a different ID of 2341:8036. Maybe the spreadsheet is using the official (purchased from DaemonBite the company) encoder?

I also tried a Nintendo Switch HORIPAD, ID 0f0d:00c1, I get count/avg/max/min/stdev 3232/4.476/7.07/1.96/1.447, again roughly comparable to the spreadsheet's 2980/4.717/7.616/1.692/1.471 though maybe a bit further off.

At this point I'm assuming the differences are down to randomness and/or sloppy parts of my setup (eg. maybe extra capacitance or interference from using resistors on a breadboard instead of an actual IO board, cheap arduino clones, cables too long, etc). Not sure if my numbers are good enough to submit (and also I'm not seeing where to submit). But they seem good enough to me that I could grab some weird controller or adapter that nobody cares about, or modify an existing one, and say at a high level that it's comparable to some other controller that has been deemed to be good/bad/ugly.

Thanks again!