720p @ 60 Hz CEA-861E Video Format Timing Error

[sy2002]

Hi Adam,

Thank you for your fantastic help with issue #1 . I merged your code and now I am waiting for @gardners to confirm with his HDMI analyzer, that your fix works.

While we wait, I thought I would approach you with another small topic: As already written in issue #1, this issue does not seem to be a big problem: On all our tested HDMI monitors, the Game Boy on MEGA65 output works like a charm.

But today I learned, that on a certain HDMI frame grabber, that the YouTuber RetroCombs (https://www.youtube.com/channel/UCjdKGdIl5leQfhJZiHUYFbQ) is using, the image is black, i.e. the frame grabber cannot grab the image.

I revisited the latest HDMI Analyzer output from Paul and found a "video format timing error". Look at this:

--------------------- Frame No = 1 ----------------------
CEA-861E Video Format Timing Error
VSYNC Active Edge is delayed 8510 pixel(s) from specified position.
VSYNC Inactive Edge is delayed 8510 pixel(s) from specified position.

[... a lot of more info deleted ...]

--------------------- Frame No = 2 ----------------------
CEA-861E Video Format Timing Error
VSYNC Active Edge is delayed 8510 pixel(s) from specified position.
VSYNC Inactive Edge is delayed 8510 pixel(s) from specified position.

[ ... and so on ]

Attached, you find the full output as ZIP (the scan is a few weeks old and does not include yet your fix of issue #1).

hdmi-analyzer-old.zip

The frame grabber that RetroCombs is using is HDML-Cloner Box Pro.

The video timing that we are using for the 720p @ 60 Hz is this:

https://github.com/sy2002/gbc4mega65/blob/master/MEGA65/vhdl/video/video_modes_pkg.vhd#L50

Do you have any idea what this error means and if I do something wrong (for example the timing in the above link is wrong) - or - if maybe our modifications of your code introduced an error? Please have a look at our modifications by doing a DIFF between our code and yours:

https://github.com/sy2002/gbc4mega65/blob/master/MEGA65/vhdl/drivers/hdmi/vga_to_hdmi.vhd

(I do not really understand why @gardners changed your code and what he did there, but I just wanted to rule out the option, that these code changes are responsible for the above timing error - which do not seem to happen, when the original MEGA65 core outputs PAL @ 50 Hz via HDMI while the Game Boy outputs 720p @ 60 Hz via HDMI and while both cores - MEGA65 and Game Boy for MEGA65 - are using the modified version of your code from Paul.)

OR:

Might there be a bug in your original code?

Any help / hint highly appreciated ;-)

[amb5l]

@sy2002 I am looking at this issue now.

The differences @gardners introduced appear to be... 1) fix to audio info frame contents based on tests against the N5998A HDMI protocol analyser (interesting!) 2) dynamic switching between 44.1kHz and 44kHz sample rates 3) adding Source Product Descriptor info frames - with some work in progress on making this info scroll

There are also some minor changes that may be related to your Linux toolchain and/or readability.

These diffs are not relevant to your reported issue with 720p60. I think your vertical timing is wrong. In video_modes_pkg.vhd, constant C_VGA_1280_720_60 specifies the following:

• active = 720 (V_PIXELS)
• front porch width = 5 (V_FP)
• sync width = 5 (V_PULSE)
• back porch width = 21 (V_BP)

So the vertical total = 720 + 5 + 5 + 21 = 751. This is not correct - it should be 750 - and this probably explains the frame grabber problems. Compare with my video_mode.vhd settings for this mode.

You have a comment that states "changed V_BP to 21, which solved this HDMI analyzer error...". So either change V_BP back to 20, or decrease V_FP from 5 to 4 to get the correct total number of lines (750).

[gardners]

I'm back at home now, so can get to the analyser again. Where is the bitstream for me to test?

[sy2002]

@amb5l Thank you for your analysis and your feedback - this is very helpful!

I changed V_FP to 4 now, because back in the days, when I had V_BP at 20, I got this other HDMI analyzer error that you are referring to.

Synthesizing right now, will post a bitstream for Paul to test as soon as it is done.

[sy2002]

Here is the bitstream that changes V_FP to 4 while keeping V_BP to 21:

MEGA65_R3.bit.zip

@gardners Theoretically this one should fix both: this issue and #1 CAUTION: Only test Super Mario Land 1 and Tetris, because for avoiding the 2hrs synthesis time, I did only build with the small Cartridge RAM.

[sy2002]

@gardners was testing the result on the HDMI Analyzer (full result log here: Analyzer-Output-210711.zip)

Here is the summary:

Changing V_FP to 4 while keeping V_BP=21 leads to another error:

CEA-861E Video Format Timing Error
VSYNC Active Edge is delayed 6860 pixel(s) from specified position.
VSYNC Inactive Edge is delayed 6860 pixel(s) from specified position.

So in summary:

If I use V_BP=20 and V_FP=5 (which is the HDMI standard AFAIK) I am getting

"Number of HSYNC pulses from VSYNC active edge to Video Data Period should be 25 (VS_TO_VIDEO)
   --    Error : VS_TO_VIDEO does not equal values for the selected video format(24)."

If I use V_BP=21 and V_FP=5 I am getting

CEA-861E Video Format Timing Error
VSYNC Active Edge is delayed 8510 pixel(s) from specified position.
VSYNC Inactive Edge is delayed 8510 pixel(s) from specified position.

And using V_BP=21 and V_FP=4 leads to the above-mentioned error.

Do you think the approach of the other issue #3 is more promising? (Did you test your timing on an HDMI analyzer?)

[amb5l]

Unfortunately I do not have access to an HDMI analyser.

One thing to try is to run my HDMI test pattern generator design against your HDMI analyser. This will tell you if my timing generator recipe is more correct for 720p60.

I will review and comment on issue 3.

[sy2002]

Thank you - I think it might be indeed easier to go the route of plugging your generator into our project (issue #3) than to run your test pattern generator, because I guess the time I need to port it to the MEGA65 is roughly equal to the time I need to do the "plug-in experiment" :-)

So I will do the latter.

But after we confirmed #1 as fixed for not mixing things up.

[gardners]

@amb5l what boards to you support? I do have a couple of other HDMI-out FPGA boards here, if I rat through my pile of old boards. But it will probably be faster for @sy2002 to do his approach, so only worry if problems are hit there.

[amb5l]

@gardners Digilent Nexys Video and QMTECH Wukong. I may be able to obtain another board - give me a list and I will look into it.

[gardners]

In theory I have a Wukong board, but I can't immediately find it, so I might need to wait for @sy2002 porting it over to the MEGA65 board.

[sy2002]

@amb5l and @gardners : I have plugged-in Adam's VGA timing generator into the gbc4mega65 project.

It works like a charm on my VGA and HDMI monitor (720p @ 60 Hz) and I am now of course extremely eager to learn: Are the errors of type CEA-861E Video Format Timing Error gone by now?

IMPORTANT: I did a branch. That means, that this branch does not contain the newest fixes from issue #5. The bitstream only tries to fix the issue #2 at hand. @gardners Please only focus on the CEA-861E Video Format Timing Error when testing this bitstream:

gbc-issue2.zip

[gardners]

REport for gbc-issue2.zip:

20210721140430.txt

[amb5l]

In these results, test ID 7-27 gives

Picture Aspect Ratio, M1-M0 = 0b10(16:9)

This does not match commit 358f15 which zeroes M1-0?

[sy2002]

This does not match commit 358f15 which zeroes M1-0?

@amb5l No, because I branched before plugging-in your timing generator. I wanted to keep the two fixes separate, so that we are not mixing up things (see my "important: ...." message in comment https://github.com/amb5l/tyto_project/issues/2#issuecomment-881931376)

@gardners and @amb5l (and @MJoergen FYI):

WE DO HAVE SOMETHING TO CELEBRATE 🚀 🎸 💎 👍

Plugging-in Adam's timing generator in gbc4mega65 fixes the CEA-861E Video Format Timing Error problem.

Adam, congrats to your great code quality. And thank you so much for your help: Not only will the Game Boy on the MEGA65 will become better now (and maybe now also work on Retro Comb's frame grabber) - also the whole porting effort of MiSTer cores to the MEGA65 in the MiSTer2MEGA65 project will benefit from your work.