Here are all three files, modified to add component video option NTSC or PAL. (Attached) I'm removing the duplicate file above.
On my analog displays, having video data in the first few scans seems to cause display trouble, but only on some analog devices. My old high resolution CRT is fine. The 80's era CRT is crappy. My newer component analog TV is almost fine. I won't be able to run this on an HDTV tonight, but maybe one of you can.
I think it will display just fine. IMHO, older analog TV's aren't expecting to see anything in that early part of the frame and it's messing with their AGC circuit, but that's just a guess.
The tiger displays great, as do a couple of the low intensity ones. IMHO, this driver is great, and if it's to be used with analog displays, some "safe area" is still needed from what I can tell.
Check out the hood effect on the car, and texture on Superman! Composite mangles those a little. Lots of little details pop on the component display.
***I tried editing some of the images to put a black strip up top to figure out where the boundary is. They didn't process correctly after that. Is there a trick here? I just quickly used MSPAINT, and yeah I know better.
Well, thank Jim. He's knocked it out of the park with the SDRAM driver! All I did was add a little here and there to make the component option available.
**While testing these for component, I love that we can keep data in the machine, and even in the SDRAM for a period of time. My experience is a few seconds with the SDRAM before it starts to degrade. Most of the image is still there, just with some speckles in it after that. Once the big load is done, one can just fire off the slideshow.spin file over and over. At first, I thought this a negative feature, but honestly it's a great feature given the larger sets of data we are going to be working with.
@Sapieha: Does your PAL TV demonstrate some image shift at the top of the screen on either component or composite?
Actually, if you run it NTSC, does it do any of that in monochrome?
Hi potatohead, I'm having trouble with the component syncing it's juddering, I'll try a few other monitors, to see if it's just this monitor that doesn't like it.
Wow! I've never seen such sharp pictures via NTSC composite before. These are amazing! The interlacing really delivers the details.
I'm getting the tearing, too, though, and I'm looking at the video signal on my scope now. The tearing may be caused by there being only 5-5-5 vertical serration pulses, which is PAL signalling. NTSC specifies 6-6-6. If that were to be fixed, it might get rid of the tearing. The signal seems very stable, in any case, so it must be the vertical pulses that are causing the tearing. My Agilent scope has an NTSC mode and it gets confused when trying to show lines by number, because it's not getting the expected vertical pulses. When I put it into PAL mode, though, it can make sense of the signal.
Here is a drawing of NTSC signalling:
Once the signalling is being done correctly, there won't be any issues with particular monitors.
Thanks Chip, glad you like it, amazing the picture clarity isn't it!
Thanks for the NTSC timings, I'll get on it this evening
I tried to change it myself, already, but I got the frames out of sync when I changed the constants. You will be much better at straightening this out.
And, yes, the clarity is like nothing I've seen before, not even from gaming consoles. It might be because they blur their output, intentionally, to minimize the harsh flicker that high-contrast interlacing produces. Wait... that's not it. They all use progressive scan to avoid the flicker, altogether, at the expense of half the vertical resolution. I really like the detail, though. It has to be seen to be believed. It's like HDTV.
Correction, one other device would do that: A PS2 running component looks very similar. That thing also had a great signal, but it had a crappy optical disk. I've since ditched it and moved on, but it's the only thing I've seen close.
Wow! I've never seen such sharp pictures via NTSC composite before. These are amazing!...........
Hi praise indeed and it's the same (if not better) for PAL :cool:
When Jim first showed me this I had that same Wow! moment, I've tried this on all of my monitors and TV's and it's first class on all of them.
If the real silicon performs as well as this (and I'm sure it will) you will have a sure fire hit on your hands.
We already have plans in place for a product or two so fingers crossed the shuttle run is a success too.
Hi praise indeed and it's the same (if not better) for PAL :cool:
When Jim first showed me this I had that same Wow! moment, I've tried this on all of my monitors and TV's and it's first class on all of them.
If the real silicon performs as well as this (and I'm sure it will) you will have a sure fire hit on your hands.
We already have plans in place for a product or two so fingers crossed the shuttle run is a success too.
Coley.
If the real silicon works, it will be better than this, as the DACs will be monotonic (these FPGA R-2R implementations are not that great). Also, the silicon DACs will be 75-ohm, whereas these FPGA DACs are 47-ohm, so they are outputting in a much more limited span than the chip's DACs will be, in order to get 1V into a 75-ohm load.
I'm quite sure that the reason this video looks so good is because of the interlacing and the absence of MPEG compression. If, for some magical reason, it IS the Prop2, that's all the better.
Can you give the new driver a try for NTSC timing?
It's the TV_SDRAM_Driver.spin in the first post.
Cheers,
Jim.
I'm still getting tearing at the top. The vertical pulses are correct now, but I see some minor timing differences between the display lines and serration pulses, but not seemingly enough to cause such tearing. Still looking...
Cheers, for the feedback, I will try again tomorrow, going to bed now
I see that there needs to be half a line of rest after the last short serration pulse on one of the fields, instead of a new scan line starting right away.
What I did was ( assuming it would be blank ) let it do a normal blank scan line.
I made the vertical sync sections look they should last night, but there was still tearing. I'm not sure what the trouble is. I suspect that some timing/sequence might have gotten dragged from the original PAL implementation into the NTSC. As I recall, PAL was difficult to implement and had some timing nuances that were absent from NTSC. I'll play with it more today.
I have time this evening. If it is not fixed by then, can you and or Jim post up a wip driver?
One thing I noticed was the first image is a partial frame, and it displays fine. It is the full frame ones that tear. I'm wondering whether or not the HSYNC isn't a bit wonky.
@Baggers: I have had no luck generating or editing images. Would be nice to know what the trouble is, but all I need is a simple monochrome image of a intensity ramp, or maybe two. One going from black at top to white at bottom, and the other going from white at top to black at bottom, both full frame.
I have time this evening. If it is not fixed by then, can you and or Jim post up a wip driver?
One thing I noticed was the first image is a partial frame, and it displays fine. It is the full frame ones that tear. I'm wondering whether or not the HSYNC isn't a bit wonky.
@Baggers: I have had no luck generating or editing images. Would be nice to know what the trouble is, but all I need is a simple monochrome image of a intensity ramp, or maybe two. One going from black at top to white at bottom, and the other going from white at top to black at bottom, both full frame.
Or let me know what I can use to make images. .
Doug,
I'm not certain this is what you want but hopefully it's somewhere near.
To make an image .bin file, first create the image (I used photoshop) as 720x576 resolution, then expand the canvas size (to the right of the image) to 768x576 and save as 32 Bit BMP.
Then you convert the .bmp file to .bin using:- p2prep filename.bmp filename.bin -b32
Youtube video looks amazing. Do you have any sense of Dot crawl or any other nasty artifacts on a PAL signal. Have you had a chance to view this on a analogue composite in device yet? This could be the device... Think what asking someone to do is put this signal in to a Sony PVM or similar that is not expecting a hacked around NTSC signal that a standard TV will sort out internally. We seem to think is a straight PAL signal. Sorry to be always so difficult.
Hi Mike_GTN, long time no see on the forum, hope you are good and well
This driver is not a hacked NTSC to get PAL, this driver was written primarily as PAL, with PAL timings, my daughter is going out today, so I will be able to have a look at it on her tv and let you know.
Comments
On my analog displays, having video data in the first few scans seems to cause display trouble, but only on some analog devices. My old high resolution CRT is fine. The 80's era CRT is crappy. My newer component analog TV is almost fine. I won't be able to run this on an HDTV tonight, but maybe one of you can.
I think it will display just fine. IMHO, older analog TV's aren't expecting to see anything in that early part of the frame and it's messing with their AGC circuit, but that's just a guess.
The tiger displays great, as do a couple of the low intensity ones. IMHO, this driver is great, and if it's to be used with analog displays, some "safe area" is still needed from what I can tell.
Check out the hood effect on the car, and texture on Superman! Composite mangles those a little. Lots of little details pop on the component display.
***I tried editing some of the images to put a black strip up top to figure out where the boundary is. They didn't process correctly after that. Is there a trick here? I just quickly used MSPAINT, and yeah I know better.
Thanks
**While testing these for component, I love that we can keep data in the machine, and even in the SDRAM for a period of time. My experience is a few seconds with the SDRAM before it starts to degrade. Most of the image is still there, just with some speckles in it after that. Once the big load is done, one can just fire off the slideshow.spin file over and over. At first, I thought this a negative feature, but honestly it's a great feature given the larger sets of data we are going to be working with.
@Sapieha: Does your PAL TV demonstrate some image shift at the top of the screen on either component or composite?
Actually, if you run it NTSC, does it do any of that in monochrome?
"@Sapieha: Does your PAL TV demonstrate some image shift at the top of the screen on either component or composite?
Actually, if you run it NTSC, does it do any of that in monochrome? "
Will made tomorrow one PIC - so You can see how it looks Both in PAL and NTSC
Cheers,
Jim.
I'm getting the tearing, too, though, and I'm looking at the video signal on my scope now. The tearing may be caused by there being only 5-5-5 vertical serration pulses, which is PAL signalling. NTSC specifies 6-6-6. If that were to be fixed, it might get rid of the tearing. The signal seems very stable, in any case, so it must be the vertical pulses that are causing the tearing. My Agilent scope has an NTSC mode and it gets confused when trying to show lines by number, because it's not getting the expected vertical pulses. When I put it into PAL mode, though, it can make sense of the signal.
Here is a drawing of NTSC signalling:
Once the signalling is being done correctly, there won't be any issues with particular monitors.
Thanks for the NTSC timings, I'll get on it this evening
Thanks for looking Chip. Ha! So we have a hybrid driver at the moment. If that's all it is, sweet.
I tried to change it myself, already, but I got the frames out of sync when I changed the constants. You will be much better at straightening this out.
And, yes, the clarity is like nothing I've seen before, not even from gaming consoles. It might be because they blur their output, intentionally, to minimize the harsh flicker that high-contrast interlacing produces. Wait... that's not it. They all use progressive scan to avoid the flicker, altogether, at the expense of half the vertical resolution. I really like the detail, though. It has to be seen to be believed. It's like HDTV.
I'll fix it in a bit, as we're about to have tea
Hi praise indeed and it's the same (if not better) for PAL :cool:
When Jim first showed me this I had that same Wow! moment, I've tried this on all of my monitors and TV's and it's first class on all of them.
If the real silicon performs as well as this (and I'm sure it will) you will have a sure fire hit on your hands.
We already have plans in place for a product or two so fingers crossed the shuttle run is a success too.
Coley.
If the real silicon works, it will be better than this, as the DACs will be monotonic (these FPGA R-2R implementations are not that great). Also, the silicon DACs will be 75-ohm, whereas these FPGA DACs are 47-ohm, so they are outputting in a much more limited span than the chip's DACs will be, in order to get 1V into a 75-ohm load.
I'm quite sure that the reason this video looks so good is because of the interlacing and the absence of MPEG compression. If, for some magical reason, it IS the Prop2, that's all the better.
Can you give the new driver a try for NTSC timing?
It's the TV_SDRAM_Driver.spin in the first post.
Cheers,
Jim.
I'm still getting tearing at the top. The vertical pulses are correct now, but I see some minor timing differences between the display lines and serration pulses, but not seemingly enough to cause such tearing. Still looking...
Ah, there's only 5 trailing serration pulses on one the fields - so we're getting a whole half line of tearing.
I see that there needs to be half a line of rest after the last short serration pulse on one of the fields, instead of a new scan line starting right away.
I made the vertical sync sections look they should last night, but there was still tearing. I'm not sure what the trouble is. I suspect that some timing/sequence might have gotten dragged from the original PAL implementation into the NTSC. As I recall, PAL was difficult to implement and had some timing nuances that were absent from NTSC. I'll play with it more today.
One thing I noticed was the first image is a partial frame, and it displays fine. It is the full frame ones that tear. I'm wondering whether or not the HSYNC isn't a bit wonky.
@Baggers: I have had no luck generating or editing images. Would be nice to know what the trouble is, but all I need is a simple monochrome image of a intensity ramp, or maybe two. One going from black at top to white at bottom, and the other going from white at top to black at bottom, both full frame.
Or let me know what I can use to make images.
Doug,
I'm not certain this is what you want but hopefully it's somewhere near.
Gradients.rar
To make an image .bin file, first create the image (I used photoshop) as 720x576 resolution, then expand the canvas size (to the right of the image) to 768x576 and save as 32 Bit BMP.
Then you convert the .bmp file to .bin using:- p2prep filename.bmp filename.bin -b32
hope that helps....
Coley
Youtube video looks amazing. Do you have any sense of Dot crawl or any other nasty artifacts on a PAL signal. Have you had a chance to view this on a analogue composite in device yet? This could be the device... Think what asking someone to do is put this signal in to a Sony PVM or similar that is not expecting a hacked around NTSC signal that a standard TV will sort out internally. We seem to think is a straight PAL signal. Sorry to be always so difficult.
Thank-you
Mike.
This driver is not a hacked NTSC to get PAL, this driver was written primarily as PAL, with PAL timings, my daughter is going out today, so I will be able to have a look at it on her tv and let you know.
Cheers,
Jim.