search

lgblgblgb / xemu

Emulations (running on Linux/Unix/Windows/macOS, utilizing SDL2) of some - mainly - 8 bit machines, including the Commodore LCD, Commodore 65, and the MEGA65 as well.
https://github.com/lgblgblgb/xemu/wiki
GNU General Public License v2.0
208 stars 32 forks source link

MEGA65: VIC-IV row count register setting at $D07B has no effect #270

Closed smnjameson closed 3 years ago

smnjameson commented 3 years ago

The register at $d07b should tell the VIC IV how many lines to process, this is not happening on xemu which is always displaying 25 lines in the example:

vic4tests.zip

Expected:

https://user-images.githubusercontent.com/4640763/120922152-72158c00-c6bf-11eb-956c-aa5a9b8ba084.mp4

lgblgblgb commented 3 years ago

As usual, thanks for tracking the issue and reporting and writing test suite!

Note: as far as I study @hernandp 's code, it seems that register is about the variable display_row_count in vic4.c. The problem however, that currently, it's set in vic4_update_vertical_borders and also has some connection with interpreting legacy registers (I guess when hot registers are enabled). So I'm not sure, if it's just easy to take $D07B 's value instead of some pre-set display_row_count value.

Also, we should see, how that register works on real MEGA65, my questions like:

Besides the need to emulate this, I don't really sure why this register is useful at all, if there cannot be anything at the bottom part of the screen not rendered, when row count is smaller than available rows on the screen otherwise, ie what the value to use this feature at all? Not that we don't want to emulate just it would help to understand its purpose if I know the answer :)

smnjameson commented 3 years ago

If row count is smaller than the screen, then the VIC4 will just display background, and it only affects character modes, sprites are unaffected. And yes in V400 mode it defaults to 50. As far as I am aware this has no connection to any VIC2 registers at all so hot registers are no relevant.

As for its use, it will be quite common for game developers to expand their available char screen to larger dimensions by way of this register and border movements. As for making it smaller there's no obvious need that I see right now unless a developer wants to be very efficient with screen memory.

lgblgblgb commented 3 years ago

Thanks. The connection (IMHO) with legacy registers that the value of $D07B should be set on legacy mode set otherwise the screen remain limited ie when switching to V400, as the value should be automatically raised to 50 instead of the old 25 then. However writing $D07B then surely should override that pre-set value. Surely, I call "legacy" anything which is not "native" VIC-IV thing, VIC-II and VIC-III as well, the same way as "hotreg" is defined for "legacy" setting method to actually update internal VIC-IV registers (if hotregs are enabled, for sure). Hmm, at this point, I may have a look on VHDL of mega65-core how this setting is affected by anything (other than user write directly).

lgblgblgb commented 3 years ago

Ok, I have done a horrible hack (but at least a single liner modify to try to fix this issue). vic4.c in Xemu has a display_row_count as I mentioned. And it seems kinda match VHDL how it's handled. So I deleted and instead being a variable, now it's defined as a macro now to be register D07B ;) Yeah, do not tell me, super ugly ...

At least after this one line change the test program result seems to match :-O No idea till now that it has other side effects or anything though, maybe sprite rendering is also not working as this stage. It would be cool to have sprites in the test program to check if affected or not ...

Result is being compiled and deployed now as usual. edit: now it's deployed