Since you love refactoring and making the life our our CPP's better :-) Here is an idea I stumbled over today. Feel free to assign to me, if you want me to do this (after Christmas) - or do it by yourself - or decide that it makes no sense, then close the issue as "not planned":
I think we are in agreement, that our CPP needs to be fully in control which screen resolutions, refresh frequencies and other modes (such as RGBHV vs CSYNC, 15kHz vs 30KhZ, scandoubler, yes/no) he is offering to his users. All these settings are done in mega65.vhd and this is IMHO also where they belong.
The only thing that I do not like is, that we ask the CPP to use numeric magic numbers for the screen resolution/refresh frequency instead of nice constants. For example in the demo core the situation looks like this:
qnice_video_mode_o <= 6 when qnice_osm_control_i(C_MENU_SVGA_800_60) = '1' else -- C_SVGA_800_600_60); -- SVGA 800x600 @ 60 Hz
5 when qnice_osm_control_i(C_MENU_HDMI_720_5994) = '1' else -- C_HDMI_720x480p_5994, -- HDMI 720x480 @ 59.94 Hz
4 when qnice_osm_control_i(C_MENU_HDMI_640_60) = '1' else -- C_HDMI_640x480p_60, -- HDMI 640x480 @ 60 Hz
3 when qnice_osm_control_i(C_MENU_HDMI_5_4_50) = '1' else -- C_HDMI_576p_50, -- PAL 576p in 5:4 @ 50 Hz
2 when qnice_osm_control_i(C_MENU_HDMI_4_3_50) = '1' else -- C_HDMI_576p_50, -- PAL 576p in 4:3 @ 50 Hz
1 when qnice_osm_control_i(C_MENU_HDMI_16_9_60) = '1' else -- C_HDMI_720p_60, -- 1280x720 @ 60 Hz
0;
And in the C64 core it looks like this:
qnice_video_mode_o <= 3 when qnice_osm_control_i(C_MENU_HDMI_5_4_50) = '1' else -- C_HDMI_576p_50, -- PAL 576p in 5:4 @ 50 Hz
2 when qnice_osm_control_i(C_MENU_HDMI_4_3_50) = '1' else -- C_HDMI_576p_50, -- PAL 576p in 4:3 @ 50 Hz
1 when qnice_osm_control_i(C_MENU_HDMI_16_9_60) = '1' else -- C_HDMI_720p_60, -- 1280x720 @ 60 Hz
0; -- C_HDMI_720p_50, -- HDMI 1280x720 @ 50 Hz
In our M2M framework.vhd, line 219+ we are defining:
... encourage CPP's to use constants instead of magic numbers
... remove these constants from framework.vhd and offer them "somewhere" (within globals.vhd?) so that they are available "everywhere" (for the CPP as well as for the M2M framwork)
... refactor the demo core and the C64 core to actually use these constants instead of magic numbers
Since you love refactoring and making the life our our CPP's better :-) Here is an idea I stumbled over today. Feel free to assign to me, if you want me to do this (after Christmas) - or do it by yourself - or decide that it makes no sense, then close the issue as "not planned":
I think we are in agreement, that our CPP needs to be fully in control which screen resolutions, refresh frequencies and other modes (such as RGBHV vs CSYNC, 15kHz vs 30KhZ, scandoubler, yes/no) he is offering to his users. All these settings are done in
mega65.vhdand this is IMHO also where they belong.The only thing that I do not like is, that we ask the CPP to use numeric magic numbers for the screen resolution/refresh frequency instead of nice constants. For example in the demo core the situation looks like this:
And in the C64 core it looks like this:
In our M2M
framework.vhd, line 219+ we are defining:I was wondering, if we should...
... encourage CPP's to use constants instead of magic numbers
... remove these constants from
framework.vhdand offer them "somewhere" (withinglobals.vhd?) so that they are available "everywhere" (for the CPP as well as for the M2M framwork)... refactor the demo core and the C64 core to actually use these constants instead of magic numbers