Jump to content

Photo

GPU with mutiple interrupts


44 replies to this topic

#1 42bs OFFLINE  

42bs

    Chopper Commander

  • 120 posts
  • Location:Germany

Posted Sat Jul 7, 2018 9:40 AM

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



#2 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,545 posts
  • Location:Manchester UK

Posted Wed Jul 11, 2018 9:22 AM

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.



#3 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 120 posts
  • Location:Germany

Posted Wed Jul 11, 2018 10:03 AM

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.



#4 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,545 posts
  • Location:Manchester UK

Posted Wed Jul 11, 2018 3:36 PM

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.



#5 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 120 posts
  • Location:Germany

Posted Wed Jul 11, 2018 3:44 PM

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



#6 JagChris OFFLINE  

JagChris

    River Patroller

  • 3,527 posts
  • Location:Oregon

Posted Wed Jul 11, 2018 8:52 PM

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

#7 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 120 posts
  • Location:Germany

Posted Wed Jul 11, 2018 11:01 PM

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

No. Do you have a link?



#8 JagChris OFFLINE  

JagChris

    River Patroller

  • 3,527 posts
  • Location:Oregon

Posted Wed Jul 11, 2018 11:49 PM

No but I think I can send it to you in chunks unless someone else pops up with a link

#9 JagChris OFFLINE  

JagChris

    River Patroller

  • 3,527 posts
  • Location:Oregon

Posted Thu Jul 12, 2018 12:15 AM

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

#10 CyranoJ OFFLINE  

CyranoJ

    Quadrunner

  • 5,413 posts
  • RAPTOR in LOCAL
  • Location:Adelaide, SA

Posted Thu Jul 12, 2018 12:21 AM

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



#11 philipj OFFLINE  

philipj

    Moonsweeper

  • 495 posts
  • Location:Birmingham, Alabama

Posted Thu Jul 12, 2018 1:57 AM

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.

Attached Files



#12 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,545 posts
  • Location:Manchester UK

Posted Thu Jul 12, 2018 3:14 AM


 

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



#13 JagChris OFFLINE  

JagChris

    River Patroller

  • 3,527 posts
  • Location:Oregon

Posted Thu Jul 12, 2018 9:21 AM

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.

#14 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 120 posts
  • Location:Germany

Posted Thu Jul 12, 2018 1:52 PM

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



#15 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 120 posts
  • Location:Germany

Posted Thu Jul 12, 2018 1:55 PM

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.



#16 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 120 posts
  • Location:Germany

Posted Thu Jul 12, 2018 10:03 PM

 

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.



#17 JagChris OFFLINE  

JagChris

    River Patroller

  • 3,527 posts
  • Location:Oregon

Posted Thu Jul 12, 2018 10:11 PM

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

#18 CyranoJ OFFLINE  

CyranoJ

    Quadrunner

  • 5,413 posts
  • RAPTOR in LOCAL
  • Location:Adelaide, SA

Posted Thu Jul 12, 2018 10:13 PM

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.



#19 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 120 posts
  • Location:Germany

Posted Fri Jul 13, 2018 12:21 AM

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, Fri Jul 13, 2018 2:07 AM.


#20 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 120 posts
  • Location:Germany

Posted Mon Jul 16, 2018 2:27 PM

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.



#21 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,545 posts
  • Location:Manchester UK

Posted Mon Jul 16, 2018 3:08 PM

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, Mon Jul 16, 2018 3:09 PM.


#22 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 120 posts
  • Location:Germany

Posted Mon Jul 16, 2018 9:55 PM

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.



#23 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 120 posts
  • Location:Germany

Posted Mon Jul 16, 2018 9:56 PM

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.



#24 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,545 posts
  • Location:Manchester UK

Posted Tue Jul 17, 2018 3:40 AM

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



#25 42bs OFFLINE  

42bs

    Chopper Commander

  • Topic Starter
  • 120 posts
  • Location:Germany

Posted Sat Jul 21, 2018 10:26 AM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users