Update the "Framebuffer2VGA" component

[MJoergen]

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

[MJoergen]

Interestingly, the monitor I have connected to my MEGA65 is a Dell U2412M. According to the User's Manual, it supports a HSYNC frequence between 30 kHz and 83 kHz. However, it turns out the monitor works perfectly fine with a 15 kHz HSYNC frequency. With this video resolution (to the VGA input) the monitor reports an input resolution of 720x288 @ 50 Hz, whereas with the "standard" 31 kHz HSYNC frequency the monitor reports this as 720x576 @ 50 Hz.

So it appears the User's Manual does not contain a complete list of resolutions accepted by the monitor.

[sy2002]

@MJoergen FYI: This is not only a Galaga issue. I also plan to port the GameBoy to the M2M framework soon. And the GameBoy has 160 x 144 Pixels as a native resolution and it works with a frame buffer. So our upcoming concept will have multiple "customers".