Zerosquare Posted June 26, 2022 Share Posted June 26, 2022 And as a reminder, here's what the doc says: Quote Link to comment Share on other sites More sharing options...
42bs Posted June 26, 2022 Author Share Posted June 26, 2022 Interestingly the issue appears only for GPUOBJ interrupts. I have timer and CPU interrupt active w/o problem. Quote Link to comment Share on other sites More sharing options...
42bs Posted June 26, 2022 Author Share Posted June 26, 2022 1 hour ago, Zerosquare said: And as a reminder, here's what the doc says: Yes, I know. But, as I wrote before, JagTris crashes after a while if I use "addq #4,r31". Sometime the write back fails. So I ended up with restoring r31 with the stack top. In JagTris only the MOD player uses 68k, all the game is using the GPU and GPUOBJ and timer interrupt. But it does not use "jump z," or "jr z,"! Quote Link to comment Share on other sites More sharing options...
42bs Posted June 26, 2022 Author Share Posted June 26, 2022 1 hour ago, Zerosquare said: he audio/input engine I wrote (that's been used in a number of Reboot and rB+/Jagstudio games) My current theory is, that OP and GPU are tied very closely, so maybe that's the root of the issue. Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted June 26, 2022 Share Posted June 26, 2022 Yeah, was trying to remember where the GPU interrupt stack thing was first discovered, and it was this thread, @42bsagain of course. Sort-of-confirmed from Doom sources. Quote Link to comment Share on other sites More sharing options...
+cubanismo Posted June 26, 2022 Share Posted June 26, 2022 Curious: Is the theory here that the wrong register bank is used for the first instruction after the interrupt, or that the flags (CC bits live here, right?) are in general not restored in time, causing code in the interrupt return tail to affect the jump condition? Quote Link to comment Share on other sites More sharing options...
42bs Posted June 27, 2022 Author Share Posted June 27, 2022 4 hours ago, cubanismo said: Yeah, was trying to remember where the GPU interrupt stack thing was first discovered, and it was this thread, @42bsagain of course. Sort-of-confirmed from Doom sources. Arg, I am getting older. I looked again at the DOOM source and thought: Hey, look what they do. I really did not remember this thread Quote Link to comment Share on other sites More sharing options...
42bs Posted June 27, 2022 Author Share Posted June 27, 2022 More test: Switch back to the canonical return (restore flags in the jump-slot). Now do this in the foreground code: moveq #1,CPUIrqFlag waitStart: cmpq #0,CPUIrqFlag jr pl,waitStart ; wait for interrupt from 68k nop The OP interrupt set this bit to -1. This works (for a while) then my code hangs. Switching to set the flag to -1 and wait for it to become positive does not work at all, the loop is always skipped. Returning to the "un-canonical" return from interrupt, there is no hang and the test for negative version also behaves correctly. Sidenote: DMAEN helps to fix the "test" issue, but display is heavily corrupted. Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted July 2, 2022 Share Posted July 2, 2022 Have you tried it on another Jaguar? Quote Link to comment Share on other sites More sharing options...
42bs Posted July 2, 2022 Author Share Posted July 2, 2022 58 minutes ago, Zerosquare said: Have you tried it on another Jaguar? Hmm, no, but will. I hope there is no difference. Quote Link to comment Share on other sites More sharing options...
Seedy1812 Posted July 4, 2022 Share Posted July 4, 2022 (edited) On 6/27/2022 at 5:49 AM, 42bs said: More test: Switch back to the canonical return (restore flags in the jump-slot). Now do this in the foreground code: moveq #1,CPUIrqFlag waitStart: cmpq #0,CPUIrqFlag jr pl,waitStart ; wait for interrupt from 68k nop The OP interrupt set this bit to -1. This works (for a while) then my code hangs. Switching to set the flag to -1 and wait for it to become positive does not work at all, the loop is always skipped. Returning to the "un-canonical" return from interrupt, there is no hang and the test for negative version also behaves correctly. Sidenote: DMAEN helps to fix the "test" issue, but display is heavily corrupted. I think reading the cmpq flags is happening too early ? On cycle 3 the flags are in a valid state. Yet the jr pl,waitStart needs the flags to be valid on the 1st cycle. But isn't that cycle 2 of the cmpq ? Edited July 4, 2022 by Seedy1812 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.