Author Topic: FPGA video format conversion  (Read 12447 times)

0 Members and 1 Guest are viewing this topic.

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 2567
  • Country: ca
Re: FPGA video format conversion
« Reply #50 on: September 27, 2017, 02:16:33 pm »
Question:  Are you sure your video output pattern you are generating actually covers the video output.  Could there be a bug in your FPGA code.  Have you tried sending your video output to another screen.  If it's analog VGA, it should work on other monitors for testing...

Can you provide us a scope-shot from v-sync to v-sync of your video out and h-sync.
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #51 on: September 27, 2017, 10:00:26 pm »
Pretty sure everything is all good with the code.

Captures of the HP1662AS video signals (captured straight from the device) can be found about halfway down the page: projects.matthollands.com/2017/09/18/project-crt-oscilloscope-lcd-mod-calculating-video-timing/

The attachments are all captures from the output of my FPGA (to simulate the signals):
- 1x Line time = 40us,  h-sync = 3.23us
- 1x Zoom in
- 2x Line time = 20us, h-sync = 1.61us
- 2x Zoom in
- 2.5x Line time = 16us, h-sync = 1.21us
- 2.5 Zoom in
- 3x Line time = 13.333us, h-sync = 1.21us (this is inaccurate due to zoomed out time base)
 -3x Zoom in h-sync = 1.07us (accurate)

The v-sync and frame time all stay approximately constant.

For some reason the screen is now appearing to lock onto the 2.5x screen but not display it properly. 3x now seems to lock onto 1600x1200. Either way, I'm pretty sure I am generating ok signals.
« Last Edit: September 27, 2017, 10:51:14 pm by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #52 on: September 27, 2017, 11:07:52 pm »
Question:  Are you sure your video output pattern you are generating actually covers the video output.  Could there be a bug in your FPGA code.  Have you tried sending your video output to another screen.  If it's analog VGA, it should work on other monitors for testing...

Can you provide us a scope-shot from v-sync to v-sync of your video out and h-sync.

I just tested the signals on an oldish hp monitor:
HP1662AS signals - doesn't lock on
2x - 1280x800
2.5x - 1280x1024
3x - 1600x1200

Meanwhile, the 10.1" panel:
HP1662AS signals - doesn't lock on
2x - 1280x768
2.5x - ??? Seems to lock but doesn't display anything?!
3x - 1600x1200
Read about my stuff at: projects.matthollands.com
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 2567
  • Country: ca
Re: FPGA video format conversion
« Reply #53 on: September 28, 2017, 03:25:49 am »
Arrrg, on your scope shots, your missing a trace with the analog video.  I am unable to tell if when your actual picture starts vertically and ends vertically...
Ok, found it on your website link...

Now, your sync is only 3.3v.  A lot of monitors will fail to lock on this unless it is 5v level.  Of, they might manage to occasionally sync in and out...

Also, especially for trying to get the native mode on your main screen, sometimes the sync polarity needs to be positive (inverted).  Some monitors demand this if you want to access a preset mode.  This may mean inverting just the horizontal, or vertical, or both syncs.

As for your sync pattern, it looks fine, but, to improve it a little, latch the VS signal with each initial HS signal transition.  This will make the VS activate and de-activate at the same time as next HS signal transition.  This is not important for CRTs, but may affect some more modern LCD screen's power saving sleep mode...


Ok, I see what's going on on your website, your scope's video output has an astronomically huge equal v-front/back_porch of 87 lines each!  The v-sync pulse of 3 lines is normal.

However, your scope-shot from the source doesn't seem to reflect this figure.  Can you do me the favor and look at the video output and count the number of h-syncs between the last line of video and the beginning of the V-sync, then, the number of h-syncs during the v-sync, then, the number of h-syncs between the end of the v-sync and the first line with active video.

« Last Edit: September 28, 2017, 04:08:50 am by BrianHG »
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
FPGA video format conversion
« Reply #54 on: September 28, 2017, 04:36:07 am »
Arrrg, on your scope shots, your missing a trace with the analog video.  I am unable to tell if when your actual picture starts vertically and ends vertically...
Ok, found it on your website link...

Now, your sync is only 3.3v.  A lot of monitors will fail to lock on this unless it is 5v level.  Of, they might manage to occasionally sync in and out...

Also, especially for trying to get the native mode on your main screen, sometimes the sync polarity needs to be positive (inverted).  Some monitors demand this if you want to access a preset mode.  This may mean inverting just the horizontal, or vertical, or both syncs.

As for your sync pattern, it looks fine, but, to improve it a little, latch the VS signal with each initial HS signal transition.  This will make the VS activate and de-activate at the same time as next HS signal transition.  This is not important for CRTs, but may affect some more modern LCD screen's power saving sleep mode...


Ok, I see what's going on on your website, your scope's video output has an astronomically huge equal v-front/back_porch of 87 lines each!  The v-sync pulse of 3 lines is normal.

However, your scope-shot from the source doesn't seem to reflect this figure.  Can you do me the favor and look at the video output and count the number of h-syncs between the last line of video and the beginning of the V-sync, then, the number of h-syncs during the v-sync, then, the number of h-syncs between the end of the v-sync and the first line with active video.

Getting a 5V sync is a bit difficult, but for reasonable formats I haven't seen any monitors fail to lock (I've tried maybe 4 displays at some point).

Ill try doing some inverting of h-sync and v-sync.

I can count the h syncs. Do you mean on the original video source?

The huge front and back porches may explain why so much of the CRT isn't used. There is maybe 3/8th" of unused (black) display either side of the display area.

So does the display use the video signal as well as the syncs to lock onto the signal? Surely it can't because otherwise it would be unable to display a fully (or mostly) black image since there would be no video data to lock onto.
« Last Edit: September 28, 2017, 04:39:43 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #55 on: September 28, 2017, 06:31:13 am »
BrianHG is right. You need to get a better idea of the original video signal.

For starters, it is NOT OK to arbitrarily guess the pixel clock frequency. Getting an accurate pixel clock is vital for a properly sampled original video and will in turn significantly affect the quality of converted video. Your final solution doesn't tap into the pixel clock from the original circuit, that doesn't mean you don't need to know its exact frequency. In other word, to get an accurate H_TOTAL is as important as H_VISIBLE.

And everything else should be measured in pixel clock counts. Don't guess, measure. How do you know the exact pixel count of front and back porch? You need to find the DE (data enable) signal in the original circuit, sometimes disguised as 'Blanking'. Compare DE with hsync you get accurate count of H front and back porch, and same for V front and back porch. From the scope capture it doesn't seem that you have a symmetrical V front and back porch, how can you assume they have the same line count?

Another big misconception: Line doubler doesn't mean you have half the pixel count per line and double the line count while keeping the pixel clock the same. It means you double the pixel clock and line count while maintaining the same pixel count per line.

Personally I found a frequency counter works better than DSO when measuring the video timing, especially two-channel models that counts A by B and measures TI A to B. Obviously you have one of the latest scopes that would be better than scopes from 10, 20 years ago.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
FPGA video format conversion
« Reply #56 on: September 28, 2017, 06:42:22 am »
BrianHG is right. You need to get a better idea of the original video signal.

For starters, it is NOT OK to arbitrarily guess the pixel clock frequency. Getting an accurate pixel clock is vital for a properly sampled original video and will in turn significantly affect the quality of converted video. Your final solution doesn't tap into the pixel clock from the original circuit, that doesn't mean you don't need to know its exact frequency. In other word, to get an accurate H_TOTAL is as important as H_VISIBLE.

And everything else should be measured in pixel clock counts. Don't guess, measure. How do you know the exact pixel count of front and back porch? You need to find the DE (data enable) signal in the original circuit, sometimes disguised as 'Blanking'. Compare DE with hsync you get accurate count of H front and back porch, and same for V front and back porch. From the scope capture it doesn't seem that you have a symmetrical V front and back porch, how can you assume they have the same line count?

I am NOT guessing. I measured the video signal and divided it by the horizontal resolution (from the service manual) to get the pixel clock. Don't know why you think I guessed it. 17.375MHz.

If you're being confused by the article, that was using an arbitrary clock frequency because there is no need to be exact when im not actually sending any video signal.

I am using a chip (TVP7002) that is designed for pixel clock reconstruction from the sync signals. You don't need to tap into the original clock - computer monitors/tvs manage not to.

Quote


Another big misconception: Line doubler doesn't mean you have half the pixel count per line and double the line count while keeping the pixel clock the same. It means you double the pixel clock and line count while maintaining the same pixel count per line.


I know. To get double the lines I use double the pixel frequency and then double all of the vertical timings.

The input video is fully characterized (you are right about the porches not being totally equal - overlooked that).The problem is transforming it to a signal that the LCD will recognize and display reasonably. (although at this point I still plan to just use a frame buffer and two separate clock domains).
« Last Edit: September 28, 2017, 06:49:19 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #57 on: September 28, 2017, 07:34:25 am »

I am NOT guessing. I measured the video signal and divided it by the horizontal resolution (from the service manual) to get the pixel clock. Don't know why you think I guessed it. 17.375MHz.

If you're being confused by the article, that was using an arbitrary clock frequency because there is no need to be exact when im not actually sending any video signal.
Yep, that's what your article said:
Quote
It turns out that we don’t actually care what the pixel clock is as long as the v-sync and h-sync pulses are the correct length and at the correct intervals. This is because the display locks onto a signal using only the h-sync and v-sync pulses.

Quote
I am using a chip (TVP7002) that is designed for pixel clock reconstruction from the sync signals. You don't need to tap into the original clock - computer monitors/tvs manage not to.

The TVP7002 will not magically figure out what your pixel clock frequency is. You still need to program it. Assuming your line time (40us) and pixel frequency (17.375MHz) are correct, you'll need to program the TVP7002 with a 695 HSYNC to pixel clock ratio.

Quote
I know. To get double the lines I use double the pixel frequency and then double all of the vertical timings.

That's not what you said in the article. Your 'original' video has H_TOTAL=800 and your 'line doubled' video has H_TOTAL=400.


Quote
The input video is fully characterized (you are right about the porches not being totally equal - overlooked that).The problem is transforming it to a signal that the LCD will recognize and display reasonably. (although at this point I still plan to just use a frame buffer and two separate clock domains).

I agree, but in a different sense. The problem is that you are trying to get to a signal that your LCDs will recognize and display reasonably, (seemingly) without the detailed specs of what your LCD driver board is capable of. Instead, I think you should try to get to a signal that conforms to a common standard (VESA compliant for instance), then all the displays are supposed to display it properly.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #58 on: September 28, 2017, 08:25:43 am »
Ignore that article except for the captures that I referenced - I am going to update it with newer information.... I really messed up a lot of these measurements  |O So here I will go through characterising the signal. Attached are the 8 measurements I took.

1. Measured line video time = 28.8016us. Assuming 500px visible as stated in the datasheet (also look about right by measuring) -> pixel clock = 17.36MHz
2. Measured horizontal front porch = 1.0312us -> h-front-porch = 18
3. Measured horizontal back porch = 6.9776us -> h-back-porch = 121
4. Measured horizontal sync = 3.202us -> h-sync = 56 (although this doesn't divide well)
H_TOTAL = 695 or 40us
5. Measured frame video time = 15.1093 -> 378 lines (this is much more than the datasheet stated 240!)
6. Measured vertical front porch = 441.04us -> v-front-porch = 11
7. Measured vertical back porch = 1.01021ms -> v-back-porch = 25
8. Measured v-sync = 120.002us -> v-sync = 3
V_TOTAL = 417 or 16.68ms
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #59 on: September 28, 2017, 10:10:34 am »
I have now implemented the new measurements on the FPGA and here are the captures of the output: (note that the video signal is way higher because we depend on the 75ohm termination to pull the voltage down to 0.7v)

1. Line video time = 28.800us instead of 28.8016us ->
2. Horizontal front porch = 1.040us instead of 1.0312us
3. Horizontal back porch = 6.950us instead of 6.9776us
4. Horizontal sync = 3.219us instead of 3.202us
5. Frame video time = 15.1218ms instead of 15.1093ms
6. Vertical front porch = 441.42us instead of 441.04us
7. Vertical back porch = 1.01105ms instead of 1.01021ms
8. Vertical sync = 120.115us instead of 120.002us

This seems within margin of error of oscillators etc.

Sorry for my previous mistakes with characterising the signal.
« Last Edit: September 28, 2017, 10:14:54 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #60 on: September 28, 2017, 10:29:02 am »
Since your measured active line count (378 lines) is much more than the datasheet stated 240, why don't you suspect that the datasheet stated 500 pixels may not be correct, either?

It is worth noting that the video image may have black borders around the display image. Comparing the video signal to the sync is not a bullet-prof method to determine the front and back porches. As a result the H_total could be off. My advise would be to find the actual, physical pixel clock and DE signals in your machine. That way you can be sure. There may or may not be surprises, but it is better to find out earlier than later.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #61 on: September 28, 2017, 10:34:41 am »
Since your measured active line count (378 lines) is much more than the datasheet stated 240, why don't you suspect that the datasheet stated 500 pixels may not be correct, either?

It is worth noting that the video image may have black borders around the display image. Comparing the video signal to the sync is not a bullet-prof method to determine the front and back porches. As a result the H_total could be off. My advise would be to find the actual, physical pixel clock and DE signals in your machine. That way you can be sure. There may or may not be surprises, but it is better to find out earlier than later.

The reason I suspect that the 500 pixels is correct is that when I measure pixels per mm, and measure the whole screen, it comes out as ~500 pixels. I agree its not a very accurate method.

The black borders (whether or not they are there) would be present all the time (the size of the screen never changes and always has a white background), so it's not really any different to having larger porches. I agree this is an assumption that could theoretically not be true, but for now I am willing to risk it.
Read about my stuff at: projects.matthollands.com
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 2567
  • Country: ca
Re: FPGA video format conversion
« Reply #62 on: September 28, 2017, 10:42:01 am »
Ignore that article except for the captures that I referenced - I am going to update it with newer information.... I really messed up a lot of these measurements  |O So here I will go through characterising the signal. Attached are the 8 measurements I took.

1. Measured line video time = 28.8016us. Assuming 500px visible as stated in the datasheet (also look about right by measuring) -> pixel clock = 17.36MHz
2. Measured horizontal front porch = 1.0312us -> h-front-porch = 18
3. Measured horizontal back porch = 6.9776us -> h-back-porch = 121
4. Measured horizontal sync = 3.202us -> h-sync = 56 (although this doesn't divide well)
H_TOTAL = 695 or 40us
5. Measured frame video time = 15.1093 -> 378 lines (this is much more than the datasheet stated 240!)
6. Measured vertical front porch = 441.04us -> v-front-porch = 11
7. Measured vertical back porch = 1.01021ms -> v-back-porch = 25
8. Measured v-sync = 120.002us -> v-sync = 3
V_TOTAL = 417 or 16.68ms

This is beginning to make more sense.  However, 417 line total -3 (normal) -11 (normal) -25 (normal) = 378.  This is still not standard vertical video mode, however, 423 lines -3 -11 -25 = 384.  This is a standard and still 59hz.  In fact, both 512x384@60hz and 640x384@60hz is an old, but standard Vesa VGA mode from the 80s...  You have obviously timed your syncs on your scope.  (These nasty things time better with a real frequency counter...)  I am not saying there is an error here, may this weird video mode is correct, but, do you have the ability to count the h-syncs from vs-vs through a counter?

Updating your video output raster specs, to double these new ones, do you fill your LCD more completely?
Also, when doing this, you don't need to yet, but, should clock at double frequency.
512x384 doubled to 1024x768 should fill your display completely.
« Last Edit: September 28, 2017, 10:44:24 am by BrianHG »
__________
BrianHG.
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #63 on: September 28, 2017, 11:10:51 am »

The reason I suspect that the 500 pixels is correct is that when I measure pixels per mm, and measure the whole screen, it comes out as ~500 pixels. I agree its not a very accurate method.

The black borders (whether or not they are there) would be present all the time (the size of the screen never changes and always has a white background), so it's not really any different to having larger porches. I agree this is an assumption that could theoretically not be true, but for now I am willing to risk it.

I guess you still don't get it why it is so important to nail down the actual pixel clock, H_ACTIVE and H_TOTAL to the last bit of accuracy (perfect integer multiples of pixel clock cycle that is). You have realized that the measured HSYNC width doesn't divide well by the calculated pixel clock cycle. That's a sign. You either measured the HSYNC wrong, or calculated the pixel clock wrong, or both.

In case this might help you reconsider: I've done some video conversion from CRT to LCD on old HP gear, and am in the process of doing more (not including the 166x series, though).
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #64 on: September 28, 2017, 11:29:04 am »
Ignore that article except for the captures that I referenced - I am going to update it with newer information.... I really messed up a lot of these measurements  |O So here I will go through characterising the signal. Attached are the 8 measurements I took.

1. Measured line video time = 28.8016us. Assuming 500px visible as stated in the datasheet (also look about right by measuring) -> pixel clock = 17.36MHz
2. Measured horizontal front porch = 1.0312us -> h-front-porch = 18
3. Measured horizontal back porch = 6.9776us -> h-back-porch = 121
4. Measured horizontal sync = 3.202us -> h-sync = 56 (although this doesn't divide well)
H_TOTAL = 695 or 40us
5. Measured frame video time = 15.1093 -> 378 lines (this is much more than the datasheet stated 240!)
6. Measured vertical front porch = 441.04us -> v-front-porch = 11
7. Measured vertical back porch = 1.01021ms -> v-back-porch = 25
8. Measured v-sync = 120.002us -> v-sync = 3
V_TOTAL = 417 or 16.68ms

This is beginning to make more sense.  However, 417 line total -3 (normal) -11 (normal) -25 (normal) = 378.  This is still not standard vertical video mode, however, 423 lines -3 -11 -25 = 384.  This is a standard and still 59hz.  In fact, both 512x384@60hz and 640x384@60hz is an old, but standard Vesa VGA mode from the 80s...  You have obviously timed your syncs on your scope.  (These nasty things time better with a real frequency counter...)  I am not saying there is an error here, may this weird video mode is correct, but, do you have the ability to count the h-syncs from vs-vs through a counter?

Updating your video output raster specs, to double these new ones, do you fill your LCD more completely?
Also, when doing this, you don't need to yet, but, should clock at double frequency.
512x384 doubled to 1024x768 should fill your display completely.

I used the frequency measurement on my scope to find the frequency of the vs and the hs and they almost perfectly divide into eachother by 417. To get 423 instead would be quite a margin of error.

Doubling the clock frequency and doubling the v-parameters the display does lock on and I am able to fill most of the display by twiddling the clock, phase, vertical and horizontal parameters on the display. But unfortunately now it overflows the display!
« Last Edit: September 28, 2017, 11:31:12 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #65 on: September 28, 2017, 11:34:24 am »

The reason I suspect that the 500 pixels is correct is that when I measure pixels per mm, and measure the whole screen, it comes out as ~500 pixels. I agree its not a very accurate method.

The black borders (whether or not they are there) would be present all the time (the size of the screen never changes and always has a white background), so it's not really any different to having larger porches. I agree this is an assumption that could theoretically not be true, but for now I am willing to risk it.

I guess you still don't get it why it is so important to nail down the actual pixel clock, H_ACTIVE and H_TOTAL to the last bit of accuracy (perfect integer multiples of pixel clock cycle that is). You have realized that the measured HSYNC width doesn't divide well by the calculated pixel clock cycle. That's a sign. You either measured the HSYNC wrong, or calculated the pixel clock wrong, or both.

In case this might help you reconsider: I've done some video conversion from CRT to LCD on old HP gear, and am in the process of doing more (not including the 166x series, though).

Ok, if I get some time on the weekend, I may be able to find some time to dig around inside the HP. Do you have any recommendations to help me find the pixel clock, etc? I've never been able to find schematics for this thing.

[edit] Oh hey, the service manual tells me that it uses a National Semiconductor LM1882CM, so I can look at the blanking pins on that, and the clock going into it to figure out the timing [/edit]
« Last Edit: September 28, 2017, 11:45:23 am by MattHollands »
Read about my stuff at: projects.matthollands.com
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 2567
  • Country: ca
Re: FPGA video format conversion
« Reply #66 on: September 28, 2017, 11:46:07 am »
I assumed you would have the TVP chip by now.  Yes, for a pixel perfect 1:1 pixel capture, you need the true H-pixel clock values.  However, since you will be squeezing or stretching the picture horizontally, we might cheat here by oversampling with the TVP and using it's low pass filter to create an approximate analog display.  I was going to guide you on the trick to getting these values out of the chip...

But, this wont work for the vertical.  You need the exact active lines, and their positions.  Unless you already have the hardware to measure this down to the dot, you cannot rely on the scope's timing here.  Even my 25k$ Techtronix scopes fails at these tasks compared to a frequency counter which is why frequency counters still sell.

Yes, @simmconn is correct, assuming you need the perfect dot-dot capture, but, you can cheat a little here and still get a perfectly good looking picture since your source is low res and we can oversample enough and have enough shades of grey to make a smooth final result.  This still doesn't mean you can go for perfection, you just may not fill your panel horizontally perfectly.  This will be up to you since trying both is easy enough.

Note that you can adjust you horizontal and vertical position by changing the front and back porch on you FPGA video output.  This is safe as long as the total number of lines/pixels from front to back remains constant.  Do not worry about the alignment in the scopes video output.  The TVP has a programmable active video sampling window region which you set to shift it's picture coming into your line buffer and you will generate your video output sync based on an programmable offset of that signal.  As long at the total lines and total pixels match a multiple of the total lines and total pixels coming out of the TVP, you can shift you active video region as needed to center the image on the LCD if the LCD's internal adjustments cant go all the way to the edge...
« Last Edit: September 28, 2017, 11:53:13 am by BrianHG »
__________
BrianHG.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #67 on: September 28, 2017, 11:54:24 am »
I assumed you would have the TVP chip by now.  Yes, for a pixel perfect 1:1 pixel capture, you need the true H-pixel clock values.  However, since you will be squeezing or stretching the picture horizontally, we might cheat here by oversampling with the TVP and using it's low pass filter to create an approximate analog display.  I was going to guide you on the trick to getting these values out of the chip...

But, this wont work for the vertical.  You need the exact active lines, and their positions.  Unless you already have the hardware to measure this down to the dot, you cannot rely on the scope's timing here.  Even my 25k$ Techtronix scopes fails at these tasks compared to a frequency counter which is why frequency counters still sell.

Yes, @simmconn is correct, assuming you need the perfect dot-dot capture, but, you can cheat a little here and still get a perfectly good looking picture since your source is low res and we can oversample enough and have enough shades of grey to make a smooth final result.  This still doesn't mean you can go for perfection, you just may not fill your panel horizontally perfectly.  This will be up to you since trying both is easy enough.

Note that you can adjust you horizontal and vertical position by changing the front and back porch on you FPGA video output.  This is safe as long as the total number of lines/pixels from front to back remains constant.  Do not worry about the alignment in the scopes video output.  The TVP has a programmable active video sampling window region which you set to shift it's picture coming into your line buffer and you will generate your video output sync based on an offset of that signal.

The TVP and PCB are on their way now. Not sure how long before I'll have that up and running. I tried moving pixels from the back porch to the front porch to see if that would let me move the image, but the screen would not lock if I changed it even by one.
Read about my stuff at: projects.matthollands.com
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #68 on: September 28, 2017, 12:03:30 pm »
In case this might help you reconsider: I've done some video conversion from CRT to LCD on old HP gear, and am in the process of doing more (not including the 166x series, though).

Out of interest, what approach did you go for? Line doubling, or frame buffer, or something different?

Btw, I appreciate all the help guys.
Read about my stuff at: projects.matthollands.com
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 2567
  • Country: ca
Re: FPGA video format conversion
« Reply #69 on: September 28, 2017, 12:10:40 pm »
I tried moving pixels from the back porch to the front porch to see if that would let me move the image, but the screen would not lock if I changed it even by one.

This does not sound right.  In fact, if the H-total and V-total remain constant as well as the H-sync and v-sync, the image should always stay locked...

Can I see the source code of your sync generator....
__________
BrianHG.
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #70 on: September 28, 2017, 01:21:15 pm »
For the existing designs I've been lucky and didn't need frame buffer. The ones in the pipeline need frame buffer.

Thanks for the pointers (re: LM1882CM). It turns out the 166xC uses BT475 RAMDAC, which is theoretically supported by my existing design. Not sure about the 166xAs, though. HP often has significantly different display subsystems between the A, B and Cs of the same product family.

I've been tapping into the digital signals in the original video circuit as much as possible in order to get a clean picture and avoid D/A and A/D altogether. It also helps color remapping. Apparently you chose a different approach, which would work as well. I just wanted to let you know what I leaned to be important during the development. Getting to the bottom of the original video timing is a start.

I sort of disagree with BrianHG in that I think sharpness (clarity) is more important in the line-art type of image from the test equipment, rather than smoothness. So I'd rather get the original picture as accurately as possible, and let the scaling process mess up the sharpness as little as possible.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 2567
  • Country: ca
Re: FPGA video format conversion
« Reply #71 on: September 28, 2017, 02:53:03 pm »

I sort of disagree with BrianHG in that I think sharpness (clarity) is more important in the line-art type of image from the test equipment, rather than smoothness. So I'd rather get the original picture as accurately as possible, and let the scaling process mess up the sharpness as little as possible.

Yes, but scaling still must be done if you want to project the original scope's 500 X-pixels onto a panel with 1280 X-pixels.  Unless you want a black border of 140 pixels on the left and right.  Converting 500 to 1280 is not a fixed multiple by 2.  Doing a nearest neighbor pixel resize here will lead to fat and thin vertical chunk pattern.  Whether you scale this digitally, or with my analog trick, scaling up 500->1280 will always be wider than 2 pixels, in fact, it will be 2.56.  Adjusting this slightly to 2.5 pixels (500-1250 (tiny black border of only 15 pixels now)), this means 2 pixels are a direct copy and every alternating second 2 pixels, you insert a 50/50 blend of the 2 in between pixels will still be a fully sharp yet less than an absolute chunky upsample.  I am not talking about doing a fancy full bi-cubic X-Y 16 to 256 tap filtering with an adaptive filter radius making a nice soft broadcast video production style scale.  He doesn't have the gate-count for that anyways, well,,, maybe since it is monochrome and so low res, but this is not the point.

We still don't know if his scope's output is truly 500 pixels VS 512 or even 640 (perfect 2:1 for this guy, no fancy filtering...).  I have a funny feeling that the quoted specs he used from the scope's user manual may just be the scope grid and center video output while the extra spare space listed in the back&front porch may contains the menu text items as we seen the video goes beyond the original specs found in MattHollands latest scope shots.
« Last Edit: September 28, 2017, 03:03:28 pm by BrianHG »
__________
BrianHG.
 

Offline simmconn

  • Regular Contributor
  • *
  • Posts: 51
Re: FPGA video format conversion
« Reply #72 on: September 28, 2017, 04:48:37 pm »
I am not talking about doing a fancy full bi-cubic X-Y 16 to 256 tap filtering with an adaptive filter radius making a nice soft broadcast video production style scale.  He doesn't have the gate-count for that anyways, well,,, maybe since it is monochrome and so low res, but this is not the point.

The FPGA he uses has more than enough resources to do a fancy scaler. This is a learning experience. Let's see what he comes up with.

Quote
We still don't know if his scope's output is truly 500 pixels VS 512 or even 640 (perfect 2:1 for this guy, no fancy filtering...).  I have a funny feeling that the quoted specs he used from the scope's user manual may just be the scope grid and center video output while the extra spare space listed in the back&front porch may contains the menu text items as we seen the video goes beyond the original specs found in MattHollands latest scope shots.

I found a 1662C in my stash tonight which I forgot how much I paid for. Well, it powers up with a good picture and I was able to take some measurement on the video part. You are exactly right, that the '500x240' in the datasheet oscilloscope section describing the waveform display window, is not the resolution of the entire picture. Assuming the 1662C has the same video timing as the 1662A, he had most of the timing right but not all. Let's see if he'll get to the right numbers, or like he said, it may not be that important for getting a converted picture.

Sadly my existing board doesn't fit the 1662C due to a stupid mechanical issue - it is not the first time that happens. Because of that I won't be working on it any time soon, if at all.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
    • Matt's Projects
Re: FPGA video format conversion
« Reply #73 on: September 28, 2017, 09:51:53 pm »
Can I see the source code of your sync generator....

Code: [Select]
module vga_control( CLK, //CLK input
                    ENABLE, //enable module
                    RESET, //resets device
                    VGA_CLK, //pixel clock for vga
                    VGA_X, //x position of vga
                    VGA_Y, //y position of vga
                    VGA_HS, //horizontal sync
                    VGA_VS, //vertical sync
                    VGA_VISIBLE, //are we in visible region
                    VGA_RED, //4 bit red colour
                    VGA_BLUE, //4 bit blue colour
                    VGA_GREEN); //4 bit green colour
                   
    input wire CLK, ENABLE, RESET;
    wire VGA_HS, VGA_VS, VGA_VISIBLE;
    output wire VGA_CLK, VGA_HS, VGA_VS, VGA_VISIBLE;
    output reg [11:0] VGA_X, VGA_Y;
    output wire [3:0] VGA_RED, VGA_BLUE, VGA_GREEN;
   
    //HP1662AS PARAMETERS (17.36MHz clock)
    parameter H_TOTAL = 695;
    parameter H_SYNC_PULSE = 56;
    parameter H_VISIBLE = 500;
    parameter H_FRONT_PORCH = 18;
    parameter H_BACK_PORCH = 121;
    parameter V_TOTAL = 417;
    parameter V_VISIBLE = 378;
    parameter V_SYNC_PULSE = 3;
    parameter V_FRONT_PORCH = 11;
    parameter V_BACK_PORCH = 25;
   
    //Line doubled (34.720MHz clock)
    /*parameter H_TOTAL = 695;
    parameter H_SYNC_PULSE = 56;
    parameter H_VISIBLE = 500;
    parameter H_FRONT_PORCH = 18;
    parameter H_BACK_PORCH = 121;
    parameter V_TOTAL = 834;
    parameter V_VISIBLE = 756;
    parameter V_SYNC_PULSE = 6;
    parameter V_FRONT_PORCH = 22;
    parameter V_BACK_PORCH = 50;*/
   
           
    //generate clock (change clock for different display modes)
    wire PLL_LOCKED;
   //generate vga clock
    clk_wiz_17360 vga_clk(  .clk_out1(VGA_CLK),
                             .reset(RESET),
                             .locked(PLL_LOCKED),
                             .clk_in1(CLK));
                         
    //set VGA_VISIBLE high when we are in the visible portion of the image
    assign VGA_VISIBLE = (VGA_X >= H_SYNC_PULSE + H_BACK_PORCH) && (VGA_X < H_VISIBLE + H_BACK_PORCH + H_SYNC_PULSE) && (VGA_Y >= V_SYNC_PULSE + V_BACK_PORCH) && (VGA_Y < V_VISIBLE + V_SYNC_PULSE + V_BACK_PORCH);
    assign VGA_HS = ~(VGA_X < H_SYNC_PULSE);
    assign VGA_VS = ~(VGA_Y < V_SYNC_PULSE);
       
    assign VGA_RED = (VGA_VISIBLE ? 15 : 0); //red whenever we are in visible region
    assign VGA_GREEN = ((VGA_VISIBLE && ((VGA_X == H_SYNC_PULSE + H_BACK_PORCH) || (VGA_X == H_VISIBLE + H_BACK_PORCH + H_SYNC_PULSE - 1))) ? 15 : 0); //green/red vertical edges
    assign VGA_BLUE = ((VGA_VISIBLE && ((VGA_Y == V_SYNC_PULSE + V_BACK_PORCH) || (VGA_Y == V_VISIBLE + V_SYNC_PULSE + V_BACK_PORCH - 1))) ? 15 : 0); //blue/red horizontal edges
       
    //at every clock edge
    always @(posedge VGA_CLK)
    begin
        //if enabled
        if(ENABLE) begin
            //increment VGA_X and VGA_Y
            if(VGA_X < H_TOTAL - 1) begin
                VGA_X <= VGA_X + 1;
            end else begin
                VGA_X = 0;
                if(VGA_Y < V_TOTAL - 1) begin
                    VGA_Y <= VGA_Y + 1;
                end else begin
                    VGA_Y <= 0;
                end
            end
        end
       
        if(RESET) begin
            VGA_Y <= 0;
            VGA_X <= 0;
        end
    end
endmodule

Yes, but scaling still must be done if you want to project the original scope's 500 X-pixels onto a panel with 1280 X-pixels.  Unless you want a black border of 140 pixels on the left and right.  Converting 500 to 1280 is not a fixed multiple by 2.
The native display of my LCD is actually 1024x600 so 500 would scale well - shame it's apparently not 500.

Thanks for the pointers (re: LM1882CM). It turns out the 166xC uses BT475 RAMDAC, which is theoretically supported by my existing design. Not sure about the 166xAs, though. HP often has significantly different display subsystems between the A, B and Cs of the same product family.
The 1662AS uses a Brooktree BT476KPJ66 RAMDAC as well as the LM1882, looks very similar if not the same.
Read about my stuff at: projects.matthollands.com
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 2567
  • Country: ca
Re: FPGA video format conversion
« Reply #74 on: September 30, 2017, 04:30:24 pm »
Can I see the source code of your sync generator....

Code: [Select]
module vga_control( CLK, //CLK input
                    ENABLE, //enable module
                    RESET, //resets device
                    VGA_CLK, //pixel clock for vga
                    VGA_X, //x position of vga
                    VGA_Y, //y position of vga
                    VGA_HS, //horizontal sync
                    VGA_VS, //vertical sync
                    VGA_VISIBLE, //are we in visible region
                    VGA_RED, //4 bit red colour
                    VGA_BLUE, //4 bit blue colour
                    VGA_GREEN); //4 bit green colour
                   
    input wire CLK, ENABLE, RESET;
    wire VGA_HS, VGA_VS, VGA_VISIBLE;
    output wire VGA_CLK, VGA_HS, VGA_VS, VGA_VISIBLE;
    output reg [11:0] VGA_X, VGA_Y;
    output wire [3:0] VGA_RED, VGA_BLUE, VGA_GREEN;
   
    //HP1662AS PARAMETERS (17.36MHz clock)
    parameter H_TOTAL = 695;
    parameter H_SYNC_PULSE = 56;
    parameter H_VISIBLE = 500;
    parameter H_FRONT_PORCH = 18;
    parameter H_BACK_PORCH = 121;
    parameter V_TOTAL = 417;
    parameter V_VISIBLE = 378;
    parameter V_SYNC_PULSE = 3;
    parameter V_FRONT_PORCH = 11;
    parameter V_BACK_PORCH = 25;
   
    //Line doubled (34.720MHz clock)
    /*parameter H_TOTAL = 695;
    parameter H_SYNC_PULSE = 56;
    parameter H_VISIBLE = 500;
    parameter H_FRONT_PORCH = 18;
    parameter H_BACK_PORCH = 121;
    parameter V_TOTAL = 834;
    parameter V_VISIBLE = 756;
    parameter V_SYNC_PULSE = 6;
    parameter V_FRONT_PORCH = 22;
    parameter V_BACK_PORCH = 50;*/
   
           
    //generate clock (change clock for different display modes)
    wire PLL_LOCKED;
   //generate vga clock
    clk_wiz_17360 vga_clk(  .clk_out1(VGA_CLK),
                             .reset(RESET),
                             .locked(PLL_LOCKED),
                             .clk_in1(CLK));
                         
    //set VGA_VISIBLE high when we are in the visible portion of the image
    assign VGA_VISIBLE = (VGA_X >= H_SYNC_PULSE + H_BACK_PORCH) && (VGA_X < H_VISIBLE + H_BACK_PORCH + H_SYNC_PULSE) && (VGA_Y >= V_SYNC_PULSE + V_BACK_PORCH) && (VGA_Y < V_VISIBLE + V_SYNC_PULSE + V_BACK_PORCH);
    assign VGA_HS = ~(VGA_X < H_SYNC_PULSE);
    assign VGA_VS = ~(VGA_Y < V_SYNC_PULSE);
       
    assign VGA_RED = (VGA_VISIBLE ? 15 : 0); //red whenever we are in visible region
    assign VGA_GREEN = ((VGA_VISIBLE && ((VGA_X == H_SYNC_PULSE + H_BACK_PORCH) || (VGA_X == H_VISIBLE + H_BACK_PORCH + H_SYNC_PULSE - 1))) ? 15 : 0); //green/red vertical edges
    assign VGA_BLUE = ((VGA_VISIBLE && ((VGA_Y == V_SYNC_PULSE + V_BACK_PORCH) || (VGA_Y == V_VISIBLE + V_SYNC_PULSE + V_BACK_PORCH - 1))) ? 15 : 0); //blue/red horizontal edges
       
    //at every clock edge
    always @(posedge VGA_CLK)
    begin
        //if enabled
        if(ENABLE) begin
            //increment VGA_X and VGA_Y
            if(VGA_X < H_TOTAL - 1) begin
                VGA_X <= VGA_X + 1;
            end else begin
                VGA_X = 0;
                if(VGA_Y < V_TOTAL - 1) begin
                    VGA_Y <= VGA_Y + 1;
                end else begin
                    VGA_Y <= 0;
                end
            end
        end
       
        if(RESET) begin
            VGA_Y <= 0;
            VGA_X <= 0;
        end
    end
endmodule
Not bad, simple and compact.  If you would take my recommendation, I would recommend these alterations, which may help alleviate you horizontal/vertical picture alignment bug.  (maybe, the problem may be elsewhere which we can discover with another test...)

1.  Make vga_visible (for H&V) = (VGA_X < H_VISIBLE) && (VGA_Y < V_VISIBLE)
Ahhhhh, now your outputs VGA_X and VGA_Y are your actual output visible X&Y coordinates.  Now, for the X, you can use these to feed the address of your dual-port line buffer memory on the output side.
2.  Make VGA_HS = (VGA_X >= H_VISIBLE + H_FRONT_PORCH ) && (VGA_X =< H_VISIBLE + H_FRONT_PORCH + H_SYNC_PULSE) ;
3.  Do the same for VGA_VS.

********  You should only bother going further below this point if you want a real-time software controllable video output generator.

Though, thanks to compiler optimizations, and you are using fixed parameters, your current code works out simple and compact, but, if you want to adjust in real time the video positioning, in one of my old codes, I basically had in the counting loops this:
4 additional latched input regs, HS_start, HS_stop, VS_start, VS_stop, VGA_HS&VS are now output regs instead of wires...(Actually, I personally prefer everything coming out of my modules to be regs so that feeding IOs directly make extra clean clear cut clock timing):

Inside the @posedge clk/if(VGA_X < H_TOTAL - 1) begin
Code: [Select]
if (VGA_X = HS_start) begin
VGA_HS <= 1;
end else if (VGA_X = HS_stop) begin
VGA_HS <= 0;
end
The reason for not placing all the adds and sums inside the '(VGA_X = HS_start)' is since these are no longer constants for the compiler to figure out before wiring logic, any math performed gets converted into gates, versus a simple equality comparator.  Same goes for the adding a latched reg input for H_TOTAL and H_VISIBLE and of course all the Vertical factors.  Having input latched regs gives you that 1 input 14 bit data buss with 3 bit address & WE making 8 internal regs to be latched to create any video format you like.

I know there seems to be only 8 variables of consequence H_total, H_active, HS_start, HS_stop, + VS versions, but you might add 2 more later-on, something like H_genlock & V_genlock which will allow you to set an adjustable offset between the source video frame and the output video frame.  These could be tied into the counters + 1 & an external additional HS&VS input into this module.
__________
BrianHG.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf