GPU Object type

[swapd0]

This it's driving me crazy, what's wrong with my interrupt code?

 

When I add a GPU object I got no display, but I'm restarting the OP into the interrupt.

	include "jaguar.inc"

	.extern _raster_ptr

	text
_gpu_code_start::
_gpu_code::
	.gpu

	.org G_RAM
	.macro EMPTY_IRQ
	.rept 8
	nop
	.endr
	.endm

cpu_interrupt:
;	IRQ 0
	movei #start,r29
	jump t,(r29)
	nop
	nop
	nop
	nop

dsp_interrupt:
	EMPTY_IRQ
;timer_interrupt:
	EMPTY_IRQ

op_interrupt:
	load (r1),r29			; GPU_FLAGS
	storew r28,(r2)			; Restore OP!!!

	bclr #3,r29				; serviced
	bset #12,r29			; clear interrupt flag

	load (r31),r28			; return address
	addq #4,r1
	addq #2,r28				; next op
	jump t,(r28)			; rte
	store r29,(r1)

; actual address wrong, op interrupt it's too long, but so what...
blitter_interrupt:
	EMPTY_IRQ

start::
	movei #_raster_ptr,r0
	movei #G_FLAGS,r1
	movei #OBF,r2
	movei #BG,r3
	movei #G_ENDRAM,r31

	; enable OP interrupt
	load (r1),r29
	bset #7,r29
	store r29,(r1)

	moveta r0,r0
	moveta r1,r1
	moveta r2,r2
	moveta r3,r3
	moveta r31,r31
.idle:
	nop
	nop
	nop
	jr t,.idle
	nop
	nop
	nop
	nop


_gpu_code_end::

[Zerosquare]

Does the bug occur in Virtual Jaguar too, or only on real hardware?

[swapd0]

Real hardware, I don't use Virtual Jaguar.

 

This is the code that writes the GPU object into the list, SHIFT_MASK it's a macro and it's ok because it's used into bitmapped objects.

void gpu_sprite(uint32_t data)
{
	*op_ptr++ = data;
	*op_ptr++ = GPUOBJ | SHIFT_MASK(0x7ff, 3, 11);
}

Edited March 6, 2018 by swapd0

[SCPCD]

You crash the GPU by making :

	load (r31),r28			; return address
	addq #4,r1
	addq #2,r28				; next op
	jump t,(r28)			; rte
	store r29,(r1)

in your code R1 = G_FLAGS

so you increase by 4 G_FLAGS, instead to incresead R31 (the stack)

 

 

I think that it should be :

	load (r31),r28			; return address
	addq #4,r31
	addq #2,r28				; next op
	jump t,(r28)			; rte
	store r29,(r1)

Should work better.

[swapd0]

WTF!?!?! What a stupid mistake.

 

Thanks SCPCD.

Edited March 6, 2018 by swapd0

[swapd0]

Now I've to fix the problem that the next object it not into 16 bytes boundary... Stupid constraints.

[swapd0]

By the way, it you want a sky gradient don't use a gpu object type because the colour change can happened into the middle of the scan line (if you have other bitmapped objects before).

[+CyranoJ]

By the way, it you want a sky gradient don't use a gpu object type because the colour change can happened into the middle of the scan line (if you have other bitmapped objects before).

 

Put the GPU object at the start of the list. The list is processed as, well, a list. so if it's further down it takes longer to get to it.

 

[edit]

 

Just realized that probably won't work due to interrupt priorities - maybe with the bus release bit set in the objects? Also, remember that the GPU object type is bugged

[Zerosquare]

By the way, it you want a sky gradient don't use a gpu object type because the colour change can happened into the middle of the scan line (if you have other bitmapped objects before).

I assume you mean "changing one palette color on each line", like it was done in ST games?

 

I wonder if it's the best way to implement that effect on the Jaguar, anyways.

 

I've not tested it, but I'd use transparency and put a 16-bit CRY or RGB object in the background as the sky. Since each line is a single color, you can even "cheat" by making the bitmap only one phrase (4 pixels) wide and setting PITCH to zero. You could even do simple halftoning that way, to make the gradient smoother.

It would require more bus time than the palette trick, but it's cleaner and easier.

Edited March 6, 2018 by Zerosquare

[+CyranoJ]

I will add to the comment above that there is a significant impact on performance for having a GPU object on every line if the interrupt code accesses anything in RAM outside of GPU local.

[swapd0]

I assume you mean "changing one palette color on each line", like it was done in ST games?

 

I wonder if it's the best way to implement that effect on the Jaguar, anyways.

 

I've not tested it, but I'd use transparency and put a 16-bit CRY or RGB object in the background as the sky. Since each line is a single color, you can even "cheat" by making the bitmap only one phrase (4 pixels) wide and setting PITCH to zero. You could even do simple halftoning that way, to make the gradient smoother.

It would require more bus time than the palette trick, but it's cleaner and easier.

 

Yes like in ST games but changing BG colour register instead of colour zero from CLUT, I was using that way but I thought to use a GPU interrupt to save bandwidth.

[Zerosquare]

It would be interesting to benchmark it against using a bitmap object to achieve the same effect. With your method you save bandwidth, but get lots of GPU interrupts (and context switching) per frame, which may or may not slow down other things.

[+CyranoJ]

I've always found enabling a GPU interrupt to cause a massive impact - much more than adding an object.

[swapd0]

So for a 3D floor effect it's better to have a lot of scan lines objects? Of course with a "branch tree" before to keep the list short.

[Seedy1812]

So for a 3D floor effect it's better to have a lot of scan lines objects? Of course with a "branch tree" before to keep the list short.

 

Yes , but to keep it manageable group them into say 8 objects and try to binary divide the region - that way you minimise the branch objects you have to process. Processing a branch object should be the same amount as not processing a bitmap object.