batari, on Wed May 11, 2011 12:28 AM, said:
ScumSoft, on Tue May 10, 2011 10:27 PM, said:
Okay I've figured out why LOW/HI works and yet the demo I posted doesn't.
On the Harmony cart you cannot just update the LOW DataFetcher pointer over and over like I do before updating the HI on Carry set, both have to be written to consecutively in the LOW/HI order.
So to patch this for now, I just rewrite the HI pointer after updating the LOW. This adds cycle overhead to my loops which update the sprites since I have to update the pointers to the next scanline in ScreenRAM space.
But at least this mystery has been solved for now
@batari, would this be correctable in a firmware update? I am guessing once DFxLOW is written to, the next write expects the HI value? I would much rather update the LOW pointer a few times and retain the HI pointer values till I need them updated, rather than having to write LOW/HI every time LOW needs updated.
On the Harmony cart you cannot just update the LOW DataFetcher pointer over and over like I do before updating the HI on Carry set, both have to be written to consecutively in the LOW/HI order.
So to patch this for now, I just rewrite the HI pointer after updating the LOW. This adds cycle overhead to my loops which update the sprites since I have to update the pointers to the next scanline in ScreenRAM space.
But at least this mystery has been solved for now
@batari, would this be correctable in a firmware update? I am guessing once DFxLOW is written to, the next write expects the HI value? I would much rather update the LOW pointer a few times and retain the HI pointer values till I need them updated, rather than having to write LOW/HI every time LOW needs updated.
DPC+ is not in the firmware, but in the binary itself (and for things like this, I'm glad I did it this way.) So, all you need is a new DPC+.arm file to fix any issues. Here's a DPC+.arm that does not clear these bits. Let me know if there are any issues.














