GPU with mutiple interrupts

[42bs]

I don't know but it looks like the interrupt it's running using the same register bank as the normal code, because I can see the sprites if I don't have an OP interrupt, but with an GPU Object I can't see anything, and now it hangs... WTF!?!?

 

I had the same impression when tuning Tetris. All the weird effects went away at the moment I did reset r31 to the stack-top.

[42bs]

 

sprite list with the 68000 & rasters on (GPU) ---> works

sprite list with the GPU & rasters off ---> works

sprite list with the GPU & rasters on (GPU) ---> black screen but the game it's running.

 

 

 

So OBL update is also done with the GPU, I assume. Is your OBL correct? End and start values?

[swapd0]

 

So OBL update is also done with the GPU, I assume. Is your OBL correct? End and start values?

 

If I turn off the rasters (don't include the GPU Object in the list) it works, that object it's done with the 68000, the GPU routine just converts an array of "sprites" to the OP list.

 

I'll have another look tomorrow with a fresh mind.

Edited January 25, 2019 by swapd0

[LinkoVitch]

I have heard that the GPU Object is buggy. IIRC it doesn't fire just when the OP gets to YPOS but every time or something. I have never played with it myself.

 

RE Stack handling from interrupts, I have never had an issue with stack pointer corruption. I use:

 

load (r31),r28
addq #4,r31
addq #2,r28
jump T,(r28)

 

At the end of my ISR routines in U235SE. I have split the reg banks, so my ISRs have their own bank of registers to play with no worries of corrupting the secondary set.

[42bs]

I have heard that the GPU Object is buggy. IIRC it doesn't fire just when the OP gets to YPOS but every time or something. I have never played with it myself.

 

RE Stack handling from interrupts, I have never had an issue with stack pointer corruption. I use:

 

load (r31),r28

addq #4,r31

addq #2,r28

jump T,(r28)

 

At the end of my ISR routines in U235SE. I have split the reg banks, so my ISRs have their own bank of registers to play with no worries of corrupting the secondary set.

 

But that's DSP code, isnt't it? Anyway, all my weird problems went away when I did not use the "addq #4,r31" but instead reload r31 to the stack top.

I added debug code to verify r31 and saw that the value "before" incrementing was already stacktop (0xf03ffc in my case)!

So first I thought it is because I did use r31 in the normal bank as stackpointer as well, but even when I changed to two different SPs, the same happened.

 

I did check many game sources, and most of them do the same. And actually, that's no problem unless one uses nested interrupts.

[SCPCD]

I have heard that the GPU Object is buggy. IIRC it doesn't fire just when the OP gets to YPOS but every time or something. I have never played with it myself.

 

GPU object doesn't use the YPOS.

I initialy thought it was a bug, but in fact it seems that some version of the doc are wrong as the last i known version (7 Nov 1994) describe the GPU obj as interrupt always and reading the netlist confirm that.

 

Probably it was a forgotten features or they think it was not needed since there is branch object and prefer to use more bits to pass information to GPU ?

Edited January 26, 2019 by SCPCD

[LinkoVitch]

 

But that's DSP code, isnt't it? Anyway, all my weird problems went away when I did not use the "addq #4,r31" but instead reload r31 to the stack top.

I added debug code to verify r31 and saw that the value "before" incrementing was already stacktop (0xf03ffc in my case)!

So first I thought it is because I did use r31 in the normal bank as stackpointer as well, but even when I changed to two different SPs, the same happened.

 

I did check many game sources, and most of them do the same. And actually, that's no problem unless one uses nested interrupts.

 

Yep it is DSP. I guess I cannot assume the GPU and DSP cores will behave the same for all things, they do have their other differences, I was simply assuming that the way they would handly things such as stack would be identical. Not had any need to poke the GPU yet, but I will be with current projects soon, so I am glad to be forewarned about the "fun" on my horizon

[swapd0]

I bet that when an interrupt it's triggered sometimes the register swap gets a bit delayed (maybe because a movei instruction?).

 

This is my start up code.

start::
	movei #OBF,op
	movei #G_ENDRAM,stack

; enable OP interrupt
	movei #G_FLAGS,flagsPtr
	load (flagsPtr),flags
	bset #7,flags
	store flags,(flagsPtr)

	moveta op,op
	...

And here my interrupt code:

op_interrupt:
	movei #G_FLAGS,flagsPtr
	load (flagsPtr),flags			; GPU_FLAGS
	movei #_hdma_colors,rasterPtr
	load (rasterPtr),colors
	movei #CLUT,clut

	...
	movei #OBF,op           ; ?????
	storew op,(op)

; rte
	bclr #3,flags					; serviced
	bset #12,flags					; clear interrupt flag
	load (stack),rts
	movefa stack,stack				; reload stack, no sp++
	addq #2,rts
	jump T,(rts)
	store flags,(flagsPtr)			; restore interrupt

I must have the movei #OBF,op uncommented or the OP it's not resumed and I don't see anything, but that value it should be already in the register!!!!!!!!!!1!!!

Edited January 30, 2019 by swapd0

[swapd0]

Maybe the only (robust) solution is to avoid the register overlap, even they are into a different set...

[42bs]

Ok, for one, why do you use "movei" s in the interrupt. You should keep it short, so I'd recommend to have those values loaded once in the foreground code.

Depending on what you are else doing in the interrupt, I recommend to move the restarting of the OP at the top of the ISR.

 

I had also the impression, that sometimes the ISR did modify the wrong register bank. Therefore, both r31 contain the IRQ SP and I both r29 (in my case) contain the flag address.

So my initial IRQ code is this:

	org $f03030

	load	(IRQ_FLAGADDR.a),IRQ_FLAG.a
	movei	#obj_irq,IRQScratch0.a
	bset	#12,IRQ_FLAG.a
	load	(IRQ_SP.a),IRQ_RTS.a
	jump	(IRQScratch0.a)
	bclr	#3,IRQ_FLAG.a

So even if the bank-swap is delayed, the first "load" is done correctly.

 

After these changes I had no longer problems with the interrupts. I increased my 1kHz timer to 10kHz (besides the OP-VBL interrupt) w/o problem.

Edited January 30, 2019 by 42bs

[swapd0]

If I remove the movei in the interrupt code it doesn't work. And it should work because I've load it into the startup code.

 

Anyway I'll have another look at it...

[42bs]

Are you sure you've selected bank 1 for the foreground code?

When switching bank, you should not use any register for at least 2 cycles:

 

movei #1<<14|%11111<<9,r1 ; clear all ints, REGPAGE = 1
store r1,(status)
nop
nop ; wait
moveta status,IRQ_FLAGADDR.a

Edited January 31, 2019 by 42bs

[swapd0]

I've done some test and all the registers that I move to the alternative back are not preserved at the irq routine, and I only use moveta at the init code, the only way that I get the correct values at the irq service routine it's if I run the GPU on a nops loop. If I touch any register I see them modified at the irq.

 

I've copied the flags register to a memory location and the init code runs at register bank #0, I need to see if the irq runs at bank #1... but now I'm very tired, I've wasted many hours with this.

Edited February 1, 2019 by swapd0

[42bs]

IRQ runs on register bank 0!

 

14 REGPAGE Switches from register bank 0 to register bank 1. This function is
overridden by the IMASK flag, which forces register bank 0 to be used.

 

See my previous post!

Edited February 1, 2019 by 42bs

[swapd0]

IRQ runs on register bank 0!

 

See my previous post!

 

Then my init code it's wrong because I do a move.l #0,G_FLAGS and that make the main code runs at bank 0.

[swapd0]

Fixed!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1!!!!

 

Thanks a lot Bastian

 

By the way I got this in my init code.

  moveq #0,d0
  move.l d0,D_FLAGS			; disable DSP-IRQs
  move.l #1<<14|%11111<<9,G_FLAGS	; disable GPU-IRQs, bank #1

If I set the DSP with the same flags as the GPU the u235se doesn't work...

[LinkoVitch]

Fixed!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1!!!!

 

Thanks a lot Bastian

 

By the way I got this in my init code.

  moveq #0,d0
  move.l d0,D_FLAGS			; disable DSP-IRQs
  move.l #1<<14|%11111<<9,G_FLAGS	; disable GPU-IRQs, bank #1

If I set the DSP with the same flags as the GPU the u235se doesn't work...

 

The start of the DSP code in u235SE sets the DSP up how it likes it, and enables things only once it is ready. I imagine if you are starting the DSP with all the things already set it may be firing interrupts before they are configured, or running in the wrong bank etc.

 

I'd not try and pre-empt it's own setup routine.

[swapd0]

Don't worry, when I fixed the GPU rasters on a test program Classic Kong refuses to work, so I had to change the DSP init code. It looks a bit weird because the setup code it's different, but I don't care because I load the u235SE code, run and forget about it.

[ggn]

BTW would anyone like to post a small working example of this so everyone will get some closure?

[42bs]

BTW would anyone like to post a small working example of this so everyone will get some closure?

 

I am currently reworking the BJL examples for rmac/rln/tj_ass.