Jump to content
IGNORED

Another weirdness with the GPU


42bs

Recommended Posts

1 hour ago, Zerosquare said:

And as a reminder, here's what the doc says:

1629092734_GPUinterrupt.thumb.png.de3368d387c68900a6feca23bfa031ad.png

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,"!

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 :(

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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 by Seedy1812
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...