If you make OUT high on the PAL video pin, it will enable the ADC which will report its bitstream on IN. Then, use a nearby smart pin in SCOPE mode with the shortest filter and set trigger levels low to trigger on the SYNC dip. Then, another cog can capture the 8-bit sample stream to hub RAM for display, like in the HDMI scope demo. Then, You won't need an oscilloscope. The P2 will do the job.
Love it, but went straight over my head. But the scope mode needs definitely a spin object to attach for debugging of projects.
Still hammered with work, but will have hopefully some P2 time soon.
Oh, I meant just in terms of driver features. Should PAL require a bit more...
Oh ok. Yeah PAL is the problem child for using the most COG RAM space of every output type in this driver due to its special sync needs.
I could yank the mouse or pixel doubling and don't mind doing that for my own testing, but I would like to keep them in of course.
To gain more space I could pull out smaller parts such as cursors or external memory access but don't really want to do that unless I get desperate as it really starts to complicate the resulting code combinations or may require multiple codebases etc. Plus I really like all these features.
The 256 colour palette is a huge user of RAM too and is a candidate to free space, but so useful. I don't want to yank that. If I move to real HDMI with audio it might need to go though.
If you make OUT high on the PAL video pin, it will enable the ADC which will report its bitstream on IN. Then, use a nearby smart pin in SCOPE mode with the shortest filter and set trigger levels low to trigger on the SYNC dip. Then, another cog can capture the 8-bit sample stream to hub RAM for display, like in the HDMI scope demo. Then, You won't need an oscilloscope. The P2 will do the job.
That would be nice to try at some point. I'll have to talk to ozprop about something like this.
@jmg,
looking at your diagram, I think my current method which sends colour bursts up to and including lines 310/623 and resuming on line 7 or 319 should be okay from a phase point of view as the CFRQ oscillator just continues on and nothing gets reset there as such plus I can continue with next setcq update at the next real hsync blanking interval I send and not reset it on each field (I believe the setcq xor flip state is ok there), however I do see one possible thing that could be a problem:
While I imagine leaving the colour bursts running one or two scanlines longer at the end should be ok for the PLL (because it still all remains in phase and following the PAL rules), missing the burst on line 6 on every field number 3 could be problematic if the PLL opens its gate and is expecting a valid colour burst here. I don't start sending it until line 7. Maybe I will try to change it to include starting the burst on all line 6's as well to see if that helps.
UPDATE: I changed the code to start sending colour bursts on line 6 (didn't need any more longs to do this thankfully) and verified it on the scope, but it didn't fix the plasma TV thing with the delayed colour update in the visible portion. I was really hoping this would fix that.
Another idea could be to set up a Smart pin NCO outputting a simple fixed colour burst MHz, and then XOR that with a sliced copy of the burst.
If the smart pin NCO can be started at -180-45', then the XOR flops from 0 to 90'
That would allow check for possible phase disturbances ?
Hey check this out... I was finally able to get the right colour bar sequence by using the second colour burst phase you get for the -V solution! I swear I had tried this combination before but perhaps it needed the other fix with line 6 as well or something else in my code was different at the time of the test. There is still a problem though in that my Dell LCD doesn't like this signal and the plasma takes it's time to lock at the top of frame. But I am happy the colours seem right now and with any luck I can do more fine tuning from this point.
The P1 PAL TV driver seems to send a burst on every non-vsync line (including interlaced half-lines?).
@Wuerfel_21. If so, that seems a bit weird and probably wouldn't be the standard way to do colour bursts. It also seemed when Ltech captured the output from the P1 that the middle scanline in a group of 3 didn't have a proper colour burst either if you look through bmp images in the posted zip file, they were labelled "FlatLumaChroma". Seems like some lovely hires captures from that Tektronix device being used.
Do you have a P1 ready to see whether your TV has problems displaying it?
I could try to set up a P1 I have for trying that (first I need to make breakout pins and setup resistor connector board etc) but that may be a bit of a diversion right now. I may get to it later.
Also, I visited Tubular and ozpropdev this afternoon and we tried a variety of other displays with my P2 PAL colour bar test code I have and got slightly different results when feeding it with composite video.
1) JVL (not JVC) branded low cost LCD TV/monitor, this synced but displayed only what the top of my plasma displays. i.e. not the proper colours my plasma recovered below that. Seems to be the same set of colours though. Picture below.
2) Some generic (can't recall the brand) 4k monitor, basically the same end result as 1).
3) Akai CRT TV. Fed composite into it's AV2 and it displayed bars in grey scale only, would not recover colour
4) DickSmith branded LCD monitor, it was trying hard to display the bars but kept flickering and dropping out before it could get a stable image, still bad colours.
5) Same type of Dell 2405 LCD monitor that I have here (different physical unit) but does the same thing as mine and won't display anything - stays black.
Here is the colour bar PAL test binary if anyone wanted to see if it works on their analog TV inputs.
Install AV board on P8..P15 of P2-EVAL
S-video (Y) signal on output 0 of A/V board
S-video (C) signal on output 1 of A/V board
OR
Composite (CVBS) on output 2 of A/V board
I built it with fastspin/flexgui, but hopefully other tools like loadp2 can download this binary directly into the P2 if you don't have a flexgui setup (I haven't tried that way yet myself). Ozpropdev used PNUT to download it. The P2 PLL rate will get set to 108MHz.
EDIT: this binary has a bug discovered later and fixed, new one in later post is the one that works on my displays.
You question:
"In both your PAL and NTSC oscilloscope captures of three scan lines together, do you know why the middle lines are not showing a full colour burst? That looks strange to me."
Look at the left bottom of the pict.
First is flat , second only luma, third only chroma.
It is busy today but if I get time I make the same measure with a analogue reference pal color bar generator, if we still found an analogue one :-)
But a black burst reference signal we get for sure.
I believe the issue you have is the integrity of the phase of the burst between the fields.
The sequence has to be rock stable.
This is from the analogue time, tubes are drifting and sync on the start of each line.
I believe today , they just check every x lines if the phase is still in sync.
It will explain the first wrong block on you screen
-If I remember, the first couple of lines only contain the burst with no luma/chroma, needed to sync the color decoder between the frames
Yeah I would agree with you @Ltech about the integrity of the phase during the fields. I think I have found something in my code that might be contributing to this but I need to double check. When I reload the cq parameter per field at the start of the vertical back porch for each field, I might also be resetting it incorrectly to the wrong starting value every second field. I just need to check if it is doing that in the code because both fields are treated the same there. This burst stuff is critical to get right.
The latest theory I had seems to be the right one. In my code when the CQ parameter was being read it was overwriting the current CQ state I had been flipping and half the time it would be the wrong value at the start of the field. I set it up once now at startup and don't ever overwrite, just xor it. I'll have to figure out a way to allow it to be dynamic and work with VGA etc but for now this will do.
It also now works on my Dell LCD too. Now I just need to tidy up all these code changes and retest progressive and NTSC stuff.
Attached is the updated P2 colour bar binary with this phase fix. If you get a chance @ozpropdev or @Tubular could you try it out too and let me know if it works on any of your composite displays now?
By the way, the colour at the bottom is just the NTSC colour burst colour as a border which is what the two PAL phases would average to - it is meant to be olive green from what I read so that lines up too.
Here is the colour bar PAL test binary if anyone wanted to see if it works on their analog TV inputs.
Install AV board on P8..P15 of P2-EVAL
Composite (CVBS) on output 2 of A/V board
That tries to work, but does the "I'm confused" dance of rapid Colour / B&W alternate and the Y & B bars are full height (when there), and other 4 split roughly 50% of their height, but with shimmer on the split Y.
I'll try the newer one next...
YEAH!!! FIXED PAL (I think).
It also now works on my Dell LCD too. Now I just need to tidy up all these code changes and retest progressive and NTSC stuff.
Attached is the updated P2 colour bar binary with this phase fix. If you get a chance @ozpropdev or @Tubular could you try it out too and let me know if it works on any of your composite displays now?
By the way, the colour at the bottom is just the NTSC colour burst colour as a border which is what the two PAL phases would average too - it is meant to be olive green from what I read so that lines up too.
Great - Now that one works (CVBS)
I see the olive green and stable bars... - well done.
This Monitor does not have S-Video choice, but it does have YPbPr
S-video looks nicer if you somehow a chance to see it via that output too jmg. Doesn't have the crawl up the colour bars that composite has and looks pretty clean. The YPrPb output was already working before, though I didn't try with proper colour bars and those component colour space parameters have not yet been optimised for PAL - they are still using Chip's NTSC stuff IIRC.
But the composite PAL is getting better now, before I was just using NTSC colour burst so it wasn't real PAL.
S-video looks nicer if you somehow a chance to see it via that output too jmg. Doesn't have the crawl up the colour bars that composite has and looks pretty clean. ..
But the composite PAL is getting better now, before I was just using NTSC colour burst so it wasn't real PAL.
I've located another Monitor with S-Video - now, I just need to find or make a cable
The CVBS looks remarkably free from crawl effects, but I'll check S-Video as that should allow higher BW Y.
That's great that you got it whipped, Rogloh. Now just clean it up and pack it tight.
Yep, I'm fairly confident I'll make this PAL change fit without too much effort compressing things further.
I don't think the PAL fixes so far should add more than perhaps one or two more instructions. Luckily I am also able to fit the line 6 change into the existing footprint, I just need to patch one call address upon relocation of the PAL sync code because I don't think using my preferred callpa #1, #\blank form is possible. That instruction needs relative addresses instead (callpa #1, #blank) which breaks after the relocation when the call jumps to the wrong place, however if I patch this address up after relocating the code I can save an instruction which pays for one change. The setcq change needs slightly more effort if it remains dynamic but won't be too bad. I might just need to lock down the initial CQ value in PAL mode and not update it afterwards. Doing that would only add perhaps 1 more instruction, but wouldn't let dynamic CQ saturation/brightness type changes be applied with PAL. I'll see how it works out. Perhaps there is a way to allow it to be dynamic even with PAL. It may just need a second xor on odd/even frames.
I've located another Monitor with S-Video - now, I just need to find or make a cable
The CVBS looks remarkably free from crawl effects, but I'll check S-Video as that should allow higher BW Y.
Yeah try to make a cable if you have the parts to solder up the s-video inline socket or cable plug to some RCA plugs.
I do get some amount of colour crawl still on the LCD in CVBS output but S-video is really nice. I've not focussed on the pixel clock/colour clock sync so much at this point, mainly the colour phase which was until now very broken, so there could still be some timing work to do there too, but ideally it should now be with parameters and not the driver code with any luck. The driver can take independent XFRQ and CFRQ values and pixel timing can be finely tweaked. Right now there is no XZERO at all in composite/s-video modes (it gets removed in the patching stage with PAL/NTSC output) so perhaps the frame will glitch slightly from time to time and the colour will slowly slip. If any additional XZEROs are needed for fixing this they would add some instruction(s). TBD.
You may be able to almost get rid of the dot crawl by hand tweaking the SETXFRQ value up or down to lower the beat frequency. It seems to me, that for PAL, you may not want to use an XZERO anywhere, so that you can work on the SETCFRQ vs SETXFRQ relationship. You can move those values around quite a bit to eliminate beat frequencies, before you get either too out of spec.
Is there a single instruction you can use to effectively set Z,C from the bottom two bits of a register without destroying the register?
I am trying to pack in the PAL code with dynamic CQ update and have found after the update I need to do an XOR not on odd/even fields as I had first thought but actually on fields 2,3 out of the 1,2,3,4,1,2,3,4 counting sequence. This means that I need to do a if_c_ne_z type of conditional instruction if Z,C are extracted from the bottom two bits of the field counter.
I am already setting up the C flag based on the field counter LSB which I need to use for some decisions and I'd like to find an instruction to leverage it and also set Z somehow to gain information about the 2nd bit (or C/Z can be swapped around). I was looking at that MODCZ one, and RCZR D WCZ but that destroys the D and I don't want to destroy my field counter.
TEST D, #3 WCZ doesn't quite do what I want either, because I think the odd/even information is lost.
Is there a way or do this or do I need to keep the extra instruction? I vaguely recall there was a way to do this. Perhaps that was on the P1. What am I forgetting?
testb fieldcount, #0 wc 'field interlace state odd/even
if_c call #\hsync 'deal with interlaced field lines
if_c xcont m_slim, hsync0 'send a slim half line
... '<snip> C is retained through other code running here, Z is unused throughout
testb fieldcount, #1 wz <---- I want to get rid of this line
pal0 if_c_ne_z xor cq, palflipcq
Ok. Thought it might be the case. If that's right it turns out yesterday's PAL fixes will take either:
2 extra instructions for no-dynamic reload of CQ after startup in PAL mode, leaving 3 spare from my 5.
3 extra instructions for a dynamic per field reload capability of CQ, leaving only 2 spare!
Dynamic CQ could allow hue/saturation/brightness changes on the fly and could be useful. I'd still quite like to include this capability for all analog output modes.
I'm looking for anything else I can do to save these instructions. I haven't exhausted it all yet. I am doing the XOR in 3 places which I don't like and am checking to see if possibly two could be merged.
Comments
Love it, but went straight over my head. But the scope mode needs definitely a spin object to attach for debugging of projects.
Still hammered with work, but will have hopefully some P2 time soon.
Mike
I could yank the mouse or pixel doubling and don't mind doing that for my own testing, but I would like to keep them in of course.
To gain more space I could pull out smaller parts such as cursors or external memory access but don't really want to do that unless I get desperate as it really starts to complicate the resulting code combinations or may require multiple codebases etc. Plus I really like all these features.
The 256 colour palette is a huge user of RAM too and is a candidate to free space, but so useful. I don't want to yank that. If I move to real HDMI with audio it might need to go though.
That would be nice to try at some point. I'll have to talk to ozprop about something like this.
looking at your diagram, I think my current method which sends colour bursts up to and including lines 310/623 and resuming on line 7 or 319 should be okay from a phase point of view as the CFRQ oscillator just continues on and nothing gets reset there as such plus I can continue with next setcq update at the next real hsync blanking interval I send and not reset it on each field (I believe the setcq xor flip state is ok there), however I do see one possible thing that could be a problem:
While I imagine leaving the colour bursts running one or two scanlines longer at the end should be ok for the PLL (because it still all remains in phase and following the PAL rules), missing the burst on line 6 on every field number 3 could be problematic if the PLL opens its gate and is expecting a valid colour burst here. I don't start sending it until line 7. Maybe I will try to change it to include starting the burst on all line 6's as well to see if that helps.
UPDATE: I changed the code to start sending colour bursts on line 6 (didn't need any more longs to do this thankfully) and verified it on the scope, but it didn't fix the plasma TV thing with the delayed colour update in the visible portion. I was really hoping this would fix that.
If the smart pin NCO can be started at -180-45', then the XOR flops from 0 to 90'
That would allow check for possible phase disturbances ?
The P1 PAL TV driver seems to send a burst on every non-vsync line (including interlaced half-lines?).
Do you have a P1 ready to see whether your TV has problems displaying it?
I could try to set up a P1 I have for trying that (first I need to make breakout pins and setup resistor connector board etc) but that may be a bit of a diversion right now. I may get to it later.
Also, I visited Tubular and ozpropdev this afternoon and we tried a variety of other displays with my P2 PAL colour bar test code I have and got slightly different results when feeding it with composite video.
1) JVL (not JVC) branded low cost LCD TV/monitor, this synced but displayed only what the top of my plasma displays. i.e. not the proper colours my plasma recovered below that. Seems to be the same set of colours though. Picture below.
2) Some generic (can't recall the brand) 4k monitor, basically the same end result as 1).
3) Akai CRT TV. Fed composite into it's AV2 and it displayed bars in grey scale only, would not recover colour
4) DickSmith branded LCD monitor, it was trying hard to display the bars but kept flickering and dropping out before it could get a stable image, still bad colours.
5) Same type of Dell 2405 LCD monitor that I have here (different physical unit) but does the same thing as mine and won't display anything - stays black.
Install AV board on P8..P15 of P2-EVAL
S-video (Y) signal on output 0 of A/V board
S-video (C) signal on output 1 of A/V board
OR
Composite (CVBS) on output 2 of A/V board
I built it with fastspin/flexgui, but hopefully other tools like loadp2 can download this binary directly into the P2 if you don't have a flexgui setup (I haven't tried that way yet myself). Ozpropdev used PNUT to download it. The P2 PLL rate will get set to 108MHz.
EDIT: this binary has a bug discovered later and fixed, new one in later post is the one that works on my displays.
You question:
"In both your PAL and NTSC oscilloscope captures of three scan lines together, do you know why the middle lines are not showing a full colour burst? That looks strange to me."
Look at the left bottom of the pict.
First is flat , second only luma, third only chroma.
It is busy today but if I get time I make the same measure with a analogue reference pal color bar generator, if we still found an analogue one :-)
But a black burst reference signal we get for sure.
I believe the issue you have is the integrity of the phase of the burst between the fields.
The sequence has to be rock stable.
This is from the analogue time, tubes are drifting and sync on the start of each line.
I believe today , they just check every x lines if the phase is still in sync.
It will explain the first wrong block on you screen
-If I remember, the first couple of lines only contain the burst with no luma/chroma, needed to sync the color decoder between the frames
page 14
"To achieve an SC/H phased plant, the timing of sync becomes as important as subcarrier"
The latest theory I had seems to be the right one. In my code when the CQ parameter was being read it was overwriting the current CQ state I had been flipping and half the time it would be the wrong value at the start of the field. I set it up once now at startup and don't ever overwrite, just xor it. I'll have to figure out a way to allow it to be dynamic and work with VGA etc but for now this will do.
It also now works on my Dell LCD too. Now I just need to tidy up all these code changes and retest progressive and NTSC stuff.
Attached is the updated P2 colour bar binary with this phase fix. If you get a chance @ozpropdev or @Tubular could you try it out too and let me know if it works on any of your composite displays now?
By the way, the colour at the bottom is just the NTSC colour burst colour as a border which is what the two PAL phases would average to - it is meant to be olive green from what I read so that lines up too.
That tries to work, but does the "I'm confused" dance of rapid Colour / B&W alternate and the Y & B bars are full height (when there), and other 4 split roughly 50% of their height, but with shimmer on the split Y.
I'll try the newer one next...
Great - Now that one works (CVBS)
I see the olive green and stable bars... - well done.
This Monitor does not have S-Video choice, but it does have YPbPr
But the composite PAL is getting better now, before I was just using NTSC colour burst so it wasn't real PAL.
I've located another Monitor with S-Video - now, I just need to find or make a cable
The CVBS looks remarkably free from crawl effects, but I'll check S-Video as that should allow higher BW Y.
Tested on 2 LCD monitors. Both Ok.
Digging out 2 CRT's now....
I don't think the PAL fixes so far should add more than perhaps one or two more instructions. Luckily I am also able to fit the line 6 change into the existing footprint, I just need to patch one call address upon relocation of the PAL sync code because I don't think using my preferred callpa #1, #\blank form is possible. That instruction needs relative addresses instead (callpa #1, #blank) which breaks after the relocation when the call jumps to the wrong place, however if I patch this address up after relocating the code I can save an instruction which pays for one change. The setcq change needs slightly more effort if it remains dynamic but won't be too bad. I might just need to lock down the initial CQ value in PAL mode and not update it afterwards. Doing that would only add perhaps 1 more instruction, but wouldn't let dynamic CQ saturation/brightness type changes be applied with PAL. I'll see how it works out. Perhaps there is a way to allow it to be dynamic even with PAL. It may just need a second xor on odd/even frames.
Yeah try to make a cable if you have the parts to solder up the s-video inline socket or cable plug to some RCA plugs.
I do get some amount of colour crawl still on the LCD in CVBS output but S-video is really nice. I've not focussed on the pixel clock/colour clock sync so much at this point, mainly the colour phase which was until now very broken, so there could still be some timing work to do there too, but ideally it should now be with parameters and not the driver code with any luck. The driver can take independent XFRQ and CFRQ values and pixel timing can be finely tweaked. Right now there is no XZERO at all in composite/s-video modes (it gets removed in the patching stage with PAL/NTSC output) so perhaps the frame will glitch slightly from time to time and the colour will slowly slip. If any additional XZEROs are needed for fixing this they would add some instruction(s). TBD.
Dusted off 2 CRT monitors, PAL colour bars look fine.
Nice work!
The avermedia capture device is happy to display it in mono, and its 'signal' light comes on, which is encouraging
Well done
I am trying to pack in the PAL code with dynamic CQ update and have found after the update I need to do an XOR not on odd/even fields as I had first thought but actually on fields 2,3 out of the 1,2,3,4,1,2,3,4 counting sequence. This means that I need to do a if_c_ne_z type of conditional instruction if Z,C are extracted from the bottom two bits of the field counter.
I am already setting up the C flag based on the field counter LSB which I need to use for some decisions and I'd like to find an instruction to leverage it and also set Z somehow to gain information about the 2nd bit (or C/Z can be swapped around). I was looking at that MODCZ one, and RCZR D WCZ but that destroys the D and I don't want to destroy my field counter.
TEST D, #3 WCZ doesn't quite do what I want either, because I think the odd/even information is lost.
Is there a way or do this or do I need to keep the extra instruction? I vaguely recall there was a way to do this. Perhaps that was on the P1. What am I forgetting?
testb fieldcount, #0 wc 'field interlace state odd/even if_c call #\hsync 'deal with interlaced field lines if_c xcont m_slim, hsync0 'send a slim half line ... '<snip> C is retained through other code running here, Z is unused throughout testb fieldcount, #1 wz <---- I want to get rid of this line pal0 if_c_ne_z xor cq, palflipcq2 extra instructions for no-dynamic reload of CQ after startup in PAL mode, leaving 3 spare from my 5.
3 extra instructions for a dynamic per field reload capability of CQ, leaving only 2 spare!
Dynamic CQ could allow hue/saturation/brightness changes on the fly and could be useful. I'd still quite like to include this capability for all analog output modes.
I'm looking for anything else I can do to save these instructions. I haven't exhausted it all yet. I am doing the XOR in 3 places which I don't like and am checking to see if possibly two could be merged.