Jump to content

GPU Interrupt issues


Recommended Posts

Ok, run into a strange problem, and really out of ideas:


I tried "re-compile" JagTris source and it seems there are no more GPU interrupts?!


I only activate the Timer Interrupt, and as soon as it fires, the GPU seems to stop. The code seems to be correct as in VirtualJaguar it is running, so there must be something which is different from the real HW.

The 68k keeps running and I can dump some value via Skunk and see that the return address is pushed on the stack.

Sometimes the interrupt code runs a one or two instructions than it goes off the rails.

	org 	$f03020
.l	store	r1,(r2)
	storew	r1,(r0)
	jr	.l
	addq	#1,r1

This is the timer code, r0,r1,r2 are preset by the foreground code. R0 = $f00058, r2 is in DRAM.


Any idea what could make the GPU turn weird?


I first thought it is related to some stuff JagGD is doing, but same behavior with JagGD and Skunk. :(


Edited by 42bs
Link to comment
Share on other sites

14 hours ago, DEATH said:

aren't you supposed to "clear the master interupt mask, and the appropriate interrupt latch, and enable higher priority interrupts immediatly" ?


Normally is it cleared as last instruction in the interrupt (in the jump-slot).

Link to comment
Share on other sites

What I understand of this piece of code is that it trigg an infinite loop the first time the timer interrupt happens.

If r0 & r2 contains what it should, the GPU should update at a very high rate the BG color and a memory location.

Does it what you would like to do ?

I'm not sure to understand what you observe on real HW.



Is a more complete code available somewhere ?


Link to comment
Share on other sites

I just wanted o recompile Jagtris (on GitHub). And yes, I would just expect the BG to cycle. Which happens in VJ.

In the foreground code I do the same. When the timer fires I see no more color cycling.

Printing the GPU PC with Skunk shows weird values.


Link to comment
Share on other sites

You do a STORE in DRAM just at the very beginning of an interrupt, then just 2 instructions later a JR followed by an ADDQ on a register used for the STORE in DRAM just before which may not be finished.... Maybe this drives the GPU crazy. Try with others instructions as I suggested.

Link to comment
Share on other sites

11 hours ago, 42bs said:

But is it accurate? Means emulates the bugs?

i would say that 80% of the time, when a code runs on phoenix, it runs on the real hardware

if i remember well, only memory 4 bytes alignment for GPU access runs in phoenix but not on Jag

if my code runs in both phoenix and VJ, it runs on Jag

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.

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.


  • Recently Browsing   0 members

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