Setting up maximum-size playfield

[Toni Wilen]

WaitNotLine0 can incorrectly detect 255 to 256 change as line 0. Custom registers are always word wide: $dff004.l access requires 2 back to back reads and register content can change between reads if read at the end of scanline.

More reliable method is to only poll $dff004.w bit zero 1 to 0 change.

[ross]

Originally Posted by Toni Wilen

WaitNotLine0 can incorrectly detect 255 to 256 change as line 0. Custom registers are always word wide: $dff004.l access requires 2 back to back reads and register content can change between reads if read at the end of scanline.

Furthermore it is always a good idea to read VHPOSR before VPOSR because of a x position roll-up to 0 before y update (that can be nasty if you wait for y precise line position).

More reliable method is to only poll $dff004.w bit zero 1 to 0 change.

I normally do the $dff006 then $dff004 read and check (because of generic line wait), but like you suggested for VBL only, code like this is good:

	lea	$dff004,a0
	
.l1	move.w	(a0),d0
	lsr.w	#1,d0
	bcc.b	.l1
.l2	move.w	(a0),d0
	lsr.w	#1,d0
	bcs.b	.l2

Just out of curiosity .. I never do illegal access to custom registers (writing on read only and vice versa or byte access), but to make more compact code there is actually some consequence writing such this?

	lea	$dff004,a0
	
.l1	lsr	(a0)
	bcc.b	.l1	
.l2	lsr	(a0)
	bcs.b	.l2

Thanks

[Toni Wilen]

Writing to read-only register does nothing (but I still wouldn't do it, it can get annoying when using debuggers that detect illegal accesses) but extra write access can be waste of time (especially if 68020+).

Everyone uses byte wide custom register reads anyway. (Most common is blitter busy bit check, KS code does it too).

[ross]

Originally Posted by Toni Wilen

Writing to read-only register does nothing (but I still wouldn't do it, it can get annoying when using debuggers that detect illegal accesses) but extra write access can be waste of time (especially if 68020+).

Yes, only for compact code and register shortage

Everyone uses byte wide custom register reads anyway. (Most common is blitter busy bit check, KS code does it too).

I avoid also this :

	lea	$dff002,a0
	
.l1	move.w	(a0),d0
	add.w	d0,d0
	bmi.s	.l1

[Photon]

Originally Posted by Toni Wilen

DMACON write is correct, it is supposed to clear the bits

Hehe. Yeah, I guess I was confused about the purpose by the bit backwards code at the time. It was written clearly in the first post, though.

If you just want to pump out data to bpl1, the easiest and fastest way is with the Copper, something like:

	dc.w $1b29,$fffe
	REPT 24
	dc.w $110,0
	ENDR
	dc.w $1c29,$fffe
	...

And then you'd fill the zeros with the Blitter.

You can emulate the Copper by triggering a Copper interrupt each line a bit before that (HPOS+6px) to have your data ready in time, and poll it, then pump out the data. But it would be 2x slower (+VAT) than Copper+Blitter. For spamming bplcon1 it has its uses, maybe one could be invented for bplxdat?

[ross]

Originally Posted by Photon

[..] For spamming bplcon1 it has its uses, maybe one could be invented for bplxdat?

Problem here is that if you activate BPLCON0 BPUx bit then DMA channels fetch data from memory.
Only exceptions are the fake 7-planes mode with only 4 channel fetch plus BPL5/6DAT, and BPL1DAT like the previous message.
So pumping BPLxDAT is not useful.. Or I miss something?

[EDIT]
hmm, and if you disable BPLEN in DMACON and use BPUx bit AND pump BPLxDAT what is the result?

[EDIT2]
Just tried in WinUAE.. results are "strange"
Something seems to work but not as expected..

[EDIT3]
better set FMODE=0
all works properly, maybe some effect can be made


There is only one thing that I need a confirmation.
It seems that the condition for display is BPLCON1 x-pos and "every 16 pixels" BPL1DAT strobe (all BPLxDAT are anyway buffered).
This is really copper intensive for a complex display.. (opposed to 7-planes mode where strobe is DMA triggered).
Toni?

[Toni Wilen]

Originally Posted by ross

There is only one thing that I need a confirmation.
It seems that the condition for display is BPLCON1 x-pos and "every 16 pixels" BPL1DAT strobe (all BPLxDAT are anyway buffered).
This is really copper intensive for a complex display.. (opposed to 7-planes mode where strobe is DMA triggered).
Toni?

It would be quite pointless to fully emulate bitplane DMA with copper but it would be very cheap way to make horizontal 16-pixel (with as many planes as you want) repeating pattern. Perhaps it can make something interesting when combined with HAM mode.

[mark_k]

Originally Posted by Toni Wilen

WaitNotLine0 can incorrectly detect 255 to 256 change as line 0. Custom registers are always word wide: $dff004.l access requires 2 back to back reads and register content can change between reads if read at the end of scanline.

Thanks. That problem never seemed to happen if running from chip/slow RAM, but does from Zorro II fast RAM.

[mark_k]

I've uploaded a bug-fixed version of the scroll test program to The Zone. Archive contains two versions, one with 4-pixel-wide bars, the other 8. Colours are different too: colour 0 is yellow, colour 1 blue.