Very Minor alignment issue for different resolutions

[dshadoff]

There is a homebrew Split-Resolution test, which may be the only program which uses all three resolutions on the screen at the same time - it can be found on this page: SplitRes by Chris Covell

I am also attaching the program here:
SplitRes.zip

ORIGINAL HARDWARE: You can see on a picture from original hardware that the program intended all three resolutions to have the left edge aligned:

MiSTer: However, MiSTer's alignment is slightly wrong for the mid-resolution (by 1 or 2 pixels), and high-resolution is wrong by a little bit more:

Mednafen: For reference, Mednafen has high-res and low-res aligned, but mid-res is slightly wrong:

[dshadoff]

This is a very low priority, as I do not believe it to interfere with the enjoyment of any games.

[sorgelig]

If i remember right i did adjustments to the way it is to let games with variable resolutions in the frame to look better.

[dshadoff]

Sometime soon, I will measure timing between HSYNC pulse and start of data with an oscilloscope, on original hardware and MiSTer composite, for each resolution. It's very small, and this will prevent guesswork.

[dshadoff]

I've started to take some measurements; I am placing findings here, and will make conclusions before deciding what sort of changes might be required (if any).

Scope traces from PC Engine Duo, using "Screen Dimension Test" from this page: Screen Dimension Test

First round - "256 pix mode":

Settings: Low horizontal resolution (~5.37 MHz, approx. 256 pix visible, 186.24ns/pixel): HSW = 02 HDS = 02 HDW = 1F HDE = 04

Full scanline trace:

H Sync region:

Notes: 1) The period immediately preceding HSYNC is 1.4uS, indicating a value for HS_OFF of 60 in HuC6260.vhd (rather than the current 46) 2) The duration of HSYNC is 4.75uS, indicating a value for HS_CLOCKS of 204 in HuC6260.vhd (rather than the current 192) 3) The display line has some 'empty but usable' space both before and after the pixel information - approx. 2.06uS before, and 2.64uS after the pixel data in this mode. a) Adjusting HDS = 01 reduces the 'empty but usable' signal to 0.57uS, implying that not only can 8 more pixels be displayed to the left in overscan, but it appears that there are still 3 pixels of empty space. b) Adjusting HDW upward also reduces the trailing 'empty but usable' space by 1.49uS. c) This means that the original hardware is capable of displaying at least 272 pixels horizontally in this resolution (possibly more, but the leftover would not be full 8-pix tiles). 4) Changing HSW (sync width) has no effect on sync width, as this is generated by the 6260 on the PC Engine (it is an unused function within the 6270 chip). 5) Likewise, changing HDE appears to have no effect, as the duration of a scanline is of fixed length.

Finally, the timings at 5MHz mode are are follows: A = 1.4uS B = 4.75uS C = 0.75uS D = 2.84uS E = 1.3uS F (sum of C+D+E) = 4.89uS Begin = 2.06uS End = 2.64uS

This also means that the first pixel displayed in this mode is 6.95uS after the HSYNC ends. (Note that this timing should be consistent across modes, for the display settings used on the SplitRes demo in the first post of this issue)

[dshadoff]

Second round - "344 pix mode":

Settings: Medium horizontal resolution (~7.16 MHz, approx. 344 pix visible, 139.68ns/pixel): Note: These are not the default settings on Screen Dimension Test, but rather they are the settings used for the mid-res section on the SplitRes demo):

HSW = 02 HDS = 04 HDW = 2A HDE = 04

Timings for this trace are as follows: A = 1.4uS B = 4.75uS C = 0.75uS D = 2.84uS E = 1.3uS F (sum of C+D+E) = 4.89uS Begin = 2.15uS End = 2.26uS (*) Note that the SplitRes demo has left edges which are aligned, but the right edge of the mid resolution extends out a bit to the right by approx. 2-3 pixels.

First pixel displayed in this mode is 7.04uS after the HSYNC ends.

[dshadoff]

Third round - "512 pix mode":

Settings: High horizontal resolution (~10.74 MHz, approx. 512 pix visible, 93.12ns/pixel):

HSW = 02 HDS = 0B HDW = 3F HDE = 04

Timings for this trace are as follows: A = 1.4uS B = 4.75uS C = 0.75uS D = 2.84uS E = 1.3uS F (sum of C+D+E) = 4.89uS Begin = 2.24uS End = 2.6uS

First pixel displayed in this mode is 7.13uS after the HSYNC ends.

[dshadoff]

Viewing the original hardware again, the left edges don't exactly align, although they appear to align more exactly than the appearance in the MiSTer screenshot.

The PC Engine also can display more information in the horizontal overscan area on both sides, in each of the medium and high-res modes... although it's not clear whether this information is actually useful.

In any case:

• if we consider that one scanline duration (including HSYNC and all signals) is 63.555uS (2730 cycles at 42.954545 MHz)
• and that "Begin" and "End" are actually part of the display line area, we arrive at a display scanline length of 52.515 uS, or roughly 2256 clocks (although some portion would be unaligned to tiles).
• Also, the LEFT_BL_CLOCKS should more appropriately be 11.04uS, or 474 clocks

[dshadoff]

MiSTer measurements for 256-pix mode:

Timings for this trace are as follows: A = 1.07uS (variance = -0.33) B = 4.46uS (variance = -0.29) C = 1.02uS (variance = +0.27) D = 2.52uS (variance = -0.32, but this is explained by 9 cycles instead of 10) E = 2.08uS (variance = +0.78) F (sum of C+D+E) = 5.06uS (variance = +0.17) Begin = 1.328uS End = 2.05uS

First pixel displayed in this mode is 6.95uS after the HSYNC ends.

[sorgelig]

For games not using variable resolution during a single frame these offsets aren't visible. But for games with variable resolution (i forgot the name of game - kind of dungeon hunter), current offsets make it look better. But if you want to add correction - then it's up to you.

[dshadoff]

For alignment, I'm thinking that all that may be required is a "shift of 1 pixel to the right" at each mode, which would more closely align their left edges, and would still allow a full tile block shift to the left in 256 pix mode, with all pixels visible (currently only 7 of 8 are shown). The right edge does appear to stop a bit early (but again, most of the excess would normally be considered overscan).

This basic information may also be helpful with other future questions about video.