OSSC Pro

[vol.2]

of course you can. And with a myriad of other processors as well. 480p to 540p just usually isn't very nice to look at. It makes more sense to pad the area to 540p instead and try to compensate by maxing out th overscan on the TV instead.

That's what I already do with a PC/Raspberry Pi and it works perfectly. You don't have to "max" out the overscan either, there is plenty of leeway.

What I'm looking for is a set-it-and-forget-it solution to producing the padded image for consoles. Would be nice if OSSC Pro had that built in.

It's worth noting that the only way to bypass the digital image processing in a Sony HDCRT is to input a digital signal.
There is a switch in the service menu to bypass the processing completely, but it has to be a digital signal because all analog signals follow a different signal path and get pre-processed into digital before going to the digital processing stage.

So, basically, it also has to be scaled and output via HDMI or DVI.

[Bahn Yuki]

of course you can. And with a myriad of other processors as well. 480p to 540p just usually isn't very nice to look at. It makes more sense to pad the area to 540p instead and try to compensate by maxing out th overscan on the TV instead.

That's what I already do with a PC/Raspberry Pi and it works perfectly. You don't have to "max" out the overscan either, there is plenty of leeway.

What I'm looking for is a set-it-and-forget-it solution to producing the padded image for consoles. Would be nice if OSSC Pro had that built in.

It's worth noting that the only way to bypass the digital image processing in a Sony HDCRT is to input a digital signal.
There is a switch in the service menu to bypass the processing completely, but it has to be a digital signal because all analog signals follow a different signal path and get pre-processed into digital before going to the digital processing stage.

So, basically, it also has to be scaled and output via HDMI or DVI.

My 34xbr960s(3 of them) don't have lag on component inputs when Sent 1080i.

Sent from my LM-Q710.FG using Tapatalk

[vol.2]

My 34xbr960s(3 of them) don't have lag on component inputs when Sent 1080i.

Did you enable HDPT in the service menu?

From what I understand, the analog all gets tossed into a analog-digital chip before it goes to the final stage because the rest of the chips (all the H/V stuff) operates digitally. I don't think that stuff would be particularly laggy, and if it's already 1080i, then it doesn't go on to the final DRC stage where the lag happens (this is all assuming you've turned on HDPT in the service menu).

Then again, I can't remember if I tried it and compared 1080i via the DVI and the Component. I suppose if you don't notice any difference, then it doesn't matter.

[Bahn Yuki]

My 34xbr960s(3 of them) don't have lag on component inputs when Sent 1080i.

Did you enable HDPT in the service menu?

From what I understand, the analog all gets tossed into a analog-digital chip before it goes to the final stage because the rest of the chips (all the H/V stuff) operates digitally. I don't think that stuff would be particularly laggy, and if it's already 1080i, then it doesn't go on to the final DRC stage where the lag happens (this is all assuming you've turned on HDPT in the service menu).

Then again, I can't remember if I tried it and compared 1080i via the DVI and the Component. I suppose if you don't notice any difference, then it doesn't matter.

I've measured the lag. The component 1080i seems a few microseconds faster than hdmi which is why I don't understand your claims of digital being faster than analog.

Sent from my LM-Q710.FG using Tapatalk

[Downcry]

My 34xbr960s(3 of them) don't have lag on component inputs when Sent 1080i.

Did you enable HDPT in the service menu?

From what I understand, the analog all gets tossed into a analog-digital chip before it goes to the final stage because the rest of the chips (all the H/V stuff) operates digitally. I don't think that stuff would be particularly laggy, and if it's already 1080i, then it doesn't go on to the final DRC stage where the lag happens (this is all assuming you've turned on HDPT in the service menu).

Then again, I can't remember if I tried it and compared 1080i via the DVI and the Component. I suppose if you don't notice any difference, then it doesn't matter.

I have an XBR960.

Oddly enough, it works the opposite of what you’d expect.
All non-component inputs are immediately converted to YPbPr (not YCbCr) before going anywhere.
So in some sense, the component inputs are less processed than HDMI inputs.

The HD Passthrough setting (HDPT=0) applies to any 33.75 kHz (1080i/540p) input; digital and analogue.
I’ve verified this using my Time Sleuth lag tester.

[Downcry]

My 34xbr960s(3 of them) don't have lag on component inputs when Sent 1080i.

Did you enable HDPT in the service menu?

From what I understand, the analog all gets tossed into a analog-digital chip before it goes to the final stage because the rest of the chips (all the H/V stuff) operates digitally. I don't think that stuff would be particularly laggy, and if it's already 1080i, then it doesn't go on to the final DRC stage where the lag happens (this is all assuming you've turned on HDPT in the service menu).

Then again, I can't remember if I tried it and compared 1080i via the DVI and the Component. I suppose if you don't notice any difference, then it doesn't matter.

I've measured the lag. The component 1080i seems a few microseconds faster than hdmi which is why I don't understand your claims of digital being faster than analog.

Sent from my LM-Q710.FG using Tapatalk

My components inputs also are several microseconds faster than my HDMI input, but I’d say it’s negligible.

[vol.2]

I've measured the lag. The component 1080i seems a few microseconds faster than hdmi which is why I don't understand your claims of digital being faster than analog.

Never made any lag claims or "faster" claims at all.

Oddly enough, it works the opposite of what you’d expect.
All non-component inputs are immediately converted to YPbPr (not YCbCr) before going anywhere.
So in some sense, the component inputs are less processed than HDMI inputs.

The HD Passthrough setting (HDPT=0) applies to any 33.75 kHz (1080i/540p) input; digital and analogue.
I’ve verified this using my Time Sleuth lag tester.

So, this is the block diagram for the 34xbr960. It calls out YCbCr, but the schematic has YPbPr, so that's confusing.

[Downcry]

I've measured the lag. The component 1080i seems a few microseconds faster than hdmi which is why I don't understand your claims of digital being faster than analog.

Never made any lag claims or "faster" claims at all.

Oddly enough, it works the opposite of what you’d expect.
All non-component inputs are immediately converted to YPbPr (not YCbCr) before going anywhere.
So in some sense, the component inputs are less processed than HDMI inputs.

The HD Passthrough setting (HDPT=0) applies to any 33.75 kHz (1080i/540p) input; digital and analogue.
I’ve verified this using my Time Sleuth lag tester.

So, this is the block diagram for the 34xbr960. It calls out YCbCr, but the schematic has YPbPr, so that's confusing.

Exactly right.
The block diagram was the first thing I saw, so I thought it was digital too, before looking at the actual schematic.

Probably just a typo or miscommunication within Sony.

[vol.2]

Exactly right.
The block diagram was the first thing I saw, so I thought it was digital too, before looking at the actual schematic.

Probably just a typo or miscommunication within Sony.

I'm not so sure about that. The first leg of it is analog component, but on the schematic, it enters CXA2171Q as YPbPr and exits as YCbCr, pins 25,26,27.

[marqs]

There's still possibility to increase the number of GPIOs although that would mean I have to free up some FPGA pins.

That's good to know, I hope doing that wouldn't create other inconveniences. Depending on whether operating multiple expansion modules simultaneously is an intended feature, it could still be favorable for a single module to consume as few GPIOs as possible.

The expansion port is now updated to 50 pins with the following pinout:



The port includes a number of fixed and configurable I/O:
* 2 dedicated outputs from clock generator
* 6 I/Os directly connected to FPGA (EXP_IO_A)
* 2x16 lines (EXP_IO_B) connected to FPGA via 2 level shifters (both dynamically configurable as input or output)
* Fixed I2S and SPDIF audio outputs
* I2C
* 5V and 3.3V supplies

The number of I/Os is now sufficient for FT602Q, and with the fixed audio outputs it's possible to design an expansion card with FT602Q plus SPDIF/analog audio outputs in case audio cannot be embedded into UVC stream.

[ASDR]

Since we're talking about the expansion connector again, could you maybe address how these expansions are going to look / work, physically?

The OSSC is probably my favorite modern retro gaming possession, so I was extremely excited about the OSSC Pro announcement, with the exception of the missing composite / S-Video support. That alone meant that I'd likely have at least one expansion for my future OSSC Pro. The original render of the PCB makes it look like any expansion would dangle precariously from the side of the device. That just seems like something waiting to be unplugged or snapped off. Would it be possible to relocate the expansion port to the back of the device and connect expansions over something flexible, IDE cable like? I'm just trying to imagine how this would end up working on the finished product.

I'm sorry if this has already been addressed or the details of this have already been changed.

[DiegoPonga]

I have been following the OSSC Pro for a while now, and it looks great. I have OSSC v1.6 and I absolutely love it!

The features I am most excited are HDMI support (for some RAD2X cables) and windowed 1080p signal (i.e., if you get a 4:3 960p game, the TV will believe it's a 16:9 1080p).

I am aware that 2160p is a bit crazy in terms of hardware. And I guess VRR is as well. Could a hipothetical super-expensive expansion board tackle this?

[marqs]

I am aware that 2160p is a bit crazy in terms of hardware. And I guess VRR is as well. Could a hipothetical super-expensive expansion board tackle this?

It'd be a bit pointless to design an expansion card that would end more expensive than the base system. I've found partial register/usage descriptions for SiI1136 which could theoretically replace the existing TX chip and enable pushing up to 300MHz, but that's still only half of the pixel clock required for 4:4:4 3840x2160@60Hz. At that point FPGA and PCB routing become another set of bottlenecks so asking for 4K is basically the same as asking to replace the already most expensive part with something of ~4x price and making development impossible for anyone who doesn't want to pay $5k for tools.

[vol.2]

How much flexibility does this "windowed" mode have?

Would you be able to send "windowed" 480p at 540p timings to an HDCRT in order to maintain the native 33.75kHz scan rate?

[strayan]

How much flexibility does this "windowed" mode have?

Would you be able to send "windowed" 480p at 540p timings to an HDCRT in order to maintain the native 33.75kHz scan rate?

I like what you’re thinking!

[marqs]

The original render of the PCB makes it look like any expansion would dangle precariously from the side of the device. That just seems like something waiting to be unplugged or snapped off. Would it be possible to relocate the expansion port to the back of the device and connect expansions over something flexible, IDE cable like? I'm just trying to imagine how this would end up working on the finished product.

I've thought about adding screw terminals on both sides of the connector which would provide a robust method for attaching expansion modules. They could be connected via a ribbon cable as well, but its length quickly starts to limit bandwidth of the expansion bus so that would work for low-performance peripherals only.

Would you be able to send "windowed" 480p at 540p timings to an HDCRT in order to maintain the native 33.75kHz scan rate?

Adaptive LM mode is already able to do such windowing, and scaler mode will eventually as well if more fancy processing is needed. BTW, what are the 540p timings - same as 1080i but without interlace?

[Downcry]

Would you be able to send "windowed" 480p at 540p timings to an HDCRT in order to maintain the native 33.75kHz scan rate?

Adaptive LM mode is already able to do such windowing, and scaler mode will eventually as well if more fancy processing is needed. BTW, what are the 540p timings - same as 1080i but without interlace?

540p isn’t an official standard, much the same as 240p.
I assume it would be best to match the 1080i timings as well as possible for best compatibility.

[vol.2]

BTW, what are the 540p timings - same as 1080i but without interlace?

540p is 960x540. As Downy said, it's similar to the 240p trick used by NES, etc. You can fool an HDCRT into displaying progressive 480p material by feeding it a progressive scan signal at a 1080i scan rate. The video chip isn't smart enough to know the difference. The issue is that it's not the right size image, so the 640x480 has to be centered in the screen, and then you stretch out the geometry. (for best results)

If you would be willing to have an "HDCRT" preset for scaling or something like that, I'm sure people would be willing to test for you. My HDCRT is in storage, but I'll have a chance to mess with it before the end of the year.

[Downcry]

BTW, what are the 540p timings - same as 1080i but without interlace?

540p is 960x540. As Downy said, it's similar to the 240p trick used by NES, etc...

Slight nitpick: If we’re talking digital interfaces (hdmi/dvi etc) it’s likely that devices will be picky about the pixel clock, so it will probably need to be 1920x540 to maintain the expected 74.25MHz.

I believe the total resolution including blanking would be 2200x563.

[strayan]

Might be a very niche use case, but 720p windowed in 768p could also be handy.

In my case windowed 720p in 768p is a perfect case! 1366x768 TV’s are super common. Line tripled 240p with scanlines every 3rd line looks outstanding (especially on a plasma)

FYI you can already do it with an Crestron HD scaler but it adds a few frames of lag.

[vol.2]

Slight nitpick: If we’re talking digital interfaces (hdmi/dvi etc) it’s likely that devices will be picky about the pixel clock, so it will probably need to be 1920x540 to maintain the expected 74.25MHz.

I believe the total resolution including blanking would be 2200x563.

What devices are you talking about?

Generally, the digital to analog devices I've used have happily synced much lower than that. (Extrons, Tendaks, etc)

Should be able to do CEA mode 8, 720x240p standard timings. Somthing like Modeline ("NTSC 720x240 (60Hz)" 13.820 720 744 809 880 240 244 247 262 -hsync -vsync)

Don't get me wrong though, I would love for there to be line-doubled "" line-tripled "" line-quadrupled "" and so on. I push 3850x240 typically out to a PVM and it's sharp as a tack.

[Downcry]

Slight nitpick: If we’re talking digital interfaces (hdmi/dvi etc) it’s likely that devices will be picky about the pixel clock, so it will probably need to be 1920x540 to maintain the expected 74.25MHz.

I believe the total resolution including blanking would be 2200x563.

What devices are you talking about?

Generally, the digital to analog devices I've used have happily synced much lower than that. (Extrons, Tendaks, etc)

Should be able to do CEA mode 8, 720x240p standard timings. Somthing like Modeline ("NTSC 720x240 (60Hz)" 13.820 720 744 809 880 240 244 247 262 -hsync -vsync)

Don't get me wrong though, I would love for there to be line-doubled "" line-tripled "" line-quadrupled "" and so on. I push 3850x240 typically out to a PVM and it's sharp as a tack.

The various LCD displays (monitors and TVs) I have with digital inputs don’t like 960x540 over hdmi.
It’s the same with my HDFurys, and various HDMI to YPbPr adapters.

They all have no problem with 1920x540.
I assumed it had to do with 960x540 having an oddball pixel clock of 37.125MHz.

I could be wrong, all I know is 74.25MHz over HDMI works on all my devices.

[ASDR]

The original render of the PCB makes it look like any expansion would dangle precariously from the side of the device. That just seems like something waiting to be unplugged or snapped off. Would it be possible to relocate the expansion port to the back of the device and connect expansions over something flexible, IDE cable like? I'm just trying to imagine how this would end up working on the finished product.

I've thought about adding screw terminals on both sides of the connector which would provide a robust method for attaching expansion modules. They could be connected via a ribbon cable as well, but its length quickly starts to limit bandwidth of the expansion bus so that would work for low-performance peripherals only.

Might be difficult to screw in a case, since the screws that go into the OSSC would be on the inside and the expansion PCB be in the way of your screwdriver?

I'm just thinking of pulling out my OSSC Pro from my AV rack with a few heavy cables dragging on both boxes. The way the main device and the expansion are side-by-side that just seems to put a lot of mechanical stress on the connection.

To me it seems maybe the nicest spot to fit an expansion module would just be on top of the main unit, possibly screwed in? (unless there are heat vents that would be blocked, I guess). Even if you can't move the expansion connector, a super short ribbon doing a 180 or a tiny PCB like this



could connect the two boards on the side when stacked on top of each other.

[vol.2]

The various LCD displays (monitors and TVs) I have with digital inputs don’t like 960x540 over hdmi.
It’s the same with my HDFurys, and various HDMI to YPbPr adapters.

I'm inferring that your concern is going from OSSC Pro->YPbPr to HDCRT.
I would have thought that the OSSC Pro would be capable of outputting in YPbPr itself?

Regardless, line-doubled and higher modes would all be welcome. I would insta-buy an OSSC Pro if I could just hook up my NESRGB and output a clean 3840x540 to my HDCRT with minimal other steps.

[Lawfer]

One question about "Line Multiplication", I know that 240p can be changed to 1600x1200 with the Line5x setting of the OSSC and that 480p can be changed to 1440x960 with the Line2x setting of the OSSC, but is there anything like that for 1024x768 or 1280x720?

[Konsolkongen]

The OSSC only does clean integer-scaling on the vertical axis, thankfully. You can use 3x mode to output 240p games in 720p.

[Lawfer]

The OSSC only does clean integer-scaling on the vertical axis, thankfully. You can use 3x mode to output 240p games in 720p.

I wasn't asking that, I was asking if the OSSC (or the upcoming OSSC Pro) has any "Line Multiplication" setting for 1024x768 and/or 1280x720. Meaning say if I have a 1280x720 output and use Line2x to change that, resulting in 2560x1440 or say if I have a 1024x768 output, change that with Line2x to 2048x1536.

[jandrogo]

The OSSC only does clean integer-scaling on the vertical axis, thankfully. You can use 3x mode to output 240p games in 720p.

It would be amazing if it can scale to 1440p, which means 240(x6),480(x3) and 720(x2) can be integer scaled.. and take advantage of high refresh rates of fancy new monitors

[orange808]

It would be amazing if it can scale to 1440p, which means 240(x6) ... can be integer scaled.. and take advantage of high refresh rates of fancy new monitors

How?

[H6rdc0re]

I am aware that 2160p is a bit crazy in terms of hardware. And I guess VRR is as well. Could a hipothetical super-expensive expansion board tackle this?

It'd be a bit pointless to design an expansion card that would end more expensive than the base system. I've found partial register/usage descriptions for SiI1136 which could theoretically replace the existing TX chip and enable pushing up to 300MHz, but that's still only half of the pixel clock required for 4:4:4 3840x2160@60Hz. At that point FPGA and PCB routing become another set of bottlenecks so asking for 4K is basically the same as asking to replace the already most expensive part with something of ~4x price and making development impossible for anyone who doesn't want to pay $5k for tools.

How about 2560x1440p @60Hz for 480p Line 3x and 240p Line 6x and/or 1920x1080p @120Hz?