RGB2HDMI visual glitches in WB booted from X-Copy Pro September '92 EN

[solarmon]

Not sure which area to put this question in, but it is related to my RGBtoHDMI build.

This is directed at Jope, since this question is about X-Copy, which has the master disks hosted at:

http://jope.fi/xcopy/masterdisk.html

I assume this the same 'jope' in this forum! And I'm hoping you can gives some hints to what I'm trying to find out.

The question is, what is the difference between "X-Copy Pro May '92 EN" (xcopy_92-may_en_master.adf) and "X-Copy Pro September '92 EN" (xcopy_1992-11_en_1200.adf).

Note the '1200' referenced in the filename of the later version. What does this mean?

The reason why I ask is that this "xcopy_1992-11_en_1200.adf" version shows video artefacts (pixel sparkles on the right hand side of contrasting edges - specifically, black next to light grey) when used with an RGBtoHDMI adapter in an A500plus (ECS Denise) or A500 (OCS Denise).

This is most evident on the Workbench screen/desktop the disks loads (when you press F10 on boot). Is this a special version for an A1200? What is 'special' about it?

This video artefact issue does not occur when using xcopy_92-may_en_master.adf on the same setup.

[Jope]

There is probably not that much special about it, all X-Copy master disks work with just about any Amiga.

I doubt there is anything special otherwise. The white text on blue background works better with your RGB2HDMI setup than black text on a grey background.

Have you tried booting up a normal WB2.x disk in your A500 to see whether the image looks fine?

[solarmon]

The issue occurs also on my A500 rev 6A.

It looks like it is a Workbench 1.3.2 based disk as the Workbench info from the menu says that is Workbench version 34.28.

It looks like in the X-Copy program itself (using xcopy_1992-11_en_1200.adf) it also seem to show this sparkling effect issue - but also on some other colour contrasting edges other than black/light-grey.

Everything else I've tried (including different Workbench disk version - 1.3, 2.05, 3.0), I don't seem to get this issue. Apart from Xenon II (1 disk) on the boot logo where it says "Bitmap Brothers". Coincidentally (?) that also has black/-light-grey contrasting edges.

I was just wondering why the ADF image name has been tagged with "A1200".

[Jope]

The names are as they came from Mr. Vince, who made the images of the master disks. Perhaps it was written on the label of the master.

Can you take a picture of the effect you see? I have an rgb2hdmi here that I need to test at some point, so it'd be interesting to see whether I can reproduce it.

[BippyM]

Some versions of xcopy have gfx corruption on aga (modulo issues with aga I guess)

[solarmon]

I have a ticket on c0pperdragons's GitHub:

https://github.com/c0pperdragon/Amig...ideo/issues/40

See the picture of Workbench window widget, hut it happens on any such contrasting 'edge'.

It would be great if somebody can test this to see whether they can reproduce it.

[Jope]

Ok, I doubt this is down to anything in software. The only thing i can imagine is that perhaps the system-configuration screen position setting has been adjusted to something else than the default and the new position causes this shimmering. Or the choice of colours in the X-Copy master disk's system-configuration is a bit different to the default 2.0 colours. Or a combinatino of both.

That effect in your screenshot is not something you can really achieve in software running on the Amiga. It is a problem with the device that is sampling the image. So I'll go back to my first guess that this is an RGB2HDMI problem.

[solarmon]

Yes, it is an RGBtoHDMI problem - as the issue does not occur over the RGB video output (at the same time).

But I was trying to figure out why it is only happening with disk image, what is it about it that would cause this issue.

If somebody could test this then I will know whether it is just an issue with my setup.

[solarmon]

As per https://github.com/c0pperdragon/Amig...ideo/issues/40

I used 74HVC series logic chips, which are half the speed of the 74LVC logic chips. This seems to have resolved the sparkles artefact.

Even on a relocator adapter, it has nearly entirely eliminated it - adding a 47pF cap between PiCLK and GND seems to have reduced it even further.

However, I'm still interested in finding out why X-Copy Setp 92 disk images seems to cause more sparkles compared to anything else. I also noticed that DiagROM v1.2.1 was showing a lot of sparkles too.

[hooverphonique]

I suspect it's the specific pixel color transitions causing the glitches, like e.g. high contrast ones - you compared different versions of xcopy - do they have the exact same graphics in the glitchy areas?

I think the problem is caused by signal reflections (as mentioned in the github thread)

[Jope]

My guess is also the colour choices.

[solarmon]

@Jope and hooverphonique

You are both right.

This is the colour palette of the X-Copy disk, which has the sparkles:



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.

[Jope]

Good that you found the bug though. Future versions of the converter board will surely have faster components..

[mr.vince]

Originally Posted by Jope

The names are as they came from Mr. Vince, who made the images of the master disks. Perhaps it was written on the label of the master.

It quite probably was. I usually carry over all info found on labels etc.

If someone's life depends on it, I can grab the box and take a peek. But I guess running this on some AGA chipset will reveal the truth. Probably.

[Stedy]

Hi,

Looking at the PCB from Github, https://github.com/solarmon/RGBtoHDM...202%20-%20SOIC

I can see why you have issues.
1) You have a high speed, fast edge rate XOR gate, the 74LV84 has <1ns rise/fall times and 24mA drive. This is great for a 30cm motherboard, not so good for ~60mm PCB trace. You have tried some slower devices, with mixed results, the MC74VHCT86 from Onsemi would be a good fit but this is not all.
2) The PIClk signal is way too close to pixel data R0 and R1. You must keep clock signals at least 3x track width separation from other signals
3) A capacitor on Piclk helps but add an AC terminator (75-100R resistor) with the capacitor C6 and you'll remove the high frequency edges on the clock signal to the PI.
4) Either change C5 to 1206 size or provision for another 0805 capacitor. Small, high value ceramics really drop off with applied voltage. See https://pdfserv.maximintegrated.com/en/an/TUT5527.pdf. This will give a bit more margin for power supply noise.

These tweaks should clean up the signal traces and improve the picture.

[solarmon]

Originally Posted by Stedy

Hi,

Looking at the PCB from Github, https://github.com/solarmon/RGBtoHDM...202%20-%20SOIC

I can see why you have issues.
1) You have a high speed, fast edge rate XOR gate, the 74LV84 has <1ns rise/fall times and 24mA drive. This is great for a 30cm motherboard, not so good for ~60mm PCB trace. You have tried some slower devices, with mixed results, the MC74VHCT86 from Onsemi would be a good fit but this is not all.
2) The PIClk signal is way too close to pixel data R0 and R1. You must keep clock signals at least 3x track width separation from other signals
3) A capacitor on Piclk helps but add an AC terminator (75-100R resistor) with the capacitor C6 and you'll remove the high frequency edges on the clock signal to the PI.
4) Either change C5 to 1206 size or provision for another 0805 capacitor. Small, high value ceramics really drop off with applied voltage. See https://pdfserv.maximintegrated.com/en/an/TUT5527.pdf. This will give a bit more margin for power supply noise.

These tweaks should clean up the signal traces and improve the picture.

Actually, the pixel sparkles were experienced on the original c0pperdragon RGBtoHDMI v2 boards. These original boards have very poor mask clearances, which is what I believed to be the main cause, especially when there is flux residue contamination, along with bad soldering work.

My custom RGBtoHDMI SOIC based boards with the large chip package and larger pin pitch also really helps.

In fact, all of my custom RGBtoHDMI boards found at https://github.com/solarmon/RGBtoHDMI don't seem to have any pixel sparkles issues from my testing - because I've made sure the mask clearances are better and the pin holes much smaller for the header pins, so that there is not much movement. I have used both VLC and VHC TSSOP chip packages and I don't have the issues that I had with the original c0pperdragon RGBtoHDMI v2 boards.