Correct selection of PAL resolutions

[retrorepair]

I'm working out porches for the CRT switching in retroarch and going through the cores and I'm finding Genesis Plus GX is not reporting the correct resolution to retroarch for PAL.

It's odd because 240p test suite by default will start in 240 vertical resolution which is correct for PAL but every game I've tried switches to a 224 vertical res which is not.

I only noticed this as I've been measuring porches with an oscilloscope and megadrive looked quite different where everything else seems to now be correct (so far). Xrandr is confirming this too.

Obviously this is without borders enabled.

Am I missing something? I feel like I've tried everything.

[ekeeke]

I think I already answered this elsewhere. The value reported by the emulator is correct and corresponds to the active screen height when borders are disabled. PAL does not 'force' the active height to 240 lines, this is a misunderstanding on your side, most games actually run in 320×224 mode on PAL megadrives and only a few of them (PAL optimized ones like Street of Rage 3 and Story of Thor or PAL exclusives like Super Skidmark) use the extended video mode to fill a bit more of 50hz TV screen.

You have to understand the screen resolution is controlled by software and is not tied to VDP mode. The only thing that changes between PAL and NTSC consoles (apart the lightly different master clock speeds) is the number of lines per frame/field (262 for NTSC vs 313 for PAL) and consequently the vertical timings (vsync, vblank, etc) and the height of active screen with borders included (243 lines for NTSC and 294 for PAL). See also core/hvc.h for more details.

Not sure what you mean by 'measuring porches' but that's not something a libretro core can control (it only renders a framebufer with active video content and report the size of this framebuffer with associated display infos size, aspect ratio, refresh rate, etc) so the remaining 'lines' of the video signal have to be handled by retroarch somehow, which include top/bottom borders if they are disabled on core side obviously.

[retrorepair]

I underatand what your saying, but that's not really what I've found in the real world.

I'm testing using european cup soccer which is a PAL exclusive game. Using an oscilloscope I can visually see the timing being used on the console and the positioning of the image on the TV. If I compare it to genesis plus gx which is running in 320x244@49hz the signal looks very diffrent and the positioning on the tv is not the same. If i do the same with picodrive with the "show overscan" option enabled (not entirely sure this option means what it sounds like it does) it produces an image of 320x240@50hz. Ignoring the incorrect refresh, the scope shows a near identical measurement and the positioning on the TV looks the same.

I'm not saying your wrong, this is obviously a subject your going to have a lot more experience in than me, but I am confused with the results.

I can post pictures to show what I mean if it helps.

[ekeeke]

Picodrive libretro core always report 320x240 as display size, which means the framebuffer height will always be stretched to 240 lines by retroarch (which is incorrect) and active video height will always be 240 lines. What the 'show overscan' does in Picodrive is the same as enabling top/bottom borders emulation in Genesis Plus GX except it limits itself to add 8 lines above anf 8 lines below the active screen area, no matter actual video mode height or PAL/NTSC mode (which is incorrect as explained above, top/bottom borders in PAL mode are much larger and depend on the video mode height).

Again, if you disable top/bottom border emulation in Genesis Plus GX, these borders HAVE to be recreated somehow by the frontend if you want the output video signal to look like the original one. When it is disabled, the reported height corresponds to the active video height without borders, which is the correct resolution height (much likely 320x224 for this game as I don't think it uses extended video height mode, like I said, only a few did).

The core NEVER reports 244 as height (even when borders are emulated, it limits itself to 240 lines for NTSC and 288 for PAL, to keep screen centered and top/bottom borders symetrical with the same size, which is not "exactly" what real hardware does as mentionned before but does not really matter since those extra lines were not visible on TV screen anyway) so i am not sure from where you get this 320x244 thing. And again, any positioning will be done by the frontend, not the core itself, so whatever you see is the result of how retroarch video driver handles the framebuffer content and recreate the video signal (what is sure is that 320x240 is NOT a PAL-specific resolution and should not be handled like this, PAL standard is 576 active interlaced lines, which correspond to 288 non-interlaced lines, part of them being fixed to border color on the Megadrive , the amount depending on how the game was programmed and which video mode it uses).

[retrorepair]

Ok so as an aside to this, I'm still working on crt resolution switching in retroarch but have some questions (I can't find anywhere else to ask and the mods on spriteminds aren't activating my account).

Firstly, I'm now basing all my work on overscan resolutions where possible (very few cores seem to provide them, this being the one I'm currently most interested in).

I read on spriteminds (your post) that the overscan resolution, minus h/v blanking should be 347 wide for 320 and you link to charles's findings on sms for vertical resolutions which would make it 294 for 224. Thing is, in PAL mode at least, genesis plus gx seems to output 348x288. Is that correct? If so, it doesn't work out with what I've found the pixel clock to be as with porches (again referring to your post) the total resolution should be 420x313, though with the width being 348 that ends up at 421. I've padded the height to match 294 so now have 313 but when I do 421x313x49.701459 that equals a 6.549,310mhz pixel clock which isn't the 6.70mhz I've read it should be? It also only just syncs on the vertical like this so something isn't right I would guess.

I really need to know what the overscan resolutions should be for all modes including the porches so the CRT switching can be as accurate as possible, and provide a future reference for anyone else that may need them. Finding accurate information on this stuff is more difficult than I'd thought!

Could you help at all?

[ekeeke]

I read on spriteminds (your post) that the overscan resolution, minus h/v blanking should be 347 wide for 320 and you link to charles's findings on sms for vertical resolutions which would make it 294 for 224.

That's correct but there should be more recent post from Nemesis with more accurate details. See http://gendev.spritesmind.net/forum/viewtopic.php?f=22&t=1291&start=17

Also, it's 294 lines for any video height mode, the active height (be it 192 in Mode 4 or 224/240 in Mode5) does not matters, it is just the overscan aera that get bigger or smaller).

Thing is, in PAL mode at least, genesis plus gx seems to output 348x288. Is that correct?Thing is, in PAL mode at least, genesis plus gx seems to output 348x288. Is that correct?

Yes, I limited Genesis Plus GX output to 348x288 because of restrictions of Wii / Gamecube hardware (this was originally a port of Genesis Plus to these platforms): framebuffer width must be an even number of pixels and max video height in PAL mode is 576 lines interlaced (288 non-interlaced). It does not matter much since those extra pixels/lines are not visible anyway on TVs.

Another difference is that Genesis Plus GX makes left/right border of the same size (14 pixels) while on real hardware it is more 13 pixels left and 15 pixels right (or the opposite, can't remember right now). Similarly, vertically, I think top border is a little higher than bottom border (also in NTSC mode). In Wii/Gamecube port, I added xoffset/yoffset configurable settings to match exactly the display of my Mega Drive.

If so, it doesn't work out with what I've found the pixel clock to be as with porches (again referring to your post) the total resolution should be 420x313, though with the width being 348 that ends up at 421. I've padded the height to match 294 so now have 313 but when I do 421x313x49.701459 that equals a 6.549,310mhz pixel clock which isn't the 6.70mhz I've read it should be? It also only just syncs on the vertical like this so something isn't right I would guess.

I'm not sure to follow you. First, calling 420x313 the total "resolution" is a bit misleading: there are 420 pixels per line and 313 lines per frame in non-interlaced mode but anything outside that 347x294 window is not really active screen, those are blanked video signal. Secondly, why would "the width being 348 ends up at 421" ? Just because the emulator outputs larger border on one side does not mean you have to increase the number of pixels per line, that won't work and will break video timings. What you need to do is either to ignore the additional pîxel or reduce the width of left or right blanking by one pixel.

What you are also missing in your calculations is that pixel clock in H40 mode (320-pixels wide mode) is not constant. It oscillates between MCLK/8 and MCLK/10 while HSYNC signal is low. See this post http://gendev.spritesmind.net/forum/viewtopic.php?f=22&t=519&start=86 This is done to still get 3420 MCLK per line in H40 mode with 420 pixels (in H32 mode, there are 342 pixels per line and pixel clock is fixed to MCLK /10) : 390 pixels at MCLK/8 + 30 pixels at MCLK/10 WIth MCLK=53203424 cycles / s (on PAL consoles), you get 53203424/3420/313 = 49.701459 frame/s and pixel clock = 6.65 Mhz or 5.32 Mhz

On NTSC models, MLCK=53693175 cycles/s so pixel clock = 6.71 MHz or 5.37 MHz and framerate is 53693175/3420/262= 59.9227 Hz

Note that you can mod PAL consoles to output a 60Hz signal, in which case the framerate becomes 53203424/3420/262=53.376170 Hz