Incorrect display with overscan in screen 0 width 40

Here are the 50Hz versions

Some observations:

Normally the display area (without overscan) should start with semi-colons ";", which is the ASCII character before "<". If you look closely at the screen shots you can see that it only displays the last pixel line of the semi-colons, right above the line starting with the "<" characters. In the 60Hz version this replaces the last pixel line of the ")" row and in the 50Hz version the last pixel line of the "/" row.

The yellow area starts at line 0 (i.e. where the display area normally starts). Display of the last pixel-line of the semi-colons starts at line -3.

The top rows in the top border are what would be displayed at the bottom of the screen if it were some 264 or 312 lines high.

Let's calculate this for the 60Hz version: looking at the left side of the screen, let's start at the "<" row. Up to the "#" row this gives 27 rows, meaning 27*8=216 lines. The last row in the top border is the ")" one. Character ")" has an ASCII value of 41 and "#" has an ASCII value of 35. So, 6 more rows after the "#" row. 216+6*8=264. Yes, the last pixel line of the ")" row is not shown, but instead it shows the last pixel line of the ";" row, so that still means we have 264 lines in total.

For 50Hz: rows "<" up to "&" give 30 rows, i.e. 30*8=240 lines. Last top border row "/", ASCII 47, last bottom row "&" ASCII 38, meaning 47-38=9 rows more: 240+9*8=312 lines total.

NTSC: 264 lines
PAL: 312 lines
Both very close to the specs of 262 and 313 :)

If the interrupt for setting the height back to 212 is not done on line 0, but at line 214, then everything seems to shift up a bit (see the attachments for the 60Hz test of this).

Also, if you look closely at the photos you'll notice that with interrupt at 0 there's a total of 29 rows of characters displayed and with the interrupt at 214 it suddenly manages to display 30 rows. I'm guessing this is just how my TV works though and it'll probably look different from TV to TV and monitor to monitor.

Some IRC conversation about this issue that might contain hints on this:

<mth> we still have a hack in the line counter for screen 0, which makes one of anma's demos work, but which we have to fundamental base for
<quibus> mth: I can remove it and try what it does
<mth> the screenshots I saw from kanima suggest that the lines on which overscan is active are correct, but the wrong name table entries are displayed there
<mth> also in the openMSX shot, there are two rows with A's, while the real MSX has each row one time
<mth> which would suggest there is only one reset moment for the name table index
<quibus> actually, things seem to get better without the hack, mth
<grauw> anyway it’s not the bottom of the ) duplicated, but rather the bottom of the character that comes before <
<grauw> (;)
<mth> ah, so that would be the exact time the counter is reset then
<grauw> yes
<quibus> (and Boring Scroll? breaks with it still)
<mth> my guess is that there is a counter which is incremented if a certain moment in time the active mode is screen 0
<mth> with Boring Scroll such moments don't come for the upper half of the screen because a different mode is active there
<grauw> I wonder if this also happens if you switch back to 212 lines after it’s passed line 212… rather than at line 0 as this test seems to do (judging by the colorisation)
<mth> but the reset might still happen, so the counter would be at 0 when immediately after switching to screen 0</mth></grauw></mth></mth></quibus></grauw></mth></grauw></grauw></quibus></mth></mth></mth></quibus></mth>

Also, reporter reported that on screen 5 the emulation is correct. So that's even more pointing to the text mode counter.

See also ticket #43 at https://sourceforge.net/p/openmsx/bugs/42/