Changing Bitplane Pointers Mid-Scanline

[Rob68K]

Has anyone here played around with this?

It appears I can get a stable 3 bitplane image to restart midline but not 4.

I'm wondering whether it's merely a timing issue or just impossible.

Just looking to void wasting any more time on this.

Cheers.

[paraj]

Description sounds a bit suspicious, but maybe I'm misunderstanding it. Sounds like a timing issue.
If you post copper and CPU code that's making these changes we can say for certain. If CPU isn't involved in changes you can omit that, but copper (or CPU) setup of screen is needed. (Or just a binary of whole thing)

[Toni Wilen]

Most likely reason is this chipset behavior: any DMA pointer modification exactly 1 cycle before DMA transfer that uses same pointer: pointer modification write goes nowhere.

EDIT: there was thread about mid scanline change here somewhere.

[Rob68K]

Originally Posted by paraj

Description sounds a bit suspicious, but maybe I'm misunderstanding it. Sounds like a timing issue.
If you post copper and CPU code that's making these changes we can say for certain. If CPU isn't involved in changes you can omit that, but copper (or CPU) setup of screen is needed. (Or just a binary of whole thing)

It's just copper waits and moves.

This is the code that sets it up.

I'm also reusing the first hardware sprite so it's a bit more complicated than in might be but this is literally what I'm using.

initCopScrollView
	lea		copView,a0			destination in copperlist
	move.w 	#12*16-1,d7			height of viewport
	move.l	#$3861fffe,d0		wait for sprite change
	
	move.l	#$3899fffe,d1		wait for bitplane change
	
	move.l	#$38f1fffe,d2		wait for sprite reset
	move.l	#$3801fffe,d4

	move.l	#scrollView+3*26,d5		scrollView is interleved bitplanes to display
	move.l	#scrollView-6+3*26,d6	with horizontal wraparound

.icLoop
	move.l	d6,d3
	move.l	d4,(a0)+			bitplanes
	move.w	#$00ee,(a0)+
	move.w	d3,(a0)+
	sub.w	#26,d3
	move.w	#$00ea,(a0)+
	move.w	d3,(a0)+
	sub.w	#26,d3
	move.w	#$00e6,(a0)+
	move.w	d3,(a0)+
	sub.w	#26,d3
	move.w	#$00e2,(a0)+
	move.w	d3,(a0)+

	move.l	d0,(a0)+			sprite change
	move.l	#$014000c8,(a0)+
	move.l	#$0146007f,(a0)+
	move.l	#$014400ff,(a0)+

	move.l	d5,d3
	move.l	d1,(a0)+			bitplanes change
	move.w	#$00ee,(a0)+
	move.w	d3,(a0)+
	sub.w	#52,d3
	move.w	#$00e6,(a0)+
	move.w	d3,(a0)+
	add.w	#26,d3
	move.w	#$00ea,(a0)+
	move.w	d3,(a0)+
	sub.w	#52,d3
	move.w	#$00e2,(a0)+
	move.w	d3,(a0)+

	move.l	d2,(a0)+			sprite reset
	move.l	#$01400050,(a0)+
	add.l	#$01000000,d0
	add.l	#$01000000,d1
	add.l	#$01000000,d2
	add.l	#$01000000,d4
	add.l	#26*4,d5
	add.l	#26*4,d6
	dbra	d7,.icLoop
	rts

[Rob68K]

Originally Posted by Toni Wilen

Most likely reason is this chipset behavior: any DMA pointer modification exactly 1 cycle before DMA transfer that uses same pointer: pointer modification write goes nowhere.

Yes. I'm seeing that when I vary the order of the pointers in the copperlist or change the wait position. I get BPxPTL writes having no effect and the plane in question that should 'restart' from the left side just carries straight on.

[Rob68K]

OK. I give up. I really don't think it's possible.
I've tried all 24 combinations of writing the bitplanes at each DMA slot on the line and none of them result in 4 planes lining up at once.
I'll just have to fall back to a more tried and tested technique for my scroll routine.
One that won't be a complete nightmare to blit sprites to, at least.

[paraj]

Sorry, I had missed that it was mid-scaline, that's indeed more tricky (and maybe not possible).

[mc6809e]

Keep this in mind: in four plane mode there is a BP DMA cycle every other cycle. The copper will use the cycles in between. The trouble is that it takes two DMA slots for one copper move. BP DMA is essentially running twice as fast as the copper.

[Rock'n Roll]

to change the bitplanepointer maybe for a 2nd playfield on a middle of a scanline:
- it is possible to change up to 2 bitplanepointer on a scanline for the next 16pixel bpl fetch
for a correct change without loosing or destroying bitplanedata
when changing bitplanepointer are realized with only two copper-moves by changing only the BPLxPTL
and if the changing the pointer is not directly 1 cycle before his BPLx DMA cycle.
in copperlist copper-moves series: change first bpl2 pointer before bpl1

- if more then 2 bitplanepointer:
from 3 to 4 bitplanes the changing starts 16pixel later to the bitplanes 1 and 2,
so the bitplanepointer for bitplanes 3 and 4 have to set 16pixel later for every line (2bytes)
this leaves a not correct displayed area in the beginning from 16pixel

idea:
put a 16x256pixel attached sprite over this lack of playfield with the bitplanedata from this area

[Rob68K]

Originally Posted by Rock'n Roll

idea:
put a 16x256pixel attached sprite over this lack of playfield with the bitplanedata from this area

That's a really good idea.
The background just wouldn't be able to use colour zero is all.