RetroTink 4K All But Officially Announced ....

[fernan1234]

Thanks for that very informative post bobrocks. This convinced me to not bother with the Morph even at the black friday discount and just "wait" to buy (and actually receive sooner) the Tink4K.

[bobrocks95]

Thanks for that very informative post bobrocks. This convinced me to not bother with the Morph even at the black friday discount and just "wait" to buy (and actually receive sooner) the Tink4K.

I will also be getting a Tink4K at launch, it will definitely be more feature-rich out of the box, and it's not like it'll lose value by using it if I re-evaluate in the future. I will probably add a digital Morph in the future since I like its web features the Tink won't get.

[Guspaz]

I like its web features the Tink won't get.

I am working on adding wifi support to the RT4K via the SD slot. A bit indirect so it won't be quite as well integrated, but I'm expecting to have two-way communication with the RT4K, so I think we can eventually get most of the functionality that people would want in a web interface.

[SavagePencil]

I like its web features the Tink won't get.

I am working on adding wifi support to the RT4K via the SD slot. A bit indirect so it won't be quite as well integrated, but I'm expecting to have two-way communication with the RT4K, so I think we can eventually get most of the functionality that people would want in a web interface.

You mentioned that earlier in the thread, can you elaborate a little on the setup? I remember WiFi SD cards a few years back, but IIRC they could only do reads over WiFi.

Put another way: what are you envisioning gets plugged in where?

[Guspaz]

The Fysetc SD-WIFI-PRO (not to be confused with their older and much less capable SD-WIFI) costs $20-30 (including programming board), is the size and shape of a regular SD card, and has onboard 8GB of NAND flash, and an ESP32-PICO-V3-02 with 2MB of SPI PSRAM and 8MB of internal flash (for firmware and internal storage). It also has wifi.

It has limitations. The wifi is slow, probably due to not having much room for antennas and the fact that sd cards live inside a metal shield in SD slots. And the ESP32 has no direct access to the standard SD card pins (GPIO is exposed via the SD 7.0 extra pins but the RT4K slot doesn’t have pins there). The 8GB of nand can only be connected to either the ESP32 or the SD pins via a switch chip, not both at the same time. However, I do have the ability to check the CS pin to see if the host device is using the SD card. The only caveat is that I need to avoid stealing the sd card from the RT4K during boot and firmware updates, otherwise than that it tolerates the ESP32 effective unplugging the SD card well.

So far I’ve implemented a basic web interface and a working WebDAV server (to let you mount the SD card in Windows over the wifi). I have the beginnings of RT4K profile manipulation. Next, I’m designing a simple API to communicate with the RT4K via the file system. I can do a lot with just a few simple commands: create a new profile and I can get all current configuration/setting of the RT4K. Load a profile and I can change any configuration/setting of the RT4K. I also have some ideas of things I can do with profile manipulation that the RT4K can’t do on its own.

Yes, this is going to be a little bit janky. But I think that even with the limitations of this setup, there’s the potential for quite a lot.

Another idea that I had for adding wifi control to the RT4K is a pi zero installed inline to the RT4K power line, since the pi zero can handle the power load and the RT4K supports serial communication via USB. However the RT4K serial interface isn’t implemented yet and when I saw the SD-WIFI-PRO and realized it supported the .NET nanoFramework, I just had to get one to play around with, and it’s probably a more user-friendly option even if it can’t communicate as easily directly with the RT4K. Who knows, maybe in the future, a combined approach with both simultaneously will enable even better things.

[SavagePencil]

Has anybody with a pre-release RT4K put it through its paces for the AES? The 5X had some serious troubles with it (which the OSSC handled…handily).

[Josh128]

Not sure the mad Dr. Mike still checks in here, but I'll post this in case anyone else might have a clue--- regarding 4K 120Hz capability, it seems that HDMI 2.0 bandwidth of 18 Gbps is actually adequate for 4K 120Hz if the chroma and color resolution are limited to 8 bit color and 4:2:0 chroma subsampling.

Now, I know some purists will scoff at these settings, but for video games, especially the 8 and 16 bit generations, these settings should not be a problem, and I'd take them any day as a trade off for a 4K BFI mode to reduce blur.

Im sure Mike has considered this but I dont recall seeing the discussion here, anyone know?

[Guspaz]

The RT4K does not currently support chroma subsampling on output, and the HDMI transmitter is currently pixel clock limited and not bandwidth limited, so I'm not sure that a 4:2:0 output mode would necessarily help. The RT4K can send (and certain TVs like LG OLEDs can receive) 4K60 4:4:4 at 10bpc, despite that being 124% of the max allowed bandwidth (pixel clock is under 600 MHz, but TMDS clocks are massively overclocked). But it won't really let you go over 600 Mhz pixel clock at all. That's not an RT4K limitation, it'll let you try, but the HDMI transmitter will just fall over if you try to go much beyond 600 MHz.

I adapted Tom Verbeure's timing calculator for the RT4K, including outputting RT4K custom modeline timings directly. I've also already integrated this calculator into my SD-based wifi interface for the RT4K and have some ideas about letting the user directly set custom modelines on the RT4K from the calculator: https://guspaz.github.io/video_timings_calculator

[Josh128]

The RT4K does not currently support chroma subsampling on output, and the HDMI transmitter is currently pixel clock limited and not bandwidth limited, so I'm not sure that a 4:2:0 output mode would necessarily help. The RT4K can send (and certain TVs like LG OLEDs can receive) 4K60 4:4:4 at 10bpc, despite that being 124% of the max allowed bandwidth (pixel clock is under 600 MHz, but TMDS clocks are massively overclocked). But it won't really let you go over 600 Mhz pixel clock at all. That's not an RT4K limitation, it'll let you try, but the HDMI transmitter will just fall over if you try to go much beyond 600 MHz.

I adapted Tom Verbeure's timing calculator for the RT4K, including outputting RT4K custom modeline timings directly. I've also already integrated this calculator into my SD-based wifi interface for the RT4K and have some ideas about letting the user directly set custom modelines on the RT4K from the calculator: https://guspaz.github.io/video_timings_calculator

So the number of pixels in the resolution would be the limiting factor, not the bits per color or chroma sub sampling. Hmmm...so its likely a no-go even for a future update eh? What about some odd ass resolution like an anamorphic 1920x2160 that would not run over a 600MHz pixel clock? That said, I dont know if any monitor would accept such a resolution. Im guessing Mike kicked all these types of ideas for workarounds already and nothing looks like it will work?

[Guspaz]

The RT4K isn't picky, as long as the timings aren't too tight (the scaler does need some time between each scanline/frame to do stuff), it'll let you output whatever you want in the custom modeline.

2880x2160 is useful (if your display supports it) since it lets you do pixel-perfect 4:3 (that is, no scaling required from the TV) at up to 89 Hz, which I just tested as working (I tried 90 Hz but at 600.5 MHz it's a step too far) which is quite useful for higher refresh rate 4:3 content like DOS (70 Hz).

I just tested 1920x2160 at 120 Hz and that worked OK. Of course you'll need your TV to stretch that to 4:3 or 16:9 and you'll need to correct the aspect ratio on the RT4K so that the source image is scaled to fill the 1920x2160 window that the TV stretches out to 4:3 or 16:9.

However, the caveat here is always, the RT4K will output whatever you tell it, but will your display support it? I have an LG C1 which is notoriously tolerant of strange resolutions and signals. The same isn't true of all displays.

And for exceeding the TMDS bandwidth limit, I haven't done extensive testing, but I can tell you that my LG C1 accepts 4K60 10bpc just fine (the 124% TMDS overclock), but my HDMI 2.1 Sony AVR refuses to pass it through. The Sony AVR otherwise doesn't mind passing through those oddball resolutions like 1920x2160p120 or 2880x2160p89. But it doesn't like it when you exceed the TMDS clock limit.

EDIT: All the testing I mentioned above was done with either CEA-861 or CVT-RBv2.

[Josh128]

The RT4K isn't picky, as long as the timings aren't too tight (the scaler does need some time between each scanline/frame to do stuff), it'll let you output whatever you want in the custom modeline.

2880x2160 is useful (if your display supports it) since it lets you do pixel-perfect 4:3 (that is, no scaling required from the TV) at up to 89 Hz, which I just tested as working (I tried 90 Hz but at 600.5 MHz it's a step too far) which is quite useful for higher refresh rate 4:3 content like DOS (70 Hz).

I just tested 1920x2160 at 120 Hz and that worked OK. Of course you'll need your TV to stretch that to 4:3 or 16:9 and you'll need to correct the aspect ratio on the RT4K so that the source image is scaled to fill the 1920x2160 window that the TV stretches out to 4:3 or 16:9.

However, the caveat here is always, the RT4K will output whatever you tell it, but will your display support it? I have an LG C1 which is notoriously tolerant of strange resolutions and signals. The same isn't true of all displays.

And for exceeding the TMDS bandwidth limit, I haven't done extensive testing, but I can tell you that my LG C1 accepts 4K60 10bpc just fine (the 124% TMDS overclock), but my HDMI 2.1 Sony AVR refuses to pass it through. The Sony AVR otherwise doesn't mind passing through those oddball resolutions like 1920x2160p120 or 2880x2160p89. But it doesn't like it when you exceed the TMDS clock limit.

EDIT: All the testing I mentioned above was done with either CEA-861 or CVT-RBv2.

Excellent, thank you for testing that. Thats quite interesting. So BFI on 2160p is potentially already an option, with some rather large asterisks*, at least. Now, with something like that 2160p89, what would be a use case for that? Im assuming it works only because of the VRR capability of that C1? In any case, its not an even multiple of the source, Im guessing, unless the source is a PC running VRR ?

This is amazing stuff, really.

[Guspaz]

VRR displays tend to support arbitrary fixed framerates within their VRR window. Not always the case, obviously, but it is for the C1. The purpose of 2880x2160 is that it's a 1:1 pixel mapping of 4:3 to a 4K display. There are commonplace use cases for it at 70 Hz, which is DOS PCs. Maybe there are some use cases that need a bit more too. The WonderSwan is 75 Hz, though it's not 4:3 so you'd possibly want a wider output resolution.

Why 89 Hz? Because I was just trying to see where the limit was. With CVT-RBv2 timings, 89 Hz works, 90 Hz doesn't. However, just now I tried tightening the timings ever so slightly to get 2880x2160 at 90 Hz under 600 MHz (I dropped vblank from 94 to 90, which gets the pixel clock from 600.5 MHz to 599.4 MHz), and that actually did work, so the C1 is displaying 2880x2160 at 90 Hz right now. I don't know how high you could push it with even tighter timings before either the RT4K or the LG C1 gives up, I'll leave it to someone else to experiment with.

The RT4K lets you specify any output progressive-scan video timings you like, so while it has a bunch built-in, people with special use cases can customize that as much as they like, within the hardware and scaler algorithm limitations. I don't have a use case for 2880x2160p90, but if somebody out there does, well, it works on the C1 with the modeline:

Code: Select all

2880, 8, 32, 80, 1, 2160, 80, 8, 90, 0, 90, "2880x2160p90"

The RT4K's native modeline format is the one output by my timing calculator tool that I posted a while back.

[fernan1234]

Wake me up when we get interlaced-scan video timings.

But seriously, it's great knowing that there will be so much flexibility. Thanks for all the testing work (and SD wifi experimenting), Guspaz.

[tongshadow]

Very interesting discussion over blurbusters forum, the Chief states that the Tink4K will allow custom BFI modes for fasters displays. This means that if you're running on a 240hz display, you can get superior motion blur reduction.

https://forums.blurbusters.com/viewtopi ... 42&p=99111

[VEGETA]

i am more interested in the adc chip used and the composite decoder chip if anyone can verify.

[Josh128]

Very interesting discussion over blurbusters forum, the Chief states that the Tink4K will allow custom BFI modes for fasters displays. This means that if you're running on a 240hz display, you can get superior motion blur reduction.

https://forums.blurbusters.com/viewtopi ... 42&p=99111

This guy is a true nerd. I love it. Interesting that he recommends against LCDs for the BFI stuff, LCDs are the displays that need it most, lol. In any case, bravo. Mike appears to have produced a winner on so many levels.

[fernan1234]

This guy is a true nerd. I love it. Interesting that he recommends against LCDs for the BFI stuff, LCDs are the displays that need it most, lol. In any case, bravo. Mike appears to have produced a winner on so many levels.

Not really, since BFI is to reduce persistence or eye-tracking blur (not pixel-response motion blur), which affects LCDs and OLEDs equally especially with 60fps content. But using this on LCDs should be fine too as long as you enable the LCD saver mode.

[Josh128]

His reasoning is pretty sound though, and I guess I never considered it-- input image based BFI on an LCD might only cause the LCD to change to black screen for 8ms and not actually shut off the LEDs which would not be optimal whereas OLED doesnt have the issue of a separate backlight. Also, dont some LCDs shat themselves with rapidly flickering images/changes to the entire LCD? Just another reason to loathe LCD I guess.

[fernan1234]

Also, dont some LCDs shat themselves with rapidly flickering images/changes to the entire LCD? Just another reason to loathe LCD I guess.

Yes, though this is only a problem for IPS panels in particular. That's what the LCD saver mode is supposed to address. But it is true that overall OLEDs are better suited for BFI effectiveness, though at the same time OLEDs have lower full screen brightness capabilities than comparable LCDs, which means they are less able to compensate for brightness loss from BFI especially when combined with further brightness loss from using CRT mask filters.

[tongshadow]

Also, dont some LCDs shat themselves with rapidly flickering images/changes to the entire LCD? Just another reason to loathe LCD I guess.

Though at the same time OLEDs have lower full screen brightness capabilities than comparable LCDs, which means they are less able to compensate for brightness loss from BFI especially when combined with further brightness loss from using CRT mask filters.

That's where HDR Mode comes in, OLEDs have exceptional HDR performance after all.

[fernan1234]

That's where HDR Mode comes in, OLEDs have exceptional HDR performance after all.

Of course, without HDR the whole thing would be a non-starter. But almost all available OLEDs are still very much limited in full screen brightness at around 200 nits regardless of HDR. This means that double+ brightness halving from BFI and CRT filter combos leaves you with around 50 (maybe 70 at best) nits which is not good at all. MiniLEDs are a good option with decent blacks and much larger full screen brightness headroom to work with, though they in turn have other disadvantages including lower max refresh rates.

Basically you're looking at various compromises one way or another for the next few years.

[tongshadow]

That's where HDR Mode comes in, OLEDs have exceptional HDR performance after all.

Of course, without HDR the whole thing would be a non-starter. But almost all available OLEDs are still very much limited in full screen brightness at around 200 nits regardless of HDR.

Useless metric, peak brightness at varying APL levels is much more important to evaluate HDR performance on real content. QD-OLEDs are very good at that:
https://www.rtings.com/tv/reviews/sony/a95l-oled
Also, anyone into retrogaming has probably gotten used to CRT's brightness levels, which is lower than any modern display.

And like Josh mentioned, you need fast response times in order to software-level BFI to work well (sub 8ms GTG times), the likes of which I dont expect from VA MiniLEDs.

[fernan1234]

Useless metric, peak brightness at varying APL levels is much more important to evaluate HDR performance on real content. QD-OLEDs are very good at that:

Retro game systems with CRT filters on is not "real content" in the same sense as your HDR movies and TV shows. QD-OLED also has this limit currently and for the next few years as far as we can see. Again, for the purposes of BFI and CRT filters, which basically halve the full screen brightness each, this is the metric that matters.

Also, anyone into retrogaming has probably gotten used to CRT's brightness levels, which is lower than any modern display.

Pro CRTs are calibrated between 100 and 120 nits. Regular CRT users probably crank up the black level, maybe even black level and saturation, and end up above that. But even the broadcast standard of 100 (for a light-controlled room) is well below the 50-60 you'll end up with on any OLED (WOLED or QD-OLED) once you have both BFI and CRT filters on. Something that will help is higher refresh rates (especially above 240Hz), but those will have other compromises (will need to use lower resolutions).

[tongshadow]

But even the broadcast standard of 100 (for a light-controlled room) is well below the 50-60 you'll end up with on any OLED (WOLED or QD-OLED) once you have both BFI and CRT filters on.

Have you measured this? What calibrator and OLED model did you use?

Anyways, 8-Bit Squire has just released a video talking about the TINK4K using HDR and BFI to match a CRT, he was very pleased with the results and claimed his OLED was "just a little bit dimmer than the CRT":
https://www.youtube.com/watch?v=3ZmPkozY6Cg

[fernan1234]

Anyways, 8-Bit Squire has just released a video talking about the TINK4K using HDR and BFI to match a CRT, he was very pleased with the results and claimed his OLED was "just a little bit dimmer than the CRT":

He's being mild by saying "just a little bit." The difference is clear in the video and you can bet it's even more when seen in person.

No need to think about calibration and models, the way this works is simple numbers. You can either believe it, or be disappointed when you put a CRT next to the flat panel, or don't compare them and live in blissful ignorance (and with all the lights in the room off).

[Josh128]

Anyways, 8-Bit Squire has just released a video talking about the TINK4K using HDR and BFI to match a CRT, he was very pleased with the results and claimed his OLED was "just a little bit dimmer than the CRT":

He's being mild by saying "just a little bit." The difference is clear in the video and you can bet it's even more when seen in person.

No need to think about calibration and models, the way this works is simple numbers. You can either believe it, or be disappointed when you put a CRT next to the flat panel, or don't compare them and live in blissful ignorance (and with all the lights in the room off).

This is a display shortcoming more than the scaler, of course. I will add that this comparison is only valid on a true 15KHz CRT. The second you upscale and add faux scanlines to your 15KHz titles to display them on any display, even a 31KHz + CRT, you lose that huge brightness advantage for the CRT. Its a real thing, my 36" FD Trin Wega KV-36FS210 SDTV will burn my retinas in a lit room from about 5 to 6 feet away unless I turn down the brightness/picture/contrast, whereas the HS420 and XS955 are markedly dimmer when using an RT5X to upscale and add scanlines. If you dont add scanlines, you dont lose brightness, but you also wouldnt on an OLED or LCD either, except for the BFI mode. But BFI mode without faux scanlines will get you back a lot of lost brightness vs BFI + scanlines.

In any case, theres going to be tradeoffs using anything but a 15KHz CRT to play 15KHz games. Its my opinion that in the abscence of a CRT to game on, even as 240p/480p image quality snob, they are tradeoffs I could live with.

[tongshadow]

Anyways, 8-Bit Squire has just released a video talking about the TINK4K using HDR and BFI to match a CRT, he was very pleased with the results and claimed his OLED was "just a little bit dimmer than the CRT":

He's being mild by saying "just a little bit." The difference is clear in the video and you can bet it's even more when seen in person.

No need to think about calibration and models, the way this works is simple numbers. You can either believe it, or be disappointed when you put a CRT next to the flat panel, or don't compare them and live in blissful ignorance (and with all the lights in the room off).

Well, even John was impressed too:
https://twitter.com/dark1x/status/1686843392917954560

Sure, we can agree that masks and BFI lowers brightness by a lot in SDR, but in real HDR the dynamic must be completely different.

[bobrocks95]

Only disappointment with that video is not addressing that all 3 aren't possible. Displays adding BFI is typically quite laggy I thought, or am I wrong? If you use the Tink's BFI, you have to drop the resolution, and then lose scanline mask clarity. There's kind of trade-offs for all these options, unless I'm wrong.

[tongshadow]

Retrogaming on flat panels has always been about trade-offs after all.

[Guspaz]

Any/all BFI does require at least some amount of delay, since you need to scan out the frame twice as fast as it's received. Different implementations may add more or less lag though.

You do have to drop the resolution to do 120 Hz, though perhaps not as much as you'd think, depending on the content and display. For 4:3 content, you can drop to 2880x2160 without any scaling, so still full resolution, and as mentioned earlier that gets you up to ~90 Hz. To hit 120 Hz, we need to go a bit lower, true. Round about 2110x2160, maybe slightly higher with tighter timings. For 4:3 content, this results in around 73.3% of the resolution on one axis, and 100% of the resolution on the other axis. Which means the TV only needs to scale one axis (good for preserving scanline regularity), and their 4:3 setting is ideal for that. However, this is much better than dropping down to a generic 1440p120, where you drop down to 66.7% resolution on *both* axes and waste a bunch of your pixel clock on pillarboxing.

Caveats: your TV will need to accept such a resolution, and some TVs (like the LG C2 and C3, but not C1) add extra lag when you manually specify the aspect ratio.

tl;dr: you can always get more out of a scaler like the RT4K if you want to tune and optimize it for your exact use case.