MiSTer Laggy

[wickerwaka]

Hi there, I added a new core to the distribution today called "MiSTer Laggy", you'll see it in the _Utilities directory. MiSTer Laggy is a core for doing display latency testing and it works with a small hardware peripheral that connects to the user port. It works much like a Time Sleuth but uses your MiSTer to run the firmware and generate the video signal. There are more details on it's use in the readme: https://github.com/mister-devel/MiSTerL ... Ter#readme

A KiCAD project and 3D printer files are in the hardware directory: https://github.com/MiSTer-devel/MiSTerL ... n/hardware

If you are in the US I have a small number of premade devices for sale here: https://www.tindie.com/products/pbretro/mister-laggy/

Biggest thing I've discovered with this device so far is that you really should use vrr_mode if you are using an LG OLED. Their low latency boost mode is fantastic, 2.4ms latency, but only if the refresh rate is 50hz or 60hz. Lots of arcade cores have refresh rates like 58hz or 62hz and when receiving a refresh rate like that the LG OLED goes into a buffering mode and adds 1-3 frames of latency. When in VRR mode it does not add this additional latency. Given how complex the settings and possible inputs are on modern TVs I'm sure there are a lot of other "gotchas" and sub-optimal pathways that it's possible to hit.

Some details on the core development itself. I didn't want to have to write all of the UI and other logic in HDL, so I made a core with a 68000 CPU and a basic timemap graphics system. The firmware is written in C and compiled to 68000 with GCC (it's pretty cool that GCC still supports CPUs like the 68000). I already had a toolchain setup because I was making from test roms for 68000-base arcade hardware so repurposing it for this project was simple enough. Since it is all in C I was able to easily port over the HDMI video mode code from Main so the core itself can change it's resolution and refresh rate.

[dshadoff]

Very nice work !
I particularly like the idea of embedding a low-level CPU for various things.
In real-world hardware, it would probably be an ARM, but I'm sure implementing 68000 was much easier.

[thorr]

Very cool! If I wasn't a CRT nut, I would totally jump on this.

[PikWik]

very cool, cant wait to test all of my setups to get an idea of the input lag

thanks so much!

[netbeui]

This is cool! Will it only work on LCDs or can it also be used on CRTs?

[thorr]

very cool, cant wait to test all of my setups to get an idea of the input lag

thanks so much!

I think it is for display lag testing only, not for controller testing, if that is what you mean by "input lag".

[Armakuni]

Hopefully a UK or EU hardware seller will start to produce some boards. Would love to give this a try

Great project

[Hackshed_Carl]

Sublime!

Thank you!!!!

[orange428]

Hi, this is great. Now I can lag test my ipad display...the Time Sleuth did not support that high of a resolution. Thanks for putting this together!

[PikWik]

very cool, cant wait to test all of my setups to get an idea of the input lag

thanks so much!

I think it is for display lag testing only, not for controller testing, if that is what you mean by "input lag".

err, yes! this will be great to test my raw display input latency for each monitor i use with a MiSTer. ive always wanted a time sleuth, but that price point scared me off

[wickerwaka]

This is cool! Will it only work on LCDs or can it also be used on CRTs?

It will work on CRTs, yes. It's a normal mister core so it outputs analog video along with HDMI.

[mike2411]

This is awesome, thanks so much for making this. I couldn't justify the $120 for a Time Sleuth.

[Stupid Dufus]

What resolutions are supported for testing? I don't see them listed on the github instructions, and I can't get past the "no sensor detected" screen to try and to try and check it there

edit: nevermind. searching through the source on github I found the resolutions:
{ 640, 480, false },
{ 800, 600, false },
{ 1280, 720, true },
{ 1024, 768, false },
{ 1366, 768, false },
{ 1280, 960, false },
{ 1708, 960, true },
{ 1920, 1080, true },
{ 1600, 1200, false },
{ 1792, 1344, false },
{ 1920, 1440, false },
{ 2048, 1536, false }

[neogeo81]

If you are in the US I have a small number of premade devices for sale here: https://www.tindie.com/products/pbretro/mister-laggy/

Oh no, no shipping to Switzerland. Why?

[FPGA64]

All the PCB , and print files are available on the github. Postage from the US is normally high to Europe plus it would be a pain in the arse dealing with all the different vat rates and customs declarations.

Hopefully one of the European Hw makers will see the demand and make them available over here, with a donation to WickerWaka, for the work in producing the board.

[neogeo81]

Yeh, let's hope that. i am not the diy guy saddly

[wickerwaka]

This round is pretty much sold out but I will have another batch soon. I will try selling through etsy also which I believe handles the various import duties.

[MiSTer Consoles]

This round is pretty much sold out but I will have another batch soon. I will try selling through etsy also which I believe handles the various import duties.

I picked up one this morning. This is a steal compared to the Time Sleuth. Thank you so much for your efforts here. Very much appreciated! I'm looking forward to testing the lag on my TVs.

[hipsofjw]

Could you upload the gerber files onto github? Thanks!

[Anim8]

Biggest thing I've discovered with this device so far is that you really should use vrr_mode

Looks like a nice device to test with.

VRR/Gsync/Freesync will come out on top due to its built in use of Quick Frame Transport(QFT), which causes the wait period(buffer) to occur after the frame is displayed, rather than before the frame. Which happens on displays which use a fix scanrate when not using the displays max hz.

It does have the downside of been incompatible with Black Frame Insertion. Which is why I use Flexible scan mode which is the next best option. Excluding adding in fixed-scanrate rate custom resoultuion/refresh rate, which can get messy.

To try give an example of a fixed scanrate panel at say 240hz it would need to have a fixed 4ms scanrate. So to slow it down to run at 60hz(16ms) it needs to wait/hold/buffer for 12ms then scanout over 4ms(the fixed speed) which gives you the 16ms for each frame at 60hz.
(image example of this)

Where VRR modifies the Vertical Total(VT/HSR)(blanking space) on a frame by frame basis depending on the FPS needed at that time. So the panel still runs at the fixed 4ms(240hz) speed but it adds blank space to each frame so that scanout starts straight away without delay. So for 1080p@60hz(1920x1080), imagine a frame which is now 1920x4320@60hz(3240 lines of added vblank). So for the panel to complete this in time it now needs to start the scan out without buffering, as it can only cover the 4320 lines in 4ms@60hz/fps or it can do 1080 lines in 4ms@240hz/fps, or 2160 lines in 4ms@120hz/fps etc.
(image example of this)

Its also possbile to also add a fixed custom resolution/refresh(EDID) where you manually increase the VT to add extra blank space to get rid of the buffer, without the need of VRR but if you get this wrong your display will likely say out of range or its possible it could damge the display if it attempts to. So I wouldn't recommend attempting this unless you know what your doing. Plus it will only work with vsync=off, but its less of an issue as the tearing is usually offscreen somewhere in the blanking area or will be small due to the fast scanout speed.

Best for latancy when not using the displays max hz is;

1. VRR or Custom EDID
2. Flexible-scanrate panel (image example of this)
3. Fixed-scanrate panel (which is most displays these days)

[PikWik]

it just arrived, and i appreciate how plug-and-play the whole experience is.

i ran update all, got a usb c cable, plugged it into the user port, and started testing the different refresh rates.
the numbers didnt surprise me, but i was happy to see rtings is reliable with their test results. its also nice to see things remained consistent when moving into the weird refresh rates (54hz-57hz)

this is a great piece of gear to have, thanks again!

[Armakuni]

Biggest thing I've discovered with this device so far is that you really should use vrr_mode

Looks like a nice device to test with.

VRR/Gsync/Freesync will come out on top due to its built in use of Quick Frame Transport(QFT), which causes the wait period(buffer) to occur after the frame is displayed, rather than before the frame. Which happens on displays which use a fix scanrate when not using the displays max hz.

It does have the downside of been incompatible with Black Frame Insertion. Which is why I use Flexible scan mode which is the next best option. Excluding adding in fixed-scanrate rate custom resoultuion/refresh rate, which can get messy.

To try give an example of a fixed scanrate panel at say 240hz it would need to have a fixed 4ms scanrate. So to slow it down to run at 60hz(16ms) it needs to wait/hold/buffer for 12ms then scanout over 4ms(the fixed speed) which gives you the 16ms for each frame at 60hz.
(image example of this)

Where VRR modifies the Vertical Total(VT/HSR)(blanking space) on a frame by frame basis depending on the FPS needed at that time. So the panel still runs at the fixed 4ms(240hz) speed but it adds blank space to each frame so that scanout starts straight away without delay. So for 1080p@60hz(1920x1080), imagine a frame which is now 1920x4320@60hz(3240 lines of added vblank). So for the panel to complete this in time it now needs to start the scan out without buffering, as it can only cover the 4320 lines in 4ms@60hz/fps or it can do 1080 lines in 4ms@240hz/fps, or 2160 lines in 4ms@120hz/fps etc.
(image example of this)

Its also possbile to also add a fixed custom resolution/refresh(EDID) where you manually increase the VT to add extra blank space to get rid of the buffer, without the need of VRR but if you get this wrong your display will likely say out of range or its possible it could damge the display if it attempts to. So I wouldn't recommend attempting this unless you know what your doing. Plus it will only work with vsync=off, but its less of an issue as the tearing is usually offscreen somewhere in the blanking area or will be small due to the fast scanout speed.

Best for latancy when not using the displays max hz is;

1. VRR or Custom EDID
2. Flexible-scanrate panel (image example of this)
3. Fixed-scanrate panel (which is most displays these days)

I always thought VRR/Freesync on MiSTer was just a hack to help panels support odd frequencies ? The frames are sent with the variable rate flag to fool the scaler, it's actually more handy on TVs than monitors which have more flexible scalers anyway

I always led to believe these techs needed GPU/Driver support to function properly with the idea behind them to reduce screen tearing and stuttering due to inconsistent frame to frame times coming from the GPU

Proper G-Sync also needs a FPGA in the panel scaler to function properly and is displayport only

Freesync and cheapo G-Sync is based on VESA adaptive sync which is Display port only, Freesync over HDMI is a AMD proprietary tech added to the VESA spec.

VRR is part of the HDMI 2.1 spec which the DE-10 Nano doesn't really support

HDMI Sync_mode 2 only adds a few scanlines of latency anyway

[zakk4223]

The vrr mode on the mister doesn't really modify the video signal to do varying length vblank. Also the chip is somewhat limited so it can't really scanout at high refresh rates. vsync_adjust=0 DOES do variable vblank, at the expense of being triple buffered. Also I'm not entirely sure it is stable (I think the onboard HDMI chip gets really confused by variable blanking). People have reported the debug menus in their TVs showing constant TDMS errors with adjust=0 and vrr.

[Anim8]

I always thought VRR/Freesync on MiSTer was just a hack to help panels support odd frequencies ? The frames are sent with the variable rate flag to fool the scaler, it's actually more handy on TVs than monitors which have more flexible scalers anyway

That makes sense.

Proper G-Sync also needs a FPGA in the panel scaler to function properly and is displayport only

The G-Sync module does have some extra tricks. For example its able to use varying amounts of overdrive/voltage to the pixels during the scanout. The pixels at the bottom of the screen can now be run with more voltage vs the top which helps the display to complete all pixel transitions at around the same time. Helps to stop the bottom half of the screen lagging behind the top half and improves motion clarity.
ULMB2 takes advantage of this

There is some limitations. The displays which use the G-Sync module often have a set number of inputs and they are capped at 85hz+ for BFI.

the chip is somewhat limited so it can't really scanout at high refresh rates.

Looks to have a 210Mhz pixel clock so your correct that high hz scanout speeds is limited.
To run at with x3 more lines over the standard 1080p would need closer to 550 - 600Mhz pixel clock.

https://mister-devel.github.io/MkDocs_M ... etition-pr

Which got me thinking if its possible to use an upscaler like the retrotink 4k as that has a 600 MHz pixel clock. Rather than upscaling use it to add blank lines to reduce latency without the need for VRR.

[Bunker]

Will you be re stocking soon @wickerwaka ?

[wickerwaka]

Yes, this week hopefully. Just waiting for a PCB delivery.

[PikWik]

Which got me thinking if its possible to use an upscaler like the retrotink 4k as that has a 600 MHz pixel clock. Rather than upscaling use it to add blank lines to reduce latency without the need for VRR.

ive also wondered if this is possible, or rather something like doubling the refresh rate of the original core to gain better input latency (simulated 120hz from a 60hz source). the answer i got is this would introduce video artifacts

[jsvw007]

Can custom resolutions be used in the video modes? I use 540p custom resolution for my HD-CRT to supposedly remove all input lag and I'd like to test it.

[SpikePit]

{ 640, 480, false },
{ 800, 600, false },
{ 1280, 720, true },
{ 1024, 768, false },
{ 1366, 768, false },
{ 1280, 960, false },
{ 1708, 960, true },
{ 1920, 1080, true },
{ 1600, 1200, false },
{ 1792, 1344, false },
{ 1920, 1440, false },
{ 2048, 1536, false }

So does that mean only the true values are testable? Just 720p, 1080p, and 1708x960?

[jsvw007]

wickerwaka replied to me on Twitter and said the laggy will use whatever resolution you have set on MiSTer by default when you first load the core, so all custom resolutions are covered!