Jump to content
42bs

GPU with mutiple interrupts

Recommended Posts

Hi

 

I am facing a strange bug: I have OP interrupt and timer interrupt (1ms period) active.

From time to time, it seems R31 (stackpointer) is not decremented in the timer interrupt which results in a stack underflow.

The OP interrupt never shows this.

 

Did anyone see a similar problem? I could not find a hint in the bug list.

 

Cheers

 

42Bastian

  • Like 1

Share this post


Link to post
Share on other sites

Could they both be firing at the same time? or one is firing within the execution of the other? What is your ISR handler code doing?

 

In my DSP code (I have 3 interrupts all running, all timer based), I don't clear the latches etc until the ISR has completed.

Share this post


Link to post
Share on other sites

Hi

I did a lot of debugging and it seems it is somehow related to my JSR/RTS macros.

MACRO JSR
 move pc,LR
 subqt #4,SP
 addqt #10,LR
 jump \0
 store LR,(SP)
ENDM

MACRO RTS
 load (SP),LR
 jump (LR)
 addqt #4,SP
ENDM

I switched now to a more RISC like style (ARM,PPC) and load only PC into an register w/o pushing. Now it seems to work far better.

 

The strange thing is that I really do not use the same registers for IRQ and normal work.

For IRQ r31/r30 (reserved them in both banks) and for normal subroutines r29/28.

 

Anyway, good to know the DSP works with a lot of interrupt.

Share this post


Link to post
Share on other sites

I assume you have a stack pointer in GPU RAM and not on the bus too ? :) I'd not be surprised if that store could fail to complete before the return happened if that were the case :)

 

For my DSP stuff I have split the banks, so the interrupts have their own stack and bank of registers to play with and I know 100% that the rest of the code's data isn't scrambled.

Share this post


Link to post
Share on other sites

Both stacks are in GPU RAM. But I tried also to move the non-IRQ stack into DRAM. No change.

It is realy weird. It seems r31 is sometimes not decremented.

I checked some of the game sources I have, but it seems no one used the GPU really as main processor as I do.

Guess I am a bit late with such problem :-)

Share this post


Link to post
Share on other sites

Do you have access to and have you checked the Fight For Life sources?

No. Do you have a link?

Share this post


Link to post
Share on other sites

If you can give me some keywords to search for that might enable me to give you specific files that may be helpful.

Share this post


Link to post
Share on other sites

If you can give me some keywords to search for that might enable me to give you specific files that may be helpful.

Or maybe you could just ZIP it and upload it, making it a lot easier...

  • Like 4

Share this post


Link to post
Share on other sites

I got a copy... I use to play around with the 3DStudio Max files animation sequences. I even had a JS2 copy of the Beta version limited release before I sold it sometime back. I hope this helps out.

FFLSource.zip

  • Like 3

Share this post


Link to post
Share on other sites

 

The strange thing is that I really do not use the same registers for IRQ and normal work.

For IRQ r31/r30 (reserved them in both banks) and for normal subroutines r29/28.

 

 

 

Just having a scan through the manual and remembered that Primary R30 is trashed when flow is transferred to the ISR, and Primary R31 is Interupt Stack pointer... perhaps this could be the issue?

 

The end of ISR code I use:

load	(STACKPTR),r28		; Get the address of the last instruction executed from stack
addq	#4,STACKPTR		; realign the stack
addq	#2,r28			; point to the next instruction
jump	T,(r28)			; jump back into main code
store	r29,(r30)		; write the control flags back

STACKPTR is R31 obviously :)

  • Like 3

Share this post


Link to post
Share on other sites

Or maybe you could just ZIP it and upload it, making it a lot easier...

If I remember correctly mine has a bunch of ROMs in the same directory that makes it exceed the upload limit. Was feeling too lazy to pick through it all.

 

Or maybe I'm thinking of the HS CD sources I lost.

Share this post


Link to post
Share on other sites

If you can give me some keywords to search for that might enable me to give you specific files that may be helpful.

 

Any GPU source ;-)

Share this post


Link to post
Share on other sites

I got a copy... I use to play around with the 3DStudio Max files animation sequences. I even had a JS2 copy of the Beta version limited release before I sold it sometime back. I hope this helps out.

Cool, thanks.

  • Like 1

Share this post


Link to post
Share on other sites

 

Just having a scan through the manual and remembered that Primary R30 is trashed when flow is transferred to the ISR, and Primary R31 is Interupt Stack pointer... perhaps this could be the issue?

 

The end of ISR code I use:

load	(STACKPTR),r28		; Get the address of the last instruction executed from stack
addq	#4,STACKPTR		; realign the stack
addq	#2,r28			; point to the next instruction
jump	T,(r28)			; jump back into main code
store	r29,(r30)		; write the control flags back

STACKPTR is R31 obviously :)

 

Just like mine ... (well, I do not need to use the T, for jumps with lyxass).

 

I tried different places for the fixing of the return address. No change. The Atari docs are not clear, when the writing of the flags takes place.

So I also tried this

addqt #2,r28 ; return address
moveta r28,r28
jump (r28)
move r29,(r30)

But looking throuh FFL sources, it seems to be like in others: The GPU is mainly used for short code sequences. Which run to completion and then stop. No interrupts.

  • Like 1

Share this post


Link to post
Share on other sites

For what it's worth, this is my GPU interrupt code, works 100%, but again, only using a single interrupt (GPU Interrupt Object)

gpu_int:

    load    (r26),r29
    bclr    #3,r29                  ; Clear IMASK
    bset    #12,r29                 ; Clear Pending
    load    (r31),r28               ; Addr of last instruction
    addq    #4,r31                  ; Correct Stack
    addq    #2,r28                  ; Next instruction	

; some code
	
    jump    (r28)				; RTE 
    store   r29,(r26)				
    nop

r26 = #G_FLAGS

r31 = Stack pointer

 

*Addendum

Another point of note - I don't use the jump vectors, this code is directly at the vector address.

  • Like 2

Share this post


Link to post
Share on other sites

You've modified your lynx assembler to work with the Jag? Interesting.

 

Yes. Years ago ;-) But lately fixed bugs. ... I should put it on M$hub (eh) GitHub ;-)

Edited by 42bs
  • Like 1

Share this post


Link to post
Share on other sites

Ok, it seems, the bug is almost gone, with a small workaround. Every 60000 or so interrupts, I still see that the stackpointer is not decremented.

I wonder if there are design documents of GPU/DSP arround because pushing the return address hardcoded seems to be complicated.

Share this post


Link to post
Share on other sites

Random thought, does this happen on VJ too? If it does might help identify the particular alignment of voodoo or some such.

 

Have you tried assembling your code via another assembler? just to validate that there isn't something weird going on there too (not saying your assembler is at fault and it's a pretty grasping idea.. but this is the jag :D)

 

Is the OP Interrupt being triggered by GPU objects in an OP list too? I believe these are somewhat buggy as it is, and maybe you have found a new aspect of their buggyness?)

Edited by LinkoVitch
  • Like 1

Share this post


Link to post
Share on other sites

VJ is not running on my machine (like MAME and other sdl based stuff). :(

 

Another assembler will be difficult as I use a lot of the lyxass macro features, but I counter checked the code with my small quick'n'dirty disassembler. So far no bugs.

 

But yes, the cat has bitten me once or twice. "Nice" example:

cmpq #7,r0
jr z, .cont
moveq #10,r1
mult r0,r1
.cont
moveq #20,r1 // debug

Due to the scoreboard bug, the mult writes back after the moveq and the 20 never appeared.

Share this post


Link to post
Share on other sites

Is the OP Interrupt being triggered by GPU objects in an OP list too? I believe these are somewhat buggy as it is, and maybe you have found a new aspect of their buggyness?)

 

I use the OP interrupt for VBL. I could try and do the VBL in 68k for a test.

  • Like 1

Share this post


Link to post
Share on other sites

Be interesting to hear if that "fixes" the issue :)

 

I first quick test does also show the issue. Though I have the subjective impression it happens less often.

Though my workaround works, it is still not reasonable.

Atari says, the r31 is decremented and then the return address is store to the new r31.

That's how we return: Load from r31 then increment.

The workaround is _not_ to increment r31. So as if the GPU does not decrement it sometimes.

I will place an sentinel at the end of stack to see if it gets corrupted.

Share this post


Link to post
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.

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