MEGA65: YAPED32 problems, bad sprite positions, VIC-IV related

[lgblgblgb]

YAPED32 is much better for now (see issue #212). However one outstanding issue is the wrong sprite vertical position. We know it's problematic for NTSC, but it's for PAL now. It seems, modifying some VIC-IV registers YAPED32 uses (TEXTYPOS, BORDER, ???) does not affect the sprites (or the opposite, affects them, when it shouldn't???) compared to a real MEGA65's behaviour.

Also it seems some problem on the last displayed text line, if I remember correctly.

This issue has been quickly filled out now, before I forget this again.

Discord: https://discord.com/channels/719326990221574164/782757495180361778/908792305476075520

EDITED One note though: that maybe it's not an issue here, but setting border or "TEXTPOS" either vertically or horizontally may be something sprite positions should be taken account for. Here, I guess only the vertical sprite positions are the problem, but who knows, that horizontal position is also a problem in emulation just YAPED32 in fact does not trigger since it does not use that feature. So it can be globally an issue to do something with the sprite positions (compared how they behave on the hardware) when specific settings affecting text position (let it be border and/or "textpos" setting) are changed.

[lgblgblgb]

@hernandp Of course - as usual - if you have any idea here, no need to hold back :)

[hernandp]

Thanks @lgblgblgb !!! I'm gonna to work on it asap ,thanks ;)

You can assign this to me if you want.

[lgblgblgb]

Thanks @lgblgblgb !!! I'm gonna to work on it asap ,thanks ;)

You can assign this to me if you want.

Ok, cool and thanks :) Also the author wrote (see the discord link) that he may write a test program to confirm this theory using sprite collisions (what I've implemented in Xemu since a while) automatically, to know the position of sprites and compare to "where they should be"-kind of knowledge.

[lgblgblgb]

I've updated the issue text above to clarify that it can be a "global" problem not restricted only to YAPED32 or vertical position problem. Sure, in this very case, what helped catch the problem is YAPED32 and it has problem with vertical position (it seems), but in general it can be a more generic problem than only that.

[lgblgblgb]

One idea though: writing a little program to put a sprite and assign some keys to change (individually by certain keys) texpos x/y border x/y whatsoever ... By running on MEGA65 then, it can be seen if changing parameters affects the sprite position or not, just by seeing the sprite if "seemingly moves" or not (though in case of Xemu, the re-defined active texture dimensions may be a problem, thus maybe worth to run with "full borders" on? hopefully it's enough ... if not, the sprite position should be compared to a feature drawn on the screen eg a character or so). That can be compared with running inside Xemu then, for sure.

@hernandp surely, if you don't have time to write such a thing, I may do, but it can take some days for me, because of other on-going projects here (partly MEGA65, partly family-kind). So it's not that, you must do it, just if you have time and if you like to do that. And it's possible you have better ideas anyway.

[hernandp]

One idea though: writing a little program to put a sprite and assign some keys to change (individually by certain keys) texpos x/y border x/y whatsoever ... By running on MEGA65 then, it can be seen if changing parameters affects the sprite position or not, just by seeing the sprite if "seemingly moves" or not (though in case of Xemu, the re-defined active texture dimensions may be a problem, thus maybe worth to run with "full borders" on? hopefully it's enough ... if not, the sprite position should be compared to a feature drawn on the screen eg a character or so). That can be compared with running inside Xemu then, for sure.

@hernandp surely, if you don't have time to write such a thing, I may do, but it can take some days for me, because of other on-going projects here (partly MEGA65, partly family-kind). So it's not that, you must do it, just if you have time and if you like to do that. And it's possible you have better ideas anyway.

I will do it :)

[gardners]

the vicii.prg test program from the mega65-tools repo might be a good test program to modify for this, by testing various positions of the border etc, and checking sprite positions. For the record, sprite positions should not change when either borders or text area is moved.

[hernandp]

I found the bug. Fix available soon ;)

[lgblgblgb]

I found the bug. Fix available soon ;)

Cool :D :D I am not sure though about the other problem was mentioned that the last line is not OK (besides the main problem of sprite position).

[hernandp]

I found that default display_row_count in hardware is 24 even when there are 25 lines on display. When V400 is set, 49 instead of 50 is selected on display_row_count. So I think that the correct emulation is to set display_row_count to 24/49 depending on V400 and render up to display_row_count + 1 rows instead of up to display_row_count in the loop. I'm testing this now.

e.g If you do SYS $FFED to query col/rows you will get 40x25 at boot, but peeking 53371 will yield 24 instead. Maybe @gardners can give us some insight on the design/reasoning.

[hernandp]

Ok seems to work. Take your time to check

https://github.com/lgblgblgb/xemu/pull/316

Thanks.

[lgblgblgb]

Cool! I feel better today (and bored with staying in the bed all the time) so I probably will check it some time during the day.

[hernandp]

Cool! I feel better today (and bored with staying in the bed all the time) so I probably will check it some time during the day.

I hope you feel better, take care! :)