New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash on DLI #49
Comments
Hi!
Thanks for the very well researched bug report!
I like the "PAUSE 0" solution, as it will make DLI activation more consistent. I don't know if it is enough if one of the first display-list lines has a DLI active, but I suspect that this case would be rare.
Yes, that will work. Will commit now. Have Fun! |
I defined two DLIs in order to change between them as needed. It worked great and I got the effect I wanted.
My program crashed Altirra once, and I didn't do the forensics at the time because I thought it was related to the latest change, but after some days and many, many runs, it crached again, and this time I started Altirra's debugger, finding that the PC was stopped at a KIL instruction ($02).
The address was $9E5C, and that was in the middle of the bytecodes. I loaded the symbols and found that the bytecodes was close to one of the DLIs I defined, which it was located a $9E9F. The other DLI was located at $9F5C.
Then, it seems that a DLI was activated just in the middle of the DLI swap, where only one of the address bytes was updtated, pointing to an invalid address.
I'm not sure, but I think that a solution without the plain DLI command to deactivate the interrupt (and get a glich) or without preceding the activation of the next routine with a PAUSE 0 to get in sync with the vertical blank, it could be to emit the bytes for the pause within the (re)activation of a given DLI.
I mean, in the syntax file, instead of:
use:
(TOK_0 and TOK_PAUSE were added after the first emit).
The text was updated successfully, but these errors were encountered: