RetroTINK 5x-Pro

[Guspaz]

If you're getting severe burn-in after two months of CNN 18 hours a day, that's equivalent to having static elements on the screen for 8 hours a day for 4.5 months (as you might expect with the Windows taskbar), or perhaps 2-4 hours a day every day for 9-18 months (as you might expect with somebody who plays a multiplayer game every day). I think that any signs of any burn-in after just two months, even in a torture test, is extremely concerning, even for non-monitor use.

[Hoagtech]

Hows it going Mike?

I had a wuestion about the state of rotating image in another thread, and I thought I would ask you personally how the progress was going for rotation on the Retrotink 5x?

I have two of them and would love to test a couple rotation theories on your device

[Guspaz]

I'm not Mike, but the RT5X isn't ever going to support image rotation. The RT4K might (don't count on it, but don't rule it out) support it at some point in the future, but not at launch.

Image rotation, in addition to the mandatory full frame latency penalty, requires very different (and much less efficient) memory access patterns. It cripples the memory bandwidth.

[NateWolfKira]

Just a quick update. I remade my PSP settings video with a more concisely written video description. I hope y'all find it helpful.

[orange808]

On the 4k, please consider doubling the frame rate at 1080p with rotation. Any HDMI standard that supports 4k will have enough bandwidth.

Correct me if I'm wrong, but: for sample and hold, that will effectively halve the time the signal spends on the wire between the video processor and display, because the frame was already fully buffered by the video processor. Most sample and hold displays should completely scan out an updated frame from the Tink4k about half a frame faster. For a zero lag sample and hold digital display, the final result would be rotation with only half a frame of additional lag (at the bottom of the screen) versus feeding a native signal to the display, because we already buffered the signal at the Tink4k. Fast rotation would be welcome for users that choose to play without strobing/BFI and have a compatible display.

[Guspaz]

The issue with rotation isn't HDMI bandwidth, it's memory bandwidth, since it turns sequential access to the framebuffer into non-sequential access. For example, if you have a 64-bit memory bus (and I don't know how wide the RT5X or RT4K memory bus is, I'm just picking the typical SDRAM bus width), that means that the minimum read and write size is 8 bytes. If you're reading a framebuffer sequentially, where every pixel is 24 bits, and thus three bytes, that's fine, you just keep reading 8 byte chunks because even if that isn't divisible by 3, you'll need the extra bytes next read anyway. But if you rotate the framebuffer by 90 degrees, you're now reading only three bytes per scanline before jumping way ahead in memory. Suddenly, your 8 byte read only has 3 bytes of usable data, and your memory bandwidth is reduce to barely more than one third.

[orange808]

The issue with rotation isn't HDMI bandwidth, it's memory bandwidth, since it turns sequential access to the framebuffer into non-sequential access.

I didn't say it was. ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

I just don't have a warp processor that can frame double the output of legacy game consoles and arcade PCBs to 1080p@~120Hz and I know I want one. Was hoping it might be possible on the next machine. I actually do own a warp processor that can handle 1080p@120Hz but it's fully frame locked to the input refresh. Although, I could chain that behind another machine if I wanted curved edges with low latency, because it uses a dynamic line buffer.

Barring a display manufacturer that directly integrates a robust video processor with their panel/beamer, that's the only way to make tate run faster. Tate games are arcade games. Not many arcade RPGs out there. Lag matters.

The golden age of the video processor (as we knew it) is behind us. Everything is moving to PC-based processing. Moving everything inside an OS makes edge blending/warp configuration easier, it allows us to use machine learning, and it's easier to integrate nvidia's GPU features into a software solution (running on a prebuilt PC) than design a scaler machine from scratch. Stuff like the recent madvr machines and Vioso's offerings don't give me a lot of hope for the standalone video processors of tomorrow and video games. Low latency doesn't matter for image warp applications or home theatre.

So, if there will be a low lag rotation machine that increases the output cadence with repeated frames for (possible) lower latency performance, it will have to come from a community project. (or probably not at all)

For example, if you have a 64-bit memory bus (and I don't know how wide the RT5X or RT4K memory bus is, I'm just picking the typical SDRAM bus width), that means that the minimum read and write size is 8 bytes. If you're reading a framebuffer sequentially, where every pixel is 24 bits, and thus three bytes, that's fine, you just keep reading 8 byte chunks because even if that isn't divisible by 3, you'll need the extra bytes next read anyway. But if you rotate the framebuffer by 90 degrees, you're now reading only three bytes per scanline before jumping way ahead in memory. Suddenly, your 8 byte read only has 3 bytes of usable data, and your memory bandwidth is reduce to barely more than one third.

I get the bandwidth issue. I assumed the new device would have improved specs.

I certainly wasn't suggesting that doubling the frame rate would make the memory faster. I also wasn't begging for any (existent or nonexistent) unreleased beta firmwares that could (and should) be tested by more qualified people (like Voultar) that can offer more useful and informed feedback for Mike than "it doesn't work". So don't lump me in into that. That's all hoagie.

I mentioned the HDMI cable because of the bandwidth to send 120fps down the wire at 1080p, but now that I think about it, I think HDMI 1.4 could already do that with 8bpc. So, that's moot.

[Unseen]

For a zero lag sample and hold digital display, the final result would be rotation with only half a frame of additional lag (at the bottom of the screen) versus feeding a native signal to the display, because we already buffered the signal at the Tink4k.

For a clockwise rotation, the first pixel to scan out is still the first pixel of the last line of the frame, no matter how fast or slow your display is. Anticlockwise is similar if you consider the last pixel of the first line.

Suddenly, your 8 byte read only has 3 bytes of usable data, and your memory bandwidth is reduce to barely more than one third.

I have this completely untested theory that this could be handled by segmenting the image into squares (or maybe rectangles) and buffer those in FPGA block RAM, which has no such problem with arbitrary access stride. Each of them could be efficiently bursted in and out of external RAM, the question is just if the total amount needed is within reasonable limits. On the read side this scheme basically needs 2x rectangle-height number of lines worth of RAM, on the write side it's 2x rectangle-width lines. Obviously you'd try to rotate before scaling to minimize the total amount of memory.

[Guspaz]

I mentioned the HDMI cable because of the bandwidth to send 120fps down the wire at 1080p, but now that I think about it, I think HDMI 1.4 could already do that with 8bpc. So, that's moot.

While rotation isn't planned, 120+ Hz modes are planned on the RT4K, including software BFI for OLED displays, albeit at reduced resolutions like 1440p120 or 1080p240. Other than typical software BFI pattern, I believe Mike also expressed interest in implementing a film projector BFI pattern, where film projectors in theatres typically closed the shutter multiple times without advancing the film. In other words, the projector would typically operate at effectively 48 Hz or 72 Hz, with the shutter closed between each hz, but showed the same frame 2 or 3 times in a row. This can be simulated with BFI at 96 Hz or 144 Hz.

So, yes, all sorts of higher refresh rate shenanigans are in the works.

[Extrems]

I have this completely untested theory that this could be handled by segmenting the image into squares (or maybe rectangles) and buffer those in FPGA block RAM, which has no such problem with arbitrary access stride. Each of them could be efficiently bursted in and out of external RAM, the question is just if the total amount needed is within reasonable limits. On the read side this scheme basically needs 2x rectangle-height number of lines worth of RAM, on the write side it's 2x rectangle-width lines. Obviously you'd try to rotate before scaling to minimize the total amount of memory.

This is basically the same strategy GPUs use.

[orange808]

For a clockwise rotation, the first pixel to scan out is still the first pixel of the last line of the frame, no matter how fast or slow your display is. Anticlockwise is similar if you consider the last pixel of the first line.

¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯ I never said anything different.

Console: ~60fps ->
Tink4k: full frame buffer takes ~17ms ->
Wire: send frame at 120Hz ~8ms ->
Display processing and scanout: ~8ms + Tink4k processing lag ~17ms = ~25ms lag.

If the wire had more bandwidth, I could theoretically get the "send frame" step (between the Tink4k and display) down near zero.

The time the Tink4k took to buffer and process the frame is gone. We can't go back in time, but everything after the theorical Tink4k is the future.

When the Tink4k is holding all the information for an entire frame and about to send the information down the wire, everything downstream of the Tink4k in the chain hasn't occured. So, if I want to send the signal faster, I certainly can. After that, we only need the display to accept (honour) the frame rate and have low lag. Mine definitely will.

I have a display that accepts 240Hz, so I'd actually like 240Hz. We have diminishing gains every time we double the frame rate, but I'd love to get ~12 more milliseconds back on my display when I play tate. In that case, after my display completely scans out the entire frame, my "new" frames completely scan out ~4ms "behind" completely scanning out one frame without a video processor (because of the time saved with fast transport and scanout).

My current tate solution takes 42ms to complete scanout on the display feeding a 60Hz signal. Assuming the Tink4k could do the job in ~17ms, a total of 21ms lag at 240Hz output would cut my lag in half at the bottom of the screen.

That kind of improvement over the best current solution is nontrivial and it would be more than a niche use case. Lots of people like MiSTer. Okay, let's use that as an example. If I understand correctly, the MiSTer buffers an entire frame for tate and sends it out at 60Hz. My suggestion should outperform the built in solution when paired with a low lag display that accepts high frame rates. Definitely not a niche use case at 1080p 120Hz. Display compatibility for that signal has become widespread and many users would gladly adopt an external scaler to get faster latency playing shmups.

[Unseen]

If the wire had more bandwidth, I could theoretically get the "send frame" step (between the Tink4k and display) down near zero.

I can only make sense of this if I assume that you believe that the display cannot start showing any part of the frame it is receiving before it has received the entire frame. Why would that be so? There are displays on the market that have measured lag below 1 frame, which contradicts that constraint.

If I understand correctly, the MiSTer buffers the entire frame and sends it out at 60Hz.

That depends on the output used and the configuration. Current docs on the net claim about 4 scanlines of lag with vsync_adjust=2, though it doesn't work with all displays - the usual off-spec video timing problem.

[orange808]

If the wire had more bandwidth, I could theoretically get the "send frame" step (between the Tink4k and display) down near zero.

I can only make sense of this if I assume that you believe that the display cannot start showing any part of the frame it is receiving before it has received the entire frame. Why would that be so? There are displays on the market that have measured lag below 1 frame, which contradicts that constraint.

You're being obtuse.

I already own a video processor that outputs 120Hz and I can already see what happens if I double the input's frame. I already know it cuts the latency.

Enjoy arguing with yourself.

I added a lot of qualifiers to avoid this kind of pointless conversation. Carry on.

[Unseen]

I already own a video processor that outputs 120Hz and I can already see what happens if I double the output frame rate. I already know it cuts the latency.

That's the slight difference between "happens to help for your particular setup" and "will help every setup".

[orange808]

I already own a video processor that outputs 120Hz and I can already see what happens if I double the output frame rate. I already know it cuts the latency.

That's the slight difference between "happens to help for your particular setup" and "will help every setup".

I specifically referenced the bottom of the screen and a complete scanout multiple times. So, you're still being obtuse. Most every screen scans out faster with a higher frame rate. It has to or it wouldn't be ready to output the next frame.

Mike is a smart guy. He'll understand the suggestion. I may not get my wish, but he'll understand. That's all that matters.

Drive 8km at 4km per hour. 2 hours.
Drive 4km at 4km per hour, rest for 30 minutes, and drive 4km at 8km per hour. 2 hours.

It's not rocket science.

[Fudoh]

are you sure about that?

I haven't put much thought into this and it's a bit hard to describe, but since a 60Hz source can't deliver a full frame within 8.x ms, you can't lock the output of the first of each doubled frame (at 120Hz) to the source signal. Instead you have to delay the output by half a frame. The first of the doubled frame can ONLY be output when the source has already sent half a frame.

I think this kills the 0.5 frame advantage you're thinking of.

I think I could explain better using a diagram, but maybe you get my idea ? (and as thought, it might be BS, have only put a minute into it right now).

(EDIT: ok, you meant strictly rotation PLUS 120Hz output. Got it. Finished frame by the source is mandatory, but the additional time to send and display the frame could be minimized. Might cause a problem with double images though, don't you think? Might be counter productive with the kind of games, that actually require the 0.5 frame speed boost in the first place...)

[orange808]

are you sure about that?

Sure. Try it with a machine with a full frame buffer. Unfortunately, I don't own any machines that do good deinterlacing or rotation and output 1080p 120Hz, so it hasn't been practical.

In Time Sleuth/Leo Bodnar terms using a low latency display, you will get a frame of lag (~17ms) at the top of the screen and ~24ms of lag at the bottom while feeding a 60Hz source that is fully buffered and "frame doubled" to 120Hz by a video processor. The frame of lag is there, but we are cutting down the time to full scanout, because we would normally expect two full frames of latency (at the bottom) if the video processor was frame locked in this scenario.

I haven't put much thought into this and it's a bit hard to describe, but since a 60Hz source can't deliver a full frame within 8.x ms, you can't lock the output of the first of each doubled frame (at 120Hz) to the source signal. Instead you have to delay the output by half a frame. The first of the doubled frame can ONLY be output when the source has already sent half a frame.

I think this kills the 0.5 frame advantage you're thinking of.

I think I could explain better using a diagram, but maybe you get my idea ? (and as thought, it might be BS, have only put a minute into it right now).

Yes. I believe I specifically mentioned that we cannot go back in time.

It's valid strategy anytime a machine uses a full frame buffer. As a thought exercise, imagine an independent machine is invalidating it's own internal frame buffer in constant ~17ms cycles.

(EDIT: ok, you meant strictly rotation PLUS 120Hz output. Got it. Finished frame by the source is mandatory, but the additional time to send and display the frame could be minimized. Might cause a problem with double images though, don't you think? Might be counter productive with the kind of games, that actually require the 0.5 frame speed boost in the first place...)

Good point on frame lock and frame rate conversion artifacts (tearing or studding). That depends on the particular video processor and how well it can be configured. Although, doubling frame rates isn't a completely new or uncommon feature in video processing. I can feed 30fps into a few of my machines right now and get frame doubled output at 60Hz. Is this different?

Agreed on motion blur. It sucks. On the other hand, I don't see the problem with sample and hold with repeated frames for this situation.

Does anyone use black frame insertion with tate rotation? I do not, because BFI adds lag on my displays. I already have 42ms of lag. I don't want to add half a frame more for BFI. The additional motion resolution isn't worth the latency to me. Given the choice, I'd rather subtract latency. 42ms untll complete scanout using my external rotation machine (in the video chain) is already too much lag.

[Josh128]

Might cause a problem with double images though, don't you think? Might be counter productive with the kind of games, that actually require the 0.5 frame speed boost in the first place...)

Correct here. Frame doubling any input will definitely cause the double image illusion, especially if the monitor backlight strobe rate = the doubled frame rate or if its OLED or CRT. Whether its acceptable or not depends on the game-- faster moving objects suffer from the illusion much more than slower moving objects.

[orange808]

Might cause a problem with double images though, don't you think? Might be counter productive with the kind of games, that actually require the 0.5 frame speed boost in the first place...)

Correct here. Frame doubling any input will definitely cause the double image illusion, especially if the monitor backlight strobe rate = the doubled frame rate or if its OLED or CRT. Whether its acceptable or not depends on the game-- faster moving objects suffer from the illusion much more than slower moving objects.

FWIW, my original request specifically said sample and hold. ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯ My qualifiers were crafted with purpose.

I never had any intention of using BFI.

[Mr.Ash]

I noticed a problem with the RT5X not displaying a 567p/480p picture signal from my PS2.

My setup looks like this:

- PS2 PAL version with Modbo 4.0 modchip
- FMCB 1.965 and OpenPSLoader 10 Anniversary Edition
- GSM settings -> for NTSC HDTV 480p 60Hz, for PAL HDTV 576p 50Hz
- Original Sony YPbPr cable
- RetroTink 5X with firmware version 3.0

When I turn on the PS2 everything still runs normally, as the console outputs a PAL 50Hz (576i) picture signal, but the colors look quite pale, and yes, in the HDMI settings of the RT5X I set the HDMI color space to Full.
After that I use OpenPSLaoder to run my games from the USB memory stick, I set the GSM settings for the PAL games to HDTV 576p 50Hz and for the NTSC games to 480p 60Hz.
Unfortunately the RT5X does not recognize the 576p nor the 480p picture signal of the PS2, the info display always reports "no signal".

After that I connected the PS2 with the exact same settings and cable to my old DVDO iScan VP50, and it recognizes the 576p and 480p signals of the PS2 without any problems, furthermore the colors are rich from the beginning and not faded like on the RT5X.

In both cases the scaler is connected to the same HDMI port on the TV and uses the same settings.

This now leads me to the following questions:

1. why are the colors of the PS2 via YPbPr cable so pale on the RT5X, but not on the VP50?
2. why does the RT5X not recognize the 576p and 480p picture signals of the PS2 at all, while the VP50 does not?

Are there any setting in the RT5X to fix the described problems?

[TooBeaucoup]

1. why are the colors of the PS2 via YPbPr cable so pale on the RT5X, but not on the VP50?
2. why does the RT5X not recognize the 576p and 480p picture signals of the PS2 at all, while the VP50 does not?

I can't explain why you're having the issues you are. However, I wanted to mention that I've never found my PS2's picture output pale via component cables. I'm running an NTSC console, although, I don't think that should matter.

[Josh128]

Ditto-- no issues with my PS2 via component into GBS-Control.

[Mr.Ash]

However, I wanted to mention that I've never found my PS2's picture output pale via component cables. I'm running an NTSC console, although, I don't think that should matter.

I've never had any problems with that either. The problem only exists with the RT5X, all other devices work perfectly with the PS2 and show a colorful 480p/576p picture via YPbPr cable.

I am of course aware that playing games via OpenPSLoader and modified GSM settings does not correspond to the actual PS2 standard. However, I find it strange that all other devices support this type of image output without any problems, just not the RT5X.

I will try to connect the PS2 via RGB cable and see if it works.

[VEGETA]

any news on RT4K? I am interested in knowing the price range. asked the designer numerous times but didn't answer me.

plus, what key features will it have more than 5x (besides 4k res)?

[orange808]

https://forums.atariage.com/topic/33275 ... nt-5036907

[bobrocks95]

any news on RT4K? I am interested in knowing the price range. asked the designer numerous times but didn't answer me.

plus, what key features will it have more than 5x (besides 4k res)?

Mike has said multiple times now to put aside $1000 USD and you should be pleasantly surprised. I'm hoping for around $750 myself, and maybe expecting $800 at the high end.

The 4K is mostly for more advanced scanline filters. The only other features the 5X doesn't have that I know of are HDR color correction, the HDMI input, and support for 720p and I believe 1080p inputs. Since the RT5X has been full logic block wise for a while I could see other future features being locked behind it (I really hope Mike can figure out rotation), but no explicit promises so far.

[VEGETA]

any news on RT4K? I am interested in knowing the price range. asked the designer numerous times but didn't answer me.

plus, what key features will it have more than 5x (besides 4k res)?

Mike has said multiple times now to put aside $1000 USD and you should be pleasantly surprised. I'm hoping for around $750 myself, and maybe expecting $800 at the high end.

The 4K is mostly for more advanced scanline filters. The only other features the 5X doesn't have that I know of are HDR color correction, the HDMI input, and support for 720p and I believe 1080p inputs. Since the RT5X has been full logic block wise for a while I could see other future features being locked behind it (I really hope Mike can figure out rotation), but no explicit promises so far.

I am expecting 800$ but many others are telling me it will be 1000$, both are crazy prices. we will see if it is gonna be revealed soon.

as for features, what advanced scanlines? i feel like scanlines are not really used extensively by gamers, they just want that feature to exist though. HDR in RT4K is fake, just a flag to make the TV brightens pixels when using scanlines, this is what I read here. HDMI input is a good feature which can open the gate to using modern gaming devices on older CRT TVs when downscaling using the device. Rotation is basically for shooters, which people request now but can't figure out how they will play it when it is rotated... from controller point of view.

[bobrocks95]

Rotation is basically for shooters, which people request now but can't figure out how they will play it when it is rotated... from controller point of view.

Tate modes for shooters expect you to rotate the display with it. Up is still up, etc. Now some had modes to turn vertical games into horizontal ones by remapping the controls (up = left) but this was for when you couldn't rotate the TV but wanted full res, and is less common.

It sounds like you'd probably be best sticking with the 5X, I think most people will be.

[VEGETA]

Rotation is basically for shooters, which people request now but can't figure out how they will play it when it is rotated... from controller point of view.

Tate modes for shooters expect you to rotate the display with it. Up is still up, etc. Now some had modes to turn vertical games into horizontal ones by remapping the controls (up = left) but this was for when you couldn't rotate the TV but wanted full res, and is less common.

It sounds like you'd probably be best sticking with the 5X, I think most people will be.

if i have a vertical shooter and want it to be horizontal, then either i rotate the tv or rotate the picture. rt4k does the later, but now up direction is shown as right and so on. which is why I asked what people are doing.

for me i have an original ossc and stopped using it when i got a good sony crt, all my setup is in the crt.

however, still interested in the scene

[SavagePencil]

You're muddying up the thread, but any game that allows you to explicitly specify a tate mode will also adjust the controls to accommodate.