sy2002 / mister2mega65 Goto Github PK

@MJoergen : Please assign to me as soon as you created the "framework layer", i.e. XDC, top file, etc.

Hello, porting MiSTer cores to Xilinx is also very important for MiSTeX,
a MiSTer port to different FPGA boards, including, but not exclusive to Xilinx FPGAs.

I hope we can communicate.
I already have working ports for the QBert arcade core and flappy bird (apart from the menu and template mister cores).

https://github.com/MiSTeX-devel

Just as an internal reminder for not forgetting the TODOs: In the gbc4mega65 project, we are currently fine-tuning the HDMI video and audio compatibility. The results of these three issues need to be ported to the MiSTer2MEGA65 framework, too:

HDMI protocol analyzer complains about: "Invalid combination" Q1/Q0, Y1/Y0, YQ1/YQ0

720p @ 60 Hz CEA-861E Video Format Timing Error

Question: Is there an easy transistion?

After merging from newest C64 enhancements: Only one vdrive is working

In the VIC20 config.vhd we find something like this:

   OPTM_G_SUBMENU,                                          -- RAM: %s
   OPTM_G_TEXT          + OPTM_G_HEADLINE,                  -- RAM expansions
   OPTM_G_LINE,                                             --
   OPTM_G_EXP_PORT      + OPTM_G_SINGLESEL,                 -- $0400 (3KB)
   OPTM_G_EXP_PORT      + OPTM_G_SINGLESEL,                 -- $2000 (8KB)
   OPTM_G_EXP_PORT      + OPTM_G_SINGLESEL,                 -- $4000 (8KB)
   OPTM_G_EXP_PORT      + OPTM_G_SINGLESEL,                 -- $6000 (8KB)
   OPTM_G_EXP_PORT      + OPTM_G_SINGLESEL,                 -- $A000 (8KB)
   OPTM_G_LINE,                                             --
   OPTM_G_CLOSE         + OPTM_G_SUBMENU,                   -- Back to main menu

This works fine. But it was never "meant to work" like this. Instead, when the OSM code was written, I always assumed that you would have one ID per OPTM_G_SINGLESEL item. Interestingly enough, this way of using the system still works like a charme. At least in the VIC20 use case. And there are cases, like in the VIC20 case, where this is pretty elegant.

This task is about two things:

1. Research in the OSM code (I guess a focus is on M2M/rom/menu.asm), if this way of using the system is robustly implemented. Check all use cases.

2. If the research in (1) unveils challenges, then fix them and enhance the M2M framework so that this use case is officially covered

As of the time of writing this, I (sy2002) have no idea about all the magic that is happening in various retro project to generate a greatly improved retro look and better accuracy like supporting the "smearing effects" that real CRT's had and that were pro-actively used by programmers back in the days. This issue is a research issue for M2M enhancements that eventually can support them and an obvious place where to test them would be the C64 for MEGA65 core. For the time being, this issue is used to collect info.

1. Tom Harte's CLK emulator offers some stunning features around this. Have a look at these screenshots:
   https://github.com/TomHarte/CLK/tree/3dc9b625a18833c0ac6b7ed9e2c9bd0142f70314#signal-processing

2. (Copied from our C64 core's ROADMAP.md) A MiSTer feature request from @paich64:
   MiSTer-devel/C64_MiSTer#104

3. Here is even more info coming from @paich64 (Quoting him):

Such colour blending has been recently implemented for the C64 in the RGB2HDMI project.

RGB2HDMI is a modern solution to connect old computers to HDMI display.

For the commodore 64, 2 devices are needed :

1. the Copperdragon "VIC-II-dizer" FPGA board which produces so called "Lumacode"
   https://github.com/c0pperdragon/LumaCode/wiki/
   https://github.com/c0pperdragon/LumaCode/wiki/VIC-II-dizer-(for-the-C64-computer)

2. The Lumcode is then interpreted by RGB2HDMI
   https://github.com/hoglet67/RGBtoHDMI/wiki
   https://github.com/IanSB/RGBtoHDMI
   release 59 mentions the implementation of colours blending : https://github.com/IanSB/RGBtoHDMI/releases

3. In this issue, we have 2 pictures : On showing the display without colour blending and the second one showing the display with colour blending
   IanSB/RGBtoHDMI#20

4. This video describes the lumacode protocol is :
   https://www.youtube.com/watch?v=SBgo8oGFung

Please implement a fractional scaler for the OSM only:

We would just change the "canvas" of the OSM without changing the output resolution at all. (And obviously we are also not touching the core itself.) The output resolution continues to be defined statically in globals.vhd :

constant VGA_DX               : natural := 720;
constant VGA_DY               : natural := 540;

Do it here in the M2M framework - feel free to add one more more OSM items to test and then please assign it to me when done: I will take it from there, merge it to the C64 develop branch and also add the OSM submenu, enhance the documentation in README.md and in VERSIONS.md and in FAQ.md and enhance the test protocol in tests/README.md

The framework should offer SDRAM support in a Dual Port Dual Clock fashion that also allows working on the falling edge, so that QNICE can be used to "fill" the SDRAM for example with cartridge data or with disk images while the actual core uses SDRAM in its own way.

As soon as we support the RTC in hardware (#29) then we can start tackling it in the firmware.

One obvious idea what the firmware can do with an RTC is:

Files on the SD card (FAT32) that are written to/changed, for example disk images, can showing the updated date/time in future.

Maybe there are even more ideas.

The firmware part is not a low hanging fruit for the R4/R5 surge.

The use case is to be able to control the core and menu without needing physical access to the MEGA65. This could either be done over the serial (UART) port or over Ethernet.

This feature can be implemented in several stages of progressing usability and complexity.

1. The first stage is to forward serial input to the core's and/or M2M's keyboard input.
2. The second stage is to copy the OnScreen Menu frame buffer to the serial output (as text only).
3. The video output from the core could be compressed and sent over the Ethernet, one frame at a time per request. In other words, the user types a keyboard sequence to force a screenshot (snapshot) of the current output frame. The protocol/format would be something proprietary, but easy to implement in the FPGA. This would be decompressed and converted to an image on the host computer.
   Note: I already have a proof-of-concept developed for another project on the Nexys4DDR board (https://github.com/MJoergen/nexys4ddr/tree/master/c64).
4. This stage would continuously generate a stream of data sent over the Ethernet port. This would be converted to a video file, to be viewed later (not real time).
5. The final stage would implement protocol support for some kind of Remote Desktop, that can connect to a standard client on the host machine. This requires a complete IP stack with TCP and UDP support

I expect stages 1-4 to be do-able with very modest resource requirements in the FPGA, and also modest development resources, given that there is already a working POC.
Stage 5 is much more complex: TCP is usually implemented in software, not hardware, so this will likely involve the QNICE CPU, perhaps only after interrupt support and/or DMA support is implemented.

It is a balancing act of being able to show directories with rather more than less files in them in the Shell's FileBrowser (i.e. maximizing the size of HEAP in m2m-asm.asm) and providing meaningful default values for the maximum amount of VDRIVES (VDRIVES_MAX), the maximum amount of manually loadable CRTs/ROMs in the OSM (CRTROM_MAN_MAX) and the maximum amount of automatically loaded ROMs (CRTROM_AUT_MAX) since the latter three maximum values lead to a certain amount of overhead that significantly eats into the free HEAP space.

Even though the user of our M2M framework can configure the amount of actually used VDRIVES, manually loadable CRTs/ROMs and automatically loaded ROMs in globals.vhd, the user currently needs to touch framework code in case of any of these amounts is larger than 3 as described in the comments in globals.vhd:

constant C_VDNUM              : natural := 3;  -- amount of virtual drives; if more than 3: also adjust VDRIVES_MAX in M2M/rom/shell_vars.asm, maximum is 15
...
constant C_CRTROMS_MAN_NUM       : natural := 0;  -- amount of manually loadable ROMs and carts, if more than 3: also adjust CRTROM_MAN_MAX in M2M/rom/shell_vars.asm, Needs to be in sync with config.vhd. Maximum is 16
...
constant C_CRTROMS_AUTO_NUM      : natural := 0;  -- Amount of automatically loadable ROMs and carts, if more than 3: also adjust CRTROM_MAN_MAX in M2M/rom/shell_vars.asm, Needs to be in sync with config.vhd. Maximum is 16

In the case of VDRIVES and manually loadable ROMs/CRTs, the M2M framework user currently needs to touch two spots in shell_vars.asm and one spot in shell.asm and in the case of automatically loading ROMs the user needs to touch one spot in shell_vars.asm.

This is complicated and error prone and it goes against the M2M framework's philosophy that M2M framework users are not supposed to touch the actual framework in the M2M folder but only work in "their" CORE folder.

Here is how we can fix this:

1. Move the appropriate settings (.EQU constants) from shell_vars.asm to CORE/m2m-rom/m2m-rom.asm)

2. Enhance our framework's ROM build script CORE/m2m-rom/make_rom.sh such that the script parses m2m-rom.asm and then dynamically generates include files that contain everything that the M2M framework needs depending on the settings in m2m-rom.asm.

3. These include files are then included in shell_vars.asm and in shell.asm.

4. We then also need to adjust the hints in strings.asm and the comments in globals.vhd

This empowers the M2M framework's users to configure the above-mentioned "balancing act" by changing constants in m2m-rom.asm i.e. in "their space" without touching any framework code.

HDMI compliancy: Assert +5V according to section 4.2.7 of the specification version 1.4b

This very line of code was a game changer when it comes to HDMI compatibility:

   ct_hpd_o           : out   std_logic := '1';

It is here in the R3 version of the core:

https://github.com/MJoergen/C64MEGA65/blob/develop/M2M/vhdl/top_mega65-r3.vhd#L43C72-L43C160

TODO:

• Add this to the R4 board implementation
• Have a test user confirm that it works (either by measuring the +5V or by using one of the devices, for example HDMI capture device, that do not work without these +5V)
• Add this to the R5 board implementation
• Have a test user confirm that it works

Why "confirm that it works?": Because the R4 and R5 boards a new and might have hardware-bugs on the board

@MJoergen You can assign this to me after you fixed it in the code for the "confirm" part of the job: I know the users and the issue quite well.

The democore's M2M-measured DY diverge from ASCAL's DY as shown here:

We agreed upon a protocol between the firmware and "CRT or ROM loading hardware". Examples which are using this protocol currently are in the C64 core:

• Software .crt loading
• Program file .prg loader

The protocol consists of a few state machines and a few constants.

Right now the state machines as well as the constants are always copy/pasted into the multiple "clients/servers" of this protocol.

1. The minimum we should do is to put the constants into an official M2M package and then the CPP would import the package instead of copy/pasting the constants all the time.

2. Optional for bonus points: Can we write some generic code that CPPs can use to implement this protocol (and if so, we would then refactor the above-mentioned "users").

   -- Status reporting from QNICE/firmware:
   constant C_CRT_ST_IDLE         : std_logic_vector(15 downto 0) := X"0000";
   constant C_CRT_ST_LDNG         : std_logic_vector(15 downto 0) := X"0001";
   constant C_CRT_ST_ERR          : std_logic_vector(15 downto 0) := X"0002";
   constant C_CRT_ST_OK           : std_logic_vector(15 downto 0) := X"0003";

   -- Status reporting to QNICE/firmware
   constant C_STAT_IDLE           : std_logic_vector(3 downto 0) := "0000";
   constant C_STAT_PARSING        : std_logic_vector(3 downto 0) := "0001";
   constant C_STAT_READY          : std_logic_vector(3 downto 0) := "0010"; -- Successfully parsed CRT file
   constant C_STAT_ERROR          : std_logic_vector(3 downto 0) := "0011"; -- Error parsing CRT file

   -- Control and Status register
   constant C_CRT_CASREG          : unsigned(15 downto 0) := X"FFFF";
   constant C_CRT_STATUS          : unsigned(11 downto 0) := X"000";
   constant C_CRT_FS_LO           : unsigned(11 downto 0) := X"001";
   constant C_CRT_FS_HI           : unsigned(11 downto 0) := X"002";
   constant C_CRT_PARSEST         : unsigned(11 downto 0) := X"010";
   constant C_CRT_PARSEE1         : unsigned(11 downto 0) := X"011";
   constant C_CRT_ADDR_LO         : unsigned(11 downto 0) := X"012";
   constant C_CRT_ADDR_HI         : unsigned(11 downto 0) := X"013";
   constant C_CRT_ERR_START       : unsigned(11 downto 0) := X"100";
   constant C_CRT_ERR_END         : unsigned(11 downto 0) := X"1FF";

Use the demo core and test:

1. Does 800x600 work?

2. About the glitches in 720p @ 60 Hz mode:

Feedback from @MJoergen:

======

Re: glitches in the 720p @ 60 Hz mode.

The (minimum) HyperRAM bandwidth required by the ascaler can be calculated as follows:

The ascal'er first writes the entire frame (at the core frame rate), then reads the entire frame (at the HDMI output frame rate).

In the case of the democore, the frame size is 720x576x3 bytes (24 bits per pixel), i.e. 1.24 MB. This must be written 50 times a second and read 60 times a second. I.e. a total of 110 times a second. The total memory bandwidth required is therefore:
1.24 MB * (50 + 60) = 137 MB/s. The total available HyperRAM bandwidth is 200 MB/s. The utilization is therefore 137/200*2 = 68%.

In practice there is some overhead (the ascaler actually stores a bit more data, and there is a transaction overhead with the HyperRAM). So in practice the HyperRAM is approx 75% busy in this configuration. This is an average amount, and the HyperRAM accesses can/will/do overlap occasionally. I'm guessing this explains the glitches.

I'm adding a statistics module, that can "analyze" the HyperRAM accesses and measure the time it's busy. But what is more relevant is how much time is spent waiting to get access. Both average waiting time and maximum waiting time is of interest.

======

The major question about this glitch is: Has it always been there? I.e. even in 1.0.0. Needs to be validated on an R3 board.

Feedback @sy2002 to @MJoergen:

====

3. Re Glitch in 720p @ 60Hz Mode: OK I will put this on my list to test: If it has been always there, then there would be no need to fix it now. Might also be an interference / moiré-ish pattern due to 50Hz core interfering with 60Hz screen mode?

====

Quote from @MJoergen in a Skype conversation:

Here's an idea for M2M version 3 (or whatever): Add ethernet support (UDP and/or TCP) in QNICE, and then let it read files from a network file share. For instance, in the OSM one would configure an IP address, and then the file browser would read files from a server instead of from the SDCard. This would require users to setup a file sharing server on their host PC. I actually played around with that some years ago using the TFTP protocol, but perhaps HTTP is more "modern". Anyway, this requires implementing a TCP/IP stack in QNICE assembly. This would be a purely framework-only feature, i.e. the core would be agnostic of it.

At a later stage one could perhaps somehow add support for it in the C64 core, e.g. by assigning device number 9 or 10 to this feature, so users could just type LOAD "$",9,1 to browse the file server directly.

Here is Paul's first "bring-up" post:

https://c65gs.blogspot.com/2023/06/mega65r4-bring-up.html

This article shows: This is a lot more than just "changing a few FPGA ports in the XDC file":

1. As soon as we start to think about the architectural enhancements and feature enhancements that are necessary to support the MEGA65 R4, we need to read all Paul's posts (revisit blogspot and see if there are more than just the one mentioned above) and other info sources (incl. MEGA65 source code)in detail: We need to come up with a list of things that need to change or that need support in the R4.

2. We also need to think about implications on the level of a core: Can the M2M framework abstract-away things like the changes in the IEC port? Or the amount of memory and HyperRAM vs SDRAM? If yes, then M2M supports IEC from then on and for example the C64 core would not need any notion of "is a R3/R3A or R4 running?" otherwise it would, i.e. cores would start to become machine-type-aware

Some early first thoughts in random order (and as written above: This list needs to be heavily scrutinized):

• HDMI driver IC
• Removal of MAX10: Reset-detection
• Analog audio DAC with I2C config interface
• 64 MB SDRAM
• Bi-directional joystick ports: (How to) support? Paul describes a mouse problem on the MEGA65 with new port; mouse support for C64 => GEOS, etc. needs double-check
• New RTC chip (M2M does not support RTC, yet, but would be nice, e.g. for GEOS but also for tagging *.d64 with the right date/time when the core writes to a disk image: We need to support 3 different RTCs as it looks like: Original M65 R3 RTC, "workaround R3 RTC" and new R4 RTC)
• IEC has a new and different circuit incl. one signal that is now negated

This is a reminder to act synchronously by linking to the issue in the C64MEGA65 repo: MJoergen#97

If you decide to close the issue 97 in the C64 repo with "Close as not planned" then please do so, too, with this one.

If not, then port the fix to the M2M framework, too and then this is the reminder for it.

Randomly found this while waiting for synth to complete and browsing log files.

Not sure if relevant, feel free to "Close as not planned" if not relevant:

[Synth 8-6044] Case expression and choice expression width mismatch, Case expression is 9 wide and choice expression is 8 wide ["M2M/vhdl/controllers/HDMI/video_out_clock.vhd":136]

It is about this 9-bit long case statement and these 8-bit long when statements:

        case '0' & addr is
          -- Desired frequency = 25.200 MHz
          -- CLKFBOUT_MULT_F   = 31.500
          -- DIVCLK_DIVIDE     = 5
          -- CLKOUT0_DIVIDE_F  = 5.000
          -- CLKOUT1_DIVIDE    = 25
          -- Actual frequency  = 25.200 MHz
          when x"00" => data := x"06" & x"1145" & x"1000";  -- CLKOUT5 Register 1
          when x"01" => data := x"07" & x"0000" & x"8000";  -- CLKOUT5 Register 2
          when x"02" => data := x"08" & x"1083" & x"1000";  -- CLKOUT0 Register 1

Research how MiSTer handles NVRAM, for example in @sho3string 's Stargate port and offer a solution for NVRAM for example to store high-scores

Please proof-read these two articles:

https://github.com/sy2002/MiSTer2MEGA65/wiki/Fatal-Errors

https://github.com/sy2002/MiSTer2MEGA65/wiki/Shell-memory-layout

Feel free to not only edit for spelling and grammar but also for clarity.

Close this issue when done.

The pin layout on R4 and R5 is pretty different from R3/R3A. Therefore:

From a Skype message from @sy2002 to @MJoergen:

The placement contraints in the XDC for HyperRAM, keyboard, SD card controller and VGA output registers where mission critical to fix certain "odd bugs" that we encountered. You can walk through the closed issues on GitHub in the C64 folder. So we need to take this seriously. Since the PIN positions changed: Did you ensure that the new position is in line with what is described in the comment?

Michael, can you create an updated version of the "Framebuffer2VGA" component? One that allows two operation options: Option 1: CUT a few scanlines at the top and at the bottom of the rotated screen. Option 2: PAD a few scanlines at the top and at the bottom of the screen. And about the x-axis: You would always pad with transparent pixel to keep the aspect ratio. With that, we could go for officially supported 60Hz resolutions according to the CEA-861-D standard.

The idea is that you are not doing scandoubling, so that we still have a non-scandoubled 15 kHz ouput that we can use for CSync and CRTs. The scan-doubler is activated in the framework if someone chooses standard VGA out.

According to the table on page 13 of the CEA document, there are a bunch of 15kHz resolutions that either work with CUTTING or with PADDING. Eventually it should be our end-user's choice if they prefer to loose a bit of the headline or the footer or both - or - if they have a "non-full-screen" rotation. I am talking VGA because thanks to ASCAL, HDMI will look awesome in 60Hz.

Suggestions for the rotated output, coming from a NOT rotated resolution of 288x224 pixels, i.e. expecting that the rotated resolution is <224-left/right/padded> x 288 or less than 288:

CEA Video ID code 8: 720x240, 60 Hz, aspect ratio 4:3, chapter 4.11 page 27. We would have to cut 48 pixels. Either 22 at the top and 22 at the bottom or 48 at either top or bottom. So the caveat is the cut. The advantage is: Full screen and buttery smooth 60 Hz. Interestingly enough - I don't get it: The table on page 12-14 also specifies "odd" frame rates that might even be what Galaga needs. In case of VGA. But for flicker-free HDMI we need 60Hz anyway.

For people who want to connect a VESA compliant monitor (which is more like a computer monitor and not a retro TV or display): 800x600 @ 60 Hz. Fits nicely the 2x288=576 with not that much padding and is an officially "respected" resolution that a lot of monitors can copy with.

I feel that the Galaga core would not have independent settings: HDMI or VGA: It would be more one menu with certain options. Some of them look great on HDMI, some of them great on a SVGA monitor and some of the kind of OK on retro CRTs (cutting/padding).

Additionally (or alternatively) we might also look at these "Low-definition television" standards:
https://en.wikipedia.org/wiki/Low-definition_television

"CIF / SIF" offers "288p" which would be exactly the y-size we need and x would be padded to fill to the actual resolution: 352×288
https://en.wikipedia.org/wiki/Source_Input_Format

The ZX-Uno for MEGA65 core has a very nice feature: If you switch on Caps Lock then the cursor keys of the MEGA65 in conjunction with the Space bar are simulating a joystick.

For users of our cores, who don't have a joystick handy this might be a game changer.

We might implement this feature in a way, that the simulated joystick by default is in port #1 and if one uses the "flip joystick ports" signal, then the simulated joystick goes to port #2.

@MJoergen Please decide if you want to do this in 5.1 (then the existing label "R4/R5 Surge" is correct - or not, then delete that label).

Adding support for RTC in M2M makes sense because:

1. Multiple cores can make use of an RTC: C64 core (GEOS), ZX Uno (currently outputs an error due to missing RTC when booting), the PC 486 core from MiSTer...

2. The firmware can make use of the RTC and make sure that files on the SD card (FAT32) that are written to/changed (for example disk images) are showing the updated date/time: #30 (The firmware part is not a long hanging fruit for the R4/R5 surge, but maybe the hardware part is.)

3. We need to abstract away the details of the different RTCs in R3/R3A vs. R4/R5 and even the fixed RTC for R3/R3A which uses a PMOD connector. So there are three RTCs as of now that we need to support.

It would be nice with more color options in the menu (even full RGB?), for an improved user experience, making text easier to read and nicer to look at.

The current implementation limits the RGB color representation to be a combination of foreground and background, including a DARK or an INVERSE option (e.g. 0x16 for yellow foreground on green background). This works for the basic usage, but ideally it could support individual full RGB scale, like #F0E68C for background and #4B0082 for foreground.

This is just wishful thinking from my side, and naturally not very important :-) Nice-to-have feature.

I am MegaBeauvais#9623 on MEGA65 Discord.

Labeled as V2.0.0 and needed for the C64 core V5.1:

We found that each board revision seems to need its own HyperRAM phase. We need to experimentally confirm the right phases for R4 and R5 and we stick to the known-good phase for R3/R3A.

Right now, the M2M framework supports these combinations of resolutions, aspect ratios and display frequencies:

16:9 720p 50 Hz = 1,280 x 720 pixel
16:9 720p 60 Hz = 1,280 x 720 pixel
4:3  576p 50 Hz =   720 x 576 pixel
5:4  576p 50 Hz =   720 x 576 pixel

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:

4:3  576p 60 Hz =   720 x 576 pixel
5:4  576p 60 Hz =   720 x 576 pixel

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.

The M2M framework now automatically detects the screen resolution (i.e. visible pixels) received from the CORE. Inside the "monitor" this can be retrieved as follows:

QMON> MEMORY/CHANGE ADDRESS=FFF4 CURRENT VALUE=0101 NEW VALUE=00FF
QMON> MEMORY/CHANGE ADDRESS=FFF5 CURRENT VALUE=0001 NEW VALUE=0010
QMON> MEMORY/DUMP START ADDRESS=7003 END ADDRESS=7004

7003: 0180 010E 

The above is from the C64MEGA65 core, and shows that the horizontal size is 0x0180 = 384 pixels, while the vertical size is 0x010E = 270 lines.

This information should also be available without having to enter the "monitor". E.g. either displayed to UART upon start-up, and/or visible somewhere in the OSM.

Each core is supposed to deliver these signals to the M2M framework:

      -- Video output
      video_ce_o              : out std_logic;
      video_ce_ovl_o          : out std_logic;
      video_red_o             : out std_logic_vector(7 downto 0);
      video_green_o           : out std_logic_vector(7 downto 0);
      video_blue_o            : out std_logic_vector(7 downto 0);
      video_vs_o              : out std_logic;
      video_hs_o              : out std_logic;
      video_hblank_o          : out std_logic;
      video_vblank_o          : out std_logic;

But what does one do, if the core does not deliver any HBLANK/VBLANK signals?

For example: ZX-Uno:
https://github.com/sy2002/zxuno4mega65/blob/dev-M2M/CORE/vhdl/main.vhd#L115

It only outputs HSYNC/VSYNC but no HBLANK/VBLANK.

How can we make the life of people who port cores as simple as possible when it comes to this topic?

We need to make our Scandoubler smarter. Right now, several parameters are hardcoded, for example but not limited to video_mixer's input parameters:

	parameter LINE_LENGTH  = 768,
	parameter HALF_DEPTH   = 0,
	parameter GAMMA        = 0

This can lead to problems such as wrong colors or some cores not even working on certain monitors. For example for @sho3string the scan doubled mode of Galaga is not working on his analog ("VGA") monitor, while for @sy2002 it is.

Here is a copy/paste from a Skype chat between sy2002 and @sho3string:

1. Galaga via analog out ("VGA") using all three modes "Standard", "15 kHz HS/VS" and "15 kHz CSync" all work like a charme on my monitor. I am talking about the release version that you've put on the filehost.
2. The same is true for Xevious : Works perfect in all three VGA modes
3. But Bosconian has color glitches in "Standard" VGA mode (it is "too pink") but it works fine in 15 Khz HS/VS and in CSYNC mode.
4. Please send me Bomb Jack. Maybe VS/HS works on my Monitor.

What this is showing me: The raw analog output of these Arcade cores need some better processing to work on all analog ("VGA") monitors. Our standard M2M scandoubler is not always catching the right RGB info and therefore timing, this is why Bosconian is too pink in scandoubled mode (aka "Standard") but works fine in 15 kHz mode (HS/VS or CSYNC).

This info came via the R5 board email discussion group:

Trenz produced and tested first R5 prototypes.

During tests, we discovered a squeaking sound due to the operation of 2 new power supplies MP8869S.
As we found out, this is due to the LLM operating mode, which automatically switches to PWM mode when a certain power consumption threshold is reached.
See description of Reg01 SysCntlreg1 in the datasheet. Unfortunately there is no OTP memory for reconfiguration on production.

Paul asked:

Regarding the power supply noise, am I correct in assuming that we can make the FPGA bitstream control those to select the silent mode of operation?

Answer from Vadim:

That's correct. The FPGA is connected to power supplies via the I2C bus.

Should video_counters.vhd be located in the subfolder av_pipeline because it is instantiated within the file "av_pipeline.vhd" which is located in "av_pipeline" - or is there a specific reason why it is located in the "main" folder ("vhdl")?

Depending on your answer: Please move the file or not (and if you move: adjust the XPR project file) and then close this one here.

Do not yet merge to the C64. I plan a larger merge later.

I've got a safety copy of "Raid on Bungeling Bay" that shows a "ghost image" of the helicopter's rotor Blade.

The same is shown correctly on an Ultimate 64

Handle PMODs: XDC and stable default settings in the top files:

The refactoring will ultimately reduce the complex logic tree generated.

The idea is to use simpler (and slightly slower) algorithms, but reduce complexity (and maybe even synthesis time).

Currently, the EAE uses approx 1339 LUTs and 410 slices. This can probably be reduced by a factor of 5 or more.

Currently, a calculation takes 3 clock cycles. After refactoring I estimate a calculation to take around 7 clock cycles.

To accommodate the slower calculation, a CPU_WAIT_FOR_DATA signal should be added.

Reported from @sho3string via Skype:

When you position a sub-menu at the very end of the menu, then it does not work. Explained in this video:

Looks like the newer HyperRAM chips on R4/R5 boards are able to cope with 200 MHz instead of the 100 MHz we are currently using. Would be a very welcome latency reduction and speed boost.

As reported here:

https://www.forum64.de/index.php?thread/125676-c64-core-f%C3%BCr-den-mega65/&postID=2154516#post2155129

An Amiga Mouse in Port 1 blocks (probably) any core's keyboard. Tested with C64 and ZXUno.

TODO:

1. The MEGA65 core does not have this problem and I do know that in the VHDL codebase of the MEGA65 core there is code that handles the Amiga mouse and even can detect it. We should use that tp prevent that this happens.

2. Update the C64 FAQ before we release 5.1 (this will be tracked in the C64 issue tracker, here: MJoergen#123)

The Framebuffer you did for Galaga looks interesting.

Is it generic enough to become an official "member" of M2M? An optional tool that is helpful for cores like Galaga - or the GameBoy (which is not yet ported to M2M) and which render to framebuffers?

If so, please merge/migrate to M2M.

Here is the QNICE branch which is based on the "M2M branch" V1.61 that includes MJoergen's new SD card controller:
https://github.com/sy2002/QNICE-FPGA/tree/mfj_new_sdcard

MJoergen's new SD controller passed "F+D" in the monitor plus the hardcore testing suite "fwrite.c". Here are his comments taken from a Slack conversation between him and me:

1. My SDCard repo is updated with the latest fixes.
2. The QNICE repo is revived, so that V1.61 standalone builds and works on R3 (with old SD card controller).
3. The QNICE repo has added a branch "mfj_new_sdcard" based off V1.61. Has been tested using your fwrite.c program.
4. The M2M repo has added a branch "mfj_new_sdcard" using this new QNICE. Builds, but has not been tested.
5. The M2M repo needs more work, because we need to support SPI mode on R3. This requires some work, and I'm not motivated for that right now. So I'll leave things as they are now, and go back to the VIC20 repo.
6. As we talked about on our last call, I don't think the new SD card controller is ready for M2M v2.0, partly due to very limited testing, and partly due to lack of support for SPI mode on R3. But the work required is of limited scope, so we might conceivably make a M2M V2.1 in the future, using the new SD card controller.

From a Skype conversation between @MJoergen and @sy2002:

MJoergen:

At some point we might want to look into the C64 core's SID implementation. While debugging my audio controller I noticed some strange effects from some of the games I played. Specifically, what should be a smoothly varying signal from the SID had some mysterious discontinuities, i.e. large jumps from one sample to the next. I have a slight suspicion that there is something wrong with the audio filters.

I therefore added the option to generate a simple sine wave (test tone) of a fixed frequency, and that works like a charm. I even fed the analog output into my desktop machines microphone input and fired up the program audacity and did a spectral analysis! The waveform looks smooth as a baby's bum :-)
So I'm confident my audio controller works as expected.

sy2002:

AARGH: A SID problem? Hopefully it is "just" the filter: Can you do this test again and switch-off "Audio-improvements"? This "Audio-improvements" is some strange MiSTer "thing" that we never looked-at more closely.

Next steps:

1. First of all, @MJoergen should re-do the very test with the test signal but with DEACTIVATED MiSTer filters, so that we can see: Is this a SID bug or a MiSTer audio filter bug?

2. If it is a SID issue:

• We need to rename this issue and then probably move to a future release (post 5.1). Sorgelig of MiSTer completely re-did large part of the SID in late 2022, see this list: https://github.com/MiSTer-devel/C64_MiSTer/commits/master There are five SID related commits between November 16 and November 25. Back in the days, we (AmokPhaze, deft and sy2002) tested using audio recordings of MiSTer and our current SID version for various songs and both SID variants (6581 and 8580) if and what sorgelig's updates did to the sound: WE WERE NOT ABLE TO HEAR ANY DIFFERENCES between "before and after".
• But maybe the refactoring sorgelig did, which includes using code from the this project: https://github.com/daglem/reDIP-SID, nevertheless fixes the issue that @MJoergen detected.
• If it is NOT a SID issue, then let us NOT touch the SID implementation we currently use.

3. If it is a MiSTer audio filter issue:

• Let us find out what this audio filter actually does
• Let us decide if we can/want to fix it or if the filter needs to go away (or at least is DISABLED by default)

To my knowledge then only 16x16 charsets are supported, but it would be nice with alternative sizes (e.g. 12x12).

This is just wishful thinking from my side, and naturally not very important :-) Nice-to-have feature.

I am MegaBeauvais#9623 on MEGA65 Discord.

From a Skype discussion between @sho3string and @MJoergen:

====

So this core has vertical / horizontal center for the vga out display.

Currently, the display is shifted to the right hand side on my crt. this is no problem as I can hard code some value to shift it across to the left for now.

wire [4:0] HOFFS = ... some value from OSD ( 0 - 31 )
wire [2:0] VOFFS = ... some value from OSD ( 0 - 7 )

This then gets fed into HVGEN ( i guess horizontal/vertical video generator ?? ) which moves the image back to the left depending on the values above.

Now I can easily add a sub menu like this below. But it's not very intuitive and uses up much real estate.

Horizontal Offset

1
2
4
8
16

Is it possible to some day implement something like this where you can use the arrow and automatically count up values from a minimum value to a max value ? You could say this is a feature request. I think this is more intuitive and we won't need any submenu for that at all.

Horizontal Offset - <0 -31>
Vertical Offset - <0 - 7>

Background info and the actual tracking is here:

MJoergen#141

The task at hand is:

Refactor the M2M framework: SDRAM on R6 and newer, HyperRAM on R3/R3A, R4 and R5

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:

---------------------------------------------------------------------------------------------
-- Constants
---------------------------------------------------------------------------------------------

constant VIDEO_MODE_VECTOR    : video_modes_vector(0 to 6) := (
   C_HDMI_720p_50,        -- HDMI 1280x720   @ 50 Hz
   C_HDMI_720p_60,        -- 1280x720        @ 60 Hz
   C_HDMI_576p_50,        -- PAL 576p in 4:3 @ 50 Hz
   C_HDMI_576p_50,        -- PAL 576p in 5:4 @ 50 Hz
   C_HDMI_640x480p_60,    -- HDMI 640x480    @ 60 Hz
   C_HDMI_720x480p_5994,  -- HDMI 720x480    @ 59.94 Hz
   C_SVGA_800_600_60);    -- SVGA 800x600    @ 60 Hz

I was wondering, if we should...

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

This stack-overflow article and this other stack-overflow article explains some of the intricacies.

The documentation should be a hand-held procedure, listed as step-by-step.

The goal is to be able to easily fetch and merge and later updates to the M2M framework to existing cores.