amb5l / tyto_project Goto Github PK

HDMI analyser report does not look right w.r.t. aspect ratio. For example:

InfoFrame Type Code = 0x82
InfoFrame Version Number = 0x2
Length of AVI InfoFrame = 0xd
Data Byte 1 = 0x12
	RGB or YCbCr, Y1-Y0 = 0b00(RGB)
	Active Format Information Present, A0 = 0b1(Active Format Infomation Valid)
	Bar Information, B1-B0 = 0b00(Bar Data not Valid)
	Scan Information, S1-S0 = 0b10(Underscanned(Computer))
Data Byte 2 = 0x2a
	Colorimetry, C1-C0 = 0b00(No Data)
	Picture Aspect Ratio, M1-M0 = 0b10(16:9)
	Active Format Aspect Ratio, R3-R0 = 0b1010(16:9(Center))
Data Byte 3 = 0x80
	IT content = 1(IT content)
	Extended Colorimetry, EC2-0 = 0b000(xvYCC601)
	RGB Quantization Range, Q1-Q0 = 0b00(Default)
	Non-uniform Picture Scaling, SC1-SC0 = 0b00(No Known non-uniform Scaling)
Data Byte 4 = 0x4
	Video Format Identification Code, VIC6-VIC0 = 4([email protected]/60.00Hz, Aspect Ratio = 16:9)
Data Byte 5 = 0x70
	YCC Quantization Range, YQ0-YQ1 = 0b01(Full Range)
	Content Type, CN1-CN0 = 0b11(Game)
	Pixel Repetition factor, PR3-PR0 = 0b0000
Data Byte  6 [ Line Number of End of Top Bar(lower 8 bits) ] = 0x0
Data Byte  7 [ Line Number of End of Top Bar(upper 8 bits) ] = 0x0
Data Byte  8 [ Line Number of Start of Bottom Bar(lower 8 bits) ] = 0x0
Data Byte  9 [ Line Number of Start of Bottom Bar(upper 8 bits) ] = 0x0
Data Byte 10 [ Pixel Number of End of Left Bar(lower 8 bits) ] = 0x0
Data Byte 11 [ Pixel Number of End of Left Bar(upper 8 bits) ] = 0x0
Data Byte 12 [ Pixel Number of Start of Right Bar(lower 8 bits) ] = 0x0
Data Byte 13 [ Pixel Number of Start of Right Bar(upper 8 bits) ] = 0x0
AVI InfoFrame version should be 2.
Pass
AVI VIC should correspond to one of the video identification codes.
Pass
AVI M1, M0 fields 0b10 1,0(16:9) shall match aspect ratio corresponding to transmitted VIC field.
Skip because AVI R3-R0 is not 1000(Same as picture aspect ratio)
All reserved fields in AVI InfoFrame shall be zero.
Pass
Q1/Q0 = 00(Default), Y1/Y0 = 00(RGB).
Video Format = 1280x720(VIC04).
Pass
YQ1/YQ0 = 01(Full Range)
Pass
CN1/CN0 1(ITC) 11(Game)
Error
M1-M0 = 0b10(16:9) of AVI InfoFrame Packet should correspond to the aspect ratio of the viewed image.
Skip because AVI R3-R0 is not 1000(Same as picture aspect ratio)
Test ID 7-27 : FAIL

Suggestion: set A0 to 0 (no Active Format Description), and therefore set R3-R0 to 0b0000; signal aspect ratio via M1-M0 only.

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 while reading your comment #2 (comment) a nagging little thought came up:

I reckon that our timing generator, originally developed by Scott Larson and "improved or damaged" by me and @MJoergen is not accurate.

Why should it be necessary to tweak V_BP and V_FP at all instead of using the reference values?

Or asked the other way round: Why are we getting HDMI Analyzer errors while just sticking in the correct reference timing values?

Here are possible answers:

• "Pipeline problems" (like a flip/flop delaying something here and there)
• Clock Domain Crossing problems
• Our timing generator is not good enough

So just in case that the new bitstream is not solving issue #2 and/or just in case we want to improve the code quality in our project:

I wonder, if there is a kind of quick and easy way to just replace our our timing generator with your timing generator.

Our timing generator outputs these signals:

      h_sync    : out std_logic;  -- horiztonal sync pulse
      v_sync    : out std_logic;  -- vertical sync pulse
      disp_ena  : out std_logic;  -- display enable ('1' = display time, '0' = blanking time)
      column    : out integer;    -- horizontal pixel coordinate
      row       : out integer;    -- vertical pixel coordinate
      n_blank   : out std_logic;  -- direct blacking output to dac
      n_sync    : out std_logic   -- sync-on-green output to dac

Your timing generator outputs these signals:

        f           : out   std_logic;                      -- field ID
        vs          : out   std_logic;                      -- vertical sync
        hs          : out   std_logic;                      -- horizontal sync
        vblank      : out   std_logic;                      -- vertical blank
        hblank      : out   std_logic;                      -- horizontal blank
        ax          : out   std_logic_vector(11 downto 0);  -- visible area X (signed)
        ay          : out   std_logic_vector(11 downto 0)   -- visible area Y (signed)

We actually do need disp_ena and column and row for our overlay menu and other things. So we would need to make sure that there is a way to map your output to ours and our a formula that translates ax/ay to row/column.

Also some parts of the screen scaler depend on certain timing characteristincs, I do remember that @MJoergen added 1-clock-cycle delays here and there so that the Game Boy on MEGA65 screen looks as it should. Maybe he can chime in here, too.

While merging @amb5l 's newest commit b98fe33 into "our" / @gardners version of the source, I noticed, that Adam is using something called "LFEPBL" while Paul uses "LFEBL".

I need to admit that I have no idea what this means and just wanted to make sure, that neither Paul nor Adam is having a typo.

Please see this screenshot:

Question to @amb5l : Shall I merge your LFEPBL or keep Paul's LFEBL ?

First of all, let me send my personal warmest THANK YOU for creating this awsome HDMI framework. 😃 🙇‍♂️

You helped the MEGA65 project a lot with your work (https://www.mega65.org/ and see blog entry from @gardners blog: https://www.mega65.org/) and see also the Game Boy for MEGA65 project (https://github.com/sy2002/gbc4mega65/tree/develop) that I am doing together with @MJoergen: All of us are using your work. (Please double check if this AUTHORS mention is OK for you: https://github.com/sy2002/gbc4mega65/blob/develop/AUTHORS#L53)

**The good news first: Everything works like a charm. We do not experience any bugs or problems on any real TV or Monitor. And we tested some quity picky exemplars 😆 Even the old HDMI framegrabber works. **

BUT...

At the gbc4mega65 project, we use 720p @ 60 Hz and 48 kHz sound (and it works like a charm on every TV and monitor) but the HDMI protocol analyzer complains about: "Invalid combination" Q1/Q0, Y1/Y0, YQ1/YQ0. Looks like you are using a "reserved" bit combination: Please search for error in the attached TXT file (20210620100612.txt) to learn more. Here is a quick excerpt from the Analyzer's output:

Test ID 7-23 : Pixel Encoding - RGB to RGB - only Sink
- Verify that an AVI InfoFrame is transmitted on every two video fields.
Q1/Q0 = 10(Full Range), Y1/Y0 = 00(RGB).
Video Format = 1280x720(VIC04).
Invalid Combination : Error.
YQ1/YQ0 = 10(Reserved)
Error
- Verify that any transmitted AVI InfoFrame is correct and indicates RGB pixel Encoding.
Pass
Test ID 7-23 AVI InfoFrame : PASS

- Verify that transmitted video uses RGB pixel encoding.
Test ID 7-23 : FAIL

--
Test ID 7-24 : Pixel Encoding - RGB to RGB - only Sink
- Verify that an AVI InfoFrame is transmitted on every two video fields.
Q1/Q0 = 10(Full Range), Y1/Y0 = 00(RGB).
Video Format = 1280x720(VIC04).
Invalid Combination : Error.
YQ1/YQ0 = 10(Reserved)
Error
- Verify that any transmitted AVI InfoFrame is correct and indicates RGB pixel Encoding.
Pass
Test ID 7-24 AVI InfoFrame : PASS

- Verify that transmitted video uses RGB pixel encoding.
Test ID 7-24 : FAIL

Since everything works fine, I would not consider this issue very urgent - but on the other side, it would be "nicer", "better" if we were fully HDMI compliant.

P.S. FYI just in case you need them: Here are our timing settings: https://github.com/sy2002/gbc4mega65/blob/develop/MEGA65/vhdl/video/video_modes_pkg.vhd#L50

Hi Adam (@amb5l),

it's been a while - 1 year I guess :-) I trust you are well.

I know that you already have the Tyto2 project - but since we (MEGA65, MiSTer2MEGA65 framework) are still using your "old" code from this version, I thought it might be sensible to open the issue here.

Please have a look at these warnings:

Looking at your source code here and here and not really understanding what actually happens in detail: Might it be better to use tristate_width => 4 in the DDR context instead of 1 ?