search

MEGA65 / mega65-core

MEGA65 FPGA core
Other
241 stars 88 forks source link

VIC-IV should reset D076 SPRENV400 #771

Closed dansanderson closed 8 months ago

dansanderson commented 8 months ago

Test Environment (required) You can use MEGA65INFO to retrieve this.

Describe the bug The sprite V400 flags in register D076 start at $00 in a cold boot. If a program uses hires graphics, this gets set to $FF. When I quick-press the reset button, the screen mode is reset, but this flag is not, affecting programs that use sprites or the mouse pointer and expect a boot state of $00.

This manifests as an affected non-hires program using vertically squashed sprites and a vertically squashed sprite coordinate field. A mouse pointer stops at the middle of the screen. Mouse locations are reported at their original locations, so the program sees the mouse as twice as far down on the screen than it appears.

This scenario is made likely by things like the Intro disks, where someone is browsing demos and games and is quick-pressing reset between each one.

To Reproduce I think I can repro with Intro Disk #3 by playing Classy, quick-pressing reset, then running Char Eddie.

Expected behavior Something should reset D076 to $00 along with other registers. ki-bo suggested that this can/should happen in hardware (not the ROM warm reset routine).

dansanderson commented 8 months ago

I'm still seeing this issue with 683-cartflash,20240121.22,ef01d2c, which includes a merge from release-0.96 and this change. https://github.com/MEGA65/mega65-core/commit/ef01d2c140c005d1a60af4f3ec6af4a03d65228e#diff-e4a7a5e786e706620a1b0c095bbdecf6bca39300a8ec443372c34565f45a5d2b

Specifically, sprites are in hires mode incorrectly after I use m65ftp. I transferred the latest Solitaire disk, then after exiting m65ftp immediately tried to load and run it, and the mouse cursor was exhibiting the squished behavior. Cold boot restored this issue.

Does etherload need to do something specific to reset this?

ki-bo commented 8 months ago

Etherload is just jumping into ROM reset code, no hard reset is done so this core change is not applicable there.

However, this sounds like etherload is doing something wrong. I intended to explicit reset this register in etherload, maybe I implemented it upside down..,