Pi Zero relocation adapter boards - video artefacts - pixel 'sparkles' on edges

[solarmon]

Hi,

I'm testing out several Pi Zero relocation adapters - there are three types: A, B and C:

Type A is just flips it over:

Type B shifts it sideways and flips it:

Type C shifts it sideways, flips it and rotate it:

Type A works fine without any issues.

However, type B and C has video artefacts where on certain edges there are pixel 'sparkles' artefacts.

I'm aware that this is due to the increased signal traces, but is there anything that could be done to improve it?

Thank you.

[kipper2k]

shorter tracks definitely increase performance, if you increase track lengths then you should ensure that decoupling caps are as close to IC's as possible. Also extending the board over other areas of the Amiga motherboard can also pickup unwanted noise from the motherboard so you may have to reduce board length and location to reduce the noise

[solarmon]

@kipper2k

Regarding your comment about caps being close to IC's as possible. These are just relocation boards for the Pi connector. I'm not changing anything with the RGBtoHDMI boards.

The artefacts only appear at 'edges' - where an area of colour changes to another. It's hard for me to capture that, but you can see the white pixel in this (poor quality) picture. These white pixels appear and disappear randomly on such 'edges':

Why would it only appear at these edges?

[solarmon]

I'm actually seeing this shimmering/sparkle artefact using a normal RGBtoHDMI setup - i.e. no relocator or anything.

With the normal setup setup, in the Amiga Test Kit screen, I don't see these artefacts.

However, when I load up workbench, the artefacst appear on the right hand side of any black areas next to lighter areas.

For example:

It is always on the right hand side of the contrasting edge, if that is of significance.

I haven't checked the RGBtoHDMI menu options yet. Maybe there are some settings I need to tweak?

[de-nugan]

This is the same fault I wrote about here => https://github.com/c0pperdragon/Amiga-Digital-Video/issues/11#issuecomment-769056224

I'm also using a slightly longer connection through a very short IDC cable. I tested a longer cable and saw increased sparkles and artifacts so the length does appear to be critical. I haven't been able to shorten the path as I don't have any of the female pin sockets, so I may have to solder the Pi to the board and try that instead.

My guess is that the increased path length is making it harder for the flipflops to drive the lines high from 0v (black) so we are losing bits resulting in colour sparkles where there should be grey or mid-tone colours. I aint no engineer though..

Oh and sorry to disappoint you, I've tried just about everything in the menus. I don't think it can be fixed there, likely only in hardware or perhaps firmware.

[solarmon]

So I think I have narrowed down the issue a bit. It seems this issue is only specific to this X-Copy disk I'm using to test. Everything else I've tried so far has been rock solid. The X-Copy disk I'm using is created from the xcopy_1992-11_en_1200.adf image (http://jope.fi/xcopy/zip/xcopy_1992-11_en_1200.zip). If somebody is able to test this out and check if they have the same issue. (You need to press F10 to go in to Workbench mode).

(EDIT: To be clear, this is for the issue with the standard setup. There is still the issue with the sparkles artefacts using the relocator boards)

[solarmon]

This is the same fault I wrote about here => #11 (comment)

I'm also using a slightly longer connection through a very short IDC cable. I tested a longer cable and saw increased sparkles and artifacts so the length does appear to be critical. I haven't been able to shorten the path as I don't have any of the female pin sockets, so I may have to solder the Pi to the board and try that instead.

My guess is that the increased path length is making it harder for the flipflops to drive the lines high from 0v (black) so we are losing bits resulting in colour sparkles where there should be grey or mid-tone colours. I aint no engineer though..

Oh and sorry to disappoint you, I've tried just about everything in the menus. I don't think it can be fixed there, likely only in hardware or perhaps firmware.

@de-nugan

If this issue with my relocator boards can't be fixed then I still have the option using my custom RGBtoHDMI that I'm designing and which relocates the Pi board too. Hopefully that won't have the same issue, but I still need to get these custom boards made and tested.

[IanSB]

@solarmon Try replacing the 74LVC parts with 74VHC parts. These are slower and fixed the sparkly problem on my rev5 which doesn't have the clock filtering components that are fitted on rev6 & later boards which slightly delay the clock signals. Note they must be 74VHC parts which are 5v tolerant, not 74HC parts which are not 5v tolerant when powered at 3.3v

@de-nugan I also suggest you try the above to fix your issue in https://github.com/c0pperdragon/Amiga-Digital-Video/issues/11

[solarmon]

@IanSB

Thanks for the suggestion for replacement parts. When you say 'these are slower' - do you mean the 74LVC or the 74VHC part?

I had already got a batch of the 74LVC parts because that was what was suggested in the schematics. ='(

For reference, these are the parts from LCSC:

U1!: https://lcsc.com/product-detail/74-Series_Nexperia-74LVC86APW-118_C6102.html U2 and U3: https://lcsc.com/product-detail/74-Series_Nexperia-74LVC574APW_C6098.html

Can you confirm these are the suitable replacement.

U1: https://lcsc.com/product-detail/Pre-ordered-Products_ON-Semiconductor-ON-74VHC86MTCX_C903423.html U2 and U3: https://lcsc.com/product-detail/Flip-Flops_ON-Semiconductor-ON-MC74VHC574DTR2G_C364877.html

However, the U1 74VHC86MTCX part is not in stock on LCSC.

Are you suggesting that U1, U2 and U3 should all use replacement parts?

[IanSB]

@solarmon

When you say 'these are slower' - do you mean the 74LVC or the 74VHC part?

The VHC parts are slower. Their propagation delay is about double that of the LVC parts and that allows a longer settle time before latching the data bits.

Are you suggesting that U1, U2 and U3 should all use replacement parts?

Yes although changing U1 (74LVC86) which handles the clock signal has the most effect so try that first if you are changing parts on an existing board.

Can you confirm these are the suitable replacement.

They look to be the correct family although I used these toshiba parts from RS: https://uk.rs-online.com/web/p/products/1713480/ https://uk.rs-online.com/web/p/products/1713428/

[solarmon]

@IanSB

Thanks for the parts link from RS. I'm UK based, so that suits me fine.

BTW - these issues (sparkles due to relocation board, and sparkles using a specific version of X-Copy, and Xenon II) happens on a n A500 rev 6A and an A500plus rev 8A.

[IanSB]

Thanks for the parts link from RS. I'm UK based, so that suits me fine.

The VHC86 parts have gone up a lot in price, I paid £0.056 each a few weeks ago, they are now £0.217 each. The VHC574 parts haven't gone up (yet!)

BTW - these issues (sparkles due to relocation board, and sparkles using a specific version of X-Copy, and Xenon II) happens on a n A500 rev 6A and an A500plus rev 8A.

Can't guarantee they will fix your issue but they did fix mine.

[de-nugan]

To achieve the shortest possible data path I've just soldered the Pi to the adapter board and this appears to have fixed the sparkle problem. In WB3.1 the sparkles and glitches are now gone, and the screen geometry is now absolutely bang-on pixel perfect straight out of the box.

This is on my Rev 5 (Assy 312513) A500. The parts used were Nexperia 74LVC574APW.

I'll be building more boards for some other Amigas, do you know if the VHC tip applies to any of the A/B2000 revisions?

[matthiesenj]

For HC parts, you should use VHCT or AHCT, which have TTL-compatible inputs. The point about propagation delay is probably relevant, since the original c0pperdragon design relies on the propagation delay of two gates to generate the 14MHz flipflop clock.

[solarmon]

@matthiesenj

I'm confused now - @IanSB mentioned '74VHC' parts and now you are mentioning 'VHCT' parts! Are they different? I've already ordered the '74VHC' parts.

[matthiesenj]

@solarmon nevermind - I just saw that it's actually not recommended to use the (T) versions at 3.3V AHC has schmitt-triggers on the inputs which may help clean up noisy input signals, so could be a possibility as well, especially when using relocators, etc. If you're exchanging parts on a populated board, try changing the 86 first to see if it fixes your glitches..

[solarmon]

@matthiesenj Thanks for clearing that up!

It's going to be easier for me to build new boards - re-working the existing ones probably not going to work with just a normal soldering iron!

[solarmon]

@c0pperdragon

I'd thought I'd reply in this ticket, as opposed to https://github.com/c0pperdragon/Amiga-Digital-Video/issues/11#issuecomment-793126725

This is my setup, including my relocator. You can also see how I have made my bank of 27pF capacitors:

Connecting this bank of capacitors to PiSYNC (GPIO23) and GND does not seem to make any difference to the sparkles.

However, if I connect it to PiCLK (GPIO17) I do see a significant difference - it doesn't get rid of it completely, but there is a visible difference. I'll try adding more caps to the bank and see if it makes any further improvements.

[c0pperdragon]

Oh dear! I feel soo stupid. Of course I meant the clock input (GPIO17). Don't know how I got this confused.

[c0pperdragon]

With this breadboard setup I would not expect 100% consistent quality already, but this now totally points in the right direction. If you later solder a single capacitor (220pF perhaps) to the pins directly on the backside of your relocator, where it is closest to the adapter it should give you the best results. For future revisions you could just add this capacitor to the design.

[solarmon]

@c0pperdragon LOL! It happens! No problem.

What I'm also finding is that different RGBtoHDMI v2 boards have slightly different behaviour. The difference at the moment, is that the one with the thicker pins has less artefacts than the thinner pins. I'm not sure whether it is because of those pins, or something slightly different in my soldering of those boards. It's only small sample at the moment, but there is some difference.

How this effect what capacitance value to use for PiCLK I need to try to test. Also, when I get the '74VHC' parts I will find out whether that makes a difference too.

[IanSB]

@solarmon

What I'm also finding is that different RGBtoHDMI v2 boards have slightly different behaviour.

You can get different results just by changing the ICs. During my experiments I tried swapping TI and Nexperia LVC parts on the same board and got different levels of noise, not just between manufacturers but between different chips from the same manufacturer although none of the combinations resulted in a clean image under all conditions with the amount of noise varying from barely noticeable to really bad. TI parts had some of the best and worst results with Nexperia parts somewhere in between.

I also tried adding capacitors but could never clean it up completely which is why I ended up trying the VHC parts which seem to work consistently for me but I only have the one machine to test with.

[solarmon]

@IanSB

I meant the different RGBtoHDMI v2 boards I currently have, all using the same chips. The only difference is that the first one I used the thicker header pins. Subsequent ones I used the thinner header pins. The first one (with thicker pins) seem to have less video artefacts.

But I can't come to any explanation yet since the this is only testing with a few boards.

[IanSB]

I meant the different RGBtoHDMI v2 boards I currently have, all using the same chips.

I know, what I meant was the difference in noise is due to the chips themselves. If you swapped the chips on two of your boards the noise would swap as well.

[solarmon]

I know, what I meant was the difference in noise is due to the chips themselves. If you swapped the chips on two of your boards the noise would swap as well.

Ah, right, gotcha! That is very surprising then, that it would cause that much of a difference, especially chips from the same batch?>

[c0pperdragon]

The whole matter of the parkly pixels is very confused by the fact that there are two completely independent possible causes:

1. The adapter can not reliably latch the color data. This can be caused by using the wrong data sample point (Denise vs. SuperDenise jumper) or by some other glitchy behaviour of the main board. Specifically A500 Rev.5 boards seem to not filter the CDAC clock signal properly. I guess this is mainly causing IanSB's trouble. One cure seems to be to use logic ICs that are less sensitive to high-frequency noise.

2. The signals from the adapter to the Pi do not arrive at a suitable time. The adapter adds only a very short extra delay (2 LVC gate transition times) to the output clock. So the Pi seems to not always be able already see the correct color data on the edge transitions of the clock. This is especially true when using longer leads between adapter and Pi. I proposed to just add a small capacitor to delay the clock a bit. This seems to work in some circumstances. A more proper soution would be to add more logic gates in the signal path and use their transition times. Maybe a series of simple inverter gates could do the trick.

[matthiesenj]

@c0pperdragon very true about the 2 possible causes.

Regarding 1), did you measure the (hires) pixel transition timing in relation to e.g. /CDAC for denise/superdenise? Are they borderline with respect to the flipflop setup/hold times?

[c0pperdragon]

I did measure the Denise timings and the were pretty safe when using the edges from _CDAC. Other users did try SuperDenise with _CDAC edges amd there sampling was very borderline. Sometimes it worked just fine, sometimes it caused glitches. So I extrapolated that the sweet spot for SuperDenise would be right between the edges of _CDAC and therefore used the edges of the 7MHz clock instead. This seemed to work basically flawless on SuperDenise so far.

[solarmon]

@c0pperdragon The 74VHC chips came and I built another RGBtoHDMI v2 using these chips.

I can happily report For a normal setup (no relocator) I now do not get any percieveable sparkles when using X-Copy (Oct 92) workbench or when using DiagROM 1.2.1 (I recently noticed the issue with this recently, but hadn't reported it yet), or in Xenon II (1 disk version).

Even using my relocator board, this has drastically reduced the sparkles to nearly gone. I can still see pink sparkles (on blabk/light grey edges) if I look very closely/carefully. Maybe that could be improved further with a suitable cap across PiCLK and GND, but I'm very happy with the results!

[IanSB]

@solarmon

I can happily report For a normal setup (no relocator) I now do not get any percieveable sparkles when using X-Copy (Oct 92)

Thanks for confirming they fix your issues. I suspect the problems with the extender boards are caused by reflections due to the long PCB tracks.

FYI I have designed an Amiga pickup board for the CPLD version which allows the Pi to be placed anywhere on a long ribbon cable (mainly meant for external use) which is similar to the Atari solution shown in https://github.com/c0pperdragon/Amiga-Digital-Video/issues/6#issuecomment-770140199

[solarmon]

I put a 47pF cap across PiCLK and GND and it seems to have improve the relocator video quality even further - can still make outsome pink sparkles , but they are very very hard to see, even up close.

I will also try a 220pF cap when I get it.

[LinuxJedi]

Thanks for confirming they fix your issues. I suspect the problems with the extender boards are caused by reflections due to the long PCB tracks.

In which case a resistor may help with the reflection?

[matthiesenj]

@LinuxJedi yes, series resistors on the flipflop outputs could help eliminate reflections - some logic families even incorporate series output resistors on-chip, e.g. AHC574 (which can directly replace the LVC574)..

https://www.ti.com/lit/an/scba012a/scba012a.pdf

[LinuxJedi]

@LinuxJedi yes, series resistors on the flipflop outputs could help eliminate reflections - some logic families even incorporate series output resistors on-chip, e.g. AHC574 (which can directly replace the LVC574)..

https://www.ti.com/lit/an/scba012a/scba012a.pdf

Are you sure about the AHC574? I can't see it on the datasheet. I believe the NXP ICs have it in LVC and similar if they have a '2' in them, but there is only the 374 in that so it would need rewiring.

[solarmon]

This is the colour palette of the X-Copy disk, which has the sparkles (with 74LVC parts):

I loaded up a Workbench 1.3.2 disk, with the default Workbench 1.3 colour palette, which did not have the sparkles.

However, when I used Preferences to change the colour palette to that of the X-Copy disk, the sparkles started to appear.

It also seems very specific to a certain colour, or contrast between colours. As even changing one of RGB slider just by one or two can either make the sparkles disappear or re-appear.

[c0pperdragon]

That is very interesting. Obviously in this screenshot the transition from black to grey is problematic, with some bits temporarily transiting from 0 to 1 even if they should stay at 0. This looks like some inductive coupling between the signal traces. So instread of reflection on individual signal paths, there is some interdependency between them. I guess this is happening because of the LVC parts that have very steep signal flanks that cause high currents and in consequency high magnetic fields.

Getting data transmission to reliably work over longer distances is really a headache. Slower parts may indeed help here, I guess, or redesigning the board with better seperation between traces.

[solarmon]

@c0pperdragon

Note that this issue was also happening, for me, without the relocator adapters - specifically with X-Copy, Xenon II and DiagROM. Using the relocators just made it worse, or more apparent.

[c0pperdragon]

All this of course comes down to my design not leaving enough room for variances of any kind. To get a really stable solution here, you need to introduce a generous amount of additional delay on the pixel clock line from the adapter to the Pi A capacitor seems to work in some circumstances, but some active componemt would be better. Maybe you have some logic chips to hack together something? You need to somehow cut the original connection of course.

[solarmon]

@c0pperdragon Is this what you were trying to do with this part of the circuit?

I wouldn't have the expertise to try to find a suitable fix, but what about feeding back the PiCLK signal to one of the spare not used input/output on the existing logic chip - i.e. the spare input/outputs on U3 ? Or will that still not delay it enough?

[c0pperdragon]

Yes, I used the one spare gate on the XOR for delay. It seems that this is yet not enough in sone circumstances. The free bits on the flipflops can not be used for that, though.
When you are using the adapter jumpered to Denise mode, you could actually repurpose one of the XOR gates. But this requires modifying the adapter in some irreversible way. But maybe this one gate transition would be just enough.

[LinuxJedi]

I think whilst @c0pperdragon's v1/v2 solution is fantastic work and for a majority of people it will work great, @IanSB may be right and a xc9572xl based solution may be the way to solve these minor issues long-term. Should even be able to fit it into the same physical profile as the c0pperdragon adaptor.

[c0pperdragon]

I still think this is total overkill for an internal solution. It is probalbly really only a matter of fixing the setup times.

[solarmon]

Yes, I used the one spare gate on the XOR for delay. It seems that this is yet not enough in sone circumstances. The free bits on the flipflops can not be used for that, though. When you are using the adapter jumpered to Denise mode, you could actually repurpose one of the XOR gates. But this requires modifying the adapter in some irreversible way. But maybe this one gate transition would be just enough.

@c0pperdragon

I'm designing building my own RGBtoHDMI board, that also relocates the Pi. I could add this to the design (as well as an optional cap on PiCLK) and try it out.

[solarmon]

@c0pperdragon

Oh, you mean the U1 chip. I was talking about the spare input/output on the U3 chip, Would that work - using U3?

[c0pperdragon]

No, the U3 and U2 are flip-flops. These can not be used to delay signals in this mannner.

@solarmon When you already build a new PCB you could actually add a configurable delay line. Just put a bunch of inverters in series (inverters to cancel out the different timing characteristic for high and low transitions). And add jumper links to tap into one any of the stages to use as the clock that goes to the Pi.

[solarmon]

@c0pperdragon

OK, understood.

Would a dual inverter like these 74HC2G14-Q100/74HCT2G14-Q100 be suitable.

I was looking to remove the 3.3V regulator anyways, so this could just fit in its place footprint wise.

[LinuxJedi]

Really dumb question time based on me looking at the Denise datasheet: would an AND of 7MHz and CDAC to the flip-flops clock work with straight CDAC to the PiCLK? Or is the flip-flop latency also part of the problem?

[solarmon]

Actually, this SN74LVC2G04 seems more suitable (or equivalent), as the output should be 3.3.V instead of 5V.

[c0pperdragon]

The HC inverters are probably better. HC is slower than LVC which is exactly what you need for delay. Also the signals edges are not so sharp and will cause less trouble. HC can also run with 3.3V without issue (not HCT, though!).
Schmitt-Trigger characteristic (74HC14) is not necessary, but should not hurt either.

[c0pperdragon]

Really dumb question time based on me looking at the Denise datasheet: would an AND of 7MHz and CDAC to the flip-flops clock work with straight CDAC to the PiCLK? Or is the flip-flop latency also part of the problem?

The flip-flops sample the bits at the positive edge of the clock input. So you need something that goes high twice in a single system clock cycle (high-res pixels are generated at about 14MHz). This is done with by strangle looking XOR circuit which goes high whenever the input clock changes. AND-Combining CDAC and 7MHz would only generate a 7Mhz clock with 25% duty cycle. I don't know what this should achieve.

[c0pperdragon]

Reading the whole datasheet of the HC parts, it may even be too much delay when cascading two of those and running them with 3.3V. So the LVC parts may indeed be the better option and should add about 8ns when cascading both gates.