RE: Youtube contact e-mail

[hardmode1337]

Hi mate,

Sorry about the youtube chatter; you're right this is the best place for it but as your last update was 3 years old I was unsure if this account was still maintained.

I'm glad you responded, I never got 720p working myself as I think even with PLL overclocking it just doesn't have emulated LVDS R3 like cyclone III so it 'stops there', speaking to a guy in Japan who's managed to pull it off on the III who has kindly shared some of the basic principles of PLL clocking shows it's possible at about 125% to overclock.

Regarding my project, I've managed to hook up an ADC converter from a RGB source and the RED analog is now in 8bit digital signals... awesome progress for me since I'm new to verilog and FPGA's, however, I've been unable to properly show the digital data on the screen properly (garbled) I've confirmed its the actual data though as turning the source off or running a demo sequence can clearly see it's relative to the picture on the screen. So I believe I also need a clock source to fix this - In your neo-geo source it states 'clock' I assume this is the clock in from the neo, if so is that a c sync or svideo source I'm curious and did you require any external hardware to take this directly into the FPGA such as a resistor divider or ADC chip? I am working on a CD32 RGB source and it has c sync or s-video sync as potential sync inputs for my project although I've currently only got the s-video sync exposed at the ready as I will need to tap into the c-sync (not too difficult).

My E-mail is, sumitgood [AATT] icloud.com

I appreciate what you've given to the community here in this github, the audio islands will especially be Important later in the project so I truly appreciate your hard work mate!

Thanks buddy. Chris

[hardmode1337]

Also I forgot to add that I really enjoy your implementation using the fpga4fun source as an example and moving forward from there, the reason I said 25mhz/125mhz before was I would have hoped to have got the 'basic' example of theirs working so I could start from around that point - I don't believe in ripping code and in fact find your implementation pretty cool as it uses less Altera Plugins which of course come with their own licences in which case less is more of course.

Edit: The cyclone III PLL actually has more flexible clock multiplier/dividers than that of the II; I find on the III the PLL wizard allows you to set a very accurate pixel/tmds clock over the II - it's probably at this point you come to realise how much of a step up the III is over the II and while II is great for prototyping the slightly more expensive III boards are worth their money. I use the same cheap II board as yourself, and with no headers it really gives you that freedom to experiment haha, I did as you did and simply threw headers on the HDMI data/clock to hook-up to the header i/o pins - cost-effective approach as you just need to sacrifice half an HDMI cable... like cutting worms, you get two from one. Interesting to note however, I found the GND for individual clock/data don't need to be hooked up at all for a quick-prototype, I do worry about the lengths of each wire if they're not exact this could affect getting 720/1080p and I'll find out soon enough with the III when it arrives- hopefully, a smooth ride.

[charcole]

Good work in getting so far. You shouldn't need to go to 25MHz. That's the pixel clock for 640x480 while I went for 27MHz as that's the pixel clock for 720x480 (480p). 480p is guaranteed to be supported on any HDMI TV while I seem to remember 640x480 wasn't (although probably is). My Samsung TV was incredibly picky so tried lots of things to try to get it to work including going to 480p. I was lucky that my BenQ monitor was so forgiving or I would have given up much earlier.

I was going to use an external 70MHz(?) oscillator for trying 720p. As you've discovered, it's hard to make that exact frequency from the PLL. I struggled to get all the other code (particularly the TMDS encoder) to run fast enough on that speed grade of Cyclone II though so gave up. I think I got it close. Never tried it in hardware though, just simulation.

The clock is out of the FPGA into the Neo Geo. Originally I clocked everything from the Neo Geo's main clock (that gets divided for use as CPU and GPU clocks) but because the Neo Geo outputs slightly less than 60 frames per second it meant the pixel clock (on the HDMI side) was slightly off and my TV refused to show anything. So I switched it around and had the FPGA generate the pixel clock HDMI needed and that ran the Neo Geo's clock (at a slight overclock) so it would produce a full frame exactly every 60Hz.

Therefore I think you will struggle to get your project to work correctly with your current setup, I'm afraid :( The code is set up so it can control exactly when the pixel data arrives (which is probably why it becomes garbled for you). I don't think you'll be able to make it work external to the Neo Geo without changing the code an awful lot. Only way I could see it working is if you were able to use the sync pulses to run a PLL to generate the pixel clock. However that would mean the pixel clock wouldn't be exactly right so some TVs might not accept it.

[hardmode1337]

Thank you for your insightful and Interesting response, I'm also glad you didn't give up, I too don't give up so easily.

I've been toying around tonight with your code and I've seen potential of using it as a base for other projects, although like you said how it is currently set up for the neo geo clock etc will require a lot of changes . Playing around I was able to correctly show example tones through both the "hdmi layer" if you like to call it that and the "source layer" accurately which enables me a way to test everything is good. For now my red input source is 8 bit digital directly from analog via a ADC0804 however it has a few inputs and outputs that require communication to work thoroughly and I've yet to read enough about how to use it as there isn't too much information out there online apart from datasheets and led examples. I was hoping that the 8bit digital red would write to your buffer and then display it back but that's not the case as it's just a messy signal haha I'm wondering at which part I'm making a mistake it's new terroritory although it's certainly reflective of the data changing on the demos I'm running on the Amiga cd32 .

I will keep trying and hope to get some results soon. If you have any ideas what to do with the adc0804 or the data I get back from it so it could be useful and show some picture let me know :)

Thanks

Chris

[charcole]

Hey Chris,

Just had a quick look at the datasheet for ADC0804. It seems it's too slow for video digitising. It's says conversion time is around 100 microseconds. A complete line of video NTSC/PAL video is about 60 microseconds so this is a lot slow than is required. That could be why you aren't getting anything sensible out of it.

Was also thinking you might be able to separate the input signal's clock from the HDMI clock but to do that you'd need a lot more RAM. My code is basically a line doubler so it reads a line into RAM while sending the previous line at double the rate (as an interlaced signal has half the lines). If the clocks are out of sync then best case is you'll get a rolling picture. If you wanted to separate the clocks you'd need to store a whole frame which would require external RAM.

Charlie

[hardmode1337]

Charlie,

Thanks buddy I already come to that conclusion regarding the adc0804 a quick phone call to my dad and he saw the obvious - I decided on the adc08100 and got it onto a breakout board - I've not had luck with it just yet because my time has been spread about . The cyclone 3 arrived today so will get 720p plus going maybe 1080p 30hz if possible . Thinking about getting a cyclone 4 - 15 though which would be awesome . I'll let you know how I get on soon enough in respect to the higher res and the adc. Hopefully a picture this weekend .

Chris

[hardmode1337]

Hi mate

So been prodding along and reached a bit of a head ache .

I've managed to use an adc08100 to bring home the bacon with red input for now . The signal can be cleaned up later on I am betting when things are on a pcb and done according to specs . However I have a rolling imaging vertically I believe it has something to do with the syncing not working at the pixclock end counter x counter y section if full size ... reset . The If statement doesn't work to sync up . Otherwise I can't think any else this signal rolls .

Here's what I've got picture wise ,

www.4GP.ME/bbtc/1511797161679.jpg

Progress is swift now but I'm convinced I need to sync the hdmi output with the Amiga input . I have v sync and h sync on the Amiga side of things any suggestions ?

Chris

[charcole]

Good job getting a picture.

The picture will always roll if the frame rate isn't perfectly matched. This is what I was talking about before. The best fix would probably be to have a frame buffer so you can store the whole frame. Then the input refresh rate and output refresh rate could be independent. This would require a lot of memory especially as you'd probably want to at least double buffer it to prevent tearing.

The other way would be syncing to VSync/HSync but that might be tough. Turning the low duty cycle 15kHz (ish) HSync into a 50% duty cycle 7.5kHz square wave could be done with a simple flip flop. But then you'd need to go from that up to 27MHz. You might be able to do it by chaining PLLs but you'd need a few of them to get such a multiple. If you do achieve it then the HDMI clock won't be exactly 27MHz (unless the framerate is exactly 60fps) so will probably not work on all TVs.

The only other way I could think of would doing it be to have a very high base clock which samples the timing between HSyncs and then generates the HDMI pixel clock from that. I'm not entirely sure that'd be possible though as the base clock would have to be very high for the jitter to be low enough. You'd end up with the same problem as before though as your HDMI pixel clock would be out of spec.

Charlie

[hardmode1337]

Charlie,

It appears that if I tweak the counterY height +5, the image stabilizes to almost standstill but a slow creep up the screen instead of down, I can only assume there's obviously a difference between the writing to buffer and polling it at the 1st line... unfortunately, I've been unable to successfully lock and reset the counterY simply because all attempts to do so result in garbel output (more about this below). Just to clarify some things the HDMI (27mhz) end the remains static (overlay with test pattern) while the input is rolling.

The clock of the adc is 45mhz and I use a 22.5mhz clock to read in the red input to a line buffer (exactly half seems to show the resolution without trimming), but even if I use the pixclock of the hdmi (27mhz) i get the same exact situation so this is more likely the Y not being used and here's the problem below:

A line is read from the ADC (red_in, 8 bits) and when we receive a HSync we have our line and insert it into the line buffer where Y = 0 , at the other end we unfortunately for now keep querying line 0 every frame and we get a rolling image, obviously this is improper even if it shows an image . , if I attempt to fix Y = VSync then I just get garble, I can assume I'm doing something wrong at this point and want to keep going because my rolling image isn't simply because I did it right but that i haven't done it properly yet , learning curve.. haha

I'd like to attempt this without memory if possible, line buffering seems more favorable for me.

I'm wondering how would you modify your code to simply do the following:

a) take into respect just hsync and vsync pulses (no specific width/height much like a TV doesn't know the width/height without checking the pulses to build the picture) b) write the line of information for the first horizontal pulse into the line buffer at the respective position. c) Read back the line buffer with a 27mhz cycle and set red <= line from buffer.

Chris

[hardmode1337]

Hmm perhaps a digital delay line clock in clock out may help . Throw in the clock for the ntsc into the input line and the pixel clock on the output , thinking this could be the way to resolve it and then detect ntsc or pal for the timings ? Also might need another delay line for the ADC delay .

[charcole]

Hey Chris,

Sorry about the late reply. I'm not sure I was clear enough in my last reply. You're always going to have problems because if the FPGA is outputting at exactly 60fps and your source video signal is 59.99fps (for example) you'll always get rolling. You only have a line or two's worth of memory. At some point they'll get out of sync by more than a line and it'll roll. You can try and keep it in sync by skipping a line every once in a while but I'd imagine TVs would get pretty upset by that.

You need more memory or to lock the FPGA pixel clock so the output framerate is exactly the same as the input framerate.

Charlie

[hardmode1337]

Charlie

I get all that and you're right it makes perfect sense what you're saying here .

What I realised recently is that the input is of course not exactly the same frame rate hz so that's the reason - I'll be taking a look at all the options but may settle with a ic that takes the rgb and h / v sync in to convert to a digital output such as the one in the ossc - otherwise I'll play around with trying to match the input frame rate at the output but I feel this may not be possible as you say tv may not like it .

I'll let you know what works out in the end I hope . Hehe

Chris