MJoergen
commented
1 year ago In the following, I'm referring to the document CEA-861-D, which can be found here.
Currently, we are supporting the following HDMI formats:
- 720p @ 60 Hz (section 4.3, format 4, pixel clock 74.25 MHz, aspect ratio 16:9)
- 720p @ 50 Hz (section 4.7, format 19, pixel clock 74.25 MHz, aspect ratio 16:9)
- 576p @ 50 Hz (section 4.9, format 17, pixel clock 27.00 MHz, aspect ratio 5:4)
I don't see any 576p @ 60 Hz formats mentioned in this standard.
However, I do see these two alternatives:
- 480p @ 60 Hz (section 4.2, format 1, pixel clock 25.2 MHz, aspect ratio 4:3)
- 480p @ 60 Hz (section 4.5, format 2, pixel clock 27.027 MHz, aspect ratio 3:2)
Moving forward, I suggest we consider the first alternative (aspect ratio 4:3). In any case, either choice requires the introduction of yet another clock. (Note: I'm pretty sure that the closeness of 27.00 MHz and 27.027 MHz is an illusion and trying to exploit this will cause problems on picky HDMI monitors.)
However, I don't think an additional clock is a great chore. To me it seems like a rather trivial matter of updating the two files: M2M/vhdl/av_pipeline/video_modes_pkg.vhd and M2M/vhdl/clk_m2m.vhd. All the magic is done in the latter file, based on the clock select input hdmi_clk_sel_i.
Switching to a "fully dynamically generated clocks" I see - at the moment - as a nice-to-have, i.e. a refactoring that can be implemented when time permits, but is not urgent.
sy2002
Right now, the M2M framework supports these combinations of resolutions, aspect ratios and display frequencies:
This is great for the C64 in PAL mode. But for a future version of the C64 that also supports NTSC, as well as for core which are running at 60 Hz such as Galaga, we need to support more of these combinations. My suggestion is that we add:
There are two approaches to this:
1) Can ASCAL generate the 576p @ 60 Hz without the need for additional clocks? The 720p 50 Hz and 60 Hz are generated from the same clock. ASCAL just again does its "magic". Approach one sounds simple and elegant.
2) Another approach is working with more clocks - which is a chore and not elegant at all. Maybe this would then be the final "straw that breaks the Camel's back" that motivates us to switch to fully dynamically generated clocks using the reconfiguration properties of the MMCM and the mechanisms that Adam Barnes implemented in the tyto2 project? He can seamlessly flip through 16 video modes: https://github.com/amb5l/tyto2/blob/main/src/designs/hdmi_tpg/mega65r3/hdmi_tpg_mega65r3.vhd
No matter what route: I propose not to touch anyting here before we released V5 of the C64 core.