Overscan renders lines between the height toggle incorrectly

[ppeccin]

Overscan renders lines between the height toggle incorrectly

[ppeccin]

Ok, I'll have look at this. Its good to have a test case to analyse.
Thanks.

[grauw]

In e.g. renderLineModeG4():

var realLine = (currentScanline - startingActiveScanline + register[23]) & 255;

I think instead of subtracting startingActiveScanline there, you should initialise currentScanline to -startingActiveScanline. So something like:

startingScanline = -16 - addBorder - verticalAdjust;
startingVisibleTopBorderScanline = -8;
startingActiveScanline = 0;
startingVisibleBottomBorderScanline = activeHeight;
startingInvisibleScanline = startingVisibleBottomBorderScanline + 8 + addBorder;
finishingScanline = frameVideoStandard.totalHeight + startingScanline;

That way the realLine is no longer affected immediately by a signal metrics change, that only happens in beginFrame(). This is also how it works in the 1chipMSX’s VHDL code.

[ppeccin]

Interesting... Yes, I imagine something like that may solve the issue. I will have to take a very deeper look at this. The problem is breaking other working and simpler scenarios. Thanks for the heads up, and please come back if you have any other ideas/comments!

…

On Tue, May 8, 2018 at 6:53 PM, Laurens Holst ***@***.***> wrote: In e.g. renderLineModeG4(): var realLine = (currentScanline - startingActiveScanline + register[23]) & 255; I think instead of subtracting startingActiveScanline there, you should initialise currentScanline to -startingActiveScanline. So something like: startingScanline = -16 - addBorder - verticalAdjust; startingVisibleTopBorderScanline = -8; startingActiveScanline = 0; startingVisibleBottomBorderScanline = activeHeight; startingInvisibleScanline = startingVisibleBottomBorderScanline + 8 + addBorder; finishingScanline = frameVideoStandard.totalHeight + startingScanline; That way the realLine is no longer affected immediately by a signal metrics change, that only happens in beginFrame(). This is also how it works in the 1chipMSX’s VHDL code. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AArloE5RbwfLdlj0jHOqLEu6-DYDgHkcks5twhPQgaJpZM4Tuldv> .

[ppeccin]

Hey, It has been some time!
I am finally trying to solve this problem.

But I got suck in a question...
How does the Vertical Adjust value (r18) affect the line interrupts?

I was able to solve the rendering issue on you attached overscan test. It uses Vertical Adjust = 2

But my simulation still breaks in Sex Bomb Bunny game by Matra. It uses Vertical Adjust = -6.
The line interrupts happens too early on this game, and the overscan does not happen properly.

I wonder if this is caused by the Vertical Adjust value?

Paulo

[grauw]

These posts may provide some further insight:

https://www.msx.org/forum/msx-talk/development/grauw%E2%80%99s-rpg-in-development?page=14#comment-338647

openMSX/openMSX#1106

[ppeccin]

Nice... I will read it all!

But... Do you have any clue why the line int happens so early in Sex Bomb Bunny (on WebMSX)?

[grauw]

I tried the demo version of Sex Bomb Bunny in openMSX… There too it currently does not work (probably due to that bug). But I checked what the game does with the debugger :).

Sex Bomb Bunny uses a split on line 200 and line 230 to get the overscan. The maximum vertical interrupt line is 234 in 60 Hz 192 line mode. If adjust affects the maximum line (which it shouldn’t), then an adjust of -6 would probably put it on line 236 effectively, causing it to be missed. Or something along those lines.

A simple test would be to do “set adjust(0, 6)” on that machine, and then boot Sex Bomb Bunny. If the game runs normally, then indeed you’re incorrectly letting the maximum split line be affected by the adjust.

[ppeccin]

But my problem (on WebMSX) is on the first line int, not the second. It happens so early that it is BEFORE line 192, so when it changes from 212 lines back to 192 lines it is still too early, and that does not prevent the starting of the bottom border. The overscan does not start and the bottom part of the screen is black, cutting the bottom of the game graphics. It is even worse, because this way the Vertical Int is also triggered.... Paulo

…

On Tue, May 14, 2019 at 3:44 PM Laurens Holst ***@***.***> wrote: I tried the demo version of Sex Bomb Bunny in openMSX… There too it currently does not work (probably due to that bug). But I checked what the game does with the debugger :). Sex Bomb Bunny uses a split on line 200 and line 230 to get the overscan. The maximum vertical interrupt line is 234. If adjust affects the maximum line (which it shouldn’t), then an adjust of -6 would probably put it on line 236 effectively, causing it to be missed. Or something along those lines. A simple test would be to do “set adjust(0, 6)” on that machine, and then boot Sex Bomb Bunny. If the game runs normally, then indeed you’re incorrectly letting the maximum split line be affected by the adjust. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#33?email_source=notifications&email_token=AAFOLIHFIRWFSWCHU3ELUHLPVMCCJA5CNFSM4E52K5X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVMNKEQ#issuecomment-492360978>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFOLIFSZ7CAGH6LQB3HRY3PVMCCJANCNFSM4E52K5XQ> .

[grauw]

Hmm. It’s past bed-time but let me write down some thoughts;

startingScanline = -16 - addBorder - verticalAdjust;
startingVisibleTopBorderScanline = -8;
startingActiveScanline = 0;
startingVisibleBottomBorderScanline = activeHeight;
startingInvisibleScanline = startingVisibleBottomBorderScanline + 8 + addBorder;
finishingScanline = frameVideoStandard.totalHeight + startingScanline;

And

if (currentScanline >= finishingScanline) finishFrame();

finishingScanline here depends on startingScanline, which depends on verticalAdjust. But we established already that the vertical adjust does not affect the last scan line, so that can’t be right.

Quoting a bit from the forum thread:

Given that the maximum interrupt line doesn’t change with the vertical adjustment, I thought maybe IL wasn’t affected by vertical adjust, but it is and openMSX emulates that correctly. But I did notice on my real MSX that the top lines repeat when the adjust is 7 while overscanning (except for the last), openMSX doesn’t do this.

I think this could be explained by the VDP resetting its internal line counter up to seven lines later than usual (so the first few get an old value), rather than immediately after top erase with an offset. Which would explain the maximum interrupt line not changing.

In other words, vertical adjust changes the line on which the line counter is reset, rather than the value the line counter is reset to.

Something along those lines.

I’ll have to think a bit more about what this means exactly in the WebMSX code.

[ppeccin]

Thanks for responding! Well, this is not how WebMSX code is. Where did you get that from? And to solve the problem of your Overscan test program, I took a different approach that only affects what lines are rendered, not the entire frame synch calculation. Its working fine. "Given that the maximum interrupt line doesn’t change with the vertical adjustment" That is also very strange... It should be affected since with vertical adjust, we would have more or less lines drawn after the first active image line, right???? If the interrupt line count is based on the first active image line as it has been said, we would get a variation (-8 to +7) on the number of lines available until the vertical retrace... So that would mean a different "max" scanline count for IL. Unless you are saying that the count for IL continues even after the vertical retrace, but then we would be getting ILs on the top of the frame, even still inside the top border. Is that the case??? Something is out of place. Paulo

…

On Tue, May 14, 2019 at 7:57 PM Laurens Holst ***@***.***> wrote: Hmm. It’s past bed-time but let me write down some thoughts; startingScanline = -16 - addBorder - verticalAdjust; startingVisibleTopBorderScanline = -8; startingActiveScanline = 0; startingVisibleBottomBorderScanline = activeHeight; startingInvisibleScanline = startingVisibleBottomBorderScanline + 8 + addBorder; finishingScanline = frameVideoStandard.totalHeight + startingScanline; And if (currentScanline >= finishingScanline) finishFrame(); finishingScanline here depends on startingScanline, which depends on verticalAdjust. But we established already that the vertical adjust does not affect the last scan line, so that can’t be right. Quoting a bit from the forum thread: Given that the maximum interrupt line doesn’t change with the vertical adjustment, I thought maybe IL wasn’t affected by vertical adjust, but it is and openMSX emulates that correctly. But I did notice on my real MSX that the top lines repeat when the adjust is 7 while overscanning (except for the last), openMSX doesn’t do this. I think this could be explained by the VDP resetting its internal line counter up to seven lines later than usual (so the first few get an old value), rather than immediately after top erase with an offset. Which would explain the maximum interrupt line not changing. In other words, vertical adjust changes the line on which the line counter is reset, rather than the value the line counter is reset to. Something along those lines. I’ll have to think a bit more about what this means exactly in the WebMSX code. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#33?email_source=notifications&email_token=AAFOLIFIIW237C3GOPKXXPLPVM7XJA5CNFSM4E52K5X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVNA4SQ#issuecomment-492441162>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFOLIBI5ZBV35BHZZMJFS3PVM7XJANCNFSM4E52K5XQ> .

[ppeccin]

Problem solved!
Sex Bomb Bunny working perfectly.

I'll explain it later, after more tests!

Thanks,
Paulo

[ppeccin]

Well, the problem was that I was calculating the starting of the bottom border considering the entire frame structure and metrics of the screen as specified on page 147 of the Tech Data Book.

That made a window of only 10 lines after line 192 for the overscan trick, not 20, because the way I saw it, 10 lines of the extra 20 would be at the top, and 10 at the bottom.

But it seems that the bottom border is started in relation to the REAL starting active line, in fact 192 or 212 lines AFTER the real starting active line, and not on the frame "position" it would be in a normal frame where you don't change LN mid-frame, giving really 20 extra lines of active rendering.
Is that correct the way you see it?

I still have to test and validate it a bit more, but games that use overscan started to work now.

Grauw... Another related question for you...
Regarding the TOP border finishing line and starting of the active screen. Could we do the same LN trick to bypass the starting of the active screen? That would make the entire screen stay in the border section. Like the opposite effect of the overscan technique.
Is that possible?
If so, how all the line counting would happen then? Would line interrupts even happen?

Paulo

[ppeccin]

Well, I think it's fixed!
Please, try again the new version 5.3 (already online)!

Thanks for the information!