“This PVM has a "Blue Only" mode, I've not used much. Holy moly! I know what it's for now. Shows phase error like a sore thumb. I'll have to get a photo.”
Back in the day when I used to work around TV studios, we would use a standard set of color bars and Blue Only mode to quickly set up a color monitor. With blue only mode you can quickly set hue and saturation by balancing the bars.
Maybe this can be an aid to you fellows designing display software.
Jim
Yes, that was shown to me by the person who gave me the PVM. That's fast and clever.
It has the side effect of highlighting our chroma phase challenges. Stands right out. My plan for it was to use it to help with what I will call the 15Khz project. It has TTL, RGB, S-video, composite. I'll get a component converter for it. And will set the yoke right this weekend. That tilt annoys me, but it's also why I got the thing. Easy peasy.
@potatohead (or anyone who has used this driver so far), on your revB board, which I presume is a normal P2-EVAL board with a production packaged P2 (non-glob top), when you run the complexdemo on your monitor do you see the text regions along the entire width of the screen or just on the right side with some flashing/scrolling coloured vertical stripes/bars filling the left/middle of screen in the text region? I'm tracking down an issue I see between my glob-top and production packaged revB boards that behave quite differently with the exact same code. During development of this driver on the glob-top board, I didn't ever encounter this issue and can't make it happen there, but started noticing it a few days back when I ran on the production packaged board mostly everyone else uses.
Right now I see different behaviour on the screen in text regions. It may just be streamer timing initialisation or hub RAM related, still trying to get to the bottom of it in case I am using uninitialized hub data somewhere (don't think I am). I only have a sample size of 2 boards here so it may not be glob/non-glob difference, but just different startup+PLL timing or random hub data between different P2's (I hope). Occasionally the non-glob top P2 board works as expected, but the majority (>90%) of times I download it causes this issue - which is helpful to be able to reproduce it for debug. It's weird.
First I thought this was overclock related as ozpropdev mentioned his glob-top chip overclocks a bit more than the standard packaged one, but I see it also on normal SDTV output running the P2 at 100MHz or so, so it doesn't appear to be related to the clock speed.
When I account for the 16 pixel side border size it look like the bad version is reading rendered text from memory 64 longs later than it should which could well indicate a fifo setup issue somewhere, but it is strange it works reliably on the original glob top based P2-EVAL board.
Aha, just noticed something. On my RevB normal P2 package board that was failing the complex demo before, I also had the HDMI breakout board plugged into P32-P39 pins but it is not fitted there on the glob top board right now, and whenever it was fitted on that board for earlier testing it was on P24-P31. The A/V breakout for VGA was always on P8-P15 on both boards. That was another difference between setups.
Now when I yank this HDMI breakout out on the new non-glob top board, the VGA output screen works okay. When I add it back, the 64 character offset appears in text regions next time I download the image (it appears to be consistent behaviour). This is really strange as I am not even driving these DVI pins from code in this case (or don't think I am), so maybe the extra current load or noise the cable introduces somehow couples in and affects the fifo read position at startup. If I just disconnect the DVI cable from the monitor end, it also works. WTH? How can this have an effect? Some additional small delay at startup? Voltage differences between Port A and Port B?
Update: with the DVI cable plugged into the Dell monitor (with VGA as well), there appears to be less noise than without. That wide DVI earth connector might be helping. I measured about 60mV p-p noise on the V0815 IO pins of the VGA and 90mV without it the DVI plugged in.
Update2: if I move the HDMI breakout on the new board to pins 24-31 where I used to have it on the original board, the VGA output works fine too, so this has nothing to do with glob-top vs production package. (I think I had moved it up to pins 32-39 recently to be able to quickly run Chip's oscilloscope demo). I'll try it on other port B pins to see if it is a portA/portB loading thing.
1) Both glob-top and non-glob top boards behave the same.
2) I get the VGA text problem only when the HDMI accessory board is plugged into pins 32-39 AND connected to my Dell monitor at the other end of the cable.
3) I have moved the HDMI accessory board to other positions i.e. pins 0-7, 16-23, 24-31, 40-47, 48-55 and this problem did NOT appear. I couldn't fit it 8-15 because the VGA board was operating from there and I didn't want to put it into 56-63.
So something is special about the load on low byte of port B and startup timing. I have to check my code for anything it might be doing like polling these pins at startup etc which could introduce a delay, but I don't think it should be (no need to).
I hope it is not a fastspin thing, perhaps something is buried in there. I can only easily check my own code.
Update:
4) The problem also appears on the DVI screen video output (if I modify the code to send over that instead of VGA) when the HDMI breakout board is plugged into port pins 32-39, regardless of the presence of A/V breakout board connection. Something in my code seems timing sensitive to having a load on pins 32-39.
Chip has used these HDMI output pins okay in his oscilloscope demo though of course that's going to be rather different code.
Update:
5) if the A/V accessory board is plugged into pin 32-39 with nothing else fitted, I get the problem again on VGA, but it has stripes over all the text regions. There is no normal text shown.
It is sounding like a software bug. Maybe a missing # or uninitialised variable.
EDIT: Whoa, that's a lot of conditional execution! Just looked for the first time. The zip file I've got is from the 21st November. Is there an up to date one?
It is sounding like a software bug. Maybe a missing # or uninitialised variable.
EDIT: Whoa, that's a lot of conditional execution! Just looked for the first time. The zip file I've got is from the 21st November. Is there an up to date one?
I've been testing/adding a couple of things for the next (beta?) release related to NTSC but that zipfile you looked at is still valid for now and causes the problem if you put the board on P32-P39.
I'd agree with an uninitialised variable being a symptom. I will try to print out the key state variables to the screen down the remaining right side on region change to text mode to compare good with bad. Might show up something. I realized that if you subtract $100 from the line buffer it might mean the text scanline could operate that way. Perhaps there is a long that has bit8 state still setup from prior execution and it is a 1 or a 0 depending on the presence of the load on port B and this causes the extra $100 hex to be added in...?
I didn't see that problem. Only ran one input at a time, only that board connected. I saw the good case. Non-glob top.
Thanks for checking potatohead. I think you'd need to put the A/V board on pins 32-39 to make it happen if you only have one board. If you used other pins, it doesn't happen.
I am also going to try pulling up pins 32-39 one at a time to see if they cause a problem. The terminated HDMI board would likely see a logic high when plugged into a monitor. I guess P2 pins float low.
I've been testing/adding a couple of things for the next (beta?) release related to NTSC but that zipfile you looked at is still valid for now and causes the problem if you put the board on P32-P39.
Ah, right, yep, getting the problem now I've tried. It happens with the simple text demo too.
Roger
I'm seeing the fault on both globtop and production boards with board on pin group 32.
Yes. That's in agreement.
The save & ptrb stuff in my code related to the linebuf1 pointer and its hub writes and fifo reads needs careful checking as it was recently optimized to save a long, but I think it should be good. I still cannot yet fathom how any inb pin states would affect it, but they must somehow. I will try to print these values in good and bad cases. The line buffer is shared with graphics regions and they still work okay so that variable should be fine.
Kind of lucky I stumbled onto this. You need to use a specific port group to even encounter it.
I think I just fried my glob top board VIO supply with my latest test. :frown: I wanted to pull each pin high on each pin from 32-39 so I got two female jumper breakout board cables and put a 680 ohm resistor in the middle then jumpered VIO to each pin. At one point from the jumper cable spring the partially exposed resistor leg metal scraped over the nearby earthing pin post and looks like it shorted VIO very briefly. Now after power off and repower I measure the board supply VIO voltage and it is only 0.28V or so. Looks dead and nothing downloads to the board! Damn. It was not the 5V as that is off. It was the ground post.
Repeated this test (extremely carefully) on my remaining production board and wasn't able to reproduce the problem by pulling only one pin from 32-39 high at a time, so it must need a different combination. I am not going to go further there. Too risky.
I think I just fried my glob top board VIO supply with my latest test. :frown: I wanted to pull each pin high on each pin from 32-39 so I got two female jumper breakout board cables and put a 680 ohm resistor in the middle then jumpered VIO to each pin. At one point from the jumper cable spring the partially exposed resistor leg metal scraped over the nearby earthing pin post and looks like it shorted VIO very briefly. Now after power off and repower I measure the board supply VIO voltage and it is only 0.28V or so. Looks dead and nothing downloads to the board! Damn. It was not the 5V as that is off. It was the ground post.
Is that a revB board? If so then the most likely failure is the LDO regulator. The prop2 is probably fine.
Rogloh, I wonder what happenef. It sounds like the local LDO is trying to deliver 3.3V, but it's getting pulled down exceedingly hard by maybe an internal short in the P2.
Yes it is a revB EVAL board - so the VIO supply looks very vulnerable. It was just for the briefest of moments touching ground so BE CAREFUL with your boards. I need to look at the schematic to see if I can work out what is dead.
Rogloh, I wonder what happenef. It sounds like the local LDO is trying to deliver 3.3V, but it's getting pulled down exceedingly hard by maybe an internal short in the P2.
This other stuff sounds like a software bug.
I will tell you what happened. A jumper wire from V3239 touched the large grounding post next to it for maybe 0.3seconds as a cable flicked past it and the screen went off. At that point I don't believe I had even touched any P2 pins with the other end, and if I did they were via the 680 ohm resistor.
Hopefully just the LDO and I might replace it with help from Tubular/ozprop. In the meantime I am lucky I have the 2nd working board. It does worry me that the VIO supply is not robust against brief shorts to ground as other people might hit this quite easily if working with pins.
Well I measured some of the other VIO and they were also bad (very low voltage). I need to measure all of it again to see what is up, I might be lucky and see it come back to life....
Yes it is a revB EVAL board - so the VIO supply looks very vulnerable. It was just for the briefest of moments touching ground so BE CAREFUL with your boards. I need to look at the schematic to see if I can work out what is dead.
Those LDO's have a good amount of thermal shutdown protection. They seem designed to be safe and indestructable. It would be good to measure the current going into all LDO's, which there is a jumper for. Are other LDO's outputting 3.3V? If the LDO input current is light, maybe just that LDO failed. If there is a huge current, the P2 might have developed an internal short.
Well I measured some of the other VIO and they were also bad (very low voltage). I need to measure all of it again to see what is up, I might be lucky and see it come back to life....
Oh, that means that LDO is shorting its supply too, and is preventing the 5V_Common from coming up.
Well it is powered from my Mac laptop so hopefully it would be protected against overloads. I don't have one of those inline USB meters that shows current draw so it is hard to know what current is being drawn unless I can feed in power separately to USB somehow.
Comments
Yes, that was shown to me by the person who gave me the PVM. That's fast and clever.
It has the side effect of highlighting our chroma phase challenges. Stands right out. My plan for it was to use it to help with what I will call the 15Khz project. It has TTL, RGB, S-video, composite. I'll get a component converter for it. And will set the yoke right this weekend. That tilt annoys me, but it's also why I got the thing. Easy peasy.
Right now I see different behaviour on the screen in text regions. It may just be streamer timing initialisation or hub RAM related, still trying to get to the bottom of it in case I am using uninitialized hub data somewhere (don't think I am). I only have a sample size of 2 boards here so it may not be glob/non-glob difference, but just different startup+PLL timing or random hub data between different P2's (I hope). Occasionally the non-glob top P2 board works as expected, but the majority (>90%) of times I download it causes this issue - which is helpful to be able to reproduce it for debug. It's weird.
First I thought this was overclock related as ozpropdev mentioned his glob-top chip overclocks a bit more than the standard packaged one, but I see it also on normal SDTV output running the P2 at 100MHz or so, so it doesn't appear to be related to the clock speed.
When I account for the 16 pixel side border size it look like the bad version is reading rendered text from memory 64 longs later than it should which could well indicate a fifo setup issue somewhere, but it is strange it works reliably on the original glob top based P2-EVAL board.
Good case (VGA output):
Bad case (VGA output):
Now when I yank this HDMI breakout out on the new non-glob top board, the VGA output screen works okay. When I add it back, the 64 character offset appears in text regions next time I download the image (it appears to be consistent behaviour). This is really strange as I am not even driving these DVI pins from code in this case (or don't think I am), so maybe the extra current load or noise the cable introduces somehow couples in and affects the fifo read position at startup. If I just disconnect the DVI cable from the monitor end, it also works. WTH? How can this have an effect? Some additional small delay at startup? Voltage differences between Port A and Port B?
Update: with the DVI cable plugged into the Dell monitor (with VGA as well), there appears to be less noise than without. That wide DVI earth connector might be helping. I measured about 60mV p-p noise on the V0815 IO pins of the VGA and 90mV without it the DVI plugged in.
Update2: if I move the HDMI breakout on the new board to pins 24-31 where I used to have it on the original board, the VGA output works fine too, so this has nothing to do with glob-top vs production package. (I think I had moved it up to pins 32-39 recently to be able to quickly run Chip's oscilloscope demo). I'll try it on other port B pins to see if it is a portA/portB loading thing.
1) Both glob-top and non-glob top boards behave the same.
2) I get the VGA text problem only when the HDMI accessory board is plugged into pins 32-39 AND connected to my Dell monitor at the other end of the cable.
3) I have moved the HDMI accessory board to other positions i.e. pins 0-7, 16-23, 24-31, 40-47, 48-55 and this problem did NOT appear. I couldn't fit it 8-15 because the VGA board was operating from there and I didn't want to put it into 56-63.
So something is special about the load on low byte of port B and startup timing. I have to check my code for anything it might be doing like polling these pins at startup etc which could introduce a delay, but I don't think it should be (no need to).
I hope it is not a fastspin thing, perhaps something is buried in there. I can only easily check my own code.
Update:
4) The problem also appears on the DVI screen video output (if I modify the code to send over that instead of VGA) when the HDMI breakout board is plugged into port pins 32-39, regardless of the presence of A/V breakout board connection. Something in my code seems timing sensitive to having a load on pins 32-39.
Chip has used these HDMI output pins okay in his oscilloscope demo though of course that's going to be rather different code.
Update:
5) if the A/V accessory board is plugged into pin 32-39 with nothing else fitted, I get the problem again on VGA, but it has stripes over all the text regions. There is no normal text shown.
What on earth is special about these pins?
EDIT: Whoa, that's a lot of conditional execution! Just looked for the first time.
I've been testing/adding a couple of things for the next (beta?) release related to NTSC but that zipfile you looked at is still valid for now and causes the problem if you put the board on P32-P39.
I'd agree with an uninitialised variable being a symptom. I will try to print out the key state variables to the screen down the remaining right side on region change to text mode to compare good with bad. Might show up something. I realized that if you subtract $100 from the line buffer it might mean the text scanline could operate that way. Perhaps there is a long that has bit8 state still setup from prior execution and it is a 1 or a 0 depending on the presence of the load on port B and this causes the extra $100 hex to be added in...?
Yes that was partly thanks to some ideas from forum members. A few people contributed to that one, it's pretty well optimised now.
Thanks for checking potatohead. I think you'd need to put the A/V board on pins 32-39 to make it happen if you only have one board. If you used other pins, it doesn't happen.
I am also going to try pulling up pins 32-39 one at a time to see if they cause a problem. The terminated HDMI board would likely see a logic high when plugged into a monitor. I guess P2 pins float low.
I'm seeing the fault on both globtop and production boards with board on pin group 32.
Yes. That's in agreement.
The save & ptrb stuff in my code related to the linebuf1 pointer and its hub writes and fifo reads needs careful checking as it was recently optimized to save a long, but I think it should be good. I still cannot yet fathom how any inb pin states would affect it, but they must somehow. I will try to print these values in good and bad cases. The line buffer is shared with graphics regions and they still work okay so that variable should be fine.
Kind of lucky I stumbled onto this. You need to use a specific port group to even encounter it.
Edit: Globtop has fault on pin group 40 too.
I think I just fried my glob top board VIO supply with my latest test. :frown: I wanted to pull each pin high on each pin from 32-39 so I got two female jumper breakout board cables and put a 680 ohm resistor in the middle then jumpered VIO to each pin. At one point from the jumper cable spring the partially exposed resistor leg metal scraped over the nearby earthing pin post and looks like it shorted VIO very briefly. Now after power off and repower I measure the board supply VIO voltage and it is only 0.28V or so. Looks dead and nothing downloads to the board! Damn. It was not the 5V as that is off. It was the ground post.
Repeated this test (extremely carefully) on my remaining production board and wasn't able to reproduce the problem by pulling only one pin from 32-39 high at a time, so it must need a different combination. I am not going to go further there. Too risky.
It doesn't happen if I plug in the HDMI board into 40-47 with VGA in 8-15. That's what I tested before.
Update: A/V board on P48-55 is okay. This is really weird.
This other stuff sounds like a software bug.
I will tell you what happened. A jumper wire from V3239 touched the large grounding post next to it for maybe 0.3seconds as a cable flicked past it and the screen went off. At that point I don't believe I had even touched any P2 pins with the other end, and if I did they were via the 680 ohm resistor.
Those LDO's have a good amount of thermal shutdown protection. They seem designed to be safe and indestructable. It would be good to measure the current going into all LDO's, which there is a jumper for. Are other LDO's outputting 3.3V? If the LDO input current is light, maybe just that LDO failed. If there is a huge current, the P2 might have developed an internal short.
Have you unplugged everything and plugged it back in?