OSSC Wolf Edition - Audio over HDMI

[Unseen]

I found IS66WVH8M8ALL-166B1LI
SRAM 64Mb 8Mbx8 1.8V 166MHz HyperRAM
It seems different from the rest.

It appears to have a really weird interface - I would probably use an SDRAM instead.

[becker]

It looks like Cypress made a series called HyperRAM.
http://www.cypress.com/products/hyperram-memory

I submitted a request for the HyperBus Master Interface Controller IP.
This looks like the ideal solution to add RAM to a FPGA.

ISSI seems to have something similar.
http://www.issi.com/US/product-cellular-ram.shtml

I will move forward with the Cypress version because it has the Verilog core available.

[marqs]

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?

That has only 8-bit interface, is single-port and can barely hold one 1080p frame. Depending what you plan on doing with the buffer, you might want min. 24bit-wide interface, dual port and around 128Mbit capacity. High speed and DDR are another way to fulfill bandwidth requirements (saving FPGA pins as well) if suitable wide dual port memories are not available.

[lechu]

This is a really awesome project. It looks great so far. If I didn't already have my OSSC, I'd hop onto this.

Bit off topic. This is the first time I've seen an alternate version of the OSSC. I was wondering if it would be possible to make a version without SCART. Component, and VGA inputs. Rather just have one set of RGBHV BNC inputs, with stereo and SPDIF audio in, with hdmi out. The BNC can carry all the signals capable from the OSSC. I'm not an engineer or anything, so I could be completely wrong on this. But in theory, wouldn't this version have a less complex circuit board and could potentially be cheaper than the OSSC we currently have? Sure it would only have on set of inputs. But for those of us who just want to use SCART cables, that would be all you need. Or it would be nice for those who have either an Extron switcher or video out BNC ports from a PVM. Hell, you could just use 7 RCA ports (RGBHV LR) to take up less space and make a compact OSSC Lite.

Got really off track there. But yeah. I was just wondering if something like this is feasible?

[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?

That has only 8-bit interface, is single-port and can barely hold one 1080p frame. Depending what you plan on doing with the buffer, you might want min. 24bit-wide interface, dual port and around 128Mbit capacity. High speed and DDR are another way to fulfill bandwidth requirements (saving FPGA pins as well) if suitable wide dual port memories are not available.

I think I will leave memory off for now. It is obvious that I do not know enough about it.
I was hoping to have it available if needed. I thought it could help with systems that have unusual sync. I also thought it could rotate the image for vertical shooter arcades.

This is a really awesome project. It looks great so far. If I didn't already have my OSSC, I'd hop onto this.

Bit off topic. This is the first time I've seen an alternate version of the OSSC. I was wondering if it would be possible to make a version without SCART. Component, and VGA inputs. Rather just have one set of RGBHV BNC inputs, with stereo and SPDIF audio in, with hdmi out. The BNC can carry all the signals capable from the OSSC. I'm not an engineer or anything, so I could be completely wrong on this. But in theory, wouldn't this version have a less complex circuit board and could potentially be cheaper than the OSSC we currently have? Sure it would only have on set of inputs. But for those of us who just want to use SCART cables, that would be all you need. Or it would be nice for those who have either an Extron switcher or video out BNC ports from a PVM. Hell, you could just use 7 RCA ports (RGBHV LR) to take up less space and make a compact OSSC Lite.

Got really off track there. But yeah. I was just wondering if something like this is feasible?

It is possible. It is just using a different shape connectors to bring signals in. The dev board I am working on would make this easy to do as a daughtercard.

[JDH]

I have only one question (Please be yes, please be yes!) I did a search and couldn't find anything relating to that, so apologies if it's been answered previously.

Will the OSSC Wolf Edition support "zooming" of the image? This has been the only thing missing from the OSSC experience thus far (besides integrated HDMI) I am not interested in having yet another box (DVDO) just for this purpose.

I think a lot of people interested in the OSSC end up going to the Framemeister simply because of that. Hopefully becker can shed some light on that.

[becker]

I have only one question (Please be yes, please be yes!) I did a search and couldn't find anything relating to that, so apologies if it's been answered previously.

Will the OSSC Wolf Edition support "zooming" of the image? This has been the only thing missing from the OSSC experience thus far (besides integrated HDMI) I am not interested in having yet another box (DVDO) just for this purpose.

I think a lot of people interested in the OSSC end up going to the Framemeister simply because of that. Hopefully becker can shed some light on that.

Sorry, I do not know the answer to what it takes to do a zoom. I have been trying to create an OSSC with DDR2 memory. Even if I create a board that has the RAM, it still requires programming to take advantage of it. I have been trying to learn as much as I can but ultimately I will not know enough to do it myself. I have spent hours in Quartus seeing if I could compile changed firmware. The rabbit hole on this stuff keeps going deeper. I am not even sure if adding memory is the only thing needed to give it the ability to do a frame buffer and image manipulation. Marqs and Borti are knowledgeable about the abilities of the OSSC. Borti mentioned a Cyclone V SoC would take care of a lot of limitations. I looked into it but I got scared because of the added unknowns and complexity. I felt it was too easy and too expensive to get wrong.
The board I am designing currently has the FPGA model EP4CE15F17C8N. It is the same specs as the regular OSSC but with more pins. This project has been a learning experience for me. I have done many board layouts but I have not done a project like this where I try to learn the firmware.

[Link83]

-Added a buffer to the VGA input (THS7327). The buffer has a LPF (low pass filter), adjustable schmitt triggers, and ESD (static shock) protection for the VGA port.

Just curious if the I2C pins on the THS7327 are connected to the FPGA to allow the LPF to be adjusted, like the THS7353?
Also, is CVBS/CSYNC from the SCART connection also buffered?

Borti mentioned a Cyclone V SoC would take care of a lot of limitations. I looked into it but I got scared because of the added unknowns and complexity. I felt it was too easy and too expensive to get wrong.

Would the Cylcone V potentially allow for a frame buffer? If so perhaps this is a case of "If you build it, they will come"
I realise it would be a difficult project, but given the potential I think it would be worth it (and I doubt theres many people better qualified to design an OSSC with a Cyclone V than an actual PCB designer!)

[marqs]

Just curious if the I2C pins on the THS7327 are connected to the FPGA to allow the LPF to be adjusted, like the THS7353?
Also, is CVBS/CSYNC from the SCART connection also buffered?

I think THS7327 must have I2C connected to even enable its output.

Would the Cylcone V potentially allow for a frame buffer? If so perhaps this is a case of "If you build it, they will come"
I realise it would be a difficult project, but given the potential I think it would be worth it (and I doubt theres many people better qualified to design an OSSC with a Cyclone V than an actual PCB designer!)

Cyclone V certainly has some nice properties, like 28nm process (faster, lower power than 65nm Cyclone IV), optional hard ARM core and 3/6 Gbps transceivers (could be used to drive HDMI directly). It doesn't have enough block RAM in itself for frame buffer so external memory would be still needed for that.

[Link83]

Thanks for the reply marqs

Just curious if the I2C pins on the THS7327 are connected to the FPGA to allow the LPF to be adjusted, like the THS7353?
Also, is CVBS/CSYNC from the SCART connection also buffered?

I think THS7327 must have I2C connected to even enable its output.

Ah I see. I'm still curious if the SCART input pin 20 (CVBS/CSYNC) is buffered/protected? Especially since its the signal most likely to be accidentally connected to VCC due to a number of PAL consoles replacing C-Sync with 9-12V for SCART switching.

Would the Cylcone V potentially allow for a frame buffer? If so perhaps this is a case of "If you build it, they will come"
I realise it would be a difficult project, but given the potential I think it would be worth it (and I doubt theres many people better qualified to design an OSSC with a Cyclone V than an actual PCB designer!)

Cyclone V certainly has some nice properties, like 28nm process (faster, lower power than 65nm Cyclone IV), optional hard ARM core and 3/6 Gbps transceivers (could be used to drive HDMI directly). It doesn't have enough block RAM in itself for frame buffer so external memory would be still needed for that.

Assuming the UltraHDMI has a frame buffer, from looking at the board here:-
https://circuit-board.de/forum/index.ph ... -1635-JPG/
It uses an Alliance Memory 256Mb DDR SDRAM "AS4C16M16MD1-6BCN" connected to a Cyclone III:-
http://www.alliancememory.com/pdf/mobil ... e-v1.1.pdf
Would this be the correct model/type of RAM we would need for a frame buffer on the OSSC?

[becker]

SCART pin 20 connects to a Sync on Green pin of the TVP7002 video encoder. It has a 1nF capacitor in series. There is also a 75 ohm pull down resistor. It does not have a buffer.

[Link83]

SCART pin 20 connects to a Sync on Green pin of the TVP7002 video encoder. It has a 1nF capacitor in series. There is also a 75 ohm pull down resistor. It does not have a buffer.

Since the THS7327 has two RGBHV inputs, would it be worth moving the SCART input over to the THS7327? That way C-Sync could also be buffered. For example:-
THS7327 = SCART (RGBs) and VGA (RGBHV)
THS7353 = Component (YPbPr) and Composite/S-Video if required?

[becker]

SCART pin 20 connects to a Sync on Green pin of the TVP7002 video encoder. It has a 1nF capacitor in series. There is also a 75 ohm pull down resistor. It does not have a buffer.

Since the THS7327 has two RGBHV inputs, would it be worth moving the SCART input over to the THS7327? That way C-Sync could also be buffered. For example:-
THS7327 = SCART (RGBs) and VGA (RGBHV)
THS7353 = Component (YPbPr) and Composite/S-Video if required?

It is an interesting idea. I'm not sure it works like that. The horizontal sync and vertical sync inputs of the THS7327 might not accept composite sync. Marqs will probably know the answer.
I took the THS7327 off the first daughter card schematic because I didn't know if I could figure out how to add it to the firmware. It is also a more pricy solution than using a second THS7353. I planned to make it a separate daughter card to try it out.
I haven't had much time to do anything. Everything is still a schematic. The layout is not started but I have all the footprints. I spend a lot of time trying add things like DDR2 and FTDI chip on a USB connector. Then I remove then because I am not 100% certain it's connected properly. The FTDI I wanted so people didn't have to by the USB Blaster programmer.

[Wolf_]

SCART pin 20 connects to a Sync on Green pin of the TVP7002 video encoder. It has a 1nF capacitor in series. There is also a 75 ohm pull down resistor. It does not have a buffer.

Since the THS7327 has two RGBHV inputs, would it be worth moving the SCART input over to the THS7327? That way C-Sync could also be buffered. For example:-
THS7327 = SCART (RGBs) and VGA (RGBHV)
THS7353 = Component (YPbPr) and Composite/S-Video if required?

It is an interesting idea. I'm not sure it works like that. The horizontal sync and vertical sync inputs of the THS7327 might not accept composite sync. Marqs will probably know the answer.
I took the THS7327 off the first daughter card schematic because I didn't know if I could figure out how to add it to the firmware. It is also a more pricy solution than using a second THS7353. I planned to make it a separate daughter card to try it out.
I haven't had much time to do anything. Everything is still a schematic. The layout is not started but I have all the footprints. I spend a lot of time trying add things like DDR2 and FTDI chip on a USB connector. Then I remove then because I am not 100% certain it's connected properly. The FTDI I wanted so people didn't have to by the USB Blaster programmer.

An easy to perform method to update at home does sound great but I thought it could be updated via sd card?

[becker]

An easy to perform method to update at home does sound great but I thought it could be updated via sd card?

You are correct. It will also have the SD card connector for updating firmware.
It was just an idea for a dev kit version. I thought having it connected to a computer with usb would be convenient when trying to figure out daughter card firmware.

[Seraphic]

becker, have you had any success integrating Optical Toslink input onto your prototype?

[becker]

becker, have you had any success integrating Optical Toslink input onto your prototype?

SPDIF is definitely something I want in the final design. It will start on a daughter card to make sure the circuit works.
Everything is just a schematic right now. I made one prototype but it was a dud fab so I couldn't learn much from it. The layout is being redone from scratch. I didn't like several choices I made with the first prototype so I am proceeding to a new design.
The idea is to try new features with daughter cards. When I'm happy with a set of features it be made into a single board.

[Seraphic]

Any updates on the OSSC Wolf Edition?

[becker]

Any updates on the OSSC Wolf Edition?

Progress has been slow. I do not get to work on it very much. Some weeks I don't even get to turn my computer on.
I also keep changing my mind about how I want to do the next revision. I am trying to be cautious and give myself a number of outs so I don't get stuck by any one mistake or decision.
Right now the FPGA is changed a 256 pin BGA version which means all the pins are underneath. I will not be able to get to the pins after it is soldered down. I am having most escape to connectors so various things can be tried. The change from a 144 pin to a 256 pin will give options for more devices like a component video decoder. The original OSSC is heavily optimized and did not have unused pins for additional hardware.
I am excited to see Marqs has changed the HDMI TX to an ADV7513 on his CPSII board. The original OSSC has an IT6613E which is a great chip but it can only be bought from faceless Alibaba stores. The ADV7513 is carried by normal distributors like Digikey and Mouser. The HDMI TX was the only chip that was not carried by distributors and it just made things more complicated. As far as performance, I do not think there will be much difference. Both chips work, one is just easier to source. The IT6613E was a larger chip because it had a bunch of audio pins for Dolby stuff which cannot be used for our purposes. I do not think Marqs will change the HDMI TX on his OSSC since it would require a board revision because the footprint is different. It is just a change I am considering since he is putting that project opensource. It is something I wanted early on the Wolf but was scared of the firmware.

My plan is to post a finished schematic so the community can review it. There are a lot of knowledgeable people on here and maybe they can catch something before it gets fabricated. I do not have a ETA on a schematic.

[austin532]

I hope the announcement of OSSC 1.6 hasn't effected your motivation to work. I know a lot people will still be interested in this if you put your own spin on it.

Stay focused.

[Wolf_]

I hope the announcement of OSSC 1.6 hasn't effected your motivation to work.

[becker]

I hope the announcement of OSSC 1.6 hasn't effected your motivation to work. I know a lot people will still be interested in this if you put your own spin on it.

Stay focused.

I love working on the Wolf. I have learned so much trying to do a challenging (to me) project. I am happy OSSC 1.6 was released. It added audio to the baseline function. It did force me to do something more interesting to be different. But I think it will be even better now.

[Wolf_]

I hope the announcement of OSSC 1.6 hasn't effected your motivation to work. I know a lot people will still be interested in this if you put your own spin on it.

Stay focused.

I love working on the Wolf. I have learned so much trying to do a challenging (to me) project. I am happy OSSC 1.6 was released. It added audio to the baseline function. It did force me to do something more interesting to be different. But I think it will be even better now.

Something I just found out about the ossc is that it doesn't accept s-video in, even if you use a passive s-video to scart cable. In my setup the only console I have on s-video is the cdi thanks to scart mods and the nt mini but maybe that would make a bigger difference to other people.

What would make an absolutely huge deal is if it could accept hdmi in because I have a ton of consoles modded for hdmi that are not already at least 1080p:
Dreamcast(Akura), PS3, Xbox 360, GameCube(Gameboy Player), Wii U, Ps Tv

Also I was wondering because of the line 5x and such modes what happens if you connect an xbox to the ossc via component and play a 1080i or 720p game? What is the highest resolution we can crank out of this thing?

[pyrotek85]

I hope the announcement of OSSC 1.6 hasn't effected your motivation to work. I know a lot people will still be interested in this if you put your own spin on it.

Stay focused.

I love working on the Wolf. I have learned so much trying to do a challenging (to me) project. I am happy OSSC 1.6 was released. It added audio to the baseline function. It did force me to do something more interesting to be different. But I think it will be even better now.

Something I just found out about the ossc is that it doesn't accept s-video in, even if you use a passive s-video to scart cable. In my setup the only console I have on s-video is the cdi thanks to scart mods and the nt mini but maybe that would make a bigger difference to other people.

What would make an absolutely huge deal is if it could accept hdmi in because I have a ton of consoles modded for hdmi that are not already at least 1080p:
Dreamcast(Akura), PS3, Xbox 360, GameCube(Gameboy Player), Wii U, Ps Tv

Also I was wondering because of the line 5x and such modes what happens if you connect an xbox to the ossc via component and play a 1080i or 720p game? What is the highest resolution we can crank out of this thing?

Yeah as mentioned in the OSSC thread, I'm in a similar boat as you. My 3DO is in S-Video (or composite), and an RGB mod may be a ways off, if ever. The rest of my systems are either RGB over scart, component, or VGA for the Dreamcast. One or two HDMI-in ports would be handy too.

[Wolf_]

A single hdmi in would be amazing, just use a switch if you need more than that or change them manually just like with component and scart inputs.

[Blair]

technically you can connect any HDMI enabled device to the OSSC's VGA port using an HDMI to VGA dac, (like the HD fury 2 gamer). I've done that with my PC (1070 GPU) and an Xbox 360. it works pretty good.

[Wolf_]

technically you can connect any HDMI enabled device to the OSSC's VGA port using an HDMI to VGA dac, (like the HD fury 2 gamer). I've done that with my PC (1070 GPU) and an Xbox 360. it works pretty good.

Going from digital to analogue and back to digital is such a round about way of doing things though and 2 conversions introduces two signal delaying events that don't need to be there, not to mention going to analogue would introduce quality loss into the equation and that entire process is just a mess.

It would be so much easier to just have the ossc be an all in one 0 latency upscaling unit. A true framemeister killer. When we get later versions of the ossc that can do 4k then it will be my endgame for upscaling&conversion units.

[Blair]

I get what you're saying, but if done properly any delay or quality loss should be imperceptible. and currently that's the only way to hook digital only sources to the OSSC 1.5 and 1.6. I also wouldn't hold my breath for a 4K model anytime soon. unless FPGA performance significantly increases along with prices significantly decreasing.

you've also forgotten that a D/A conversion is already occurring before anything even reaches the OSSC (for instance a ps2. in the hardware its video signal starts out as digital, but circuitry on the unit has to output an analog signal because of how display interfaces worked at the time). also I think you might be misunderstanding what the OSSC actually does. it's not technically upscaling as it doesn't have a memory buffer. it's doing something called "line doubling" and that's why it has near zero latency. but it doesn't change the resolution of 720p and above sources. (it can only line multiply 240p, 384p and 480p/i sources) as we've pretty much hit the limit of what the current hardware can physically accomplish

(perhaps a future model could line double 720p sources, but I don't see that happening anytime soon).

[Wolf_]

I get what you're saying, but if done properly any delay or quality loss should be imperceptible. and currently that's the only way to hook digital only sources to the OSSC 1.5 and 1.6. I also wouldn't hold my breath for a 4K model anytime soon. unless FPGA performance significantly increases along with prices significantly decreasing.

you've also forgotten that a D/A conversion is already occurring before anything even reaches the OSSC (for instance a ps2 in the hardware the video signal starts out as digital but circuitry on the unit has to output an analog signal because of how display interfaces worked at the time). also I think you might if misunderstanding what the OSSC does. it's not technically upscaling as it doesn't have a memory buffer. it's doing something called "line doubling" and that's why it has near zero latency. but it doesn't change the resolution of 720p and above sources. (it can only line multiply 240p, 384p and 480p/i sources)

I was aware it was linedoubling, but it was doing that to upscale the image to a higher resolution so I figured the terms would be interchangeable. I did not know that it doesn't work on 720p or above sources though.

Also I'm aware video signals start out as digital but as there is no way to cut that link out of the chain (yet) it seemed obvious that if converting to analogue and back to digital again wasn't ideal the first time repeating the cycle a second time would be even less ideal. Basically the goal is an all digital signal at every link in the chain but barring that as few analogue conversions as possible with the shortest cables and highest video qualities.

Anyways if the ossc doesn't work on 720p or higher inputs at this time then it looks like I'll have to wait for v2 because that isn't going to cut it for me.

[Blair]

it can still digitize 720p and above signals (and it's probably one of the best devices in the world at that). but I'm curious on why you would actually need something that scales or line doubles 720p and above content. most consumer televisions and monitors these days do a pretty good job scaling from those resolutions with little to no added input lag (especially if decent game mode processing is present). could you describe a scenario that isn't covered under normal circumstances?

there are some technical ways to directly tap into the pure digital signal of videogame systems but they're expensive and mostly impractical. something like the FPGA clones of older systems, for instance the Analog NT would probably work for pure digital output.