MEGA65: lack of rendering when BORDER_Y_BOTTOM is set too low

[lgblgblgb]

INTRODISK4 intro4.zip displays a basically empty screen (other than background/screen colour change):

After some "decoration" of the Xemu code (adding custom debug messages), I found this:

if (ycounter >= CHARGEN_Y_START && ycounter < BORDER_Y_BOTTOM) { ...

is the condition to render anything at all, and it seems it's not true with this code! Debug messages:

NOT RENDERING SINCE ycounter >= CHARGEN_Y_START && ycounter < BORDER_Y_BOTTOM is not true! ycounter=614 CHARGEN_Y_START=104 BORDER_Y_BOTTOM=8

For some reason intro4 sets the BORDER_Y_BOTTOM a very small value which I cannot understand, naturally of course no display then. I would say, this is the right thing, then no display!! However still this seems to work on MEGA65 and have a very nice output! So, still, it's an Xemu bug, as its behaviour does not match with mega65-core, it seems.

Reported by FPhoton (thanks!) on Discord, topic starts here: https://discord.com/channels/719326990221574164/781481205639020554/1339281119148900402

Addition, an older (?) version of intro4 mentioned here https://discord.com/channels/719326990221574164/1314179483498188830/1339305565221818422 seems to work in Xemu!

[lgblgblgb]

It turned out that INTRO4 had that setting for BORDER_Y_BOTTOM = 8 because of a typo in its code (wrong register is set by mistake). However it does not change the situation that the behaviour of Xemu differs from MEGA65, which shouldn't be the case whatever the reason of this strange setting.

On MEGA65 the effect of that setting is having no bottom border at all. I have the suspect that mega65-core checks if the current raster meets that setting and set a flag then "to render border instead". However Xemu uses a comparison with < which causes this to fail. Though the exact solution used by mega65-core needs to be checked in the VHDL source to be sure.

Simple test program:

10 BORDER 2
20 POKE $D04A, 8
30 POKE $D04B, PEEK($D04B) AND $F0

Which should produce something like this:

Note: on the screenshot the value is 0 not 8, but I guess it does not matter, still problematic for Xemu but not for MEGA65.

[lgblgblgb]

The VHDL seems to be indeed use the theory to catch the actual match and setting "vertical_border" according to that rather inequality check (what Xemu does):

      if displayy=border_y_bottom then
        vertical_border <= '1';
      end if;
      if displayy=border_y_top then
        vertical_border <= '0';
      end if;

Interestingly though, displayy is used not ycounter. I am not very sure what is the difference, Xemu only uses ycounter. What displayy can be, I wonder.

[lgblgblgb]

@gardners If possible, can you tell me please, what is displayy and why isn't ycounter alone is not enough? I tried to figure out from the VHDL but I don't feel any more clever after a hour of digging either ... Thanks!