OSSC Wolf Edition - Audio over HDMI

[Wolf_]

It has always been console related. Gaming monitors can accept basically any fps as long as it is a whole number and doesn't exceed their maximum input (not a problem as most consoles output 30-60 fps) so if you have a gaming monitor and use an ossc to get hdmi in at a whole number... it's compatible. Boom no more issues, end of story. And you would just have to tolerate a virtually imperceptible fraction of a frame per second of lag.

that's simply wrong - on so many levels that I can't even start. You make it sound as if you believe what you're writing. Please stop spreading misinformation like that.

a) monitors won't accept anything but a few standarized timings EXCEPT when they're driven by a GSYNC or Freesync GPU.
b) rendering fps are only rarely related to the output refresh rate (and NEVER on consoles).
c) what's that BS about integer fps ?
d) if you even try to framerate convert a hardware synced input signal by 0.1Hz you get VERY noticable and constant stutter.

a) Untrue. My display is a 40" 4k wasabi mango and has neither gsync or freesync and accepts whatever my gpu throws at it. As does my 27" asus monitor.
b) It is related because what I am saying is that gaming displays accept a wide variety of inputs, a lot more than displays marketed as "tvs".
c) The issue is with the hdmi standard not being as accepting of "non standard" inputs. If a tv has an issue with an input it is almost always because it is not a whole number, such as 59.9. I've never had an input that was a whole number 1-max get rejected from a console.
d) Untrue. Simply adding part of a single frame of delay to your display is imperceptible. For example the xrgb mini adds around 1.5 fps of lag and the incredibly vast majority of people can not tell at all.

[Unseen]

c) The issue is with the hdmi standard not being as accepting of "non standard" inputs. If a tv has an issue with an input it is almost always because it is not a whole number, such as 59.9. I've never had an input that was a whole number 1-max get rejected from a console.

59.9Hz (more precisely: 59.94Hz) is a standard frame rate and TVs shouldn't have any problem accepting it. I would expect major problems with 59.0Hz though.

d) Untrue. Simply adding part of a single frame of delay to your display is imperceptible. For example the xrgb mini adds around 1.5 fps of lag and the incredibly vast majority of people can not tell at all.

If you take a video signal at 59.9 Hz and process it to run at 59.0 Hz, you either need to slow it down (which is not viable for gaming purposes) or discard approximately one frame every second. This has nothing to do with delay.

[Fudoh]

a) Untrue. My display is a 40" 4k wasabi mango and has neither gsync or freesync and accepts whatever my gpu throws at it. As does my 27" asus monitor.

none of mine does. Can you demonstrate it using any non-PC source ? Or even using your PC ? I don't believe it. I'm assuming you're mixing up internal fps and external refresh rate again.

b) It is related because what I am saying is that gaming displays accept a wide variety of inputs, a lot more than displays marketed as "tvs".

how is it related when you have no technical possibility to get a console to output anything but it's standard refresh rate DESPITE it's internal rendering rate being much lower ?

c) The issue is with the hdmi standard not being as accepting of "non standard" inputs. If a tv has an issue with an input it is almost always because it is not a whole number, such as 59.9. I've never had an input that was a whole number 1-max get rejected from a console.

There is no console with a straight 60.00Hz output, is there ?

d) Untrue. Simply adding part of a single frame of delay to your display is imperceptible. For example the xrgb mini adds around 1.5 fps of lag and the incredibly vast majority of people can not tell at all.

lag (as in processing delay) is something completely different than "lag" (as in stutter created by a framerate conversion).

[Wolf_]

59.9Hz (more precisely: 59.94Hz) is a standard frame rate and TVs shouldn't have any problem accepting it. I would expect major problems with 59.0Hz though.

Both my displays have 59 fps come in on a regular basis and have no problem.

If you take a video signal at 59.9 Hz and process it to run at 59.0 Hz, you either need to slow it down (which is not viable for gaming purposes) or discard approximately one frame every second. This has nothing to do with delay.

What I was saying was that it will be delayed by .9 fps. So yes you would be throwing away roughly 1 fps to get a hdmi compliant input and in exchange you would have literally 0.9/60ths of a second to react to something. So you would have widespread compatibility and an imperceptible delay.

[Fudoh]

What I was saying was that it will be delayed by .9 fps. So yes you would be throwing away roughly 1 fps to get a hdmi compliant input and in exchange you would have literally 0.9/60ths of a second to react to something. So you would have widespread compatibility and an imperceptible delay.

oh, man, can you please stop it ? If you have no idea what you're talking about, please don't.

[Wolf_]

What I was saying was that it will be delayed by .9 fps. So yes you would be throwing away roughly 1 fps to get a hdmi compliant input and in exchange you would have literally 0.9/60ths of a second to react to something. So you would have widespread compatibility and an imperceptible delay.

oh, man, can you please stop it ? If you have no idea what you're talking about, please don't.

Kevtris managed to do it with the hi-def nes and analogue nt mini, except he did it by slowing down the game clock. Obviously not possible with an external device but his solution is lagless. This would simply be an option to trade a slight delay for hdmi compliance.

[Fudoh]

reclocking is always an option. You don't even need a flexible system like the Nt. Here it was easy since it's running on a software clock. For example: you can install a new crystal into a Neo Geo to get an output closer to NTSC specs. Not this uncommon.

Still, please demonstrate your monitor running at anything not near NTSC or VESA timings.

[Wolf_]

reclocking is always an option. You don't even need a flexible system like the Nt. Here it was easy since it's running on a software clock. For example: you can install a new crystal into a Neo Geo to get an output closer to NTSC specs. Not this uncommon.

Still, please demonstrate your monitor running at anything not near NTSC or VESA timings.

Most displays have no problem running off hdmi at whatever fps you can output. There are millions of youtube vids with fps counters so I see no reason to take the effort to demonstrate myself doing it.
https://youtu.be/WcrDhOxa-EQ

[Fudoh]

There are millions of youtube vids with fps counters so I see no reason to take the effort to demonstrate myself doing it.

and NONE of these have anything to do with the 60Hz connection between your PC and your monitor. Your monitor is running at 60Hz, doesn't matter if your games output at 30fps or 120fps.

[Xyga]

I have to say, although I don't have an explanation at all, that the latest two monitors I've tried have shown absolutely butter-smooth, judder-free scrollings with most anything I've fed them.
The HP 27xw did, and although I have yet to try many sources with it the Samsung S32F351 too apparently, the behaviour is similar (*will confirm more later)
For instance PAL MD2 switched to 60Hz is @59.36 by the OSSC, and seen as '59Hz' (their 59.94 mode?) by the two monitors.
Switching to 50Hz actual 49.69Hz is smooth too.
I don't have anything like an MVS to test sorry, and no functioning 15KHz emu setup at the moment.

My W6 definitely doesn't do this, nor the old LD450, and I have yet to see with the older Belinea 2080 S2.

[Unseen]

What I was saying was that it will be delayed by .9 fps. So yes you would be throwing away roughly 1 fps to get a hdmi compliant input and in exchange you would have literally 0.9/60ths of a second to react to something. So you would have widespread compatibility and an imperceptible delay.

Please describe your proposed frame-rate changing scheme in detail. Make sure to include an explanation how you manage to get a constant-time delay from a change in frequency (which is 1/time by definition).

[Woozle]

There is one big difference planned for this next revision. The 144 pin FPGA is switched to a 256 pin BGA. The additional pins will go to a connector or cardedge. This will create a OSSC dev board that allows daughter boards to be tried. If a daughter board is a success then it can be designed into the base later.
This seems like a smart direction because it gives a working base with the ability to prototype new ideas.

Sounds like a good idea, don't forget to route power to the expansion connector

Can't wait to see more progress.

[paulb_nl]

I have to say, although I don't have an explanation at all, that the latest two monitors I've tried have shown absolutely butter-smooth, judder-free scrollings with most anything I've fed them.

I have the same experience with my Sony W4000 TV. Even with GBI ull 59.72 or playstation 59.42Hz its still smooth. The Samsung 2494HM even has no issues with 53.20Hz for Mortal Kombat on Mame.

[Guspaz]

reclocking is always an option. You don't even need a flexible system like the Nt. Here it was easy since it's running on a software clock. For example: you can install a new crystal into a Neo Geo to get an output closer to NTSC specs. Not this uncommon.

Still, please demonstrate your monitor running at anything not near NTSC or VESA timings.

Most displays have no problem running off hdmi at whatever fps you can output. There are millions of youtube vids with fps counters so I see no reason to take the effort to demonstrate myself doing it.
https://youtu.be/WcrDhOxa-EQ

You've confused render framerate (how many times per second the GPU fills a framebuffer) with display framerate (how many times per second the framebuffer is sent to the display).

I can turn off vsync run some older games at 1000 FPS, but my display is still only going to show 60 of those 1000 frames. Worse, because I've turned off vsync, I'm not lined up to when the frames are being drawn, and I'm going to get lots of partial frames (maybe half one frame, half the previous one).

To convert between framerates that are not divisible, you need to drop frames (in the case of reducing the framerate, throw them away, skip them). This does not add any additional delay (beyond what the extra framebuffer adds), but it does mean that roughly once a second, the game will skip forward a bit since all of a sudden, twice as much in-game time will have passed between two frames as normal.

Look at it this way, say you want to convert from 5 FPS to 4 FPS. You have these frames:

12345

You would drop a frame and get this:

1245

Between frame 2 and 4, there is now a time jump. That is the judder that Fudoh is talking about.

[ZellSF]

There is no console with a straight 60.00Hz output, is there ?

The Xbox 360 is 60.00Hz.

[rtw]

I do not mean to derail this thread but there seems to be a lot of FPGA designers around here

What if we have a platform to experiment on ?

http://zedboard.org/product/zedboard

It has built in HDMI, audio and a very strong development platform through Vivado.

The SOC itself has 2xARM-A9 and a large FPGA. The development board is
not that cheap but it is already available. Xilinx have just started selling the 70xxS which
only has one core so it will be cheaper.

If the bitstream is loaded from QSPI and the software is XIP one can design the
board without any external memory since the SOC has on-chip-memory (256 KiB)!

In order to get the video signal in all one would need to do is to make a PMOD interface
board and connect it to the ZedBoard.

[orange808]

I can't get the displays​ I own to accept a flat 59kHz refresh. The window for "good" refresh rates is < ~ +-0.12kHz.

[Unseen]

It has built in HDMI, audio and a very strong development platform through Vivado.

The HDMI encoder on that board is a bit problematic, IIRC the only thing you can feed it is 4:2:2 YCbCr because only 16 data lines are connected and they are not chosen very well.

[Woozle]

I do not mean to derail this thread but there seems to be a lot of FPGA designers around here

What if we have a platform to experiment on ?

http://zedboard.org/product/zedboard

It has built in HDMI, audio and a very strong development platform through Vivado.

The SOC itself has 2xARM-A9 and a large FPGA. The development board is
not that cheap but it is already available. Xilinx have just started selling the 70xxS which
only has one core so it will be cheaper.

If the bitstream is loaded from QSPI and the software is XIP one can design the
board without any external memory since the SOC has on-chip-memory (256 KiB)!

In order to get the video signal in all one would need to do is to make a PMOD interface
board and connect it to the ZedBoard.

You could put some video ADCs on a daughter-card that plugs into the FMC port. I'm not sure how hard soldering an FMC connector would be, but it shouldn't be too hard with an oven. I'm just not a big fan of PMOD.

XADC could potentially handle the audio, since IO is a bit of a premium.

I think something like the new Pynq board http://store.digilentinc.com/pynq-z1-py ... -for-zynq/ could be helpful in the chain after an OSSC to do things which require a frame buffer. The OSSC handles digitization (no scaling) and passes it to the Pynq which can use its DRAM to buffer a frame if need be, for things like rotation or fancier scaling. Pretty sure the Artix FPGA can hit 1080p HDMI if you overclock it a bit. Has 630KB BRAM and 512MB DRAM, if purchased with an academic discount (not easy) it's only $65.

I'm getting a Pynq on academic discount for a computer vision course in the Fall, so I'll have one on hand to mess around with.

[austin532]

Not trying to be rude but instead of worrying about what to add on to it and how to do it, why not just make it the way it was intended first and then make revisions in the future if needed? Having the ports on the back plus audio over HDMI out is already a big plus. Marq's OSSC is already hard enough to get so the more OSSC's we can get out to the people who want them the better.

[becker]

I have been working on making a dev board OSSC. It has the three main IC and HDMI out connector. The fpga is a 256 pin Cyclone IV. There is a 98 pin PCIE connector on the edge. The edge has all the analog inputs to the encoder and around 40 lines to the fpga. Hopefully this gives enough options to try different daughter board combos. I did this because it was too risky to develop untested circuits into a complete board. I will have more details as a get closer to layout.

[Woozle]

At least for my comments, they were directed at developing new features that require hardware not on the OSSC (or things which are too expensive to prototype hardware Willy nilly without working firmware. Things like dram, high density BGA).

I have been working on making a dev board OSSC. It has the three main IC and HDMI out connector. The fpga is a 256 pin Cyclone IV. There is a 98 pin PCIE connector on the edge. The edge has all the analog inputs to the encoder and around 40 lines to the fpga. Hopefully this gives enough options to try different daughter board combos. I did this because it was too risky to develop untested circuits into a complete board. I will have more details as a get closer to layout.

That sounds great. Any idea when you'll get around to ordering boards and verifying functionality?

[rtw]

You could put some video ADCs on a daughter-card that plugs into the FMC port. I'm not sure how hard soldering an FMC connector would be, but it shouldn't be too hard with an oven. I'm just not a big fan of PMOD.

XADC could potentially handle the audio, since IO is a bit of a premium.

I think something like the new Pynq board http://store.digilentinc.com/pynq-z1-py ... -for-zynq/ could be helpful in the chain after an OSSC to do things which require a frame buffer. The OSSC handles digitization (no scaling) and passes it to the Pynq which can use its DRAM to buffer a frame if need be, for things like rotation or fancier scaling. Pretty sure the Artix FPGA can hit 1080p HDMI if you overclock it a bit. Has 630KB BRAM and 512MB DRAM, if purchased with an academic discount (not easy) it's only $65.

I'm getting a Pynq on academic discount for a computer vision course in the Fall, so I'll have one on hand to mess around with.

Pretty sure that soldering an FMC is not trivial and IIRC the ZedBoard does not export all the hi-speed AXI busses.

Can you explain why you don't like PMOD ?

Good idea with using the XADC

And thanks for the link on the PYNQ, even without discount it's a lot cheaper than the ZedBoard.

[Woozle]

Pretty sure that soldering an FMC is not trivial and IIRC the ZedBoard does not export all the hi-speed AXI busses.

Can you explain why you don't like PMOD ?

Good idea with using the XADC

And thanks for the link on the PYNQ, even without discount it's a lot cheaper than the ZedBoard.

I have a pretty good reflow oven that I made a while back, figured an FMC wouldn't be hard with that. There's also FMC breakout cards, they're overpriced but still an option. The low pin count FMC (on the zed board) still gives you access to a lot of good IO. But with unseen's comment in mind, the zed board might not be a good idea since both the vga and hdmi output are limited in some way.

I generally don't pmod because, (1) you only get a handful of oddly placed insecure header connections, (not all are connected to fpga logic), (2) some have series resistors, limiting input frequency to 10Mhz in some cases, (3) out of the few pmods you get, some are meant for differential signals, so using them for single-ended signals could introduce crosstalk, (4) Not a huge deal, but you only get a small amount if any clock capable input pins.

Maybe I'm being too hard on PMODs, but I just always find them a pain in the ass.

The pynq is cool because it can be run Python with fpga accelerated functions. So setting up an hdmi input into a frame buffer would be a couple lines of Python code.

[rtw]

I have a pretty good reflow oven that I made a while back, figured an FMC wouldn't be hard with that. There's also FMC breakout cards, they're overpriced but still an option. The low pin count FMC (on the zed board) still gives you access to a lot of good IO. But with unseen's comment in mind, the zed board might not be a good idea since both the vga and hdmi output are limited in some way.

I generally don't pmod because, (1) you only get a handful of oddly placed insecure header connections, (not all are connected to fpga logic), (2) some have series resistors, limiting input frequency to 10Mhz in some cases, (3) out of the few pmods you get, some are meant for differential signals, so using them for single-ended signals could introduce crosstalk, (4) Not a huge deal, but you only get a small amount if any clock capable input pins.

Maybe I'm being too hard on PMODs, but I just always find them a pain in the ass.

The pynq is cool because it can be run Python with fpga accelerated functions. So setting up an hdmi input into a frame buffer would be a couple lines of Python code.

FMCs should be doable with an reflow oven but not everyone has one
The FMC breakout boards are nice but as you pointed out very expensive.

Thank you for the clarification on PMODs!

The Python angle looks cool and if they can create optimized functions in fabric by the flick of a switch (HLS) we have a very powerful platform.

[becker]

Has anyone used DDR2 memory with an Altera fpga? I'm confused how to hook it up. There are two groups of DQ pins on opposite sides of the chip. Each group has 16 pins. Do I use both groups or just one? Which signals use the specialed DQ pins?
I looked at the schematic of a DE2 dev board and I don't see a pattern to pin choices. They are using a much larger fpga so it's not as simple as hooking it up the same as them. Most signal go to regular pins.
RAM is interesting if there is room. I keep abandoning the idea because it's unclear how to implement properly. I thought if the pads are there maybe it can be figured out later.
I am using Cyclone IV E with 256 pins.

[marqs]

DE10-Standard should also be a good candidate with on-board cvbs input and 24bit VGA DAC.

Has anyone used DDR2 memory with an Altera fpga? I'm confused how to hook it up. There are two groups of DQ pins on opposite sides of the chip. Each group has 16 pins. Do I use both groups or just one? Which signals use the specialed DQ pins?
I looked at the schematic of a DE2 dev board and I don't see a pattern to pin choices. They are using a much larger fpga so it's not as simple as hooking it up the same as them. Most signal go to regular pins.
RAM is interesting if there is room. I keep abandoning the idea because it's unclear how to implement properly. I thought if the pads are there maybe it can be figured out later.
I am using Cyclone IV E with 256 pins.

Have you considered using SRAM instead of DRAM? It's pricier than DRAM (especially at high-speed/capacity) but much easier to interface.

[becker]

DE10-Standard should also be a good candidate with on-board cvbs input and 24bit VGA DAC.

Has anyone used DDR2 memory with an Altera fpga? I'm confused how to hook it up. There are two groups of DQ pins on opposite sides of the chip. Each group has 16 pins. Do I use both groups or just one? Which signals use the specialed DQ pins?
I looked at the schematic of a DE2 dev board and I don't see a pattern to pin choices. They are using a much larger fpga so it's not as simple as hooking it up the same as them. Most signal go to regular pins.
RAM is interesting if there is room. I keep abandoning the idea because it's unclear how to implement properly. I thought if the pads are there maybe it can be figured out later.
I am using Cyclone IV E with 256 pins.

Have you considered using SRAM instead of DRAM? It's pricier than DRAM (especially at high-speed/capacity) but much easier to interface.

Hi Marqs. Do you have an SRAM to recommend? I am not sure what to look for. I found CY62167EV30 which is 16Mbit. I'm not sure it is enough. Simple math of 1920*1080*8bit color is 16.5M. I do not know if that is even how it works to buffer one frame.

[kardus]

Put me down! Great work

[becker]

I found IS66WVH8M8ALL-166B1LI
SRAM 64Mb 8Mbx8 1.8V 166MHz HyperRAM
It seems different from the rest. It is cheaper and has less pins. It looks easy to hook up and the price is good. Will this work as a frame buffer?