Skip to content

Video pipeline and output

Jump to bottom
sy2002 edited this page Oct 20, 2023 · 6 revisions

We need to describe in detail, what kind of signals the M2M framework expects "to do its magic" (R, G, B, HS, VS, HB, VB). And we need to describe helper components that the M2M framework offers such as the framebuffer component that turns a frame buffer into vga signals and also MiSTer's helper components such as screen rotate and others, so that users of our framework know the toolkits of components that we are using (see also Galaga, ZXUno, etc.)

@TODO @TODO @TODO @TODO @TODO @TODO @TODO @TODO

@TODO @TODO @TODO @TODO @TODO @TODO @TODO @TODO

@TODO @TODO @TODO @TODO @TODO @TODO @TODO @TODO

On video_ce_o and video_ce_ovl_o: You have an important @TODO when porting a core:

  • video_ce_o: You need to make sure that video_ce_o divides clk_main_i such that it transforms clk_main_i into the pixel clock of the core (means: the core's native output resolution pre-scandoubler)
  • video_ce_ovl_o: Clock enable for the OSM overlay and for sampling the core's (retro) output in a way that it is displayed correctly on a "modern" analog input device: Make sure that video_ce_ovl_o transforms clk_main_o into the post-scandoubler pixel clock that is valid for the target resolution specified by VGA_DX/VGA_DY (globals.vhd)
  • video_retro15kHz_o: '1', if the output from the core (post-scandoubler) is in the retro 15 kHz analog RGB mode. Hint: Scandoubler off does not automatically mean retro 15 kHz on.

@TODO @TODO @TODO @TODO @TODO @TODO @TODO @TODO

@TODO @TODO @TODO @TODO @TODO @TODO @TODO @TODO

@TODO @TODO @TODO @TODO @TODO @TODO @TODO @TODO

@TODO: We should mention...

... what M2M does high level (the text block below which is copy/pasted from the C64 core might help

... the dynamic nature of the pipeline (we process "anything")

... how we do it (Avalon Scaler/ascal.vhd, HyperRAM, AV pipelines, QNICE's "graphic adaptor")

... that HDMI often looks better than VGA due to the beautiful polyphase filters in ascal.vhd (example C64)

... why at this moment dynamically configurable output resolutions (like at MiSTer) are a lot of work, but that this is on our roadmap

... DVI vs HDMI

@TODO @TODO @TODO @TODO @TODO @TODO @TODO @TODO

@TODO @TODO @TODO @TODO @TODO @TODO @TODO @TODO

@TODO @TODO @TODO @TODO @TODO @TODO @TODO @TODO

A bit of background about M2M's AudioVideo-Pipeline-System: a) Analog ("VGA"): The signals that you feed into M2M's pipeline via mega65.vhd's signals called video_*_o (for example video_clk_o, video_clk_en_o, video_red_o, ..., video_vs_o, ..., etc.) are treated like this: a.1) No Scandoubler active (qnice_scandoubler_o = '0') and qnice_retro15kHz_o ='0' and qnice_csync_o = '0': The signal is directly routed (unaltered) to the DAC chip on the MEGA65's board. You cannot do this with most cores because the video mode that most cores outputs is not "official" (according to any standard, see the PDF that I sent you above) and therefore modern monitors would not "lock on to" the signal. (Some multisync monitors are able to display the raw signal flawlessly, though, but this is not the majority.) a.2) Scandoubler active, retro and csync not active: The amount of vertical lines is doubled, the horiozontal frequency is doubled (normally from around 15kHz+ to around 30kHz+), so the HSync signal's frequency doubles and so does the pixel frequency for RGB. The pixel clock and other parameters determine the final vertical frequency. Most Arcade cores are 60 Hz, this is why we saw 60 Hz on our CRT. QUESTION: Was this HS/VS or CSYNC what we saw in your most recent screenshot? a.3) As soon as you switch CSYNC=1, then an additional component in the M2M framework is activated. This component modulates the horizontal and vertical sync signals (HS/VS) into ONE Composite Sync signal. This very Composite Sync signal is then transmitted on the same PIN of the MEGA65's VGA output port, where normally the horizontal sync signal is transferred AND the vertical sync output is permanently set to HIGH. b) HDMI works quite differently: The analog signals of the core are being input into a component called ASCAL. This component is pretty magic. It detects "everything" automatically and generates a HDMI output according to the target parameters that you are giving to it. In your above-mentioned screenshot example, you chose 50 Hz. This is OK, but will flicker slightly, as the core outputs 60 Hz. So when NOT ROTATING, you could also chose 60 Hz and it would look better. c) The rotation mechanism that we are currently using has quite some weaknesses (please scroll up to my other lengthy message that contains links to M2M issues): We use MiSTer's rotate component (which is great) and which puts the rotated image into a RAM buffer, a frame buffer. Then we use a M2M component that is able to take a frame buffer and convert this again to analog video signals: RGB + HS/VS. And here is the problem: This component is not very sophisticated (see M2M issues mentioned in the lengthy message above) and this leads to this component outputting 50 Hz signals (given the screen resolution of the original core, we did not find other good and official resolutions that work). This is why in rotated mode, even though the core generates 60 Hz, due to the pipeline we have a 50 Hz signal in the end, which might even be cropped slightly wrongly. The pipeline is: 60 Hz analog signal => MiSTer rotation component writing to RAM => M2M framebuffer2analog component => 50 Hz

@TODO @TODO @TODO @TODO @TODO @TODO @TODO @TODO

@TODO @TODO @TODO @TODO @TODO @TODO @TODO @TODO

@TODO @TODO @TODO @TODO @TODO @TODO @TODO @TODO

@TODO: This language is from the C64 core, needs to be adjusted

  • HDMI: The core outputs 1280×720 pixels (720p) at 50 Hz and HDMI audio at a sampling rate of 48 kHz. This is supported by a vast majority of monitors and TVs. In case of compatibility problems, you can switch the HDMI video out to 60 Hz (without affecting the PAL core's internal 50 Hz), but this would lead to a slightly jerky experience when it comes to scrolling and other fast movements on the screen. The 4:3 aspect ratio of the C64's output is preserved during upscaling, so that even though 720p is a 16:9 picture, the C64 looks pixel perfect and authentic on HDMI.

  • VGA: For a true retro feeling, we are providing a 4:3 image via the MEGA65's VGA port, so that you can connect real CRT monitors or older 4:3 LCD/TFT displays. The resolution is 720x576 pixels and the frequency is 50.125 Hz in PAL mode. If your monitor supports this, you will experience silky smooth scrolling without any flickering and tearing.

  • Retro 15 KHz RGB over VGA: This is for the ultimate retro experience: Connect an old Scart TV (for example using this cable) or an old RGB-capable monitor (by soldering your own cable) to MEGA65's VGA port.

Clone this wiki locally