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 ?

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 ?

@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.

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 ;-)

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