Thank you, paulbni - I think that you're correct - this comparison will cause the end of VSync one line too soon.
dshadoff wrote:Another item we found (by oscilloscope measurement) is that the VSYNC/HSYNC period on this core is not acting exactly as expected; a normal PC Engine's VSYNC is a 3-line period with inverted HSYNC signals in the middle; however, the current MiSTer core's VSYNC period is actually only 2 lines + an extra non-inverted HSYNC. (The edge-offset of both the CPU test vertical line and issue #47 are nearly-exactly an HSYNC pulse width time). I am currently looking into this.
What you are talking is a serration. For modern digital TV it's not required. It's not required even for many CRTs. Serration may interfere the other parts of video, so i highly not recommend to implement it.
To be clear, this is what I am talking about:
You can see that on the PCE output (actual machine), the HSync signal is not a distinct anti-sense pulse at the start or end of the VSync - but rather is embedded into it.
On the MiSTer, the start of VSync incorporates HSync properly. However, at the end of the VSync, it appears that 2 HSyncs are asserted - one, included in the end of the VSync, and an additional one.
If this is what you are saying a serration is, I agree that it should not exist here, and I would like to eliminate it. I just can't see what is causing it yet.
Sorgelig wrote:It's not related to video shift.
Shift on VGA output is accomplished by shifting VSync/HSync. HDMI doesn't use these signals for frame composing (but they should be present for general sync).
In the case of the vertical line in the CPU test, the first color change is timed a specific number of CPU clock cycles after the VSync interrupt, and it is approximately 24 pixels further right on MiSTer as compared to real PC Engine (on both HDMI and VGA output). HSync is coincidentally about this duration.
In this case, one of two (or maybe more) things is happening - it's likely either:
1) The Vblank IRQ and VSync signal may not actually happen at the exact same moment, and may need to be separated slightly (this is the next measurement we need to take from the actual machine), or
2) The serration may be interfering with regular timing of scanline generation. By this, I don't meant that the VDC displays lines differently, but rather that the CPU gets a slightly different amount of work done.
It's not 100% clear from the oscilloscope capture whether it may be interfering with scanline timing at the start of the frame.
(But with respect to issue #47, I'm not yet sure whether it's even related.)
dshadoff wrote:-> If I add some comments to the code to aid in understanding, would you accept those changes into the standard codebase (providing of course, that they are accurate) ?
You can add comments in PCE itself - that's fine (just don't write poems there, please).
Don't modify /sys files.
I mostly wanted to comment the meaning of the signals/variables in the core itself (is "COL" short for "color" or "column" ; what does "X" count ; the _FF signals are actually 1-cycle delay pipelines in many cases, etc.)