OSSC (DIY video digitizer & scandoubler)

[H6rdc0re]

Shouldn't it be possible to do Line 4x with PSP? 1920x1088p

[Fudoh]

no framebuffer, so the OSSC can't actually "cut away" the empty area, it can only balance between active picture and front/back porch area. Even by tripling that you'd be looking at a 1440p signal already, which exceeds the OSSCs output capabilities.

[Gunstar]

I'm a bit confused, just wanting to make sure that this is the expected letterboxing for a PC CRT image when using the new PSP sampling mode:


Is the wiki talking from the perspective of a modern screen? i.e when it says filling the screen or zooming its the TV cutting off the 'overscan/full-frame' areas or something? the 960x540 mentioned here isn't the active area but the full-frame? apologies for not understanding this in advance!

In games, the 720x480 screen is letterboxed to produce a 480x272 active region. You therefore want to configure the OSSC to treat portions of the letterbox as offscreen, effectively "zooming" the image.

If you are running OSSC 0.86 or later (0.86 has not yet been released as of 2020-05-09), you can use the following settings to get a perfect 960x540 (540p) signal which completely fills the screen. One pixel is cut off from the top and bottom of the image.

[Unseen]

I'm a bit confused, just wanting to make sure that this is the expected letterboxing for a PC CRT image when using the new PSP sampling mode

Yes, a CRT cannot distinguish between the (massively increased) blanking area and a black border. A DVI/HDMI sink can tell the difference, so it can process just the much smaller active area in the center of the picture.

[Gunstar]

I'm a bit confused, just wanting to make sure that this is the expected letterboxing for a PC CRT image when using the new PSP sampling mode

Yes, a CRT cannot distinguish between the (massively increased) blanking area and a black border. A DVI/HDMI sink can tell the difference, so it can process just the much smaller active area in the center of the picture.

Thanks for the explanation, Unseen.

[headlesshobbs]

Doesn't the 5x mode have overscan? If so then why couldn't a similar logic be applied as a solution?

[H6rdc0re]

no framebuffer, so the OSSC can't actually "cut away" the empty area, it can only balance between active picture and front/back porch area. Even by tripling that you'd be looking at a 1440p signal already, which exceeds the OSSCs output capabilities.

Oh damn you're right it's a 720x480p signal.

[Gunstar]

Tried the new PSP sampling mode on a crappy LCD (no aspect ratio controls) and it works well.

[NormalFish]

anyone found settings that mitigate the psp's soft signal? Doesn't seem like someone's found a way to get the sort of razor sharp picture out of a PSP I'd hoped for.

[bobrocks95]

anyone found settings that mitigate the psp's soft signal? Doesn't seem like someone's found a way to get the sort of razor sharp picture out of a PSP I'd hoped for.

Absolutely not what you're looking for, but a modded PSTV does produce a very clean PSP image after you disable the bilinear filtering. It's (partial) emulation and not using real discs of course.

[NormalFish]

anyone found settings that mitigate the psp's soft signal? Doesn't seem like someone's found a way to get the sort of razor sharp picture out of a PSP I'd hoped for.

Absolutely not what you're looking for, but a modded PSTV does produce a very clean PSP image after you disable the bilinear filtering. It's (partial) emulation and not using real discs of course.

Yeah my vita is my go-to for PSP games, and I've been casually looking for a PSTV. It's definitely a good option. Just unfortunate how soft the original PSP is.

[whatamansion]

Anybody using the HD Retrovision cables with the OSSC? I've got a question about the HD Retrovision cables for anyone that uses them with with the NES and N64. I haven't received the cables yet, but I will soon. Which setting on the cable (the brightness switch) is the correct setting for the Tim Worthington NESRGB and his N64 RGB? Off or On?

[SAM]

Anybody using the HD Retrovision cables with the OSSC? I've got a question about the HD Retrovision cables for anyone that uses them with with the NES and N64. I haven't received the cables yet, but I will soon. Which setting on the cable (the brightness switch) is the correct setting for the Tim Worthington NESRGB and his N64 RGB? Off or On?

For HD Retrovision cables' solution, I think they are for dirrect connecting the console to your TV set. And by the way, I see no cables from HD Retrovision are for NES nor N64, what cables are you ordering from them?

I assume you are ordering the HD Retrovision SNES cable, as it is the only one able to plug into a N64. For the HD Retrovision SNES cable, I think they have a transcoder installed within the cable, as SNES could not output YPbPr Component.

Are you have yoru NES & N64 modded? If yes, you are using the wrong cables. You should use RGB cables when connecting to OSSC, as that is the best singal you could get from NESRGB & N64 RGB. I am not saying that you won't get an image on the screen with this setup, what I am saying is it is not nessary to transcode the RGB singal from your RGB modded consoles to YPbPr Component, before feeding it into the line doubler(OSSC).

[maxtherabbit]

Anybody using the HD Retrovision cables with the OSSC? I've got a question about the HD Retrovision cables for anyone that uses them with with the NES and N64. I haven't received the cables yet, but I will soon. Which setting on the cable (the brightness switch) is the correct setting for the Tim Worthington NESRGB and his N64 RGB? Off or On?

the switch should be on the brighter setting for N64 and 3-chip SNES

the dimmer setting is only for 1-CHIP

[whatamansion]

Anybody using the HD Retrovision cables with the OSSC? I've got a question about the HD Retrovision cables for anyone that uses them with with the NES and N64. I haven't received the cables yet, but I will soon. Which setting on the cable (the brightness switch) is the correct setting for the Tim Worthington NESRGB and his N64 RGB? Off or On?

For HD Retrovision cables' solution, I think they are for dirrect connecting the console to your TV set. And by the way, I see no cables from HD Retrovision are for NES nor N64, what cables are you ordering from them?

I assume you are ordering the HD Retrovision SNES cable, as it is the only one able to plug into a N64. For the HD Retrovision SNES cable, I think they have a transcoder installed within the cable, as SNES could not output YPbPr Component.

Are you have yoru NES & N64 modded? If yes, you are using the wrong cables. You should use RGB cables when connecting to OSSC, as that is the best singal you could get from NESRGB & N64 RGB. I am not saying that you won't get an image on the screen with this setup, what I am saying is it is not nessary to transcode the RGB singal from your RGB modded consoles to YPbPr Component, before feeding it into the line doubler(OSSC).

Yeah, it's the SNES HD Retrovision cable I'm talking about. My NESRGB has the multiout port and my N64 will work with them. I'm actually going to be running a 2 output setup with the gcompsw, one to the OSSC and one to my CRT (that has a component input).

I've been doing some reading up between people using the HD Retrovision component and Scart RGB and I found some videos. I honestly can't tell a difference (from what I've seen) between the two. Maybe there is, but at least from I've read and seen (videos below) it still looks as razor sharp as scart rgb.

Here's a FirebrandX video where he is using his NES with the HD Retrovision SNES cable on the OSSC: https://www.youtube.com/watch?v=foDjCoxLtEQ&t=739s

Here's another video of the Genesis using HD Retrovision on the OSSC: https://www.youtube.com/watch?v=S8-osPaw-PM&t=65s

Anybody using the HD Retrovision cables with the OSSC? I've got a question about the HD Retrovision cables for anyone that uses them with with the NES and N64. I haven't received the cables yet, but I will soon. Which setting on the cable (the brightness switch) is the correct setting for the Tim Worthington NESRGB and his N64 RGB? Off or On?

the switch should be on the brighter setting for N64 and 3-chip SNES

the dimmer setting is only for 1-CHIP

Awesome! Thanks. Do you know about the NES(RGB) too?

[maxtherabbit]

Awesome! Thanks. Do you know about the NES(RGB) too?

same deal as the others, "dim" setting is ONLY for 1-CHIP SNES

[eatnumber1]

anyone found settings that mitigate the psp's soft signal? Doesn't seem like someone's found a way to get the sort of razor sharp picture out of a PSP I'd hoped for.

What kind of display are you outputting it to? The new sampling mode and optimized line2x mode should be outputting "razor sharp" pixels, but since it's only 540p, many non-CRT TVs will soften things substantially as it upscales.

On my 4k display, the line2x mode is a substantial improvement. I still plan on taking a stab at getting line3x working too, but that's a lot more work as it requires adding some features that the OSSC doesn't have today (pixel multiplication without clock multiplication in particular).

Although I don't have one to test it, I'd expect that if someone has a 540p digital display (do those even exist?) you'll be able to get pixel perfect output.

[eatnumber1]

Shouldn't it be possible to do Line 4x with PSP? 1920x1088p

Unfortunately, no. The technique used here doesn't actually remove anything, it just shrinks what gets declared as the active region of the screen. The letterbox is still there, it's just not shown (by modern TVs, CRTs still show it).

To calculate what's possible, look at the actual total number of pixels per line, lines per frame, and frames per second, regardless of whether the pixels/lines are onscreen or not. That's 858 pixels per line, 525 lines per frame, and 59.94 frames per second. So the requisite pixel clock is 858*525*59.94 = 27MHz. Line2x mode is actually 2x horizontal and 2x vertical, so that's 858*525*59.94*2*2 = 107MHz.

The HDMI encoder chip can only run at a maximum of ~162MHz. Line4x is 858*525*59.94*4*4 = 432MHz, so is fully outside of what the encoder chip could ever possibly do.

Line3x however is interesting. 3x vertical and 3x horizontal is 858*525*59.94*3*3 = 243 MHz, so is still outside of what can be done, but 2x horizontal and 3x vertical is 858*525*59.94*3*2 = 162 MHz. That's not aspect ratio preserving though, but by doubling the horizontal letterbox, there's now so many pixels that are offscreen that we could in theory draw into the letterbox to achieve a 3x horizontal pixel multiplication factor with only a 2x horizontal pixel clock. OSSC does not support this kind of thing today however, hence why Line3x is possible, but a lot of additional work. I started poking at getting that working, but ran into bugs when running the OSSC at the edge of what it supports, so I spent a bunch of time optimizing the FPGA to work properly when doing line3x at 162 MHz. That's what the easily overlooked final bullet in the 0.86 release notes is about: "Optimizations to support higher pixel clock output."

[strayan]

"'d expect that if someone has a 540p digital display (do those even exist?) you'll be able to get pixel perfect output.

Yes, some Sharp Aquos displays were 960x540.

[Fudoh]

So is the Sony 7" PVM OLED, but I don't recall if it actually accepts this resolution.

[6t8k]

Re: GBI-hf 'gbihf-ossc' preset into OSSC Line3x 240x360 from the previous two pages:

Hmm, I got it to work by increasing Vsync threshold to 14.76 us.

One step above 14.76 worked for me, 14.76 was a bit shaky. Looks wonderful though, doing hdcustom with 360px3 and H. Samplerate at 302.

Thank you for further looking into this! I also experimented a bit and got RGBS over SCART to cooperate with my sinks:

- Analog sync Vth: 101mV
- Sampling phase: 315 deg

Video capture (160p test suite)

Furthermore, I have a Carby and a Portta HDMI-to-YPbPr DAC now, and was able to confirm that setting Vsync threshold to 14.76us makes the OSSC recognize the signal (setting sampling phase to 281 deg produces better results for me in this case): Video capture (160p test suite)

Note that YouTube only supports 4:2:0 chroma subsampling and re-encodes the video, so it's not as sharp as the live HDMI signal output by the OSSC / may show artifacts that are not present in the latter. The difference is especially noticable when looking at the 'color bleed' test's horizontal bars and checkerboard pattern in the YPbPr capture.

Lossless screenshots:

Spoiler

RGBS, whole frame (1920x1080)
YPbPr, whole frame (1920x1080)
RGBS, cropped (1440x960)
YPbPr, cropped (1440x960)

GBI version: 20200531
160p test suite version: v0.21
GCVideo-DVI firmware version: 3.0e
OSSC firmware version: 0.86a

Notes:
- This footage was recorded using --format=hd60 in GBI, --format=hdcustom works just as well with the same settings
- The Portta HDMI-to-YPbPr DAC I used looks like this
- Capture card: Magewell USB Capture HDMI Plus

[maxtherabbit]

speaking of GBI and 360p...

I haven't tested it since .84, but last I tried the OSSC wouldn't properly mode detect 360p over RGBHV, only on YPbPr

[RocketBelt]

But since you see your OSSC's input lock actually dropping, this is not your issue. Switching the OSSC's input sampling between VESA and DTV shouldn't change how the OSSC reacts to the signal. Not sure what's going on there. Maybe try the other available sync options.

Changing sampling rate actually can change things due to yet another issue with the video ADC. It requires HV sync to have sync edges closely aligned, and the distance apparently is counted in samples internally so smaller samplerate is more likely to meet the threshold requirement. I probably should try bypassing raw VSYNC to FPGA and do all detection and realignment there since the ADC's sync processing is not robust enough.

Just to update on this, I bought a new Dreamcast VGA cable off ebay to replace my old blaze vga box. With the new cable the OSSC DTV mode works perfectly.

[maxtherabbit]

speaking of GBI and 360p...

I haven't tested it since .84, but last I tried the OSSC wouldn't properly mode detect 360p over RGBHV, only on YPbPr

a followup on this now on the current FW - since the mode detect logic for specific resolutions seems to be tied to the physical input, I've also been having problems getting a 3dfx card in my PC to work using the AV3 alternate RGB setting

I've got a video matrix taking VGA from the voodoo card and feeding it to both AV2 and AV3. Enable AV3 alternate RGB on AV2 to allow me to run the noisy 3dfx card through the filter. All fine and good at 640x480 because I can force 480p in sampler to VESA 640x480. However when I run the voodoo2s in 800x600 or 1024x768 I cannot get them sampled anywhere near correct because the OSSC is mode detecting 1024x768 as 1080p and 800x600 as 576p. The LCD/OSD still correctly displays 806-p and 628-p, respectively, but when you go into the advanced timing section you can clearly see they are being sampled at the timings for 1080p and 576p.

The DOS text mode of 400p (449-p) is also having the same issue, the inverse of the problem with trying to use GBI over RGBHV. It's being sampled as 360p (384-p).

Seems like the mode detect logic needs a rework please marqs, since these PC (and GBI) modes are clearly distinguishable from their DTV counterparts by line count, it seems like there is no need to tie the logic to physical input anymore.

[marqs]

Seems like the mode detect logic needs a rework please marqs, since these PC (and GBI) modes are clearly distinguishable from their DTV counterparts by line count, it seems like there is no need to tie the logic to physical input anymore.

Certain mode presets are enabled only for certain physical inputs - the original idea was to prevent collisions with modes which have very similar line counts but are typically used with specific sources (e.g. PC via VGA input). For example, both 576p and 800x600_56 standards use 625 lines so there's no way to select the correct preset based on that information only. Nowadays the fw also considers refresh rate in these kind of cases when making the selection so the filtering based on physical inputs could be loosened or maybe even dropped altogether.

[maxtherabbit]

Seems like the mode detect logic needs a rework please marqs, since these PC (and GBI) modes are clearly distinguishable from their DTV counterparts by line count, it seems like there is no need to tie the logic to physical input anymore.

Certain mode presets are enabled only for certain physical inputs - the original idea was to prevent collisions with modes which have very similar line counts but are typically used with specific sources (e.g. PC via VGA input). For example, both 576p and 800x600_56 standards use 625 lines so there's no way to select the correct preset based on that information only. Nowadays the fw also considers refresh rate in these kind of cases when making the selection so the filtering based on physical inputs could be loosened or maybe even dropped altogether.

If it's feasible to drop it entirely I'd think that would be optimal. You never know what kinds of RGB interfaces or distribution HW people will want to stack up after all.

(totally forgot about the original 800x600p56 mode, been using 60Hz+ on it for so long)

[sofakng]

Can anybody explain the OSD display when using the Gamecube (GCDual) + Gameboy Interface (GBIHF) + OSSC?

Code: Select all

Prof.3  480x360
375-p*  450004

Prof.3 should indicate I'm using profile #3 (correct).

What does 480x360 mean? Is that the resolution coming from the GBI?

What does "375-p*" indicate?

I'm also a bit confused because I need to adjust 384p settings in the OSSC to adjust the image? (i.e. 384p -> Line3x 240x360) I think that's why the image isn't using the full screen either?

[nmalinoski]

Can anybody explain the OSD display when using the Gamecube (GCDual) + Gameboy Interface (GBIHF) + OSSC?

Code: Select all

Prof.3  480x360
375-p*  450004

Prof.3 should indicate I'm using profile #3 (correct).

What does 480x360 mean? Is that the resolution coming from the GBI?

What does "375-p*" indicate?

I'm also a bit confused because I need to adjust 384p settings in the OSSC to adjust the image? (i.e. 384p -> Line3x 240x360) I think that's why the image isn't using the full screen either?

The way it reads to me, 480x360 describes the video mode and visible line count (360), whereas the 375 describes the total line count, and 'p' for progressive. I'm not sure offhand which video proc menu applies to 360p video.

[maxtherabbit]

The 384 proc setting is sort of a catch all for medium res arcade, 400p pc modes and 360p

[6t8k]

Can anybody explain the OSD display [...]

Code: Select all

Prof.3  480x360
375-p*  450004

See also the Wiki (Basic usage -> Remote control -> INFO).
The * means that the OSSC has detected that the sync signal uses constant even field indicator (rather exotic characteristic that triggers some special processing inside the OSSC, because the video ADC chip, TVP7002, handles this poorly).