VoidScaler - a lagless line blending 15KHz downscaler firmware for OSSC

[e8root]

I am working on lagless downscaling firmware for OSSC with focus on enabling cheap and readily available 15KHz downscaling for modern HDMI HD-only consoles. Mostly focusing on pixelart games here with this project but both 480i and line blending is also supported for higher resolution games, watching videos, etc. It can also be used with PC and specifically for emulators it support refresh rates which are around 60Hz to match emulated systems.

Developed it on OSSC rev.1.8 and confirmed it to work on unmodified rev.1.6. Older/other models have to be tested. Just in case the bootloader code which is used to flash doesn't talk to I2C devices and LCD handling code only does writes on SPI bus so there should be good chance that in case of major incompatibilities the original firmware can be flashed back without needing JTAG dongle. That said this is an experimental custom written from scratch firmware tested on handful of devices (three in total, two of which are rev. 1.8 from the same company) so flashing it and especially untested hardware is on the flasher and not firmware provider. There is no warranty with such projects anyways.

Supported input method is for now only VGA RGBHV. Support for other inputs like Component might get added in the future.

For output HDMI to VGA or Component dongle can be used.
On HDMI to VGA DAC supported output modes are RGBS and RGBHV.
In the future I plan on adding RGsB, S-Video and Composite outputs. S-Video mode was already working as proof of concept on even the cheapest HDMI to VGA dongle I could buy but it needs some work after recent changes and will likely take some time until it is done. Composite will need proper filtering so might take even longer. It will be possible to output composite with HDMI to Component dongles. Otherwise for HDMI to VGA dongles cables needed will be the same as those for MISTer FPGA analog I/O board.

Of course OSSC has notoriously very little working memory so input lag even if I wanted it could not be implemented. In fact for most modes memory usage is so tight that even choosing least optimal settings they are as close to absolutely optimal for given scaling operation. This amounts to below 1ms of pure processing latency for 16:9 and below 5ms for 720p to 180p (letterboxed mode for 4:3 CRTs and 180p games). Lag is also only values I quoted for either top (in 720p) or bottom (1080p) of the screen with it going to almost zero at the other end.

Memory capacity also means some compromises had to be made. Pixel art games thankfully do not require that much where it comes to horizontal resolution and neither do most consumer CRT TVs. What I managed to squeeze is 1280 pixels luma/chroma for 720p to 240p/480i for 16:9 CRTs, 640 pixels luma, 320 pixels chroma for 720p for 4:3 CRTs (letterboxed mode or how I call it "180p mode"). Then 960 pixels luma, 450 pixels chroma for 1080p to 216p/432i for 216p games for 16:9 CRTs. This mode does not have line blending. There is also 1080p input mode which takes 1728x972 window out of 1080p and it displays as 1728 pixels luma and 864 pixels chroma. It is also for 16:9 CRTs. This is a bit more than more obvious 960p window but I wanted to be able to display full PS4/5 image after shrinking it with overscan compensation and 972p also just about fit to OSSC memory. It does not downscale to 240p but 243p and 486i just to be clear. This mode also does not have line blending... except that it does in a 2nd firmware which can be boot from bootloader. This second firmware lacks 720p to 180p mode due to memory layout/partitioning limitations.

Another hardware limitation and one of the most problematic ones was clock generation. It mostly affects 480i as it was not possible to get it to be perfectly in-spec. To mitigate this I added field calibration which for some of my CRTs give better results than proper 480i - fields can be aligned better. It does mean additional button mashing to get perfect field alignment. In the future this will be savable to SD card profiles and improving clock generation is not out of the books.

There are basic horizontal and limited vertical position controls and at least for now for only for 720p also fine aspect ratio adjustment which uses different pixel clock so does not introduce additional scaling artifacts. Also I added Rec.709 to SMPTE-C/EBU gamut correction. This needs proper testing and ideally ability to provide custom gamut correction values which feature is planned.

Currently there is no OSD and while I started working on it and have OSD rendering module done there is nothing to drive said OSD rendering module. Initialization and control is one giant state machine so writing proper OSD code might take a while.

Release... when exactly?
There is a lot of things I want to implement and perhaps some bugs to squash and technical improvements to be made but really after some time of using it myself playing pixelart games I think it is ready enough and should be just released ASAP.
In other words release will happen very soon. Maybe don't hold your breath just yet but just in case this sounds like something you would be interested in and don't yet have OSSC or cables this is a good time to order some and maybe also stack up on HDMI to VGA dongles.

EDIT//
Removed mention of Component output from HDMI to VGA DACs - technically not possible

EDIT2//
SDHC card is needed for flashing.
Generally please don't flash without having JTAG or accepting it might be needed to recover the device. This is experimental firmware.

[orange808]

Code repo link?

[PC Engine Fan X!]

Will your VoidScale support 15khz through Euro Scart protocol as well?

PC Engine Fan X! ^_~

[BuckoA51]

Nice, definitely one to watch and I will give this a go when it's ready.

[svcoco]

What a cool project. Will your firmware have a passthrough mode? That will allow to still use the ossc as a digitizer besides the downscaling.

[e8root]

Euro SCART RGB needs RGBS signals. RGBS output will be supported directly out of VGA port of HDMI to VGA dongles. SCART RGB cables are the same as OSSC Pro uses in Legacy AV Out add-on, MISTer FPGA with analog I/O board and RGB Emudriver.

Small correction to specs: Component output from VGA dongles is impossible. Found this out just yesterday when trying to implement it. Component actually uses negative voltages which are impossible from VGA DACs. Maybe some simple voltage biasing circuit could be made to shift Pb and Pr signals but directly in 'software' so to speak it seems not possible. Sync on Luma is not an issue henceforth neither is S-Video or Composite and this I already confirmed having POC NTSC signals. I didn't expect such issues with Comoponent considering it simpler hardware-wise than S-Video!

Regarding repo I will put binaries, documentation and later also the source code here https://github.com/e8root/voidscaler

Passthrough mode from all inputs is planned but it is deep inside backlog as it will require menu/OSD to even have ability to map configuration of large number of amplifier and sampling parameters and ideally also saving these settings to SD card. None of those features have been done yet. There is also no combined/composite sync decoding and it will be needed if output mode is to be consistent between downscaling and passthrough.

[RebeL9]

Sounds amazing.
A few questions:

1. Downscaling Wii’s 480p to 240p with this method isn’t possible but will it be possible in the future?
2. I have a HD fury 3, so I need another DAC as well to output HDMI to my CRT?
3. When will this be released?

[LDigital]

I really hope the line blend can be adapted for the pro soon. This is such an amazing feature it makes me want to go back to my old Ossc…. That I don’t have anymore

[fernan1234]

Also got rid of my OSSC classic assuming I'd never need it after getting a Pro...

I guess voidscaler itself may be portable to the Pro, but it would be even better if its features are simply included in the Pro fw

[SuperSpongo]

I watched the MarcoRetro video the other day and I am super hyped
I immediately thought it would be cool if we were able to set the active area so that we could use all those classic consoles on a 4:3 TV.
So basically cropping the 720p output left and right and only display the middle.

[etb]

I'm a software dev, beta testing available?

[BazookaBen]

Here's the rub with modern pixel art games: they run at all kinds of different internal resolutions.

Like I've seen 424x240, 427x240, 426x240, 416x240, 400x240, and so on and so forth. Not to mention 270p games like TMNT: Shredder's Revenge

On a PC running CRT Emudriver or Batocera directly outputting to a CRT TV or PVM, this is no problem, you set the resolution to match the game and it looks pixel perfect.

When downscaling from a console, you're going to need a lot of different output configurations not just to match these resolutions, but also to grab the correct pixel color from the input resolution and avoid grabbing an in-between pixel that's been bilinearly blurred or whatever.

[e8root]

Release is planned this Sunday.

If someone didn't see it yet MarcoRetro made a video about VoidScaler https://www.youtube.com/watch?v=G85hW3iibRk

[e8root]

Firmware released at https://github.com/e8root/voidscaler/re ... -dev021125

For now it is very rough and there is no navigable OSD, no menu, no sensible user messages, debug numbers are presented in hexadecimal format, no proper documentation, etc. Also there are some bugs, likely alignment issues with some settings, etc. Image control range is very limited, etc. etc.

Good news is that for the most common setup the firmware is pretty much plug and play. I mean HDMI to VGA DAC and RGBS cables which are the same as OSSC Pro with Legacy AV Out, MISTer FPGA with analog I/O board or RGB Emudriver. For VGA to BNC monitors normal VGA to 5xBNC cable can be used with HSync connected to Ext sync and VSync left unconnected.

Supported inputs:
- VGA in RGBHV mode - nothing more, nothing less

Supported outputs:
- RGBHV via HDMI to VGA DACs
- RGBS via HDMI to VGA DACs - default mode
- Component via HDMI to Component DACs - should be supported... at this time not tested

Button mapping reference:
- RED - progressive line blending (hold until LCD flickers for contrast adaptive blending)
- GREEN - progressive line decimation
- YELLOW - interlaced line blending (when blending available)
- BLUE - interlaced line decimation
- PIC - changes input/output aspect ratio
- BACK - chooses which lines use for line decimation/blending
- L/R - analogizer function
- UP/DOWN/LEFT/RIGHT - image centering
- OK - changes step size of image centering and field alignment for 480i
- << and >> - fine aspect ratio control (disabled for first build)
- + and - - ADC gain
- SAMP + and - - sampling phase
- MUTE - resets PLL, helpful for certain random issues
- |<< and >>| - field alignment for 480i
- POWER - turns backlight and green led off and on
- TWO ARROWS - change CSync combiner (0 - Type A (AND), 1 - Tybe B, 2 - placeholder for type C, 3 - XNOR)
- 0 - change 480i implementation (0 - hacked 240p, 1 - proper 480i)
- 3 - RGBHV output
- 6 - RGBS output

Regarding CSync combiner even though in theory Type B is more correct and it avoids slight sync issue at the top of the screen (should be invisible) I chose Type A as default as it is more compatible with various DACs (especially my HDMI to Component DACs cannot get any 480i with Type B or XNOR). XNOR is there because it is too simple to not add and because OSSC Pro uses it. No reasons to use XNOR sync combiner as Type B supersedes it and doesn't cause any sync curl issues or bad field alignment which XNOR causes on some CRTs. As for implementation of 480i on button 0 it shouldn't be really used. When it works as is does on some CRTs its main advantage is no short sync disruption when switching between 240p and 480i.

Bootloader
To enter bootloader hold second/right button when powering on the device. In bootloader there are only two things to do.
First is to use remote control and press either 1 or 2 to boot first or second firmware. Initial release doesn't have second firmware as I didn't have time to debug it for release. 2nd firmware has line blending in one of the 1080p modes and didn't have letterboxed 720p mode. In the future the intention is to combine these two firmwares in to single working solution.

Second and more important feature of bootloader is flashing the device.
SD card with OSSC compatible firmware (VoidScaler or original OSSC firmware) needs to be present when booting up bootloader and then to flash hold both buttons on the device and then press 10 on remote control. Buttons can be released the moment LCD backlight turns off. Device should automatically boot flashed firmware.

Please keep in mind this is at most beta software and I rushed this release to meet the deadline. In theory well tested but in practice I very recently changed a lot about clock generation to improve compatibility of 480i and improve general signal quality. This is also reason for missing fine aspect ratio control as all the clock settings need to be redone and now the correct clock take more effort to configure. On the other hand clock is pretty much perfect in the sense synchronization of output to input mode only really needs to happen once and modes won't ever desync - so how it should be.

Please report any issues and success stories. Especially when running it on older OSSC revisions than 1.6 as this is the oldest that VoidScaler was tested on.
Also please keep in mind before flashing VoidScaler on your device that issues can arise and especially with untested hardware. It is always best to have your USB Blaster JTAG dongle ready, just in case.

Known issues:
- Sometimes when switching to 240p part of the screen is missing in 240p. Changing almost anything e.g. to 480i and back or pressing mute fixes it usually and it doesn't happen in normal use but only when changing some settings This is a new issue, not sure what causes it. First thing I will check next week.
- When using analogizer function left/right crop changes between different settings and in 1080p also horizontal position.
- Slight blueish tint on left side in 720p letterboxed mode. Maybe some others.
- Digital devices report larger screen resolution than visible screen area.

[e8root]

Important fix here : https://github.com/e8root/voidscaler/re ... loader-fix
I removed previous release from git.

Changes:
To avoid issues with remote control bricking the device added way to flash using just buttons on OSSC itself.
To flash hold second button when powering the device and then hold both buttons for about ten seconds.


EDIT://
At this early stage perhaps best if only people with JTAG tested these early builds and especially if hardware is not OSSC 1.8 until operation is confirmed on given hardware revision/variant by others.

In case of issues - and these might happen or already happened - please get JTAG dongle. Official USB Blaster is guaranteed to work. Some cheap clones are known to have issues but might also work. I use USB Blaster clone ZL32PRG from KAMAMI and it works.

As for my setup it is Bitfunx OSSC rev. 1.8. VoidScaler was tested on two such devices and one OSSC rec. 1.6 of unknown maker.

Lastly where it comes to remote control - do note that it is programmable remote control and has different modes of operation and OSSC codes are mapped to "TV" preset.
If remote control doesn't do anything do report this as ir receiver might need reworking. I have written it from scratch so it might not be fully compatible yet. Also note if there is no reaction or if there is reaction like hexadecimal numbers showing up. I didn't check OSSC code to check if it has multiple codes built in and what these codes might be and instead I just noted codes from my own remote control.

[ackmangogo]

Amazing work.
Is possible to port to ossc pro?

[doonut]

compatible for OSSC DVI version?

[e8root]

New release https://github.com/e8root/voidscaler/re ... -dev051125
Mostly fix for wrong ir receiver setting which testing on real hardware did not catch and fix for last bootloader fix which had 50/50 chance to trigger and took too long to trigger anyways.
I also doubled TMDS clock and added option to revert it back. One of my HDMI to VGA DACs would have very slight cable dependent noise and one of my HDMI to Component DAC would have blue noise instead of pure black in some modes with low pixel clock. This change fixed these issues. On the other hand two out of three of my flat panels don't work with such high clock and OSSC Pro already had issues and with the change it seems just too much for it to decode the image.
I also added gamut correction. It needs actual validation that the coefficients were calculated correctly and the intention is to these coefficients to be user programmable.

Lastly the issue with image being some times cut. I had that issue with original firmware also and it seems IT6613 causes it. Not sure how to prevent it yet. Made some mitigations which seems to help but the issue still happens. I didn't see it happening in 480i. Also it never happened when I used imprecise clock and signal was out of specs. I am not even sure if happens on other OSSCs or maybe mine is broken. More testing is needed.

-------
OSSC Pro port will happen when I feel happy with the OSSC OG version. Don't want to split my attention too much at this time.

As for compatibility with some custom versions of OSSC - no idea. If it uses the same FPGA, same TVP7002 as input with the same amplifier settings, same IT6613 DVI/HDMI TX as output and all the relevant connections are the same it should work.
I could not find anything on OSSC DVI on google.

[RebeL9]

Does it downscale to 240p from 480p?

[Bahn Yuki]

Awesome project. As an owner of an Sony 34XBR960 hd crt, any chance of support for 33.75khz output? They are lag less in 540p/1080i. Currently using a Morph 4k to achieve this on my set via component input and it looks pretty good

[e8root]

Does it downscale to 240p from 480p?

Currently not. I am working on it.

Awesome project. As an owner of an Sony 34XBR960 hd crt, any chance of support for 33.75khz output? They are lag less in 540p/1080i. Currently using a Morph 4k to achieve this on my set via component input and it looks pretty good

Do you mean specifically 480p to 540p or some other resolutions?
720p/1080p to 540p should be possible due to timings of all these video modes being basically the same thus not need much buffering to convert between them - maybe a few lines of lag tops doing the conversion.

480p mapped to window in 540p frame to get 1:1 scaling is more tricky as it needs buffering and a lot of it. Not sure OSSC has enough memory for it. It can do 1728x972p window to 243p with chroma subsampling which means it obviously can do 1703x960 to 240p and 480p to 540p is similar enough, just here horizontal resolution would be smaller like 640 pixels but twice as many lines need to be buffered... napkin calculations look like it might be possible.
To know for sure I would need to try to implement it.

Two issues though
1) No 480p support yet and definitely no support for sampling exact pixels
2) I don't have such HD CRT... though if anything I could test on VGA monitor.

For now I focus on 15KHz and I also have OSSC Pro port to make.
It is however very interesting idea to support such conversion. I will think about it and maybe even better getting HD CRT.

[LDigital]

I can’t wait for this on the pro. Do you think it will be part of the current firmware from Marqs or an alternative firmware? The line blend with current pro feared would be the nivana

[jd213]

If possible, I'd love to see 15kHz output for the PSP. There's already a mode for cropping the 720x480p signal from a PSP to 480x272, but the OSSC still outputs it at 31kHz, even if one further reduces the V active to 240.

But awesome job regardless, I have a widescreen 15kHz consumer Trinitron that would be great for modern retro-style games, but haven't gotten around to getting a downscaler or setting up CRT Emudriver

[pelvicthrustman]

Just tested this using:
- StarTech HD2VGAA2 (HDMI to VGA Adapter) for input
- This 15KHz compatible HDMI to Component converter for output: https://www.amazon.com/dp/B074V57Y73 (I have not lag tested it, but it looks like a clone of the old Portta design)

I was able to get my Switch at 1080p to show up on my 480i only Trinitron (KD-27FS170), the only issues I had were:
- There are bizarre warping artifacts in the signal that show up on some but not all scanlines until I press '8' on the remote to reset the Pixel Clock which makes the picture perfectly stable
- About 75% of the time the picture is weirdly tinted when I start the OSSC (makes most things look yellow and yellow look blue) - when that happens I just power cycle the OSSC until the colors look normal

Other observations:
- While I can switch between 240p and 480i with no problem I honestly can not tell any difference between the decimation and blending settings (could be a me problem, I didn't test extensively)
- Changing settings too many times causes the whole thing to stop working, requiring a power cycle to fix

Pretty sure every issue I observed was called out in the release notes so nothing unexpected.

Overall looking great so far! Can't wait to test future updates.

[LDigital]

If possible, I'd love to see 15kHz output for the PSP. There's already a mode for cropping the 720x480p signal from a PSP to 480x272, but the OSSC still outputs it at 31kHz, even if one further reduces the V active to 240.

But awesome job regardless, I have a widescreen 15kHz consumer Trinitron that would be great for modern retro-style games, but haven't gotten around to getting a downscaler or setting up CRT Emudriver

PSP via component allows 15khz via component via the options. If you play ps1 games via this mode they are in 240p

[jd213]

Right, I'm more interested in getting PSP games at 240p though

[Bassa-Bassa]

272 into 240? And with h480 pixels? Doesn't sound particularly promising, does it?

[Bahn Yuki]

Does it downscale to 240p from 480p?

Currently not. I am working on it.

Awesome project. As an owner of an Sony 34XBR960 hd crt, any chance of support for 33.75khz output? They are lag less in 540p/1080i. Currently using a Morph 4k to achieve this on my set via component input and it looks pretty good

Do you mean specifically 480p to 540p or some other resolutions?
720p/1080p to 540p should be possible due to timings of all these video modes being basically the same thus not need much buffering to convert between them - maybe a few lines of lag tops doing the conversion.

480p mapped to window in 540p frame to get 1:1 scaling is more tricky as it needs buffering and a lot of it. Not sure OSSC has enough memory for it. It can do 1728x972p window to 243p with chroma subsampling which means it obviously can do 1703x960 to 240p and 480p to 540p is similar enough, just here horizontal resolution would be smaller like 640 pixels but twice as many lines need to be buffered... napkin calculations look like it might be possible.
To know for sure I would need to try to implement it.

Two issues though
1) No 480p support yet and definitely no support for sampling exact pixels
2) I don't have such HD CRT... though if anything I could test on VGA monitor.

For now I focus on 15KHz and I also have OSSC Pro port to make.
It is however very interesting idea to support such conversion. I will think about it and maybe even better getting HD CRT.

I was thinking something simple like 1080p to 540p. I currently do it with the pixel morph 4k and it works great. I can give you a modeline I get to show you what I mean.

[marqs]

Finally had a chance to try this FW (0.80-dev051125) and it's great to see the device has downscaling potential. I tested v1.3 and v1.8 boards and the firmware seemed to work on both although 1.3 had some stability issues and didn't sync with 720p input - not sure if it's the board or FW causing it. On v1.8 it was always possible to get into a working state after changing input resolution by hitting MUTE. Overall functionality seemed to work as described although I noticed BLUE key changed something (decimation/blending maybe) also on the second press of it. The only larger issue I had was firmware upgrade (tried 1.20 devel and 0.90) from bootloader which didn't complete on my either board. The operation was presumably started as the screen changed from the title to keycode display after some time and power cycling the device did result to it not loading any bitstream. The SD card used is an old and slow 2GB one.

Looking at size of the binary, I started wondering if it already includes 2 bitstreams (other for the bootloader?) or if bitstream compression was just disabled. As release of 1.20 mainline fw is approaching, having the VoidScaler firmware (even current version) in a single bitstream format if possible would soon enable loading it as 2nd FW without it needing upgrade capability to and would thus also make it safe for any user to try it.

[e8root]

My tests indicate 1080p is not entirely stable with these latest builds. Some bad boots and such can happen, random glitches from time to time. It was much more stable some time ago when there was less overall stuff in the pipeline. Some major reworking of the code will be needed unfortunately.
720p modes seems to work fine.

@marqs
SDHC card is needed. From what I understand of SD card protocol changed slightly between SD and SDHC and the version used is specifically designed for SDHC protocol. I never checked using different cards and so far testers also flashed their devices without any issues. I will need to check bootloader SD handling code and also reimplement missing checks. There are some but apparently not enough to prevent bad flashes.

With older OSSC revision not working - not sure why. Not sure what changed between different revisions to be honest. One tester had rev. 1.6 and it seemed to work fine. In this case I did check what changed and I don't use changed signals. For older revisions I tried to acquire older models for tests but they are rare and the prices online are exorbitant. Especially compared to brand new rev. 1.8. Will perhaps need to check what changed because maybe something did.

Where it comes to binary it is bigger than just two binaries because of the gap in the middle between firmwares. There was no need to pack them more tightly as bootloader skips flashing that part automatically. Next release I will also provide in the form of 2nd OSSC firmware and I guess its for rev.1.8 so it should be fairly compatible. I have not tested it yet. Firmware is below 300KB. Usually slightly below 270KB.

@LDigital
Definitely separate firmware.
Basically direct 1:1 port with some necessary for OG version 'features' disabled like all the subsampling. Maybe I will keep options for some subsampling modes like e.g. to make 216p games run at 384 pixels - which has yet to be implemented.

@jd213
To get full 240p from 272p window in 480p doesn't seem possible on OSSC OG. Too much memory needed. This includes any possible optimizations for color depth as PSP doesn't render games at 24-bit color. Simply too much buffering is needed in this case. Something like 180p (or a bit less to combat overscan) seems potentially feasible.

@Bahn Yuki
I see you use smaller visible area. Free-form scaling is not yet supported. Neither is 1080p to 540p.

Free-form scaling is not implemented because it isn't trivial and especially having to count each byte of memory. Also PS4/PS5 have their own scaling so for this purpose (also for PC in general) such feature would be redundant. PS3 doesn't have own scaling so I might consider implementing it.