Question: Is there an easy transistion?

[sy2002]

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

[amb5l]

Your theories about possible problems in your timing generator all sound reasonable. It will probably help us both to try inserting my timing generator in your project. Happy to assist...

You'll need something like this to translate my outputs to yours:

constant DEFAULT_COL : integer := -1;
constant DEFAULT_ROW : integer := -1;
...
h_sync    <= hs;
v_sync    <= vs;
disp_ena  <= not (vblank or hblank);
column    <= to_integer(ax) when disp_ena = '1' else DEFAULT_COL;
row       <= to_integer(ay) when disp_ena = '1' else DEFAULT_ROW;
n_blank   <= not disp_ena;
n_sync    <= not (h_sync or v_sync);

[sy2002]

Thank you for your support - very helpful!

So I will do the "plug-in" experiment and plug-in your timing generator in our project to see, if this fixes issue #2 .

[sy2002]

@amb5l Today I will perform the "plug-in" experiment.

What is the idea behind / semantics of align (aka alignment delay) in video_out_timing?

[amb5l]

align is an incomplete attempt to support situations where a fixed delay is required between source video (e.g. the video controller of a retro computer) and the output. For example, where the retro computer's video controller has a different pixel clock and pixels must pass through a FIFO. I am creating an FPGA implementation of the Acorn BBC micro and its CRTC is a MC6845 with a pixel clock of 16MHz. That is where this requirement came from.

You can safely ignore it - set align to zero.

[sy2002]

@amb5l There is no polarity input in video_out_timing. Is it fair to assume, that your timing generator always creates positive/positive polarity? (And if certain video modes, such as PAL @ 50 Hz, require negative/negative polarity, that one would just invert the outputs of video_out_timing?)

[amb5l]

@sy2002 Yes that's correct, the sync polarity of video_out_timing is positive. vga_to_hdmi provides control inputs for active low syncs.

[sy2002]

@sy2002 Yes that's correct, the sync polarity of video_out_timing is positive. vga_to_hdmi provides control inputs for active low syncs.

@amb5l Oh - then everything only worked "by chance" in past, because I mis-understood your inputs at vga_to_hdmi: These are only output polarities and vga_to_hdmi always expects positive/positive as input? (at 720p @ 60 Hz we happened to have pos/pos anyway, so nobody noticed...) I am asking, because the MEGA65 has a VGA output as well as a HDMI output, and therefore I will make sure "manually" in future (if we switched to your timing generator) that the VGA output also gets the correct polarity.

[sy2002]

I will close this issue because I managed to plug your timing generator into our gbc4mega65 project and it works like a charm on my Monitor. Now we can continue to work on issue #2 using your timing generator and check, if it solves it.