Mega Typhoon Deconstruction

[mcgeezer]

Originally Posted by buzzybee

Sorry, bit OT right now – but what´s that 32k boundaries all about?

The copper list for example is sitting at $48000-$4fffff

The screens are also setup on boundaries too, but yes i suppose i meant 64k boundaries so that only the low 16 bits of the 24 bit address need to be updated.

[Antiriad_UK]

I feel the need to redo my bobsnake routine in a normal, blitter interrupt and copper blitter version as I’ve never tried those. Damn I was trying to be productive as well

[FSizzle]

Originally Posted by ross

When copper DMA fetches instruction/data from chip-memory, data is from now inside Agnus (copper MOVE already specifies a destination).

Thanks for the explanation! I confirmed all the timing as you've said with some test code and the DMA debugger. I was not giving the copper enough credit it seems

[buzzybee]

Originally Posted by Antiriad_UK

I feel the need to redo my bobsnake routine in a normal, blitter interrupt and copper blitter version as I’ve never tried those. Damn I was trying to be productive as well

Thank god copper code for Reshoot Proxima is so busy controlling the display already, that I see no chance to add blitter control – otherwise I would feel the same. Very inspiring discussion here, about one of the Amigas most technically advanced games - while being very playable too, which really is something special.

I used to implement interrupt-driven blitter controller for Reshoot R and ditched it in the end for a more traditional approach, since it gained no speed advantage and also felt unstable on 060-machines.

[pink^abyss]

Originally Posted by Toni Wilen

I think I have already replied few times when this topic has been discussed: simple test case that fails to wait correctly if only 1 WAIT is required. (for example blit something, WAIT, poke some blitter register that causes blit to change if WAIT failed (for example destination pointer. Preferably not BLTSIZE ).

Hi Toni, thanks for all your hard work!

I tried to create a simple testcase but it wasn't possible. I needed at least 15 moving blits to reproduce the issue.
Another observation is that the issue only seem to happen when display dma is fetching while the blitter registers are written from the copper list. I have 5 planes active.

[hooverphonique]

Originally Posted by pink^abyss

I tried to create a simple testcase but it wasn't possible. I needed at least 15 moving blits to reproduce the issue.

It doesn't make sense if the actual number of blits per frame makes a difference - sounds more like some timing thing that you accidentally hit after 15 blits (similar to the display dma thing you mentioned).

[mcgeezer]

A great fit for this engine would be Operation Wolf.

I reckon AGA would do the arcade proud, I can't seem to recall what the Amiga version was like (possibly an ST port).

[ Show youtube player ]

The game resolution is 320x240, you could probably get away with fetch mode x4 for bitplanes and hw sprites. You would only really need two hardware sprites to provide a 16 colour display panel to the right so an early DDFSTART could be used ($1c maybe??) to get the full resolution with scrolling each way.

Pop the game into dual playfield mode for a 16 colour scrolling background and the copper/blitter technique here for blitting all those bobs.

I reckon it would be close to the arcade for sure.

Geezer

[roondar]

Originally Posted by mcgeezer

The game resolution is 320x240, you could probably get away with fetch mode x4 for bitplanes and hw sprites. You would only really need two hardware sprites to provide a 16 colour display panel to the right so an early DDFSTART could be used ($1c maybe??) to get the full resolution with scrolling each way.

I recall reading a thread about using the Copper on AGA in 4x fetch mode to create two separate horizontal screen areas moving into two separate directions. I can't find it now, but it would save those two Sprites

[ross]

Originally Posted by roondar

I recall reading a thread about using the Copper on AGA in 4x fetch mode to create two separate horizontal screen areas moving into two separate directions. I can't find it now, but it would save those two Sprites

http://eab.abime.net/showthread.php?t=88062

[ross]

Originally Posted by mcgeezer

The game resolution is 320x240, you could probably get away with fetch mode x4 for bitplanes and hw sprites. You would only really need two hardware sprites to provide a 16 colour display panel to the right so an early DDFSTART could be used ($1c maybe??) to get the full resolution with scrolling each way.

I see 2 possibilities to do it safely even using DDFSTRT=$18:
- reversing the display panel position to the left (like Banshee do)
- using a three color single sprite
The panel is divided into clearly visible horizontals stripes of different colors that can be changed with copper (you can also sync for the machine gun loader color).
To avoid the problem of transparent black just use a right DIWSTOP and use BRDSPRT=1.

[mcgeezer]

Originally Posted by ross

I see 2 possibilities to do it safely even using DDFSTRT=$18:
- reversing the display panel position to the left (like Banshee do)
- using a three color single sprite
The panel is divided into clearly visible horizontals stripes of different colors that can be changed with copper (you can also sync for the machine gun loader color).
To avoid the problem of transparent black just use a right DIWSTOP and use BRDSPRT=1.

But how can you reliably change the colours with the copper wait when It is busy driving the blitter? Large bobs would miss the y position with the copper which is why i went for a 16 colour attached sprite.

[ross]

Originally Posted by mcgeezer

But how can you reliably change the colours with the copper wait when It is busy driving the blitter? Large bobs would miss the y position with the copper which is why i went for a 16 colour attached sprite.

It's not simple but can be done :
http://eab.abime.net/showpost.php?p=...5&postcount=19

But the first option (panel to the left) it is definitely much more effective and doesn't bother you with sprites usage (even allows you to use them elsewhere).

[lmimmfn]

Why bother with the panel at all? Its not in the pc engine version and doesnt need to be so big, i. e. Sprites showing 3xrocket than each rocket available.

[DanScott]

Originally Posted by lmimmfn

Why bother with the panel at all? Its not in the pc engine version and doesnt need to be so big, i. e. Sprites showing 3xrocket than each rocket available.

I would say that when making a conversion from coin-op, you want to replicate it as closely as possible

[lmimmfn]

Originally Posted by DanScott

I would say that when making a conversion from coin-op, you want to replicate it as closely as possible

No, i agree completely, i just mean if moving the panel to the left the no panel should probably be considered also.
It is strange that op wolf used a panel as theyre quite rare in arcades, but it does make sense with the gun in the arcade cabinet.

[Antiriad_UK]

Originally Posted by roondar

Right, it is indeed hard to be exact without measurements. Perhaps I should try it myself once to see how it goes. Thanks for your views though, they certainly sound reasonable.

I've spent today playing around with this. Disappointing results so probably done something wrong. I can upload thes exes/source if anyone interested.

I did a "normal" bobsnake routine. I guess bobsnakes are a more extreme case than a game because certain things are fixed (bltsize, modulos, bltapt/bltdpt) but it's what I had to hand.
- It's a $fca cookie cut minterm so all blitter channels enabled
- BOB is 16x16 pixels in 3 bitplanes (so 16*3 high and 2 word wide blits for interleaved)
- Display in 3 bitplane mode, 320x256


For normal routine
1. Clear screen with blitter
2. Update bob positions (dual sines for x and y)
3. Finish screen clear with spare CPU
4. Draw BOBs in a tight loop:

Result, 79 BOBs.

.loop
	movem.w	(a2)+,d0-d1		;also clears top of d0 and d1 (important)

	ror.l	#4,d0			;hiword of d0 contains shift in highest nibble
	add.w	d0,d0			;loword d0 contains byte offset into screen (x / 8)
	add.w	d0,d1			;add byte offset to y offset (WARNING: possible 64k overflow)
	swap	d0			;d0.w now contains shift value in top nibble
	move.w	d0,d2			;save B shift
	or.w	d3,d0			;add minterm
	swap	d0			;d0.l=bltcon0 in high word
	move.w	d2,d0			;d0.l=bltcon0 and bltcon1
					;d1.w=byte offset into screen
	add.l	a4,d1			;Add screen ptr to offset
	move.l	d1,a3			;save d1 for movem optimization - gives an extra bob :)

	move.w	a5,dmacon-dmaconr(a6)	;Blitter nasty on
.bw2:	btst.b	d5,(a6)			;blitwait
	bne.s	.bw2
	move.w	d6,dmacon-dmaconr(a6)	;Blitter nasty off

	move.l	d0,bltcon0-dmaconr(a6)	;bltcon0/1
	movem.l	d1/a0/a1/a3,bltcpth-dmaconr(a6)
	
	move.w	d4,bltsize-dmaconr(a6)	;BLTSIZE ($58)

	dbf	d7,.loop

For copper controlled routine
1. Clear screen with blitter from copperlist
2. Update bob positions (dual sines for x and y)
3. "draw" BOBs into the copperlist (first entry has to hit before screen clr finishes)
3. Finish screen clear with spare CPU
4. Enable blit nasty to finish the frame while copper running the BOBs

Result, 63 BOBs. Yuk.

Snippet of copperlist:

	rept	BOB_NUMBOBS
	dc.w    $0001,$0000		;blitwait, ignore pos
	dc.w    $0001,$0000		;blitwait
	CMOVE	bltcon0,$0000
	CMOVE	bltcon1,$0000
	CMOVE	bltcpth,$0000
	CMOVE	bltcptl,$0000
	CMOVE	bltbpth,$0000		;static
	CMOVE	bltbptl,$0000		;static
	CMOVE	bltapth,$0000		;static
	CMOVE	bltaptl,$0000		;static
	CMOVE	bltdpth,$0000
	CMOVE	bltdptl,$0000
	CMOVE	bltsize,((BOB_HEIGHT*BOB_NUMPLANES)*64)+BOB_WORDWIDTH+1	;bltsize/null
	endr
...
...
	rsreset
CL_BLT_WAIT1		rs.w	2
CL_BLT_WAIT2		rs.w	2
CL_BLT_BLTCON0		rs.w	2
CL_BLT_BLTCON1		rs.w	2
CL_BLT_BLTCPTH		rs.w	2
CL_BLT_BLTCPTL		rs.w	2
CL_BLT_BLTBPTH		rs.w	2
CL_BLT_BLTBPTL		rs.w	2
CL_BLT_BLTAPTH		rs.w	2
CL_BLT_BLTAPTL		rs.w	2
CL_BLT_BLTDPTH		rs.w	2
CL_BLT_BLTDPTL		rs.w	2
CL_BLT_BLTSIZE		rs.w	2
CL_BLT_SIZEOF		rs.w	0

"Draw" loop. Only needs to update bltcpth, bltdpth, bltcon0/1 - all the other blt regs were setup at startup as they don't change.

.loop
	movem.w	(a2)+,d0-d1		;also clears top of d0 and d1 (important)

	ror.l	#4,d0			;hiword of d0 contains shift in highest nibble
	add.w	d0,d0			;loword d0 contains byte offset into screen (x / 8)
	add.w	d0,d1			;add byte offset to y offset (WARNING: possible 64k overflow)
	swap	d0			;d0.w now contains shift value in top nibble
	move.w	d0,d2			;save B shift
	or.w	d3,d0			;add minterm
					;d1.w=byte offset into screen
	add.l	a4,d1			;Add screen ptr to offset
	
	;d0.w = bltcon0
	;d2.w = bltcon1
	;d1.l - bltcpth/bltdpth

	move.w	d0,CL_BLT_BLTCON0+2(a0)
	move.w	d2,CL_BLT_BLTCON1+2(a0)

	move.w	d1,CL_BLT_BLTDPTL+2(a0)
	move.w	d1,CL_BLT_BLTCPTL+2(a0)
	swap	d1
	move.w	d1,CL_BLT_BLTDPTH+2(a0)
	move.w	d1,CL_BLT_BLTCPTH+2(a0)

	lea	CL_BLT_SIZEOF(a0),a0

	dbf	d7,.loop

Could of course allocate on 64k boundaries and skip the high pointers, but could also do that with the non-copper version as well so left that alone.

I would say though if you had lots of CPU game logic then I think the results would be better for the copper version. The tight loop of a bob snake is a bit extreme I may do a blitter interrupt version even though that will be even slower, just because I've never attempted this kind of thing before.

[mcgeezer]

@Antriad_UK - Could you do a screen shot of your WinUAE with "v -2" enabled so we can see the dma use?

[Antiriad_UK]

Sure. Here are the two versions attached.
Edit: actually that doesn’t look right does it. Blits not running at the bottom of the frame compared to other version.

[roondar]

Originally Posted by Antiriad_UK

Sure. Here are the two versions attached.
Edit: actually that doesn’t look right does it. Blits not running at the bottom of the frame compared to other version.

Is it possible the code accidentally stops at line 256?
Edit: no, that's can't be right, it stops too low in the frame for that.

[DanScott]

Originally Posted by roondar

Is it possible the code accidentally stops at line 256?

That's what it looks like to me. Is a PAL wait $ffdf,$fffe (or similar) required ?