GPU Interrupt issues

[42bs]

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
timer::
.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 June 10, 2022 by 42bs

[DEATH]

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

 

Edited June 10, 2022 by DEATH

[DEATH]

also, try with other instructions. For example
move r1,r2
move r1,r0
instead of "store" just for testing

[42bs]

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).

[SCPCD]

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 ?

 

[42bs]

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.

 

[42bs]

I checked the flags, there is no other interrupt pending. _And_ this code worked.

This is when you need a real debugger ? Using JTAG debuggers is sloop comfortable.

[Ericde45]

phoenix debug version is a good debugger, i use it a lot.

 

 

[42bs]

But is it accurate? Means emulates the bugs?

[DEATH]

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.

[42bs]

This shall not matter, but I will add some NOPs to be sure.

Anyway it's only debug code. The original code ceased to work.

[Ericde45]

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

[42bs]

Will check poly_mmu in Phoenix. It does not work in VJ.

[42bs]

Hmm, 80%?

 

[DEATH]

2 hours ago, 42bs said:

Hmm, 80%?

 

or :

[42bs]

@DEATH also Phoenix? Which version?

VJ does not emulate reading the PIT registers.

 

[DEATH]

1 hour ago, 42bs said:

@DEATH also Phoenix? Which version?

VJ does not emulate reading the PIT registers.

 

on VJ

[42bs]

Yes, VJ only emulates the interrupt, not the actual timer.

Edit: Same fpr Phoenix.

Edited June 12, 2022 by 42bs

[42bs]

Made a small example, there timer interrupt works w/o problem. So I must have mixed something up in JagTris.

[42bs]

*aaaaaaaaaaah*

 

Cause of the problem was my overlay routine: I changed it to load and store phrase wise. But GPU RAM cannot be written phrase wise on the real HW.