Atom Video to HDMI Adapter

[-B-]

How important is is that R2 and R4 are 1K1 1% and metal film?

Reichelt have sent me 7K5 in a bag marked up as 1K1.
I have some carbon film ones that I can put in series to get 1K1 until I reorder the proper ones.

Neil.

[Elminster]

Or put 9 of the 7.5k in parallel would miss the 1% tolerance though.

[hoglet]

How important is is that R2 and R4 are 1K1 1% and metal film?

These are fairly critical components, being part of a voltage divider.

You'll probably be OK with 5% tolerance as a temporary measure.

Or you could, I think, try 1.2K and 8.2K, as that's almost the same ratio.

Dave

[-B-]

It gets worse!
They have also sent me 10Mohm instead of 10K.

I've complained to Reichelt and asked for the correct parts.
That'll take them a few working days to sort out but I don't have my programmer yet so I can potentially wait.
That's dulled my excitement somewhat.

Neil.

[hoglet]

It gets worse!
They have also sent me 10Mohm instead of 10K.

The three 10K resistors are just pull-ups on the push switches.

Any value between 1K and 22K should work fine.

[roland]

I am happy to send you three resistors of 4.7k

[-B-]

I am happy to send you three resistors of 4.7k

Its OK Roland, I'll wait until Reichelt sort out my order. Like I said before, I can't program the CPLD just yet anyway.

Here's the progress so far, just the HDMI hole to make, add 5 resistors, insert the comparators and get the right spacers for the Pi Zero to do....

Neil.

[IanB]

Mine started up first time:

Unfortunately I don't have any Atom software accessible at the moment so I haven't been able to do any further testing.
I'll have to get the Econet setup properly as I don't have any other way of loading software.

I found an error in the BOM:
R6 and R7 are swapped, R6 should be 1K and R7 should be 430R

EDIT:
I typed in the test program in the wiki and successfully aligned the converter. Here's a screen capture from the Pi:

[hoglet]

I found an error in the BOM:
R6 and R7 are swapped, R6 should be 1K and R7 should be 430R

Good spot, that's corrected now.

I really must figure out how to get KiCad to generate the BOM. I just need to find the right plugin I think.

And great that a second person has one of these working!

Dave

[roland]

I really must figure out how to get KiCad to generate the BOM. I just need to find the right plugin I think.

IIRC it's in PCBnew: File -> Fabrication output -> BOM

[sparkyhall]

I am happy to send you three resistors of 4.7k

Its OK Roland, I'll wait until Reichelt sort out my order. Like I said before, I can't program the CPLD just yet anyway.

Here's the progress so far, just the HDMI hole to make, add 5 resistors, insert the comparators and get the right spacers for the Pi Zero to do....


IMG_4425.jpeg

Neil.

I may be mistaken, but I think you have the CPLD round the wrong way

The chamfered corner should be to the top right in your picture.

Chris

[roland]

When I compare the pictures of Hoglet en -B- then it seems right to me:

[hoglet]

I may be mistaken, but I think you have the CPLD round the wrong way

The chamfered corner should be to the top right in your picture.

You can see in Neil's picture here the location of pin 1 is marked with a circle (and a line extending out from the footprint):

On the CPLD, the corner with pin 1 is marked with a small dot, and with a chamfered corner.

So Neil has it the right way around (phew)!

Sparkyhall, what made you think that was incorrect? I want to make sure I've not written this down incorrectly somewhere.

[sparkyhall]

My sincerest apologies, I had my board the wrong way round when I compared the two and I hadn't drunk my coffee before posting.

Mines also built, I am also waiting for my programmer to arrive.

Chris

[anightin]

Getting there, just a couple more resistors to fit when they arrive:

Hopefully not too many mistakes, if anyone can spot some then please comment I only had 5% resistors so will measure values before powering up. The ones I've ordered are 1%

Andy

[hoglet]

Important Note!!!

Everyone, do please check that you have R6 and R7 the correct way around: R6 is 1K0 and R7 is 430R.

IanB spotted that these were swapped in the BOM (which is now fixed). They always were correct on the schematic.

You can see them in this photo next to C4:

R6 is the bottom one (1K0) and R7 is above that (430R)

They look incorrect in Neil and Andy's photos.

Dave

[anightin]

Thank you Dave I was assembling as per earlier BOM

Best

Andy

[IanB]

All finished and cased up:

I had to cut quite a large hole for the HDMI connector to accomodate the plastic body of the connector as well as the metal part because the case walls were too thick to allow the connector to mate properly

[hoglet]

I had to cut quite a large hole for the HDMI connector to accomodate the plastic body of the connector as well as the metal part because the case walls were too thick to allow the connector to mate properly

Yes, I had to do that as well.

On the plus side, it does give a bit of extra mechanical stability.

Dave

[sparkyhall]

Well, my programmer turned up yesterday so I was able to complete my Atom to HDMI adapter:

I'm really pleased with the results, my atom screen has never looked so good, and this on a 1366x768 display.

One minor error on the build instructions is that C18 is listed as an 0805 instead of through hole.

Need to spend some time playing with the options now.

Thanks to all those who made this possible.

Chris

[hoglet]

Hi Chris,

Glad you got it working.

One minor error on the build instructions is that C18 is listed as an 0805 instead of through hole.

Fixed now, thanks.

Need to spend some time playing with the options now.

The display looks slightly squashed to me, so you might want to experiment with different aspect ratio setting on the TV. You don't want it set to 4:3!

Dave

[roland]

I just ordered the 0805 parts

Well, luckily they are not that expensive so that I have to cancel some projects

[hoglet]

I just ordered the 0805 parts

Well, luckily they are not that expensive so that I have to cancel some projects

You still need three of them.

[IanB]

The display looks slightly squashed to me, so you might want to experiment with different aspect ratio setting on the TV. You don't want it set to 4:3!

Yes, it looks like it's squashing the Pi's 16:9 output to 4:3 so check the aspect ratio setting on the tv/monitor. The other possibility is that the Pi is generating the wrong resolution in Auto mode.

There is a potential problem with the current Atom CPLD profile as it's more or less setup for a 1600x1200 monitor although the following suggestions won't help with the 1366x768 resolution of sparkyhall's monitor which is going to be restricted to 3x3 integer scaling.

With sources that have border colour like the Atom in graphics mode, to get the best results, the capture area should be an integer sub-multiple of the display area so the border colour fills the whole screen. This also applies to the ZX81 which effectively has a white border colour due to the inverted video and also applies to the PC screen modes like CGA and EGA but not beeb, electron or monochrome sources as they can't set a border colour.

So if you are using a 1920x1080 monitor which has a centre 4:3 area of 1440x1080 the capture area should be 288x216 and for a 1600x1200 monitor the capture area should be 320x240 (with H and V offsets adjusted to centre the image). In both cases that results in integer scaling of 5x5 that fills the 4:3 screen area entirely thus preserving the border colour while maintaining integer scaling. I created two ZX81 profiles to work around this so maybe the same should be done for the AtomCPLD. However, a better solution would be to auto adjust the profile capture area to compensate for different monitor resolutions so I will investigate if that's feasible.

Here are a few comparisons in clear 4:
1600x1200 with 320x240 capture area
This scales 5x5 and fills the screen.

1920x1080 with current Atom_CPLD capture area (304x240)
This scales 4x4 with black left around the border area
You can always switch to interpolated full screen scaling to get rid of the extra black border but that will soften the image

1920x1080 with 288x216 capture area
This scales 5x5 and fills the screen but has a reduced border

Note that the screen is not perfectly centred horizontally as the Atom CPLD doesn't have the delay setting to provide pixel accurate horizontal adjustment. There may not be enough room for a general delay setting but perhaps a fixed pixel offset of 1 or 2 pixels could be added to the CPLD?

[hoglet]

There is a potential problem with the current Atom CPLD profile as it's more or less setup for a 1600x1200 monitor although the following suggestions won't help with the 1366x768 resolution of sparkyhall's monitor which is going to be restricted to 3x3 integer scaling.

When I chose 304x240 as a capture area, I didn't actually have a particular resolution in mind. What I was trying to replicate was the chunky green borders that you typically see on when an Atom drives a normal TV. And then, only approximately.

At 1280x720 it fills the screen vertically (with 3x scaling), similarly at 1600x1200 (with 5x scaling).

At other vertical resolutions, there will be some black borders.

I use this routinely at 1920x1080, where you get ~60 pixels above/below the image.

It's fine if people want to experiment with the geometry settings. We will get around to documenting these as some point. Honestly!

It's the "V Capture Height" that should be adjusted to eliminate the top/bottom border.

However, a better solution would be to auto adjust the profile capture area to compensate for different monitor resolutions so I will investigate if that's feasible.

That would make a useful additional scaling option.

Note that the screen is not perfectly centred horizontally as the Atom CPLD doesn't have the delay setting to provide pixel accurate horizontal adjustment. There may not be enough room for a general delay setting but perhaps a fixed pixel offset of 1 or 2 pixels could be added to the CPLD?

The Atom CPLD is pretty full, only one spare register.

Code: Select all

Function    Mcells      FB Inps     Pterms      IO
Block       Used/Tot    Used/Tot    Used/Tot    Used/Tot
FB1          18/18*      33/54       63/90       9/ 9*
FB2          18/18*      35/54       47/90       7/ 9
FB3          18/18*      32/54       76/90       9/ 9*
FB4          17/18       18/54       23/90       3/ 7
             -----       -----       -----      -----
             71/72      118/216     209/360     28/34

To be generally useful, we would need a 0-3 pixel delay which would take two registers.

Instead, I've just pushed a change that shifts the start of sampling over by one pixel. With this, the default profile is perfectly centered I think. There is an updated JEDEC file here:
https://github.com/hoglet67/RGBtoHDMI/b ... toHDMI.jed

Dave

[IanB]

Instead, I've just pushed a change that shifts the start of sampling over by one pixel. With this, the default profile is perfectly centered I think. There is an updated JEDEC file here:
https://github.com/hoglet67/RGBtoHDMI/b ... toHDMI.jed

I just tried this and it looks like the video is now centred in graphics modes, however I'm seeing glitches on the right hand edge of text mode:

They vary in the amount and colour, sometimes green and sometimes yellow. They appear to be at the end of the active text area, not at the end of sampling.

[hoglet]

They vary in the amount and colour, sometimes green and sometimes yellow. They appear to be at the end of the active text area, not at the end of sampling.

Do they go away if you recalibrate? (Using a text screen)

I'm busy this afternoon, but I'll look into this later.

I have a hunch I know what's going on, it's to do with the way the colour difference signals are sub-sampled. Adding a 1 pixel offset will shift the optimal colour sampling point into the 8-15 region.

Dave

[IanB]

They vary in the amount and colour, sometimes green and sometimes yellow. They appear to be at the end of the active text area, not at the end of sampling.

Do they go away if you recalibrate? (Using a text screen)
I have a hunch I know what's going on, it's to do with the way the colour difference signals are sub-sampled. Adding a 1 pixel offset will shift the optimal colour sampling point into the 8-15 region.

Yes, the optimum value has changed from 1 to 9
During calibration similar glitches are seen at the left hand side as well

[hoglet]

Yes, the optimum value has changed from 1 to 9
During calibration similar glitches are seen at the left hand side as well

I've just pushed another Atom CPLD version (v2.4) that adjusts the colour sampling point so the optimal value is back in the 0-7 range. This means the previous profile should work unchanged. So please give that a try.

Some background... It's possible (and beneficial) to sub-sample the chrominance signals by a factor of two. That's because the highest resolution colour mode (128x192) is half the resolution of the the highest resolution monochrome (256x192). I'm currently taking the chrominance sample exactly half way between the two luminance samples, as some earlier tests suggested this worked well. There is possibly scope for further optimising this, but unless anyone reports issues I'm not going to try.

Dave

[sparkyhall]

Hi Chris,

Glad you got it working.

One minor error on the build instructions is that C18 is listed as an 0805 instead of through hole.

Fixed now, thanks.

Need to spend some time playing with the options now.

The display looks slightly squashed to me, so you might want to experiment with different aspect ratio setting on the TV. You don't want it set to 4:3!

Dave

You're spot on, TV was set to 4:3, now I have set it to 16:9 it looks much better.

Chris