VDP 5 Sprite on a Line

[Tursi]

Can someone confirm my results?

 

I did some testing to qualify the behavior of the 5 sprites on a line flag, and the fifth-sprite indicator, both in the VDP status register. Aaaand.... I never saw it set.

 

I did my testing in MiniMemory. I used the following program:

 

 

 AORG >7000
 
 LIMI 0
LP1 
 MOVB @VDPST,R0
 JLT OK
 JMP LP1
OK
 MOVB R0,@>7100
 MOVB @VDPST,R0
 MOVB R0,@>7101
 RT
 
 END

 

The theory is:

-disable interrupts so the console interrupt does not interfere.

-Read the status register, waiting for the blanking bit to be set (to ensure a frame has gone by. I also tested waiting for two frames)

-If negative (bit is set), jump ahead to OK, otherwise loop back and read it again

-save the read value at >7100 (MiniMemory RAM)

-read the status register again (so I can check what bits are cleared by the read)

-save the read value at >7101

 

I then used Easy Bug to enter the program and manually set up the sprite table (which lives at >0300 in Easy Bug). I tested:

 

-4 sprites on a line and then sprite table terminated (with >D0)

-5 sprites on a line and then sprite table terminated

-6 sprites on a line and then sprite table terminated

-Two lines with 5 sprites on each line, and then sprite table terminated

-Two lines again, but with the lower indexed sprites on the lower line

 

In all cases, the 5 sprites on a line bit never set, and the "fifth sprite" value in the status register indicated the sprite index where the >D0 was. (And when the full table was present with no terminator, it reported >1F for those bits).

 

What I am asking, and there's no need to go as far as I did, was for someone to test on a 9918A, any way they like, whether they can get the five-sprites-on-a-line bit in the status register to light up. (It's value is >40). If you can, please post your test so I can try it.

 

 

 

[Asmusr]

But isn't the flag cleared every time you read the status? You have to test it after every read - not after blanking.

[Tursi]

D'oh. Yes, thank you.

[artrag]

The lower 5 bits of the status register are continuously updated during the plotting of the frame by the TMS with info on the planes being plotted.

When 5th sprite condition occurs the TMS freezes the lower 5 bits of the status register with the plane where the condition occurred an set to 1 the 5S flag.

Once you read the status register the 5S flag is reset and the lower 5 bits of the status register start again to follow the way the TMS plots sprites.

 

This means that if you read status register at the end of each frame you will get in the lower 5 bits the plane of the first time where the 5th sprite condition occurred.

If you poll the status register during the tracing of the screen you can catch multiple 5th sprite conditions.

[Tursi]

I wasn't looking for a description of behaviour but a test to characterize it.

[artrag]

	
1:	in	a,(0x99)
	and 0x5F
	cp	0x5C		; plane 28 =0x1C
	jp	nz,1b

Put 5 sprites on a line where the highest is plane 28 and this loop (on msx or coleco-vison) will wait until the raster reaches the Y of the sprite on plane 28.

I use it for screen split, in order to have two SATs active on the same screen by moving R#5 on fly.

In the example, in the upper part of the screen you can use sprites on planes 0-24 freely, in the lower part (after plane 28) you can see up to 32 sprites from a second SAT.

Edited October 8, 2014 by artrag

[Tursi]

I was characterizing the behavior of the register bits for the 5th sprite to compare the 9918A behavior against the F18A. I'm done doing so now.

 

As for raster effects, yeah. I was playing with that concept (I demoed it using the collision bit very briefly, though I think I deleted the video, and there are a number of MSX demos that use it to cool effect!) The TI response is a little slower than the Coleco, it usually takes a few scanlines, but you can still get stable results.

 

Although I don't see your example! Just 4 lines of Z80 asm. It's a neat idea to check the actual sprite number, though, that would allow you to have overlaps elsewhere without interference. I like that!

[artrag]

Look at this video (Uridium msx gameplay):

 

You will find the rom in the youtube description.
The score bar is made of 28+1 sprites, the first 24 are set 8 per line, the last 4 are the white sign, the 29th is hidden (transparent) and used to trig the screen split.

The code above is in the ISR and looks for the occurrence of a 5th sprite on plane 28 (29th sprite).

The game area has a separate sat and a spt which are switched after the polling.

 

Here follows a larger snippet from the actual code (_setVdp is a asm macro to set vdp registers)

	
	code @ 	0x0038
isr:
	push   hl         
	push   de         
	push   bc         
	push   af         
	push   iy         
	push   ix         
	
	_setVdp 5,0x37	;	SAT at 0x1b80
	_setVdp 6,0x03	;	SPT at 0x1800	(used from 0x1C00 to 0x1FF	only 32 sprites 16x16 for score bar)

[...]

	
1:	in	a,(0x99)
	and 0x5F
	cp	0x5C		; plane 28 =0x1C
	jp	nz,1b

	_setVdp 5,0x36	;	SAT at 0x1b00
	_setVdp 6,0x07	;	SPT at 0x3800	(64 sprites 16x16 for the game window)
	
[...]

	pop    ix         
	pop    iy         
	pop    af         
	pop    bc         
	pop    de         
	pop    hl         
	ei
	ret

Edited October 9, 2014 by artrag

[Asmusr]

 

You will find the rom in the youtube description.

The score bar is made of 28+1 sprites, the first 24 are set 8 per line, the last 4 are the white sign, the 29th is hidden (transparent) and used to trig the screen split.

The code above is in the ISR and looks for the occurrence of a 5th sprite on plane 28 (29th sprite).

The game area has a separate sat and a spt which are switched after the polling.

 

Here follows a larger snippet from the actual code (_setVdp is a asm macro to set vdp registers)

 

So how do you manage to call the polling routine often enough to be accurate and still get any other work done?

 

And how do you get 8 sprites on a line, is that by using a flicker routine?

[artrag]

The polling routine is in the isr and locks the cpu until the split line is reached.

Naturally the ISR, before entering in the poll cycle, does other things like update the PNT, the SAT, and some sprite definitions (this part of code is structured in order to end under any condition before the split line has been reached by the raster).

 

The 8 sprites are still as they overlap vertically on a region 8 pixel tall. This is why you see two colors on the 3 lines of text (3*8 = 24 sprites from plane 0 to 23).

The last text line instead is monochrome as it is composed by 4 sprites (planes 24-27) and it is used to trig the 5th sprite condition thanks to the transparent sprite on plane 28.

Edited October 9, 2014 by artrag